How to Deploy and Manage BitLocker Encryption

Overview:

Why unmanaged encryption is a compliance gap, not just a security one

An unencrypted laptop is not a theoretical risk. It is a lost-device incident waiting for a date, and once it happens the only question that matters to an auditor is whether the drive was protected before it left the building. BitLocker itself is free and built into Windows. The actual problem organizations run into is consistency: which drives are protected, which encryption method was used, where the recovery key lives, and whether anyone can prove any of it six months later.

The operational reason this drifts is familiar. Encryption gets turned on manually during imaging, the recovery key is escrowed inconsistently (or not at all), a laptop gets rebuilt without IT's involvement, and by the time an auditor asks for evidence nobody can produce a clean device-by-device answer.

The Disk Encryption module closes that gap by treating BitLocker as a managed policy rather than a one-time imaging step. You define the encryption rule once (method, TPM behaviour, drive scope, key rotation) and the platform applies it to every targeted endpoint, escrows every recovery key automatically, and reports live on which devices are actually protected.

This guide walks the full workflow end to end: a BitLocker policy with encryption method and TPM settings, a deployment that pushes it to real endpoints, a live status dashboard to track rollout, a recovery key vault for support and audit use, and a decrypt path for when a drive needs to come back out of policy.

• Reduce exposure: every managed endpoint reaches a known encryption state instead of relying on whatever happened at imaging time.
• Prove compliance: per-device encryption status and recovery-key records give you evidence on demand instead of a fire drill before an audit.
• Protect lost or stolen devices: a device that never reports back is still cryptographically protected, because encryption was applied before it left the fleet.
• Remove manual work: one policy scales to the whole estate; there is no per-device BitLocker wizard to run by hand.
• Recover safely: recovery keys are escrowed centrally the moment encryption starts, so a forgotten PIN or hardware change never turns into data loss.

Prerequisites

Confirm all five before creating a policy. A missing prerequisite here usually surfaces mid-deployment, when a device is already partially encrypted and much harder to walk back cleanly.

1. Administrator access: your account holds a role permitted to manage the Disk Encryption module. Read-only operators can view status and recovery keys but cannot create or publish policies.
2. Agent installed and reporting: the endpoint agent is installed, registered, and reporting healthy on every target device. Devices not yet enrolled are invisible to any policy.
3. TPM present (recommended): most target hardware has a Trusted Platform Module. Devices without one still need a defined fallback (password-based protection), or they should be excluded from TPM-only policies.
4. Windows edition supports BitLocker: Pro, Enterprise, or Education editions. Home editions cannot be managed by BitLocker policy at all.
5. Endpoint groups defined: target devices are organized into groups (department, location, OS, or tag) so policies can be scoped deliberately rather than applied ad hoc to individuals.

Architecture: how a policy becomes an encrypted drive

The policy and the encryption action travel through distinct stages: a policy defines the rule, a deployment binds that rule to specific endpoints and a trigger type, and the agent on the endpoint carries out the actual BitLocker operation and reports back.

Step 1: Open the Disk Encryption module

Navigate to the module and get oriented before creating anything, so you know where policies, deployments, status, and recovery keys each live.

Instructions

1. From the main console, go to Endpoints → Device Control.
2. Under Data Protection, select Disk Encryption.
3. Note the four sections in the left sidebar: BitLocker Status, BitLocker Recovery Keys, BitLocker Policies, BitLocker Deployments.

Path: Console / Endpoints / Device Control / Disk Encryption

Result: You're in the Disk Encryption module with no policy yet created: status and recovery keys will remain empty until Steps 2–3 are complete.

Step 2: Create a BitLocker policy

Define the encryption method for each Windows version and the server tier in a single reusable policy.

Instructions

1. Go to BitLocker Policies → Create BitLocker Policy.
2. Name the policy for what it enforces (e.g. BitLocker Drive) and toggle Enable Policy on.
3. Set Global Encryption Type to Hardware and Software unless your fleet is entirely self-encrypting drives.
4. Set the per-OS encryption methods: Windows 7/8 at AES 256-bit, Windows 10 and the server tier at XTS-AES 256-bit (XTS is the modern, tamper-evident mode and should be the default wherever the OS supports it).

Path: Console / Disk Encryption / BitLocker Policies / Create BitLocker Policy

Console: encryption method settings

Result: A draft policy exists with encryption method defined. It has no drive rules or targets yet: those follow in Steps 3–5.

Step 3: Configure OS drive protection

Set how the operating system drive is encrypted and what happens on devices without a working TPM.

Instructions

1. On the same policy, toggle Encrypt OS Drive on.
2. Set OS Drive Encryption Type to Used Space Only: this encrypts only data currently on disk rather than the full volume, which is faster and sufficient for drives that were never used unencrypted.
3. Set TPM Protection Mode to TPM Only for standard laptops and desktops.
4. Toggle Allow Without TPM on only if you have devices lacking a TPM that still need to be covered: this falls back to password-based protection.
5. Enable Enforce Minimum Complexity and set Minimum Password Length to 10 or higher when password fallback is permitted.

Path: Console / Disk Encryption / BitLocker Policies / OS Drive Protection

Console: OS drive settings

Result: The OS drive rule is set. Devices with a TPM encrypt silently; devices without one fall back to a complex password rather than being left unprotected.

Step 4: Configure fixed and removable drives

Extend the same policy to secondary internal drives and removable media, so protection isn't limited to the boot volume.

Instructions

1. Toggle Encrypt Fixed Drives on and set Fixed Drive Encryption Type to Used Space Only (or Full Volume for drives being decommissioned or reassigned).
2. Toggle Encrypt Removable Drives on and set Removable Drive Encryption Type to Used Space Only.
3. Leave removable drive encryption on plain AES if those drives need to be read on non-managed machines.

Path: Console / Disk Encryption / BitLocker Policies / Fixed and Removable Drives

Console: drive scope settings

Result: The policy now covers every drive class on the endpoint, not just the OS volume.

Step 5: Configure recovery key rotation

Set the policy to rotate the recovery key on a schedule, so a key doesn't stay valid indefinitely if it's ever exposed.

Instructions

1. Toggle Recovery Key Rotation Enabled on.
2. Set Recovery Key Rotation Period (days) to 30 for a standard estate, shorter for higher-sensitivity device groups.
3. Save the policy as a draft or select Create: it has no targets yet, so nothing deploys until Step 6.

Path: Console / Disk Encryption / BitLocker Policies / Recovery Key Rotation

Console: key rotation settings

Result: The completed policy appears in the BitLocker Policies list, fully configured but unattached to any endpoint.

Step 6: Deploy the policy to encrypt endpoints

Bind the policy to actual devices with a deployment of type Encrypt.

Instructions

1. Go to BitLocker Deployments → Create BitLocker Deployment.
2. Name the deployment for its purpose: e.g. Drive Secure.
3. Set Scope to Specific Endpoints (or Departments/Locations/All Endpoints for broader rollout) and select the target device(s).
4. Set Deployment Type to Encrypt.
5. Select the BitLocker Policy created in Steps 2-5.
6. Optionally set Notify to so an admin or team is alerted when the deployment completes.
7. Select Publish.

Path: Console / Disk Encryption / BitLocker Deployments / Create BitLocker Deployment

Console: deployment definition

Result: A task is created (e.g. <TASK-ID> – BitLocker Drive) with status In Progress, visible under Tasks with the target endpoint and timestamp.

Step 7: Monitor the encryption rollout

Track live progress per endpoint until encryption completes, using the status dashboard rather than the task log alone.

Instructions

1. Go to BitLocker Status.
2. Read the Encryption Status and TPM Availability summary widgets.
3. Find the target endpoint's row and watch Protection Status move from Unprotected, Encryption Status show Encryption In Progress, and Encryption(%) climb toward 100%.
4. Refresh periodically: the percentage updates live as the drive encrypts (e.g. 56% → 60% → 96%).

Path: Console / Disk Encryption / BitLocker Status

Console: live status

Result: Once the percentage reaches 100%, the deployment's Stage shows Completed in the BitLocker Deployments list, and Protection Status updates accordingly.

Step 8: Retrieve and manage recovery keys

Confirm the recovery key was escrowed correctly and know where to find it later for support or audit purposes.

Instructions

1. When encryption begins, you may be prompted to confirm your password as an admin action gate before the key is displayed.
2. The Recovery Key for Volume C: dialog shows the 48-digit key, with a copy button: record it in your secure key vault if you need it outside the console.
3. Go to BitLocker Recovery Keys to see every escrowed key across endpoints: Endpoint, Drive, Recovery Key ID, and Active status.
4. When a key rotates, the previous key remains listed with Active = No for historical/audit purposes; only the current key shows Active = Yes.

Path: Console / Disk Encryption / BitLocker Recovery Keys

Console: recovery key records

Result: Every encrypted drive has a retrievable recovery key on record, with rotation history preserved rather than overwritten.

Step 9: Verify protection status fleet-wide

Confirm the rollout achieved full coverage before considering the cycle closed.

Instructions

1. Return to BitLocker Status and review the TPM Availability widget for any endpoints reporting Not Available: these need a fallback password policy, not a TPM-only one.
2. Confirm every targeted endpoint shows Protection Status: Protected (once fully encrypted, status moves off Unprotected).
3. Cross-check the BitLocker Recovery Keys list: every protected endpoint should have exactly one Active key.
4. Investigate any endpoint still showing Unprotected after its deployment task reports complete.

Path: Console / Disk Encryption / BitLocker Status

Result: A fleet-wide view confirming which endpoints are actually protected, which are pending, and which need attention: the evidence you'd present in an audit.

Step 10: Decrypt a drive when needed

Reverse encryption cleanly through policy rather than a manual manage-bde -off on the endpoint, so the action stays tracked and auditable.

Instructions

1. Go to BitLocker Deployments → Create BitLocker Deployment.
2. Name it for the action: e.g. Decrypt Drive.
3. Set Scope to the same or a different target endpoint set.
4. Set Deployment Type to Decrypt.
5. Select the applicable Deployment Policy and select Publish.
6. Monitor BitLocker Status: the endpoint shows Decryption In Progress with a percentage counting down, then Fully Decrypted at 0%.

Path: Console / Disk Encryption / BitLocker Deployments / Create BitLocker Deployment

Verify

Task output confirms the action end to end:

INFO <ENDPOINT-HOSTNAME> Initiating decrypt execution of BitLocker policy <POLICY-ID-REDACTED>
INFO <ENDPOINT-HOSTNAME> TPM Status: Yes
INFO <ENDPOINT-HOSTNAME> OS: Win11
INFO <ENDPOINT-HOSTNAME> Drive D: is already decrypted, skipping
INFO <ENDPOINT-HOSTNAME> Decrypting drive C:
INFO <ENDPOINT-HOSTNAME> Successfully started decryption for drive C: - Status: DecryptionInProgress, Progress: 56%
INFO <ENDPOINT-HOSTNAME> BitLocker Policy applied successfully

Result: The drive returns to an unprotected state through a tracked action, with the same task/status visibility as encryption had.

Best practices for BitLocker management

Troubleshooting: common issues and resolutions

Frequently asked questions