Windows EFS: Recovery Agents, Key Backup, and Safe Migration

Windows Encrypting File System (EFS) protects individual files on supported NTFS volumes. It is not the same control as BitLocker, which protects a volume when it is offline, or DPAPI, which lets an application protect data under a Windows user or machine context. EFS is a file-access feature with its own certificates, recovery policy, backup behavior, and migration requirements. That makes key custody and restore testing part of the deployment - not an afterthought once a user can open the file.

First verify that the exact Windows edition, volume, and workload support the operation. Microsoft’s Win32 documentation describes EFS for files on NTFS and notes that particular file classes and locations cannot be encrypted. Do not assume that a filesystem being writable implies EFS support, or infer support from the green overlay icon in Explorer. Keep BitLocker or another whole-volume control in the design when the threat is theft of the powered-off device; EFS alone is not a substitute for protecting system data and free space.

Understand the keys attached to a file

EFS encrypts a file’s contents using a file encryption key (FEK). The FEK is protected for an authorized user’s EFS certificate and recorded with the file’s EFS metadata. Where a data recovery policy applies, a protected copy is also associated with the configured recovery agent. The user must possess the corresponding private key to recover the FEK and decrypt the file; a recovery agent’s private key provides a separate recovery path when policy and file metadata permit it.

This is why copying the file’s bytes without its EFS metadata - or keeping the data while losing every relevant private key - can leave a technically intact file that nobody can decrypt. Conversely, a backup process that reads a file through normal I/O while running as an authorized user may receive plaintext, not the original encrypted representation. Microsoft provides raw EFS backup APIs specifically so backup software can preserve encrypted data streams and the $EFS stream without needing the decryption key. Choose the backup mode intentionally and record whether the recovery design expects encrypted restoration or plaintext restoration under a controlled service identity.

Inventory before changing policy

Before a migration, change to a recovery policy, or user departure, identify the files that actually have EFS attributes and the certificates associated with them. The cipher utility can inspect a file with /c, show encryption state, export current EFS certificate and key material with /x, and generate recovery-agent certificate/key files with /r. It also supports adding or removing a user’s certificate from specified encrypted files. These commands are powerful scope controls: recursively applying an option to a broad directory can change many files, so start with a known disposable test directory and review the exact output.

For a focused inventory, record the hostname, Windows build and edition, filesystem type, file path, encryption state, certificate thumbprint, user or service identity that opens the file, and any policy-derived recovery agent. A successful interactive read proves only that the current security context can decrypt that copy. It does not prove that a backup contains the required EFS metadata or that a replacement machine has a usable private key.

Example inspection on a test file:

cipher /c C:\EfsLab\sample.txt
cipher /x C:\EfsLab\user-efs-backup

The export contains private key material. Protect it as a secret: restrict access, transfer it over an approved channel, store an offline or separately controlled copy, and document who can authorize its use. Never check the .pfx file into source control or attach it to a support ticket. A generated recovery-agent .cer is public-key material for policy distribution; the matching .pfx contains the private key and must not be treated as an ordinary certificate file.

Make recovery a tested role, not a dormant file

A recovery-agent design separates routine user access from exceptional recovery. Generate or obtain the intended recovery certificate, validate its subject and thumbprint, configure it through the applicable recovery policy, and preserve the matching private key under dual-control or another documented custody model. Do not place the recovery private key on every workstation simply because users need the public recovery certificate to be available through policy.

Run a recovery drill using a disposable encrypted file. Confirm that the intended user can read it, then confirm that an authorized recovery operator can recover a copy on a separate test system using the approved recovery procedure. Preserve the original fixture and record which key was used. If recovery succeeds only because the original user’s profile is still loaded on the test machine, the drill did not prove the data recovery agent path.

Keep the recovery key available for the retention period of every file that depends on it. Removing an agent from policy or rotating the certificate does not magically rewrite every old file. Inventory the affected data, use supported rekey or certificate-management operations when appropriate, and retain the prior private key until old backups and files have been migrated or deliberately retired. Do not destroy a key based only on a directory listing or a successful test against one recent file.

Select the correct backup representation

Ordinary file reads transparently return plaintext to a caller that has the required access and key. That behavior is convenient for applications but can surprise a backup engineer: a backup made through generic CreateFile and read calls may hold plaintext. Microsoft’s raw EFS API path - OpenEncryptedFileRaw, ReadEncryptedFileRaw, and the corresponding write/close calls - exists to export and restore encrypted files, including EFS metadata. The API documentation notes that backup or restore privileges are required for raw access when the process does not possess the file’s key.

Before using a backup product, ask its vendor whether the specific Windows agent and destination preserve EFS ciphertext and metadata, or intentionally decrypt data during backup. Test a real restore to a clean lab identity. Verify both file content and the expected encryption state, then confirm that the intended user or recovery agent can open it. A backup that reports success is not proof of a successful EFS recovery path.

Migrate with USMT deliberately

Microsoft’s User State Migration Tool documents explicit /efs behavior for ScanState, including choices to abort, skip, decrypt-copy, copy raw data, or hard-link encrypted files. The default is to fail when it encounters encrypted data unless an /efs option is selected. Choose the mode from the migration’s security and destination requirements; do not copy a generic USMT command from another environment. Microsoft also warns that files inside an encrypted folder should have consistent encryption state, or that the folder’s encryption attribute should be removed before migration, to avoid destination behavior that depends on the account running LoadState.

For a staged migration, make an inventory, select the explicit /efs mode, export required user and recovery key material securely, migrate a test profile, and validate both user and recovery access on the destination. Include mixed encrypted/unencrypted folders, an unavailable user certificate, and a missing recovery key in negative tests. If the migration intentionally decrypts copies, document the destination’s protection control and the exact point at which plaintext exists; do not describe that result as an encrypted-preserving migration.

Acceptance criteria for an EFS deployment

Before relying on EFS for data with a recovery requirement, require evidence for all of the following:

The target Windows edition, NTFS volume, directory, and file types support the intended operation.
The primary user certificate is backed up and the private key is recoverable under the documented identity process.
The recovery-agent public certificate is applied where required, and its private key has separate, tested custody.
The backup product’s plaintext-versus-raw-encrypted behavior is known, and a restore test succeeds with the intended keys.
The migration plan explicitly selects and validates its USMT /efs behavior.
Key retirement waits until active files, offline copies, and retained backups no longer depend on the old certificate.

EFS can solve a per-file access problem, but its security depends on certificate lifecycle and the behavior of every copy, backup, and migration path. Keep it distinct from volume encryption and application-secret protection, and treat key custody as operational infrastructure. If the organization cannot maintain a tested recovery path, do not newly classify EFS as the only safeguard for irreplaceable data.

Related:

Sources: