It is a Windows account designated in advance as able to decrypt files encrypted by anyone else in the domain. Configured beforehand it saves organisations regularly. Not configured, it cannot be added afterwards.
A DRA works because its certificate was attached to files at the moment they were encrypted. Creating one later does nothing for files that already exist.
The Encrypting File System has been in professional editions of Windows for years, encrypting individual files and folders using a key tied to the user account. It is transparent in use — the owner opens files normally — and it is invisible enough that many people encrypt data without realising it, usually via a green filename in Explorer.
The catch is what happens when the account goes away. A user leaves and the profile is deleted, a machine is rebuilt, a password is reset by an administrator rather than changed by the user — and the files become unreadable to everyone, including domain administrators. That is the problem a DRA exists to solve.
When a DRA is configured through Group Policy, its public certificate is attached to every file encrypted from that point onward, alongside the user’s own. The file therefore has two ways in. If the original account becomes unavailable, the DRA’s private key opens it.
The crucial consequence is temporal: this only applies to files encrypted after the policy existed. Configuring an agent today does nothing for anything encrypted yesterday, because the certificate was never attached to those files. There is no retrospective route.
Without a DRA and without the original user’s key, EFS files cannot be decrypted. Not by us, not by Microsoft, not by any recovery firm — the encryption is sound and the key is genuinely absent. Anyone claiming otherwise should be treated with suspicion.
What is worth checking before accepting that: whether the original user profile still exists on any machine or backup, whether the EFS certificate was ever exported to a .pfx file (Windows prompts for this at first use and people sometimes complied), whether a system-state or profile backup predates the loss, and whether a domain controller holds an archived copy.
Where the drive holding EFS-encrypted data has failed, recovery of the drive itself is straightforward — it is imaged read-only and the file system rebuilt, from £300 +VAT after a free 48-hour diagnostic. Recovering the user profile and certificate store from that image is often the route back in, because the key material may be recoverable even when the machine is not.
What we cannot do is break the encryption itself, and we will say so at the diagnostic rather than after an invoice.
An account designated in Group Policy as able to decrypt EFS-encrypted files belonging to other users. Its certificate is attached to every file encrypted after the policy is set, giving a second way in if the original account becomes unavailable.
No, and they are often confused. EFS encrypts individual files and folders and is what a DRA covers; BitLocker encrypts whole volumes and uses a 48-digit recovery key. A DRA does nothing for a BitLocker-locked drive.
No. The agent’s certificate is attached at the moment of encryption, so a policy created today applies only to files encrypted from today onward. There is no retrospective route for existing files.
No. The encryption is sound and without the user’s key or a pre-configured agent the files cannot be decrypted by anyone. Before accepting that, check for an exported .pfx certificate, surviving user profiles, older backups, and any archived copy on a domain controller.
The drive, yes — it is imaged read-only and the file system rebuilt, from £300 plus VAT after a free 48-hour diagnostic. Recovering the user profile and certificate store from that image is frequently the route back in. Breaking the encryption itself is not something anyone can do.