An engineer encrypts the R&D team's design files using her personal encryption certificate. She leaves the company, and her laptop is reimaged the following week. The files are still on the file server, intact and permanently unreadable, because the only copy of the private key that could decrypt them was on the laptop.
On the CompTIA Security+ SY0-801 exam, objective 1.3 lists key escrow alongside public and private keys as part of choosing the right cryptographic solution, and certificate errors are where every PKI concept shows up in daily work. This lesson covers how key escrow and key recovery work, which keys belong in escrow and which never do, and then the six certificate errors you'll meet most: what each looks like in a browser and in OpenSSL, and how to fix it.
Key escrow keeps a recoverable copy of the keys that protect data
Key escrow means storing a copy of a key with a trusted party, the escrow agent, so the key can be recovered under defined conditions. The agent might be a dedicated system run by the security team or an outside organization. Key recovery is the process of getting the key back out.
Organizations escrow keys because encrypted data is only as available as its key. An employee leaves or dies, a smart card is lost, a laptop is reimaged, or a legal hold requires the company to read years of encrypted email. Without a recoverable copy of the key, each of those turns into permanent data loss.
In a Microsoft PKI, escrow is called key archival. An administrator enables archival on the certificate template used for encryption certificates and designates key recovery agents (KRAs), people who hold special recovery certificates. When a user enrolls, the client sends an encrypted copy of the private key to the CA, which stores it in its database encrypted to the KRA certificates. Recovery takes two steps that can be split between two people:
certutil -getkey 3a9f0c21d45e7b10 recovery.blob
certutil -recoverkey recovery.blob jsmith-encryption.pfx
The first command, run by a CA officer, pulls the encrypted key out of the CA database by certificate serial number. The second can only succeed for someone holding a KRA private key, and it produces a password-protected PKCS #12 file that restores the user's key.
You'll meet the same idea outside certificates. BitLocker recovery passwords are commonly backed up to Active Directory or Microsoft Entra ID, and macOS FileVault recovery keys can be escrowed to the device management service. In each case the organization keeps a copy of a key that unlocks data.
An escrow store is also one of the most valuable targets in the company, since it can unlock everything it holds. Protect it with separation of duties, so the person who extracts a key isn't the person who decrypts it. Use dual control or M-of-N schemes, often enforced by an HSM, which require several people to cooperate. Require a documented approval, such as a ticket signed off by HR or legal, before any recovery, and log and review every recovery. On the exam, "ensure no single administrator can recover a user's key" points to dual control or M-of-N control.