Fix ERROR_NO_USER_KEYS (0x1776) EFS Missing Keys

EFS can't find your encryption keys. You'll need to back up the old profile's keys or start fresh with a new certificate. This usually happens after a Windows profile rename or domain migration.

Quick answer

Back up the old user profile's EFS certificate and private key via certmgr.msc or cipher /x, then import it into the current profile. If you don't have the old profile, you're locked out permanently—move on and create a new encryption certificate.

Why this happens

EFS ties every encrypted file to a specific user's certificate and private key. That key lives in your profile under AppData\Roaming\Microsoft\Crypto\RSA and in the registry under HKCU\Software\Microsoft\Crypto\RSA. When you rename a Windows user account, migrate to a new domain, or restore a profile from another machine, the SID changes. Windows then looks for a key under the new SID, finds nothing, and throws 0x00001776.

What's actually happening here is that the encrypted files still reference the old key, but the current user context doesn't have access to it. The error isn't about file corruption—it's about identity. The system is telling you: "I know these files are encrypted, but I have no key for the person you are now."

Fix 1: Recover the key from the old profile

Log into a separate administrator account (or use a bootable recovery tool if you can't).
Navigate to the old profile folder, usually C:\Users\OldUsername. If the profile was deleted, check C:\Users\OldUsername\AppData\Roaming\Microsoft\Crypto\RSA for any files—those are your key containers.
Copy the entire RSA folder to a USB drive. You'll also want AppData\Roaming\Microsoft\Crypto\Keys if it exists (that's where CNG keys live).
Log back into the affected account, open certmgr.msc, right-click Personal > All Tasks > Import. Choose the copied files—if they're not a .pfx, you may need to use cipher /x from the old profile before it's gone.
If you still have access to the old profile (even temporarily), run cipher /x:C:\backup.pfx from that account. It prompts for a password and exports both certificate and private key. Then import that .pfx into the new profile.

Fix 2: If the old key is gone

If the old profile is unrecoverable, stop wasting time. There is no backdoor into EFS—by design. The only option is to decrypt what you can with a recovery agent (if an admin set one up) or give up on those files.

Check if a data recovery agent (DRA) exists: run cipher /rekey as admin, or check secpol.msc > Public Key Policies > Encrypting File System. If a DRA is listed, you can decrypt any file with that agent's key.
If no DRA, you'll need to delete the encrypted files or restore them from backup after re-encrypting.

Alternative fix: Start fresh

If you don't care about the old encrypted data, the cleanest path is to force a new EFS certificate. Open an elevated command prompt and run:

cipher /generate:EFS

That creates a new self-signed certificate for the current user. After that, encrypting new files works—but old encrypted files remain unreadable unless you import the old key.

Prevention tip

Back up your EFS key before you change anything. On a regular basis, run certmgr.msc, right-click your EFS certificate (the one with the "Encrypting File System" purpose), and export it as a .pfx with a strong password. Store it somewhere safe—not in the same folder as the encrypted files. If you're about to rename a user or migrate domains, export the key first. That single step saves you from this exact error.

Note: Windows 11 22H2 and later show a clearer error message, but the underlying cause is unchanged. EFS has been this way since Windows 2000—it's not a bug, it's a feature of the trust model.