Australian cloud for business software — built and run in Sydney since 2003

+61 2 8282 5656
support@netleverage.com
Talk to an engineer
Talk to an engineer
NetLeverage
NetLeverage

Backing up EFS-encrypted files: why the restore is only half the job

Technical article
Backup & Recovery

Originally published:

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.

A file server is rebuilt after a disk failure. The file-level backup restores every folder, the job reports success, and the counts match. Then a user opens a spreadsheet and is refused access. The file is there, byte for byte. It is still encrypted, and the key that could open it was on the old server's user profile.

That is the characteristic failure of the Encrypting File System (EFS). EFS protects individual files with keys held by individual users. A backup can preserve the encrypted file perfectly. Whether anyone can read it after the restore depends on a separate set of private keys. A file-data backup may not include a usable backup of those keys; their recovery must be established separately.

This guide explains how EFS encryption and backup fit together from Microsoft's documentation, where the keys come from and where they are lost, how to find encrypted files without changing anything, and how to prove that a restored file can be opened.

Why it matters

EFS is easy to switch on. A user can turn on encryption in a folder's advanced properties, and from then on new files in that folder are encrypted. No administrator needs to be involved, and nothing about the files looks different in a backup report (our reading).

Microsoft's description of the purpose is plain: EFS "provides cryptographic protection of individual files on NTFS file system volumes using a public-key system." The stated reason is that if "a laptop that contains sensitive data is lost or stolen, the security protection of that data may be compromised." That design protects against theft, and it protects equally well against the organisation's own restore, unless the keys are managed.

Three groups of people tend to discover EFS during a recovery rather than before it:

  • Administrators restoring a server whose users encrypted folders years ago.
  • Organisations that relied on the domain's default recovery agent without knowing where its private key was kept.
  • Anyone restoring EFS-encrypted files to a different machine or account.

How it works

Two copies of one key

Microsoft's troubleshooting article explains the mechanism. EFS generates a File Encryption Key (FEK) for each file and encrypts the file with it. "The File Encryption Key (FEK) is encrypted with the EFS public key and is added to the file as an EFS attribute that is named Data Decryption Field (DDF)." To read the file, a user needs the matching EFS private key.

Where a recovery agent is configured, a second copy is made. "Every time that a file is encrypted, the FEK is also encrypted with the Recovery Agent's public key." That copy sits in the Data Recovery Field (DRF). "If you use the recovery agent's private key, you can decrypt the FEK, and then decrypt the file."

So every encrypted file can be opened by two kinds of key, and nothing else (our reading):

  • the private key of each user the file is encrypted to, and
  • the private key of each recovery agent whose certificate was in force when the file was encrypted or last updated.

Additional users can be added to a file. Microsoft lists functions to add, query and remove the user keys on an encrypted file, and cipher exposes the same operations with /adduser and /removeuser.

What can and cannot be encrypted

The File Encryption page lists items that "cannot be encrypted": compressed files, system files, system directories, root directories and transactions. "Sparse files can be encrypted." When EFS encrypts a file, "All data streams in the file are encrypted", which includes the named streams discussed in our article on NTFS file structures.

Folders are not encrypted themselves. Microsoft explains that "in an "encrypted" directory all new files in the directory are encrypted at creation." The cipher documentation adds a warning that matters during restores: "If the parent directory is not encrypted, an encrypted file could become decrypted when it is modified."

How backup software is meant to read encrypted files

A normal read supplies EFS-decrypted bytes to the backup application when the caller has the required access and decryption key; without the necessary access or key it fails. That is distinct from EFS-preserving capture. It does not establish whether the application then encrypts its backup container or repository. Ask separately how the product protects stored backup data and whether its restore options preserve EFS (Microsoft's description of normal and raw reads).

Microsoft provides the raw encryption functions for this case, and states that "Backup applications are a primary intended user for these functions." OpenEncryptedFileRaw, ReadEncryptedFileRaw and WriteEncryptedFileRaw read and write the file "leaving its data in encrypted format", including the $EFS stream that holds the DDF and DRF. If the caller does not hold the file's key, "the caller needs SeBackupPrivilege to export encrypted files or SeRestorePrivilege to import encrypted files."

The documentation is explicit on both sides:

  • On backup: "The file being backed up is not decrypted; it is backed up in its encrypted state."
  • On restore: "The file being restored is not decrypted; it is restored in its encrypted state."

The ordinary backup API is not a substitute. The page on handling encrypted files says "The encryption functions cannot be used with the Backup API", and the BackupRead page says it "is not intended for use in backing up files encrypted under the Encrypted File System."

Robocopy follows the same model. Its /efsraw option "Copies all encrypted files in EFS RAW mode." The documentation notes "The /mt parameter can't be used with the /ipg and /efsraw parameters", so multithreaded copies and raw EFS copies cannot be combined in one run.

What this means for a restore

A raw restore puts back exactly what was there: encrypted files with their DDF and DRF entries intact. The restore succeeds whether or not anyone still holds a usable key. The backup cannot tell you that the keys are missing, because it never needed them (our reading).

There is one documented edge case on the restore side. WriteEncryptedFileRaw can fail on sparse files: if a file "was backed up from a volume with a smaller sparse allocation unit size than the volume it is being restored to", the call fails with ERROR_INVALID_PARAMETER. Restoring to a differently formatted volume is therefore worth including in a test.

A non-raw copy behaves differently. CopyFile and CopyFileEx "attempt to encrypt the destination file with the keys used in the encryption of the source file", fall back to default keys, and otherwise "fail with an ERROR_ENCRYPTION_FAILED error." Copying encrypted files to a destination that cannot hold EFS, such as a non-NTFS share, will fail or require decryption (our understanding).

Where the keys are, and where they get lost

User keys

Each user's EFS certificate and private key normally live in that user's certificate store on the machine where they first encrypted a file (our understanding). Rebuilding the machine or deleting the profile can remove that local copy. Recovery may still be possible through a protected export, separately held recovery-agent keys applicable to the file, or another verified organisation-managed key recovery method. Do not assume that any of those exists without checking.

cipher /x "Backs up the EFS certificate and keys to the specified file name", either the user's current certificate or, with :efsfile, the certificates used to encrypt a particular file. The output is a PFX file protected by a password. That file is as sensitive as the data it unlocks.

Recovery agent keys

The recovery agent is the safety net. Microsoft's troubleshooting article describes its purpose as recovering data "when the copy of the EFS private key that is located on the local computer is lost."

In the historical domain arrangement described by KB 241201, the default recovery agent deserves attention. This is not a verified current-release default. Microsoft explains that "The first domain controller in a domain contains the built-in Administrator profile that contains the public certificate and the private key for the default recovery agent of the domain." The public certificate is distributed through the Default Domain Policy. The consequence follows directly: "If the Administrator profile or if the first domain controller is no longer available, the private key that is used to decrypt the encrypted files is lost, and files cannot be recovered through that recovery agent."

The page displays an update date of 12 February 2026 and the header "Applies to: Supported versions of Windows Server", but its procedure body describes Windows 2000 and Windows Server 2003 to 2008 R2, alongside older client versions. An upgraded domain might retain an older arrangement (an illustrative possibility, not a verified current default); inspect its actual policy and key custody. The quoted key-loss scenario assumes there is no surviving independent copy of the required key. The article also notes that a Windows XP computer in a workgroup "does not have a default recovery agent", which illustrates that standalone machines may have no safety net at all.

cipher /r "Generates an EFS recovery agent key and certificate, then writes them to a .pfx file (containing certificate and private key) and a .cer file (containing only the certificate)." Microsoft explains that an administrator can add the .cer file to the EFS recovery policy "and then import the .pfx file to recover individual files."

Files encrypted under an old policy

A recovery agent's key only helps for files that carry its DRF. Files encrypted before a new agent was added still carry the old agent's entry until they are updated (our reading of the cipher /u description). cipher /u "compares the user's file encryption key or the recovery agent's key to the current ones, and updates them if they have changed." Run with /n, it reports without changing anything. Changing recovery policy without updating existing files can leave a gap between what the policy says and what the files can actually be opened with.

Finding encrypted files without changing them

cipher both reads and alters encryption, so the switches matter. These are the read-only forms:

cipher /u /n

Microsoft: /u "Finds all encrypted files on the local drive(s). If used with the /n parameter, no updates are made."

cipher D:\Shares\Finance

Without switches, cipher "displays the encryption state of the current directory and any files it contains"; encrypted items are "marked with an E".

cipher /c "D:\Shares\Finance\Budget 2026.xlsx"

/c "Displays information on the encrypted file." In our understanding this includes the users and recovery certificates the file is encrypted to, which is what you need to know before relying on a recovery key.

Do not use /e, /d, /rekey, /adduser, /removeuser or /w during an audit. They encrypt, decrypt or change files, and /w "Removes data from available unused disk space on the entire volume."

A restore test that proves recovery

This is a proposed, unvalidated test for an authorised isolated lab, with synthetic files and a separate backup job using the settings under review. The aim is to establish recoverability for the tested certificate and recovery-policy generations without relying on the original profile. Qualified human review is required before adapting it to production.

  1. Prepare synthetic files representing each certificate and recovery-policy generation that matters, including older generations, not just the current policy. Record each file's expected contents or hash and its DDF user and DRF recovery-agent certificate identifiers, using cipher /c information and the certificate inventory. If a historical generation cannot be represented, record it as untested.
  2. Confirm that the lab source and destination support NTFS/EFS and that the test accounts have the expected ordinary file permissions. Keep protected key originals retrievable in approved custody before importing any temporary copies.
  3. Back up the synthetic files with the separate test job and restore the chosen recovery point to a separate lab destination with no pre-existing test-user keys. Record the product version and capture and restore options.
  4. Confirm that the restored files retain EFS, and compare their recorded certificate identifiers with the expected DDF/DRF coverage.
  5. In a clean recovery-agent trial, import only the applicable recovery-agent key copy into the authorised recovery account. Confirm access permissions, open each applicable file and compare its decrypted contents or hash with the synthetic original.
  6. In a separate clean user-key trial with no recovery-agent key present, import only the applicable test-user key copy and repeat the content checks. Record successes and failures for each generation independently.
  7. After confirming that the protected originals remain retrievable, remove only the temporary imported key copies from the lab accounts under the approved cleanup procedure. Never delete the sole surviving key copy.

A failed open requires investigation of key coverage, ordinary permissions, NTFS/EFS support, file integrity and restore settings; it does not identify a single cause. A file restored without EFS fails the EFS-preservation test and also needs investigation. That observation alone proves neither which capture API was used nor whether the backup repository stores plaintext. Verify repository encryption and restore-time decryption separately.

Worked example (illustrative)

The following is invented to show the pattern. A legal practice runs a single domain created in 2009. Several partners encrypted their working folders on the file server years ago. The domain controller that first created the domain was replaced in 2015.

The file server's system disk fails and the server is rebuilt from scratch. File-level restores complete overnight. In the morning, three partners cannot open any of their files. Their user certificates were in profiles on the old server, which no longer exist.

The IT provider turns to the recovery agent. cipher /c on a restored file shows the DRF is for the domain's default recovery agent. That agent's private key was in the Administrator profile on the first domain controller, which was decommissioned. Nobody exported it.

In this invented scenario, neither the user keys nor another usable key copy survives, so the intact encrypted files remain unreadable. An earlier isolated test covering the historical certificates could have exposed the custody gap while the files were still decryptable. A reviewed policy change and verified key custody could then have protected future recovery. Creating a new recovery agent after all applicable old keys are lost does not unlock those old files.

Risks and limits

  • The recovery agent troubleshooting page has a current supported-Windows-Server header and a 12 February 2026 update, while its procedure body describes older releases. Do not infer current domain defaults from that historical procedure; confirm your own policy and available keys.
  • A PFX file of a recovery agent opens every file encrypted to it. Store it offline, protect it with a strong password, and control who can retrieve it. Losing it is a recovery problem; leaking it is a confidentiality problem.
  • Normal reads provide EFS-decrypted bytes to the application. Backup-container encryption and restore-time handling are separate controls: verify both rather than inferring storage encryption from the capture method or a restored file.
  • EFS is separate from BitLocker, which encrypts whole volumes. BitLocker recovery keys are a different custody question and are not covered here.
  • Third-party backup products' handling of EFS is outside these sources. Ask the vendor whether they use the raw functions, and test.
  • This guide gives no steps that change encryption on production data. Changing recovery policy or updating existing files should be planned and tested separately.

Sources

All accessed 14 November 2026.

Related future topics

  • What a Windows file copy can miss: streams, links, placeholders and long paths
  • Restoring a Windows user profile: what file restores do not bring back
  • SQL Server backup encryption and certificate custody

This article was originally published on .