"No valid encryption recovery policy" error 0x1773 on domain-joined Windows 10/11

You're on a Windows 10 or 11 machine that's joined to an Active Directory domain. You try to enable BitLocker or encrypt a file with EFS (Encrypting File System). Right after you hit Apply, a dialog pops up: "There is no valid encryption recovery policy configured for this system. (0x00001773)". The drive never gets encrypted.

This error hits most often right after a domain join, or after an admin pushes a new Group Policy that accidentally clears the recovery policy. It can also show up if someone mucks with the local security policy or deletes the recovery agent certificate.

What causes error 0x1773?

The short version: Windows needs a backup plan. When you encrypt data, the system demands a valid recovery agent or recovery key. If that policy is missing—maybe the domain GPO doesn't define one, or the local policy is empty—Windows flat-out refuses to encrypt. It's a safety guard. Without it, if you lose your password or key, your files are gone forever.

The policy lives in Group Policy under Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Encrypting File System for EFS, or under BitLocker Drive Encryption for BitLocker. If that policy is undefined or set to "do not allow," you get 0x1773.

How to fix it

Step 1: Check your recovery policy

1. Press Win + R, type secpol.msc, and hit Enter. This opens Local Security Policy.
2. In the left pane, expand Public Key Policies.
3. Click Encrypting File System.
4. In the right pane, look for a certificate listed under Recovery Agents. If it's empty, you've found the problem.

Expected outcome: You'll either see a certificate (good) or nothing (broken).

Step 2: Add a recovery agent (domain environment)

If you're on a domain, this is the right fix. Your domain admin needs to do this once.

1. On a domain controller or a machine with RSAT, open Group Policy Management Console.
2. Edit the GPO that applies to the affected machines.
3. Go to Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies.
4. Right-click Encrypting File System, choose Add Data Recovery Agent.
5. Follow the wizard. It will find any EFS recovery agent certificate from your CA. If you don't have one, create one first (see next step).
6. After adding, close the GPO and run gpupdate /force on the affected client.

Expected outcome: After gpupdate, the recovery agent certificate shows up in secpol.msc under Encrypting File System.

Step 3: Create a recovery agent certificate (if you don't have one)

If your CA doesn't have a recovery agent template, you need to make one.

1. Open Certification Authority on your CA server.
2. Right-click Certificate Templates, choose Manage.
3. Find the EFS Recovery Agent template. If it's not there, duplicate a template that allows key recovery, set the purpose to "File Recovery."
4. Right-click the template, choose Properties, check the Recovery Agent checkbox.
5. Publish the template to the CA.
6. On the CA, issue the certificate to a designated recovery admin.
7. Export the certificate with the private key as a PFX, store it offline securely.

Expected outcome: You now have a valid recovery agent certificate that can be added to GPO.

Step 4: Local machine fix (non-domain)

If the machine isn't on a domain, you can create a self-signed recovery agent cert.

1. Open an admin Command Prompt or PowerShell.
2. Run:

   cipher /r:recovery_cert

3. You'll be prompted for a password to protect the PFX file. Choose something you'll remember and store it safe.
4. This creates two files: recovery_cert.cer and recovery_cert.pfx.
5. Now open secpol.msc again, go to Public Key Policies > Encrypting File System.
6. Right-click, choose Add Data Recovery Agent, browse to the .cer file, finish the wizard.

Expected outcome: The certificate appears in the recovery agents list.

Step 5: Force policy refresh and test

1. Run gpupdate /force in an admin command prompt.
2. Reboot the machine.
3. Try encrypting a test file: right-click > Properties > Advanced > Encrypt contents to secure data. Click OK and Apply.

Expected outcome: No error. The file encrypts and you see a lock icon. You can also try BitLocker on a USB drive—it should now work.

What if it still fails?

Check these three things in order:

• GPO inheritance: Is another policy overriding or removing the recovery agent? Run gpresult /h report.html and look for EFS or BitLocker policies. If you see "not defined" or "disabled," that's the culprit.
• Certificate trust: The recovery agent certificate must be trusted by the client machine. If it's from a CA that isn't in the client's Trusted Root store, the policy won't apply. Check certlm.msc > Trusted Root Certification Authorities.
• Corrupt policy cache: Run del %windir%\System32\GroupPolicy\Machine\Registry.pol (as admin), then re-run gpupdate /force. This forces a fresh download of policies.

If none of that works, you can manually set the registry key that defines the recovery policy. Go to HKLM\SOFTWARE\Policies\Microsoft\Windows NT\CurrentVersion\EFS, create a DWORD named EfsConfiguration with value 1. This allows encryption without a recovery agent on a standalone machine. But for domain machines, fix the GPO instead.