The original user profile
If it still exists on the machine, the certificate and private key are in the profile’s crypto store. A rebuilt or deleted profile is what usually breaks this.
First place
Windows EFS encrypts files against a user’s own certificate. A Data Recovery Agent is a designated account holding a second key that can decrypt those files — and it is configured in advance or not at all.
A DRA works because its certificate was bound to files at the moment they were encrypted. Setting one up afterwards does precisely nothing for anything that already exists.
Distinct from BitLocker, and confused with it constantly.
BitLocker encrypts a whole volume and unlocks it at boot. Encrypting File System works differently: it encrypts individual files and folders, and it does so against the certificate of the user who encrypted them.
Mechanically, each file gets a randomly generated symmetric key — the File Encryption Key — which is what actually encrypts the contents. That key is then itself encrypted with the user’s public key and stored in the file’s header. Opening the file means decrypting the FEK with the user’s private key, then decrypting the contents with the FEK.
Which produces the problem: lose access to that user’s private key — a deleted profile, a rebuilt machine, a departed employee, a corrupted certificate store — and the files are unreadable even though they are sitting there in plain view with normal filenames.
Configured in advance, and invisible until needed.
Where a Data Recovery Agent is configured, EFS encrypts each file’s FEK a second time — with the recovery agent’s public key — and stores that alongside the first. Either private key can therefore decrypt the file.
On a domain, the DRA is typically established through Group Policy and assigned to a designated administrator account, with the certificate exported and stored securely offline. The critical property is that it must exist before the files are encrypted: EFS writes the recovery key into the header at encryption time, so designating an agent afterwards does nothing for files already encrypted.
That is why so many organisations discover the gap at exactly the wrong moment. The mechanism works well and it is entirely preventative.
Before concluding anything is lost.
If it still exists on the machine, the certificate and private key are in the profile’s crypto store. A rebuilt or deleted profile is what usually breaks this.
Windows prompts users to back up their EFS certificate. Those .pfx files turn up on USB sticks and in document folders more often than expected.
On a domain, check whether a recovery agent policy was ever applied and whether the certificate was archived. IT may hold it without realising what it is.
Older backups may contain the profile and its certificate store even where the live machine no longer does.
Stated plainly, because this is one of the genuine dead ends.
Without the user’s private key or a recovery agent’s, EFS-encrypted files cannot be decrypted. The cryptography is sound and there is no analysis of the file that reveals the key.
What can sometimes be attacked is the password protecting the key store, and we run professional password recovery for exactly that — GPU-accelerated, guided by whatever the owner can recall. It succeeds on short, reused or partly-remembered passwords and fails against a long random one. We will tell you honestly which position you are likely in at the free diagnostic rather than after an invoice.
And where the underlying drive has also failed, the recovery is a separate problem solved first: the volume is imaged read-only and the encrypted files extracted intact, ready to decrypt as soon as a key is found. Encrypted-drive work is £800 +VAT flat after a free 48-hour diagnostic.
A Windows account designated in advance to decrypt EFS-encrypted files it did not encrypt. EFS stores a second copy of each file’s encryption key against the agent’s certificate, so either the original user or the agent can open the file.
BitLocker encrypts a whole volume and unlocks at boot. EFS encrypts individual files against a specific user’s certificate, so files stay encrypted even to other users on the same unlocked machine.
No, and this is the trap. EFS writes the recovery key into each file’s header at encryption time, so designating an agent afterwards does nothing for files already encrypted. It has to exist beforehand.
Look for the private key: the original profile if it survives, an exported .pfx backup, an archived DRA certificate in Active Directory, or an older system backup containing the profile. Those four resolve most of these.
Not the cryptography. What can sometimes be attacked is the password protecting the key store, using professional password recovery — effective on weak, reused or partly-remembered passwords and not against a long random one.
That is solved first and separately. The volume is imaged read-only and the encrypted files extracted intact, ready to decrypt the moment a key is located. Encrypted-drive work is £800 plus VAT flat after a free diagnostic.