You have a deadline. A patch window closes Friday. A reauthorization vote is on the calendar. A statutory response clock started the moment you noticed the incident. Somewhere in the middle of all that, someone — maybe you — assumed the laptop’s disk encryption was on because the drive showed a lock icon, or because the Settings toggle looked right, or because the machine came that way.
That assumption is the problem. “Encryption is on” is not a single fact. It is at least three separate facts: the volume is encrypted, the key that unlocks it is protected by something other than a bare credential, and the recovery path is intact and in your hands. A drive can satisfy the first and fail the second. Microsoft’s own documentation describes exactly that state.
This article walks through what you can verify today on Windows, using Microsoft’s primary documentation as the boundary. It states plainly what the available sources do and do not establish for macOS and Linux, rather than filling the gap with reassurance.
The question is not “is it encrypted?”
Microsoft describes BitLocker as “a Windows security feature that provides encryption for entire volumes, addressing the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned devices.” That is the threat model. It is not a claim that any particular laptop is protected right now.
The distinction that matters for verification is between encrypted and protected. Microsoft’s BitLocker documentation describes a state in which a drive is encrypted but the key protecting it is a clear key — functionally equivalent to a suspended state. In that condition, the data is encrypted on disk, but the protection you think you have is not yet in place. The documentation states that in this state, the drive is shown with a warning icon in Windows Explorer, and that the yellow warning icon is removed only after the TPM protector is created and the recovery key is backed up.
Read that again as a verification instruction: the icon is not proof of protection. The icon is a signal that something is incomplete. The completion condition is the existence of a TPM protector plus a backed-up recovery key.
Windows: BitLocker versus Device Encryption
Windows has two related mechanisms, and they behave differently.
BitLocker is the full feature. Microsoft’s documentation states that BitLocker provides maximum protection when used with a Trusted Platform Module (TPM), which works with BitLocker to ensure a device has not been tampered with while the system is offline. On devices without a TPM, BitLocker can still encrypt the operating system drive, but the documentation states the password option is discouraged and disabled by default because it lacks password lockout logic and is subject to brute-force attacks.
Device encryption is the automatic variant. Microsoft describes it as “a Windows feature that provides a simple way for some devices to enable BitLocker encryption automatically.” It requires the device to meet either Modern Standby or HSTI security requirements, and it cannot have externally accessible ports that allow DMA access. Critically for anyone checking a laptop: device encryption encrypts only the OS drive and fixed drives. It does not encrypt external or USB drives.
If you are checking a laptop that came with Windows preinstalled and you never deliberately configured BitLocker, you are most likely looking at device encryption, not a manually configured BitLocker deployment. That changes what you should check.
The clear-key state: encrypted but unprotected
Microsoft’s documentation describes the initialization sequence for device encryption in specific terms. When a clean installation of Windows completes and the out-of-box experience finishes, device encryption is initialized on the OS drive and fixed data drives “with a clear key that is the equivalent of standard BitLocker suspended state.” In this state, the drive shows a warning icon in Windows Explorer. The warning icon is removed after the TPM protector is created and the recovery key is backed up.
The documentation then describes what happens depending on how the device is joined:
- If the device is Microsoft Entra joined or Active Directory domain joined, the clear key is removed once the recovery key is successfully backed up to Microsoft Entra ID or Active Directory Domain Services.
- If the device is not joined to either, a Microsoft account with administrative privileges is required. When the administrator signs in with a Microsoft account, the clear key is removed, a recovery key is uploaded to the online Microsoft account, and a TPM protector is created.
- If the device uses only local accounts, Microsoft states plainly: “it remains unprotected even though the data is encrypted.”
That last sentence is the one to carry into any procurement or compliance conversation. A laptop with a local-only account can be fully encrypted and still leave the data accessible without a credential, because the clear key is still in play. The encryption is real. The protection is not.
What to check on Windows, in order
Microsoft documents one specific check for device encryption eligibility: the System Information app, msinfo32.exe. If the device meets the requirements, System Information shows a line reading “Device Encryption Support” with the value “Meets prerequisites.” That tells you the hardware qualifies. It does not tell you the current protection state.
For the current state, the signals Microsoft’s documentation gives you are:
- The warning icon in Windows Explorer. If it is present on the OS drive or a fixed data drive, the documentation indicates the drive is in the clear-key state. That is an incomplete configuration, not a protected one.
- The Settings UI. Microsoft states that the Settings UI does not show device encryption as enabled until encryption is complete. So a Settings toggle that reads “on” is meaningful only after encryption has finished. A toggle that reads “off” is unambiguous.
- Recovery key backup. The documentation ties removal of the clear key to successful backup of the recovery key — to Entra ID, AD DS, or a Microsoft account, depending on how the device is joined. If the recovery key is not backed up anywhere you can reach, the clear key may still be present.
One more documented behavior worth knowing: if device encryption is turned off, Microsoft states it will no longer automatically re-enable itself. The user must enable it manually in Settings. A laptop that had encryption disabled at some point will not quietly fix itself.
What the available sources do not establish for macOS
The retrieved Apple documentation is the Disk Utility User Guide index. It includes a topic titled “Encrypt and protect a storage device with a password,” and it advises formatting a new flash drive or other storage device as APFS and encrypting it with a password to protect its contents.
That is the full extent of what the retrieved source supports. It does not state FileVault’s default state, the exact on-screen indicator that confirms FileVault is enabled, how FileVault keys are escrowed, or how to verify recovery-key custody. Those are the questions a verification-first check would need to answer, and the source in hand does not answer them.
So the honest position is this: on macOS, the check that matters is whether FileVault is enabled and whether the recovery key is held somewhere you can reach. Apple’s Platform Security guide and the FileVault section of Apple Support are the primary sources to consult for the exact steps. Until those are retrieved and read, this article will not assert a menu path, a command, or a default state for FileVault. Guessing at a menu path is worse than saying you have not verified it.
What the available sources do not establish for Linux and LUKS
The cryptsetup FAQ was not retrievable for this article, and no other primary Linux source was retrieved. That means no claim here about LUKS, cryptsetup, luksDump, or how to interpret its output. The commands exist and are documented upstream, but this article will not reproduce them from memory. A verification procedure that cites a command it has not checked against the current upstream documentation is not a verification procedure.
If you are responsible for Linux endpoints, the primary sources to read are the cryptsetup project documentation and your distribution’s own disk-encryption guide. The check you are looking for is whether the LUKS header is present on the device and whether the volume is currently unlocked — those are two different states, and the second one is the one that matters for a running machine.
Recovery-key custody is the part people skip
Microsoft’s documentation makes the recovery key the completion condition for device encryption. The clear key is removed only after the recovery key is backed up. That means the recovery key is not an afterthought — it is part of the protection state.
This creates a trade-off that should be made deliberately. If the recovery key is escrowed to an organizational account, an administrator can recover the data, and so can anyone who compromises that account. If the recovery key is held only by the user, recovery depends on the user not losing it. Microsoft’s documentation describes the escrow destinations — Entra ID, AD DS, or a Microsoft account — but it does not tell you which is right for your situation. That is a decision about who can reach your data, and it belongs to you or your organization, not to a default.
For a small business or a freelancer, the practical question is: if this laptop is lost or the drive is removed, who can actually get the data back, and under what conditions? If the answer is “nobody” or “I don’t know,” the recovery path is not intact, regardless of what the encryption status says.
The ceiling on self-verification
Everything above is the operating system reporting on itself. You can confirm what Windows says about its own encryption state. You cannot, from the outside, independently confirm the cryptographic implementation, the correctness of the key derivation, or the absence of a flaw in the TPM interaction. That is a real limit, and it should be stated rather than papered over.
The BSI notes that “secure cryptographic primitives, algorithms and schemes are indispensable basic building blocks for IT-security mechanisms to ensure the confidentiality, integrity and authenticity of digital information,” and that because cryptology is an active field of research, continuous evaluation and further development are necessary. That is the general framing: cryptographic protection is a moving target, and the evaluation of it is ongoing work. It is not a statement that any particular product or configuration is sufficient.
What self-verification gives you is a check on configuration, not a proof of security. That is still worth doing, because misconfiguration is common and the clear-key state is documented.
What to do today
Pick one laptop. On Windows, open File Explorer and look at the OS drive and any fixed data drives. If a warning icon is present, the drive is in the clear-key state per Microsoft’s documentation — the encryption is not yet backed by a TPM protector and a backed-up recovery key. Check whether the device is joined to Entra ID, AD DS, or a Microsoft account, or whether it uses only local accounts. If it uses only local accounts, Microsoft’s documentation states it remains unprotected even though the data is encrypted.
Then find the recovery key. If you cannot locate it, the completion condition Microsoft describes has not been met. That is the step to finish today, before the patch window closes or the vote happens or the response clock runs out.
For macOS and Linux, the honest next step is to read the primary sources — Apple’s Platform Security guide and FileVault support pages, and the cryptsetup documentation for your distribution — and run the checks they specify. This article will be updated when those sources are retrieved and verified. Until then, the Windows check above is the one you can complete now.