---
title: "Disk encryption recovery keys"
description: "How Outpost stores BitLocker and FileVault recovery keys before it encrypts a drive, and how to reveal a key for a locked-out endpoint."
url: "https://support.outpostplatform.com/compliance/recovery-keys/"
product: "depot"
type: "how-to"
status: "draft"
ai_summary: "BitLocker (Windows) and FileVault (macOS preview) recovery keys are escrowed to the Depot when the agent encrypts a drive under a profile, and the agent does not finish encrypting until the key is stored. Reveal one under the endpoint's Security > Recovery keys tab with bitlocker:reveal (Owner only by default). Each reveal is audited before the key is decrypted."
availability:
  plans: ["home-lab", "essentials", "enterprise", "msp"]
  platforms: ["windows", "macos"]
  permission: "bitlocker:reveal"
  preview: false
source: "https://gitlab.com/outpostplatform/docs/-/edit/main/src/content/docs/compliance/recovery-keys.md"
license: "CC BY 4.0"
---

# Disk encryption recovery keys

When Outpost encrypts a drive, it stores the drive's recovery key first. If an
endpoint later asks for its recovery key, for example after a firmware update
or a hardware change, you reveal the key from the console and read it to the
person at the keyboard. This page explains when keys are stored and how to
reveal one.

## When keys are stored

| Platform | Encryption | Key stored |
| --- | --- | --- |
| Windows | BitLocker, managed by the `encryption.*` profile settings, on endpoints with a usable TPM. | The BitLocker numerical recovery password for each encrypted volume. |
| macOS (Preview) | FileVault, turned on by `encryption.macos_require_filevault`. Outpost turns it on the next time a user with a secure token signs in, or at once when the managed administrator account holds a secure token. | The personal recovery key of the startup disk. |
| Linux | LUKS is reported only. Outpost never encrypts a Linux volume. | None. |

On Windows, the BitLocker recovery password exists before the drive is
encrypted, so the agent sends it to Outpost first and encrypts only after
Outpost confirms it is stored. On macOS, FileVault creates its recovery key at
the moment it turns on, so the agent sends the key straight afterwards and
keeps a protected copy on the Mac until Outpost confirms it is stored. In both
cases, until Outpost has the key, the compliance pages show the encryption
control as **Not measured** with the reason **waiting on a recovery key to be
escrowed**.

`encryption.escrow_recovery_key` controls whether keys are stored. It is on by
default, and if any applicable profile turns it on, it stays on. Every enforced
framework baseline sets it as a floor. See
[Baseline settings by framework](/compliance/framework-settings/).

A reimaged endpoint can list keys from more than one encryption.

## Before you begin

- Seeing which keys are stored needs `bitlocker:read`. Revealing a key needs
  `bitlocker:reveal`. Among the built-in roles, only the Owner holds
  `bitlocker:reveal`. See [Roles and permissions](/depot/roles-and-permissions/).
- Revealing a key is recorded in the audit log with your name before the key
  is decrypted. Cancel at the confirm step if you opened it by mistake.
- Anyone who has the key can unlock the drive on any computer. Read it only to
  the person who needs it, and do not store it elsewhere.

## Reveal a recovery key

1. Select **Endpoints** and open the endpoint.
2. Select **Security** > **Recovery keys**. The table lists each stored key
   with its **Volume**, **Protector** ID, and the time it was **Escrowed**.
3. Find the key. For BitLocker, the person at the endpoint can read you the
   key ID from the recovery screen. Match it with the **Protector** column. A
   FileVault key is listed as **Startup disk**.
4. Select **Reveal key**. The console asks you to confirm: **Revealing this
   key is recorded in the audit log with your name.**
5. Select **Reveal it**. The key appears, with **This reveal was logged.
   Audit entry** and the entry number.
6. Select **Copy** to copy it, or read it out.
7. Select **Hide** when you are done. Leaving the page also removes the key
   from the screen.

## Verify

The endpoint accepts the key and starts. In **Settings** > **Audit logs**,
the **Console actions** record shows the reveal, with your name and the audit
entry number the console showed. See [Audit logs](/depot/audit-log/).

## If something goes wrong

| Symptom | Cause | Fix |
| --- | --- | --- |
| **You do not have permission to view recovery keys for this endpoint.** | You do not hold `bitlocker:read`. | Ask an owner for access. |
| **Reveal key** is unavailable, with **You do not have permission to reveal recovery keys.** | You do not hold `bitlocker:reveal`. | Ask an owner to reveal the key. |
| **No recovery keys escrowed for this endpoint.** | No key has arrived. Keys arrive when the agent encrypts a volume under a profile that asks for escrow. | Outpost cannot reveal a key it never received. If the drive was encrypted some other way, recover the key from wherever that process stored it. |
| The control shows **waiting on a recovery key to be escrowed** for a long time | The endpoint cannot reach Outpost, or Outpost did not confirm the key. | Check that the endpoint is online. The agent sends the key again, and the control is measured once the key is stored. |

## Next steps

- [Rotate local administrator passwords](/compliance/local-admin-rotation/)
- [Review compliance posture](/compliance/compliance-overview/)