BitLocker Management

Athena manages BitLocker drive encryption on your Windows endpoints. It shows every machine's encrypted volumes and stores each machine's recovery passwords automatically. An operator can reveal a recovery password with a reason, and every reveal is audited. You define encryption policies, assign them to agents, collections or tags, and turn on enforcement to have agents encrypt their OS drive. Athena can also rotate recovery passwords on a schedule and publish a Compliance baseline. Recovery passwords are stored on your own Athena server, so all of this works on an air-gapped network.

Where BitLocker appears#

• Agent details → BitLocker, the tab after Sysmon. It shows one machine's Effective policy and override, its Enforcement status (with Re-evaluate and, when needed, Provide PIN), its Startup PIN line (TPM + PIN policies only), its volumes, and its Recovery keys (with Reveal and the rotate-key icon). While the tab is open it updates by itself.
• Policies → BitLocker (/policies/bitlocker), in the Policies group of the left navigation, headed BitLocker policies. Until October 2026 this was the Policies → BitLocker tab; old /settings/bitlocker bookmarks still redirect for one release. It has the Enforcement master switch, Recovery password rotation, the Compliance baseline switch, the Policies list, the Assignments list and a Fleet enforcement summary.

Permissions

BitLocker has five permissions. The built-in Admin role has all of them. View BitLocker and Reveal BitLocker startup PINs are also given to the built-in Helpdesk and Operator roles, so help-desk staff can open the BitLocker tabs and read a machine's startup PIN to a user at the pre-boot prompt. Manage BitLocker is also given to Operator, so operators can change policies. Revealing recovery passwords and Decrypt stay Admin-only by default. Roles can't be edited in this release, so to give someone a permission, give them a role that holds it. See Roles & Permissions.

Volume inventory#

Each Windows agent reports its OS and fixed data volumes every time it connects to the server, and continuously while someone has its BitLocker tab open (see Live updates while the tab is open). To ask a connected agent for a fresh report, click the refresh button on its BitLocker tab (Request current BitLocker volume status from this agent). If the agent is offline, the tab says so and keeps showing the last report it received. For each volume the tab shows:

• the mount point, the volume type (Operating system or Fixed data volume) and the capacity;
• Conversion status: Fully encrypted, Fully decrypted, Encryption in progress, Decryption in progress, Encryption paused or Decryption paused;
• Encrypted percentage and Encryption method (for example XtsAes256);
• protection (Protection on, off or unknown) and lock state;
• Key protectors (for example Tpm, TpmPin, RecoveryPassword) and, on data volumes, auto-unlock;
• readiness: BitLocker capable or Not BitLocker capable.

A machine is BitLocker capable only when BitLocker is available on it and it has a TPM. A Windows edition without BitLocker, or a machine without a TPM (many virtual machines), is Not capable. Athena never sends an encryption request to a Not capable machine, and those machines are never counted as drift. If a collection fails, the tab shows Last collection failed: with the error and time.

Live updates while the tab is open

You don't need to reload the page to watch an encryption or decryption. While an agent's BitLocker tab is open, Athena switches that agent into live mode:

• the agent checks its BitLocker status every 3 seconds and reports only when something has changed. The first check is always reported, so the tab starts with fresh data. A volume that isn't changing sends nothing;
• each report updates the whole tab: the volumes (encrypted percentage, conversion status, protection), the Enforcement status and the Recovery keys list. A key that was escrowed during an encryption appears, and a key that was removed disappears;
• live mode stops when the last person viewing that agent's BitLocker tab leaves it, switches to another tab, or closes the browser. If several people have the same agent open, it keeps running until all of them have left;
• if the agent reconnects while someone still has the tab open (for example after a reboot during encryption), live mode starts again automatically.

The refresh button still works as before: it asks the agent for a report now. The toast says "Status requested. The tab updates as soon as the agent answers." and the tab updates when the answer arrives. If the agent is not connected you see "This agent is not connected. Showing the latest available report."

Recovery-key escrow#

Whenever an agent connects, it also sends the recovery passwords (the 48-digit numerical passwords) of every recovery-password protector on its OS and fixed volumes. The server stores each one encrypted. This escrow happens whether enforcement is on or off. It also happens after Athena enables BitLocker or rotates a key. Recovery passwords are never written to logs or audit entries.

The Recovery keys section of the agent's BitLocker tab lists each escrowed protector with its Escrowed: date and Last verified: date. Last verified updates each time the agent reports the same protector again. When an agent's full check-in no longer includes a protector (for example, someone removed it on the machine), Athena deletes its stored key. A volume with nothing escrowed shows No recovery key escrowed.

Keys are grouped by drive letter, newest first. The Reveal button for a volume's current (newest) key sits on the drive-letter row. Older keys that are still escrowed keep their own Reveal on their own line. The rotate-key icon on the Recovery keys title row starts a rotation.

Revealing a recovery password

1. Open the agent's BitLocker tab and click Reveal next to the protector.
2. Enter a Reason, for example a help-desk ticket number. It must have at least 3 visible characters (INC-1 passes, ok does not). Only the first 500 characters are kept.
3. Click Reveal key. The recovery password appears with a Copy button. It hides automatically after 30 seconds.

The bitlocker.key-revealed audit entry is written before the key is shown. It records who, which agent, volume and protector, and the reason, but never the password itself. If the audit entry cannot be written, the key is withheld. Refused reveals (no reason, no escrowed key, a key that cannot be decrypted) are audited as bitlocker.key-reveal-failed. The REST response carrying a key is marked Cache-Control: no-store.

Policies#

A policy describes the BitLocker state you want. Create one in Policies → BitLocker → Policies → New policy.

Deleting a policy also removes its assignments.

Assignments and priority

An assignment links a policy to a target: an Agent, a Collection or a Tag. Assignments are evaluated top to bottom - the first assignment whose target contains the agent wins, like firewall rules. A new assignment goes to the bottom (lowest priority). Use the Raise priority and Lower priority arrows to reorder.

• An assignment whose policy is disabled is skipped. Its agents fall through to the next matching assignment, or become unmanaged if nothing else matches.
• An assignment to a collection that was later deleted matches no one.
• You can assign a tag that no agent has yet. It takes effect when agents get the tag.

Per-agent overrides

On an agent's BitLocker tab, the Effective policy panel shows the policy that applies and which assignment it comes from (via collection …, via tag … or via this agent). The Override control changes that for one agent. You can add an optional reason, and every change is audited.

Enforcement#

The Enforcement switch on Policies → BitLocker is off by default. While it is off, "policies are evaluated and shown, but nothing is sent to any agent". An agent's Enforcement panel then shows the state Athena would send. Turning it on evaluates every connected agent immediately. From then on, an agent is evaluated:

• when it connects, and each time it reports its volumes;
• when a policy, assignment or override that affects it changes;
• when you click Re-evaluate on its BitLocker tab;
• when the BitLocker Enforcement scheduled task runs.

Automatic triggers do not resend a desired state the agent has already answered. So agents that reported Drift, Failed or Suspended are retried only by Re-evaluate or by the BitLocker Enforcement task. Schedule that task in the Scheduler; every 60 minutes is recommended. See Scheduled Jobs. Turning enforcement off stops all sends, but a conversion already running on a machine continues.

What the agent does

• Enforce acts on the OS volume only. Fixed data volumes are reported and escrowed, but never encrypted by enforcement.
• Unencrypted OS volume: the agent needs a ready TPM (otherwise it reports Not capable and changes nothing). It adds the policy's TPM or TPM + PIN protector and adds a recovery-password protector if there is none. If the policy requires it, the agent escrows the recovery password and waits up to 2 minutes for the server's confirmation. Then it starts encryption with the policy's method and scope.
• Already-encrypted OS volume: the encryption method and the protector are never changed automatically. If they differ from the policy, the agent reports Drift. An encrypted volume without a recovery-password protector is also Drift, and the agent leaves it untouched.
• Suspended protection: resumed only when the suspension has no remaining reboot count. If protection is suspended for more reboots, the agent reports Suspended and leaves it alone.
• A volume that is decrypting or whose conversion is paused is left untouched.
• Decrypt (from a Decrypt override) decrypts every OS and fixed volume, data volumes first. It does not need a TPM.
• A machine that already matches the policy is not modified in any way.

Sync states

Re-evaluate reports what it decided, for example Desired state sent to the agent, Already in sync, The last apply is still converging on the agent, The agent is offline, The agent has not reported its volumes yet, A startup PIN is required or Enforcement is switched off in Settings. Nothing is sent in any of these cases except the first.

The Fleet enforcement summary on the Settings tab counts agents per sync state. It also counts Encrypted, Converting, Unencrypted, Not capable and Escrowed volumes.

From a sync count to the machines#

Each sync-state tile in the Fleet enforcement summary is a link. Hover it to see Show agents in <state>, then click it (or press Enter, or middle-click to open a new tab). The Agents list opens showing only the agents in that state, for example:

/agents?field=Module.bitlocker.SyncStatus&value=Drift

• The list shows the same agents the tile counted. Agents that have never been evaluated are not in any tile, and they don't appear in any of these lists either.
• A tile with a count of 0 is dimmed but is still a link. It opens an empty list.
• The volume tiles (Encrypted, Converting and so on) are not links. They count volumes, not agents, so an agent list would show a different number.
• You can bookmark or share the link. The same filter is available as the Module.bitlocker.SyncStatus field in dynamic collections, tagging rules and monitors.

TPM + PIN startup PINs#

With a TPM + PIN policy, users type a startup PIN before Windows boots. Athena needs that PIN when it first enables BitLocker, and it never makes one up. You can store the PIN at two levels:

For each agent, Athena uses the device override if one is set, otherwise the policy PIN. If neither is set, nothing is sent. The agent stays in Drift with "This policy needs a TPM+PIN startup PIN before BitLocker can be enabled." Saving a policy PIN re-evaluates the fleet, so agents that were waiting for a PIN get it without further action.

A PIN must be 6 to 20 digits (digits only) and is always entered twice. Stored PINs are encrypted in the same way as escrowed recovery passwords, so they have the same dependency on the server's certificate authority (see Recovery-key escrow). A PIN never appears in a list or detail response, a log or an audit entry. It is only sent to the agent that needs it, and a person can see it only through the audited reveal.

The Startup PIN line on an agent

When an agent's effective policy is enforced with TPM + PIN, its BitLocker tab shows a Startup PIN line with the PIN that applies:

• Using policy PIN (with the policy name);
• Device override (with set by <user> at <time>);
• No PIN stored.

Its buttons:

• Set (pencil, needs Manage BitLocker): stores a device override and sends it to the agent now. If the machine is already encrypted with TPM + PIN, it changes its PIN in place, so its user types the new PIN at the next start.
• Remove (only when an override is set, needs Manage BitLocker): Remove the device PIN override? The agent returns to its policy PIN. If it is already encrypted with TPM + PIN, the policy PIN is sent now and replaces the current PIN.
• Show (needs Reveal BitLocker startup PINs): the audited reveal, described below.

Provide PIN appears in the Enforcement panel only when a TPM + PIN enable is waiting and no PIN is stored. The PIN you enter there is saved as the agent's device override and sent at once, just like Set.

If the line also says "The PIN that applies now has not reached this device yet - it keeps its previous PIN until it receives the new one.", the PIN that applies has changed since the last one sent to this machine. For example, the policy PIN was changed but not pushed, or the agent was offline when you set the override. Use Push PIN or save the override again while the agent is connected.

Changing the PIN on machines already encrypted (Push PIN)

Changing a policy PIN does not change the PIN on machines that are already encrypted. To roll it out to them, click Push PIN next to the policy in Policies → BitLocker → Policies (shown when the policy has a stored PIN; needs Manage BitLocker) and confirm Push the policy PIN? Athena sends the PIN to every agent that:

• is connected right now;
• is enforced with this policy and has no device override;
• already has a TPM + PIN protector on its OS volume.

Each of those agents changes its existing TPM + PIN protector's PIN in place, so the machine always keeps a TPM protector. The result reads PIN sent to N of M encrypted agent(s). Offline agents are not queued. Push again when they are back online. Changing the PIN on an already-encrypted machine needs Windows agent 1.2.103 or later.

Removing a policy PIN (Remove the stored PIN) does not touch encrypted machines: they keep their current PIN, and new TPM + PIN machines wait for a PIN again.

Revealing a startup PIN

Users with Reveal BitLocker startup PINs see a Show button on the agent's Startup PIN line and next to PIN stored in the policy list. The dialog warns "Showing a PIN is recorded in the audit log with your name." Nothing is decrypted until you click Show PIN. The PIN then appears with a Copy button and hides automatically after 30 seconds. When the dialog hides or closes, Athena tries to clear a PIN you copied from it off the clipboard.

On an agent, the reveal shows the PIN last sent to that machine. If Athena doesn't know that PIN, it shows the PIN that applies now (the override, otherwise the policy PIN). No reason is asked for, unlike a recovery-password reveal. The bitlocker.pin-revealed audit entry (Warning) is written before the PIN is shown. If it cannot be written, the PIN is withheld.

Other TPM + PIN rules

• If the OS volume already has a TPM + PIN protector, enabling needs no new PIN.
• If the OS volume already has a different TPM-based protector, the apply fails with "A different TPM protector already exists on the OS volume."
• Setting, changing, clearing and pushing PINs are audited as bitlocker.pin-changed / bitlocker.pin-pushed, before the change is made. If the audit entry cannot be written, nothing changes.
• The REST route POST /agents/{id}/pin still accepts a one-time PIN for a single enable. That PIN is not stored.

Recovery-password rotation#

Athena can replace recovery passwords, for example after one has been revealed. Rotation only touches recovery-password protectors. It never changes encryption, protection or the TPM / TPM + PIN protectors. For each volume:

1. the agent adds a new recovery password;
2. it escrows the new password to Athena;
3. it removes the old password only after Athena confirms the new one is stored.

If the confirmation doesn't arrive, the old password stays and the new, unconfirmed one is removed again. The volume always keeps an escrowed key. Until the rotation result arrives, the old key stays revealable in Athena.

• Rotate on demand: click the rotate-key icon on the title row of an agent's Recovery keys section (hover it for "Replace this agent's recovery passwords now…"). The Rotate recovery passwords? dialog says how many keys will be replaced. Click Rotate now to start. The agent must be connected. If nothing is sent, the reason is shown: not licensed, no escrowed recovery password, not capable, or offline. The icon is only shown to users with bitlocker.manage. It is greyed out while the agent has no escrowed key yet: an Enforce policy creates and escrows one when it encrypts the OS volume. An already-encrypted volume without a recovery password is reported as Drift and left unchanged.
• Scheduled rotation: on Policies → BitLocker → Recovery password rotation, turn rotation on and set Rotate recovery passwords older than (days): 1–365, default 30. Rotation is off by default. Rotation runs only from the BitLocker Key Rotation server task, which you schedule in the Scheduler (daily is recommended). The task rotates connected agents that have a BitLocker-capable volume whose newest escrowed key is older than the interval.

Each escrowed key shows its Age: N days. While rotation is on, a volume's newest key that is older than the interval is also marked Stale.

Compliance baseline#

Policies → BitLocker → Compliance baseline → Create baseline adds a detection-only baseline named BitLocker to Compliance. It has one Windows rule, BitLocker - OS drive protected, which passes only when the OS drive's protection status is On. The baseline is assigned to a dynamic collection named BitLocker capable (agents whose BitLocker readiness is Capable) and evaluated every 60 minutes. It has no remediation and changes nothing on agents.

Compliance shows the baseline as Managed by BitLocker; edits made there are overwritten. Remove baseline deletes the baseline and its results. If an operator-created baseline or collection already uses one of these names, creation is refused and nothing half-built is kept.

Filter fields#

BitLocker data is available as filter fields in dynamic collections, tagging rules, monitors and reports. For example, Module.bitlocker.OsDriveEncrypted equals false builds a collection of machines whose OS drive is not encrypted yet. An agent that has never reported has no value for any of these fields.

Audit events#

BitLocker writes these event types to the audit log, and they are forwarded to your SIEM with the rest. No entry ever contains a recovery password or a PIN.

Changes to the enforcement switch, the rotation settings, overrides and startup PINs are audited first. If the audit entry cannot be written, the change is not made.

REST API#

All routes are under /api/bitlocker and use the standard { success, data, message } envelope. Enum values are sent and returned as names (for example "XtsAes256", "Collection"); numbers are rejected. See API Reference for authentication.

For example, to turn enforcement on without touching rotation:

curl -k -X PUT -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
  -d '{"enforcementEnabled": true}' \
  "https://<server>:8443/api/bitlocker/settings"

Troubleshooting#

Related#

• FileVault Recovery-Key Escrow: escrow, rotate and reveal the personal recovery key of your Macs (licensed with BitLocker).
• Boot & Security (Secure Boot / TPM): TPM and Secure Boot inventory.
• Compliance & Baselines: where the BitLocker baseline's results appear.
• Collections and Filter Field Reference: targeting with BitLocker filter fields.
• Scheduled Jobs: scheduling the BitLocker Enforcement and Key Rotation tasks.
• Audit Event Types Reference: all audit events.
• Air-Gapped Operation: running Athena with no outbound connectivity.