Latest / The Windows Podcast with Fexingo: Microsoft, PC, and Enterprise Windows Conversations / Windows 11 Is Quietly Mandating Enterprise Full Disk Encryption With BitLocker
Transcript
- Lucas: If today's tech conversation gave you something usable — and I hope it does — I want to flag that this show stays ad-free because a small group of listeners chips in a few bucks a month over at buy me a coffee dot com slash fexingo. Luna: Yeah, it's a really lean model. No sponsors, no tracking pixels, just people who find the Windows deep-dives useful. Lucas: Exactly. And that's honestly the only reason we can cover a topic like today's without softening it. So if you're getting value, that link is there. Okay — let's talk about the hard drive on every enterprise PC you manage. Starting this year, if it runs Windows 11 Enterprise or Education, BitLocker full-disk encryption is now on by default. Luna: Right. Microsoft has been pushing this direction for a while, but the 2025 feature update made it mandatory. No more opt-in during setup. Lucas: Correct. Previously, the OS would prompt you during OOBE — out-of-box experience — and you could click 'skip' or 'enable later'. Not anymore. If the hardware meets the prerequisites — TPM 2.0, Secure Boot, UEFI — the encryption starts automatically after the first logon. Luna: And this applies to both new deployments and upgrades. If you're imaging a machine with the latest Windows 11 Enterprise image, the drive gets encrypted before the user even sees the desktop. Lucas: Right. Microsoft's stated rationale is simple: data at rest is the single biggest attack surface in a mobile workforce. Their own telemetry shows less than 40 percent of enterprise Windows devices were encrypted as of mid-2025. That's a lot of laptops sitting in coffee shops with unencrypted SSDs. Luna: Forty percent is shockingly low. I'd have guessed closer to sixty or seventy given how long BitLocker has been around. Lucas: It's a classic IT gap. Encryption is deployed on new machines, but older ones slip through. Or the policy exists but isn't enforced. Or the recovery key isn't properly escrowed, so admins disable it to avoid support calls. Microsoft is essentially closing that gap by making the decision at the OS level instead of the admin level. Luna: Let's talk about the recovery key piece, because that's where the real headache lives. If BitLocker is mandatory, every device generates a 48-digit recovery key. Where does that key go? Lucas: It's escrowed automatically to the device's Entra ID object — formerly Azure AD — if the device is Entra joined or hybrid joined. If it's purely on-premises domain joined, the key goes to Active Directory. Microsoft's documentation says the key is also saved to the user's Microsoft account if they sign in with one, but enterprise devices usually suppress that. Luna: So the key is in the cloud or on-prem AD. That's fine for most orgs, but what about the edge case — a device that never connects to the internet during setup? Does encryption fail? Lucas: No, the encryption proceeds, but the key is stored in the TPM locally. The system prompts the user to back it up later. Microsoft really doesn't want a device to be unencrypted just because it's offline. They'd rather have a key that's temporarily local than no encryption at all. Luna: That makes sense from a security standpoint, but from a support desk standpoint, it's a nightmare. A user calls in saying their drive is locked after a motherboard replacement. The key isn't in Entra ID because the device never synced. Now what? Lucas: That's the exact scenario that keeps IT pros up at night. Microsoft's guidance is to use a BitLocker recovery password viewer if you have the key hash, but that requires the user to have printed or saved the key at initial setup — which most users don't. So the practical advice is: make sure your provisioning process includes a step that triggers key escrow to Entra ID before the device is handed off. There are PowerShell scripts and Intune compliance policies for that. Luna: And this mandate applies to all fixed drives, not just the OS drive. So if a laptop has a secondary SSD, that gets encrypted too. What about removable drives? USB sticks? Lucas: Those are not encrypted by default. The mandate covers internal fixed data drives. Removable media still requires explicit BitLocker To Go policy. But the OS drive and any fixed secondary drives — yes, automatically. Luna: Performance impact? I remember when BitLocker first came out, there was a noticeable slowdown on older hardware. Lucas: Modern SSDs with hardware encryption — which is to say nearly every NVMe drive sold in the last five years — see negligible overhead. Microsoft claims less than 2 percent performance penalty on reads and writes. In practice, most users won't notice. The bigger impact is on boot time. The TPM validates the boot chain before decryption, which adds maybe two to three seconds. That's the trade-off for full disk encryption. Luna: How does this compare to Apple's approach? FileVault has been on by default for Macs for years. Lucas: Apple actually took a similar path. Since macOS Lion, FileVault is offered during setup. Since 2018, it's enabled by default on all Macs with Apple silicon and T2 chips. But there's a key difference: FileVault uses the hardware encryption engine on the T2 or Secure Enclave, and the recovery key is escrowed to iCloud. Microsoft now does the same via Entra ID. The gap is that Apple's enrollment rate is much higher — north of 90 percent — because they control the entire stack. Microsoft's ecosystem is more fragmented, so they had to mandate it. Luna: And on the Linux side, LUKS is common but rarely mandatory. Ubuntu Server offers it, but desktop Linux usually leaves encryption to the user. Lucas: Right. So this move puts Windows Enterprise on par with the Mac ecosystem for out-of-box security. The question is whether IT departments are ready for the support implications. A forced encryption policy means every drive recovery request now goes through the help desk. If your org isn't used to that, you could see a spike in tickets. Luna: Microsoft has published some recommendations. They suggest testing the experience with a pilot group, ensuring help desk staff have access to the BitLocker recovery key viewer in the Entra admin center, and using Intune to monitor encryption status. They also recommend having a policy for retiring devices — wiping the keys before decommissioning. Lucas: One thing that surprised me is that this policy applies to Windows 11 Education as well. Universities often have a mix of student-owned and institution-owned devices. For institution-owned, it's fine. But if a student brings their own device and it's domain joined for some reason — that's rare, but possible — their personal data gets encrypted. The recovery key is escrowed to the university's Entra tenant. That creates a data ownership question. Luna: Hmm. That is a genuine concern. I think most universities don't join personal devices to the domain for that exact reason. But if they have a lab environment that's shared, this is relevant. Lucas: Exactly. The mandate only applies to Enterprise and Education SKUs. Windows 11 Pro and Home are unaffected — they still offer BitLocker device encryption as optional. So the typical consumer won't see this change. It's squarely aimed at the enterprise fleet. Luna: Let's zoom out for a second. This is the latest in a series of quiet mandates from Microsoft — starting with TPM 2.0, then Secure Boot, then Virtualization-Based Security, now BitLocker. It's a clear strategy: raise the security floor across the entire enterprise ecosystem. No more optional security features. Lucas: I think that's the right framing. Microsoft is treating security as a default configuration, not a checkbox. For IT admins, that means fewer devices left vulnerable because someone skipped a step during imaging. But it also means less flexibility. If you have a legacy application that doesn't play well with encrypted drives — like a custom bootloader or a dual-boot setup — you need to explicitly exempt that device via policy. And that exemption process is not trivial. Luna: How do you exempt a device? Is there a GPO or Intune setting? Lucas: Yes. There's a Group Policy setting under Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives. You can set 'Require additional authentication at startup' to 'Disabled', which effectively turns off the mandatory encryption. But Microsoft warns that this should only be used for devices that cannot meet the hardware requirements. In practice, you'd apply this to a specific OU or device collection in Intune. Luna: And I assume Microsoft will start reporting on compliance. They already have the BitLocker readiness assessment in the Windows Security Center. I imagine future updates will surface encryption status in the Microsoft 365 admin center. Lucas: They already do, actually. In the Microsoft 365 Defender portal, there's a device inventory view that shows encryption status. So if you're an admin, you can see exactly which devices are encrypted and which aren't. And if a device fails to encrypt — say, because it lacks a TPM — you get an alert. That's powerful for closing the gap. Luna: What about the user experience? The average enterprise user logs in, sees no change, and carries on. But if they ever need to recover their drive — after a BIOS update, for example — they'll be prompted for the recovery key. That can be jarring if they don't know what it is. Lucas: That's a real friction point. Microsoft has tried to mitigate it with the BitLocker Recovery Password Viewer for Active Directory — help desk can retrieve it. But the user has to call the help desk. And if the help desk doesn't have the right tools, the user is stuck. I think the best practice is to educate users: 'Your drive is encrypted. If you see a blue screen asking for a 48-digit key, call IT. Do not try to bypass it.' Luna: And one last thing: what about devices that are already encrypted with third-party solutions? Like Symantec or McAfee full-disk encryption. Does the Windows mandate override that? Lucas: Microsoft says that if a compatible third-party encryption solution is detected, Windows will not enable BitLocker. But the third-party solution must be registered with Windows Security Center. If it's not, Windows will treat the device as unencrypted and enable BitLocker anyway. So IT needs to ensure that any third-party encryption is properly integrated, or disable the automatic BitLocker enablement via policy. Luna: That's a potential landmine for orgs that migrated to a third-party tool years ago and haven't thought about it since. Lucas: Absolutely. I'd recommend every IT admin check their device compliance report before the next feature update rolls out. Because once the update applies, the encryption starts. And you don't want to find out about conflicts the hard way.