BitLocker Practical Guide — Drive Encryption Starting With Recovery Key Management

“I reset the PC, and on the next boot a blue screen I’d never seen before appeared, asking for a 48-digit key.” “I only updated the BIOS, and it went straight to the recovery key screen — nobody handed me a key like that.” “I looked at the settings on a new PC and found ‘Device encryption’ had switched itself on. It looks like it’ll slow down our business applications, so can we just turn it off?” — over roughly the past year, we have seen a visible rise in consultations of this kind from customers.

The reason is clear. From Windows 11 version 24H2 onward, a clean-installed PC runs “Device encryption” (BitLocker’s automatic activation) by default. The hardware requirements have also been relaxed, so the pool of eligible PCs has expanded significantly. In other words, BitLocker is no longer something “large enterprises deliberately roll out” — it has become something that “quietly arrives on SME PCs too”. In this situation, the only lifeline is the recovery key, and the most dangerous state of all is one where encryption proceeds while that key sits under nobody’s management.

This article is aimed at SME IT staff and managers, and at developers responsible for business applications and equipment PCs, and sets out BitLocker not as “something to switch off” but as “something to use properly”. Drawing on primary sources such as Microsoft Learn as of August 2026, it covers the differences between editions, the bare minimum of how TPM and keys relate to each other, a decision table for where to store the recovery key, activation and operation within an organisation, incident response, and its relationship to disposal.

1. The Bottom Line First

• BitLocker is a Windows feature that encrypts an entire drive, preventing data leakage from loss, theft, or improper disposal. Even against an attack where the disk is removed and connected to another PC, the data cannot be read as long as it is encrypted.¹
• Full-featured BitLocker can only be enabled on Pro, Enterprise, Pro Education, and Education. Its simplified counterpart, “Device encryption”, is available on every edition, including Home.¹
• From Windows 11 24H2 onward, the requirements for automatic device encryption were relaxed. The HSTI/Modern Standby requirement and the requirement for “no unauthorised DMA interfaces” were removed, so once OOBE (initial setup) completes after a clean install, encryption is initialised by default on many PCs that meet TPM + UEFI Secure Boot.²
• “Starting” encryption and “enabling” protection are different things. Protection is not enabled (armed) until the recovery key has been successfully backed up to a Microsoft account, Entra ID, or (with the recovery policy configured) AD DS. A PC using only a local account, with nowhere to back up to, remains unprotected even though it is encrypted.¹²
• There are effectively four places to store the recovery key (the 48-digit recovery password): Entra ID, AD DS, a Microsoft account, or a printed/file copy. The default flow is: Entra ID if the device is Entra ID-joined, AD DS if it is AD domain-joined, and otherwise the administrator’s Microsoft account.¹³
• Being asked for the recovery key is not only a sign of something abnormal. A firmware update, a Secure Boot configuration change, clearing the TPM, a motherboard replacement, moving the drive to another machine — any change to the boot environment can trigger it. The standard practice before planned work is to suspend protection first.³
• The default encryption method is XTS-AES 128-bit. Changing the method later requires decrypting and then re-encrypting, so it pays to settle on it at the outset. For a brand-new drive, “encrypt used space only” cuts the initial encryption time substantially.⁴⁵
• If a PC asks for the recovery key and you cannot produce it, the data has to be written off. Even Microsoft Support cannot retrieve a lost key. That is precisely why the theme of this article is not “whether to encrypt” but “where to store the recovery key and who can retrieve it”.⁶

2. BitLocker vs. Device Encryption — What’s Available by Edition

Let’s start by sorting out the terminology. “BitLocker” and “Device encryption” are two faces of the same encryption technology.

• BitLocker (full-featured): enabled per drive, and the administrator-facing form of the technology — including authentication methods such as TPM+PIN and startup keys, control via Group Policy/Intune, and management through manage-bde.exe or PowerShell.
• Device encryption: a mechanism that automatically enables BitLocker on PCs meeting the requirements. A “Device encryption” toggle appears in the Settings app, and it encrypts only the OS drive and internal fixed drives (external/USB drives are excluded).¹

Support by edition is as follows.¹

What Changed in Windows 11 24H2

Automatic device encryption existed before, but it was aimed mainly at relatively recent mobile PCs meeting conditions such as “Modern Standby or HSTI compliant” and “no externally DMA-accessible ports”. Windows 11 version 24H2 removed those two requirements, narrowing the remaining core conditions to things such as “has a TPM (1.2 or 2.0)” and “UEFI Secure Boot is enabled”. The practice of OEMs registering unauthorised DMA buses in the registry (AllowedBuses) is also no longer needed, and that key itself is ignored from 24H2 onward. Note that this relaxation of requirements does not apply to Windows IoT editions.²

As a result, completing OOBE after a clean install (including a reset or re-setup) now initialises encryption by default even on an entirely ordinary desktop PC. What matters here is the distinction between “initialising” encryption and “enabling” protection.

• At the point OOBE completes, the drive is encrypted with a clear key (an unprotected temporary key). Explorer displays a warning icon.¹
• Once sign-in with a Microsoft account or Entra ID account succeeds — or, for a domain-joined PC, backup to (recovery-policy-configured) AD DS succeeds — a TPM protector is created and the clear key is removed. Only at that point does protection become active.¹²
• A PC used only with a local account remains unprotected even though it is encrypted.¹

This flow, shown as a diagram, looks like this.

flowchart TB
    A["Clean install / reset<br/>Windows 11 24H2 or later"] --> B{"Meets requirements such as<br/>TPM plus UEFI Secure Boot?"}
    B -- "Does not meet" --> Z["Not encrypted"]
    B -- "Meets" --> C["Encryption initialised at OOBE completion<br/>clear key, an unprotected temporary key"]
    C --> D{"Where is the recovery key<br/>backed up to?"}
    D -- "Microsoft account / Entra ID /<br/>AD DS, recovery policy configured" --> E["Recovery key backup succeeds"]
    E --> F["TPM protector created, clear key removed<br/>protection is enabled, armed"]
    D -- "Local account only<br/>no backup destination" --> G["Stays encrypted but unprotected<br/>warning icon is shown"]

This mechanism is exactly what lies behind “it was encrypted before I knew it”. Organisations pushing through a swap to Windows 11 PCs as part of their Windows 10 end-of-support response (Practical Options After Windows 10 End of Support — A Decision Table for ESU, LTSC, and Replacement) need to build recovery-key management into their kitting procedure on the assumption that new PCs will arrive in this state from day one.

You can check whether your own machine qualifies by opening System Information (msinfo32.exe) as an administrator and looking at the “Device Encryption Support” line. “Meets prerequisites” means the device is eligible.¹

3. The Bare Minimum of the Mechanism — TPM and the Key

What guards the BitLocker key is the TPM (Trusted Platform Module). The TPM’s job is to confirm that the device has not been tampered with while the OS was offline, and it only releases the encryption key once startup verification passes. That is exactly what lets both things be true at once: a legitimate Windows boots normally and the user enters nothing, while a disk that has simply been pulled out cannot be read.¹ The mechanics of the TPM itself — the structure that never lets keys out, PCRs, and Measured Boot — are covered with diagrams in “What Is the TPM in Windows? — An Illustrated Guide to the “Safe That Never Lets Keys Out” and Measured Boot”.

Here is a diagram of what happens on every boot.

flowchart TB
    ON["Power on"] --> M["TPM measures the boot environment<br/>firmware, boot configuration, etc."]
    M --> Q{"Does the measurement<br/>match the usual value?"}
    Q -- "Matches" --> UN["TPM releases the encryption key"]
    UN --> BOOT["Normal boot<br/>user enters nothing"]
    Q -- "Differs" --> REC["Recovery mode<br/>the 48-digit recovery key is requested"]
    REC --> K1["Boots if the recovery key is entered"]
    REC --> K2["If it cannot be entered,<br/>the data cannot be retrieved"]

On top of the TPM, you can also choose a multi-factor configuration that requires entering a PIN or inserting a startup key (a key file on a USB drive) at boot. Even a PC without a TPM can encrypt its OS drive using the startup key method, but the password method has no lockout mechanism and is vulnerable to brute force, so it is disabled by default.¹

When Is the Recovery Key Requested?

Because the TPM watches whether “the boot environment is the same as usual”, even the legitimate owner enters recovery mode when the environment changes. The representative triggers Microsoft lists are as follows.³

• Updating an early boot component, such as a BIOS/UEFI firmware update
• Turning the TPM off, disabling it, clearing it, or a TPM self-test failure
• A change to a PCR (Platform Configuration Register) used by the TPM validation profile — a Secure Boot configuration change lands here
• A motherboard replacement (a swap to a new TPM)
• Moving a BitLocker-protected drive to a different PC
• Docking/undocking, a change to the NTFS partition table, a change to the boot manager, PXE boot
• Repeated incorrect PIN entries, or (on TPM 1.2 machines) changing the boot device order

In other words, “being asked for the recovery key after a BIOS update” is neither a fault nor an attack; it is behaviour working exactly as designed. The standard practice before planned work (a firmware update or hardware replacement) is to suspend protection first. Even while suspended, the drive stays encrypted, and after the work is done you can resume without entering the recovery key. By default, protection resumes automatically on the next reboot (you can also specify a reboot count).³

# Suspend before the firmware update. By default protection resumes automatically
# after one reboot, so for an update that reboots multiple times, the second and
# later reboots can stall on the recovery screen.
# -RebootCount 0 stops the automatic resume; build the resume after the work
# into the procedure instead
Suspend-BitLocker -MountPoint C: -RebootCount 0
# Always resume after the work (this step is mandatory because -RebootCount 0
# disables automatic resume)
Resume-BitLocker -MountPoint C:

A note on terminology. Technical documentation distinguishes between the “recovery password” (the 48-digit number) and the “recovery key” (the .bek file saved to a USB drive),³ but consumer-facing screens, and this article, follow the widely used convention of calling the 48-digit number the “recovery key”.

4. A Decision Table for Where to Store the Recovery Key — Choosing Among the Four Options

This is the heart of the article. There are effectively four places to store the recovery key, and the choice is almost automatically determined by how the PC signs in. Here is the decision table first.

For a hybrid-joined device (both AD and Entra ID), the recovery password is backed up to both.⁴

There are three points an organisation needs to nail down.

1. Settle on a single “organisational storage location”. If Entra ID joining is under way, that’s Entra ID; for on-premises AD, that’s AD DS. A state where a company PC’s recovery key lives in an individual staff member’s personal Microsoft account collapses the moment that person resigns or is transferred.
2. Do not assume AD DS “just works automatically”. Backup to AD DS is premised on the policy configuration (covered below). Also, Active Directory keeps a history of recovery passwords, and old keys are not automatically removed unless the computer object itself is deleted.³
3. If you choose file storage, be strict about where it lives. The recovery key file needs to be saved somewhere other than the PC itself, such as a network folder.⁵ Whoever holds the recovery key can access all the data on the drive, so storing it separately from the protected PC and controlling access to it is essential.³

Checking Where Your Own PC Currently Stands

Run either of the following from an administrator terminal.⁵

# PowerShell: check the encryption state and protector types
Get-BitLockerVolume C: | Format-List
# Check the recovery password (48 digits) and its ID
(Get-BitLockerVolume -MountPoint C).KeyProtector

:: Command Prompt: check the state
manage-bde -status
:: List of protectors (TPM, recovery password, etc.) and the 48-digit value
manage-bde -protectors -get C:

In the output of manage-bde -protectors -get C:, the 48-digit recovery key is the one displayed as “Numerical Password”; the first 8 characters of the accompanying ID give you the clue for matching “which key it is” on the recovery screen.⁶

You can also back up the recovery password of a PC that is already encrypted to Entra ID or AD DS after the fact.⁵

# Check the recovery password's ID first, then run this
# Back up to Entra ID
BackupToAAD-BitLockerKeyProtector -MountPoint C: -KeyProtectorId "{ID}"
# Back up to AD DS
Backup-BitLockerKeyProtector -MountPoint C: -KeyProtectorId "{ID}"

:: With manage-bde
manage-bde -protectors -aadbackup C: -id {ID}
manage-bde -protectors -adbackup C: -id {ID}

Auditing “whether every PC’s recovery key is in the organisation’s storage location” is, like the basic information security measures described in IPA’s SME guideline, not a one-off task but something that belongs on an ongoing ledger (“Where Should SMEs Start on Security? — A Walkthrough of IPA’s ‘Information Security Guidelines for SMEs,’ 4th Edition”).

5. Activation and Operation in an Organisation — Policy, Commands, and Encryption Method

5.1. Using Policy to Forbid “Enabling Without a Recovery Key”

BitLocker settings can be configured from both Group Policy (GPO) and MDM (the BitLocker CSP, as in Intune).⁴ From the standpoint of recovery-key management, the single most important policy is “Choose how BitLocker-protected operating system drives can be recovered”. This is where you configure the following.⁴³

• Save recovery information to AD DS (recovery password only, or including the key package)
• Enable “Do not enable BitLocker until recovery information is stored to AD DS” — the linchpin of accident prevention, which refuses to let encryption start unless the backup succeeds. With this configuration, the recovery password is generated automatically

The same thinking applies when Entra ID-joined devices are managed through Intune: make the recovery-key backup mandatory, and only then enable encryption. Recovery keys on Entra ID can be retrieved from the Entra admin center, the Intune admin center, PowerShell, or Microsoft Graph, and that retrieval can also be delegated to the help desk.³

5.2. Encryption Method — the Default Is XTS-AES 128

If you do not configure an encryption method, BitLocker uses XTS-AES 128-bit by default. Device encryption also defaults to XTS-AES 128. You can change it to XTS-AES 256 and so on via the “Choose drive encryption method and cipher strength” policy, but Microsoft’s recommendation is to use XTS-AES for every drive and choose a 128- or 256-bit key length according to the device’s performance (and any industry regulatory requirements).⁴¹

The point to be careful of is that the method on an already-encrypted drive cannot be changed later. Changing the method or key length requires decrypting and then re-encrypting.¹ If there is a reason such as “regulatory requirements demand 256-bit”, settle on it at the outset of deployment.

5.3. Encrypt Used Space Only vs. the Entire Drive

Another choice you make at activation time is the encryption scope. Microsoft’s guidance for choosing between them is clear-cut.⁵

• Encrypt used space only: for a brand-new drive that has never held data. The initial encryption is fast
• Encrypt the entire drive: for a drive that has already been in use — one that has held data, and where deleted files may remain

The reason is that the space occupied by deleted files looks like “free space” to the file system, so “used space only” does not encrypt it, and it can be recovered with forensic tools until it is overwritten.⁵ In practice it is enough to remember: “used space only” is fine for a fresh PC straight out of kitting, and full-drive encryption is the choice when applying it later to a PC that has already seen use.

5.4. Enabling It From PowerShell

The basic pattern for a scripted rollout is as follows.⁵

# 1. Add the recovery password (48-digit) protector first (encryption has not
#    started at this point). Even if multiple recovery passwords are already
#    present from earlier retries, select only the one just added by taking
#    the ID diff before and after
$before = (Get-BitLockerVolume -MountPoint C).KeyProtector.KeyProtectorId
Add-BitLockerKeyProtector -MountPoint C: -RecoveryPasswordProtector | Out-Null
$rpId = (Get-BitLockerVolume -MountPoint C).KeyProtector |
    Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' -and $_.KeyProtectorId -notin $before } |
    Select-Object -ExpandProperty KeyProtectorId

# 2. Back up the added recovery password to the organisation's storage
#    location. If this fails you must not proceed to encryption, so
#    -ErrorAction Stop halts processing on error
#    (this step is complete once you have confirmed the key is visible in the
#    Entra admin center / AD)
BackupToAAD-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $rpId -ErrorAction Stop
# For AD DS: Backup-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $rpId -ErrorAction Stop

# 3. Only start encryption once the backup has succeeded. 3a and 3b are
#    mutually exclusive — run only one of them (settle the method and scope
#    here too)

# 3a. Standard configuration: TPM only (use this for machines that need
#     unattended reboots)
Enable-BitLocker C: -EncryptionMethod XtsAes256 -UsedSpaceOnly -TpmProtector

# 3b. TPM+PIN configuration (for stationary, high-security machines). Run
#     this instead of 3a.
#     Enter a different PIN for each machine on the spot. Embedding it as
#     plaintext in the script would give every machine the same PIN, and
#     turn the script itself into a leak point
$Pin = Read-Host -AsSecureString -Prompt "PIN for this device"
Enable-BitLocker C: -EncryptionMethod XtsAes256 -UsedSpaceOnly -Pin $Pin -TPMandPinProtector

This order — “deposit the recovery password, then start encryption” — matters. Start instead from Enable-BitLocker -TpmProtector, and if processing stops partway through, you are left with a PC where TPM protection alone is active with no recovery fallback in hand, which risks losing the data along with the next firmware update or hardware change. With the sequence above, if it stops partway, encryption has not yet started, and all you need to do is start over. For an organisational rollout, having the 5.1 policy “Do not enable BitLocker until recovery information is stored” already in effect prevents this half-finished state at the policy level as well. “Never start encryption before confirming the backup succeeded” is the golden rule of organisational rollout.

6. Incident Response — When You’re Asked for the Recovery Key, or Can’t Find It

6.1. When the Recovery Screen Appears, Start With the First 8 Digits of the Key ID

The blue recovery screen displays a recovery key ID. Even when you have several copies on hand, matching the first 8 digits of the ID lets you pin down the correct key.⁶ Where to look is exactly the table in Section 4; go through it in order.

1. The organisation’s storage location (the Entra ID admin center / Intune, or AD DS) — via an administrator or the help desk
2. The user’s own account — aka.ms/aadrecoverykey for a work account, aka.ms/myrecoverykey for a personal Microsoft account⁶
3. The copy kept at activation time — a printed sheet, a file on a USB drive, or a saved text file⁶

flowchart TB
    REC["Blue recovery screen<br/>the recovery key ID is shown"] --> ID["Note the first 8 digits of the key ID"]
    ID --> ORG["1. Organisation's storage location<br/>Entra ID admin center, Intune, or AD DS"]
    ORG -- "A matching key ID is found" --> INPUT["Enter the 48 digits and boot"]
    ORG -- "Not found" --> SELF["2. The user's own account<br/>aka.ms/aadrecoverykey or aka.ms/myrecoverykey"]
    SELF -- "A matching key is found" --> INPUT
    SELF -- "Not found" --> PAPER["3. The copy kept at activation time<br/>printed sheet, USB drive, or file"]
    PAPER -- "A matching key is found" --> INPUT
    PAPER -- "Not found" --> LOST["Nothing left but a reset, all data lost<br/>even Microsoft cannot retrieve it"]
    INPUT --> AFTER["Confirm the cause, then invalidate and<br/>reissue the key that was used, Section 6.3"]

Alongside that, make it a habit to confirm why you entered recovery mode. If you can point to something — a BIOS update the day before, touching the Secure Boot setting — that is behaviour working as designed. If it recurs with no such explanation, it is worth investigating further, including the possibility of a hardware fault or tampering through physical access.³

6.2. If It Truly Cannot Be Found

This is a hard thing to say, but if the recovery key cannot be found, there is no way to retrieve the data on that encrypted drive. For an organisation-managed PC, checking with IT is the last resort; failing that, nothing remains but resetting the device (losing all data). Microsoft Support cannot supply or recreate a lost recovery key.⁶

Framing this as “the data was lost because of encryption” gets the causality backwards. The cause is that recovery-key management was never turned into a proper system, and that very same gap would have surfaced as an information leak had the device instead been stolen.

6.3. Treat a Used Recovery Key as Single-Use — Operating Through Repairs, Loss, and Staff Departures

• Sending a machine for repair: if you handed the recovery key to the repair vendor (or might have), once the machine comes back, first add a new recovery password and confirm it has been successfully backed up to Entra ID / AD DS, and only then delete the recovery password you handed over. Deleting it first would leave the drive with no recovery option if the addition or backup then failed, so the order matters. Microsoft also recommends invalidating a recovery password after use, and the whole add-then-back-up-then-delete sequence can be completed with commands.⁵ Entra ID-joined devices also have a policy that automatically rotates a recovery password once it has been used. The default is enabled on Entra ID-joined devices, but it only works when the policy making recovery-information backup mandatory (Section 5.1) is configured. Before relying on automatic rotation, confirm that this prerequisite is configured and that the key genuinely does get replaced.⁴
• When a PC is lost: check, using records from the Section 4 command output or your management tooling, whether protection was active (the TPM protector created, the clear key removed); if it was encrypted, you are in a position to state that the data on the disk cannot be read. This is the biggest reason for auditing this while everything is normal.
• When staff leave and return their PC: the first priority is never letting a returned PC’s recovery key exist only in the departing staff member’s personal Microsoft account. If consolidation into the organisation’s storage location (Section 4) is in place, the work at return time is just re-kitting and reissuing the recovery password.

As a flow, the repair case looks like this, for example.

flowchart LR
    S["Send for repair<br/>the recovery key may have been handed over"] --> B["PC comes back"]
    B --> N["Add a new recovery password"]
    N --> BK["Confirm backup to<br/>Entra ID / AD DS succeeded"]
    BK --> D["Invalidate, delete,<br/>the recovery password that was handed over"]
    D --> OK["Update the ledger and finish"]

7. Its Relationship to Disposal — an Encrypted Disk Makes Disposal Easier

BitLocker’s benefit is not limited to while the machine is in use. If the drive was encrypted from the start, all that remains on the disk at disposal time is ciphertext. BitLocker was designed from the outset to prevent data leakage not only from loss or theft but also from “improperly disposed-of devices”, and making the data unreadable when a protected device is disposed of or recycled is part of its purpose.¹

That said, being encrypted does not mean the erasure procedure at disposal time (reset, a dedicated erasure tool, physical destruction) can be skipped. Encryption is insurance that “lowers the risk of plaintext being read off the disk before erasure, or when erasure is not possible”; it is not a substitute for verifiable erasure. On top of that, an organisation running encryption has one further task specific to it — tidying up the recovery-key copies (paper, files, entries in AD or Entra ID). Even after the disk has been wiped, disposal is not complete on the ledger while a copy of the recovery key still exists. Make deleting the old key part of the disposal procedure too.

That said, disposing of a PC also involves considerations beyond encryption — unlinking accounts and licences, the asset ledger, an audit trail. The full procedure is set out as a checklist in “What to Do Before Disposing of a Windows PC — A Practical Checklist for Data Erasure, Account Unlinking, and Backups”, so use it alongside this article when building a disposal flow that assumes encryption is in place.

8. A Business-Application Developer’s Perspective — Performance, Equipment PCs, and Clone Deployment

Finally, some cautions from the standpoint of someone responsible for business applications or equipment-control PCs.

• For performance impact, the basic move is to measure with the default 128-bit first. Microsoft itself frames the key-length choice as depending on device performance — 256-bit for a high-performance drive and CPU, 128-bit otherwise.⁴ Turn that around, and it means the default XTS-AES 128 rarely affects how a business application feels on a modern PC; in our own experience it has caused a problem in almost nothing outside applications with unusually heavy file I/O. If you’re suspicious, you should measure I/O before and after encryption at production-equivalent data volumes and decide from that; switching it off on a hunch that “it’ll probably get slower” gets things backwards.
• Encryption is transparent to applications. BitLocker encrypts the whole volume, and the behaviour of the file API does not change. Put the other way around, BitLocker cannot protect secrets an application handles at runtime on the machine — connection strings, API keys, because on a logged-on machine the drive is visible in decrypted form. That is where DPAPI and the like come in (“Storing Secrets in Windows Apps - Avoiding Plaintext Configuration with DPAPI”).
• For equipment PCs and kiosk PCs, the configuration is decided by “can it reboot unattended”. With a TPM-only configuration, recovery from a power loss also comes up unattended, but TPM+PIN or a startup key needs a human at every boot, which does not suit unattended equipment. On the other hand, a TPM-only configuration carries the risk of stalling at the recovery screen on the Section 3 triggers (firmware updates and so on), so keeping the recovery key somewhere away from the site (locked storage plus a ledger) and spelling out “Suspend-BitLocker before work” in the equipment’s maintenance procedure becomes the crux of the operation. Hardening unattended terminals in general is covered in “Locking Down Business Terminals with Kiosk Mode — Choosing Between Assigned Access and Shell Launcher, and Designing for Operation”. Note that the 24H2 relaxation of requirements for automatic device encryption does not apply to Windows IoT editions,² but that does not mean “automatic encryption won’t happen on IoT”. On models that meet the pre-relaxation requirements (HSTI/Modern Standby, etc.), automatic encryption can still occur as before, so building a manage-bde -status state check into the kitting procedure for equipment PCs too is the reliable move.
• Do not “encrypt, then image” for clone deployment. A recovery password is specific to the device that created it.³ Do not clone a master-machine image with protection already enabled; instead, after deployment, enable it per PC (or let automatic encryption happen at OOBE), then back up the recovery key, in that order. If your kitting is already scripted (“Automating PC Provisioning With winget + PowerShell — Making the Runbook Executable”), all you need to do is append the Section 5.4 activation and backup-confirmation step as the final stage.

9. Summary

• On a clean install from Windows 11 24H2 onward, Device encryption is initialised by default on PCs meeting TPM + UEFI Secure Boot. The HSTI/Modern Standby and DMA requirements have been removed, extending the scope to ordinary desktop PCs.
• The correct response to “it got encrypted on its own” is not disabling it but confirming where the recovery key is. Switching it off loses your protection at loss, theft, or disposal, and once switched off it is not automatically re-enabled.
• Where to store the recovery key is a choice of four — Entra ID, AD DS, a Microsoft account, or a printed/file copy — and is largely decided by the sign-in form. Settle on one organisational storage location and audit whether every PC’s key is actually there.
• Checking is done with manage-bde -protectors -get C: or (Get-BitLockerVolume -MountPoint C).KeyProtector, and backing up after the fact is completed with BackupToAAD-BitLockerKeyProtector / Backup-BitLockerKeyProtector.
• The recovery key gets demanded of the legitimate owner too, through firmware updates, Secure Boot configuration changes, hardware replacement, and the like. Build Suspend-BitLocker before planned work into your runbook.
• The default method is XTS-AES 128, and changing it later requires decrypting and then re-encrypting. For a brand-new drive, encrypting used space only is sufficient.
• Invalidate and reissue a recovery key once it has been used; never leave a key sitting in a departed staff member’s account; bury the key’s copies too at disposal — a recovery key is not something you “issue and forget”, it is something you manage across its whole lifecycle.
• Encryption also serves as insurance at disposal time, but it is not a substitute for the erasure procedure (reset, erasure tools, physical destruction). Rather than switching BitLocker off, using it properly together with recovery-key management is the realistic answer for SMEs.

Related Articles

• What Is the TPM in Windows? — An Illustrated Guide to the “Safe That Never Lets Keys Out” and Measured Boot
• What to Do Before Disposing of a Windows PC — A Practical Checklist for Data Erasure, Account Unlinking, and Backups
• Practical Options After Windows 10 End of Support — A Decision Table for ESU, LTSC, and Replacement
• Where Should SMEs Start on Security? — A Walkthrough of IPA’s ‘Information Security Guidelines for SMEs,’ 4th Edition
• Locking Down Business Terminals with Kiosk Mode — Choosing Between Assigned Access and Shell Launcher, and Designing for Operation
• Automating PC Provisioning With winget + PowerShell — Making the Runbook Executable
• Storing Secrets in Windows Apps - Avoiding Plaintext Configuration with DPAPI

Related Consulting Areas

KomuraSoft LLC handles consultations on designing encryption operations for Windows environments that include business applications and equipment PCs (designing where recovery keys are stored, building it into kitting, BitLocker configuration on equipment PCs), and on performance verification and troubleshooting of business applications in an encrypted environment. It’s fine to start simply by checking whether it’s safe to encrypt an equipment PC.

• Technical Consulting & Design Review
• Windows Application Development
• Bug Investigation & Root-Cause Analysis
• Contact Us

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

I noticed "Device encryption" had come on by itself. Is it okay to turn it off?

Turning it off is not recommended. On a clean install of Windows 11 version 24H2 or later, Device encryption initialises by default on PCs that meet conditions such as having a TPM and Secure Boot, so it can look as though it "switched itself on". This is the mechanism that protects your data in the event of loss or theft; switching it off loses that protection, and once you turn it off it does not automatically re-enable itself. What you should do is not disable it, but check the recovery key with a command such as manage-bde -protectors -get C: and make sure it ends up stored wherever your organisation has decided — a Microsoft account, Entra ID, or AD, for example.

Where is the BitLocker recovery key?

Where it is stored depends on how the PC signs in. For a PC set up with a personal Microsoft account, signing in to https://aka.ms/myrecoverykey with the same account lists it. For a PC joined to your company's Entra ID (a work account), check "View BitLocker keys" at https://aka.ms/aadrecoverykey. For a PC joined to an on-premises AD domain, if the policy has been configured, an administrator can retrieve it from under the computer object. There may also be a printed copy, a USB drive, or a saved file. Matching the first 8 digits of the recovery key ID shown on the recovery screen lets you identify the correct key.

Can I use BitLocker on a Windows 11 Home PC?

Which features are available depends on the edition. Full-featured BitLocker, including adding a PIN and policy management, can only be enabled on the Pro/Enterprise/Education family; it is not available on Home. The simplified counterpart, Device encryption, is available on every edition, including Home, and turns on automatically if requirements such as TPM and UEFI Secure Boot are met. However, enabling protection requires signing in with a Microsoft account that has administrator rights — a local account alone provides no protection. If you are managing it as a company PC, we recommend a configuration that assumes Pro and centrally manages recovery keys through Entra ID or AD.

After a BIOS (UEFI firmware) update, I was asked for the recovery key. Why?

BitLocker uses the TPM to verify that the boot environment has not been tampered with, and when the boot-time measurements change — because of a firmware update, a Secure Boot configuration change, clearing the TPM, a motherboard replacement, and so on — it judges the environment to be "different from usual" and enters recovery mode. This is not a fault; it is behaviour working as designed. Before a planned update, suspending protection with Suspend-BitLocker (or manage-bde -protectors -disable C:) lets you carry out the work without entering the recovery key. The drive stays encrypted while suspended, and by default protection resumes automatically at the next reboot.

If the recovery key can't be found, can the data still be retrieved?

Without the correct recovery key (the 48-digit recovery password) or another unlocking method, there is no way to retrieve the data on the encrypted drive. Microsoft Support itself states plainly that it cannot reissue or retrieve a lost recovery key. For an organisation-managed PC, check with IT first; for a personal PC, look at the Microsoft account recovery key page, a printed copy, or a .bek/.txt file on a USB drive. If none of that turns anything up, nothing remains but resetting (reinstalling) the PC, and the data is lost. That is exactly why, before debating whether to switch encryption off, you should first confirm that every PC's recovery key is under the organisation's control.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.