Latest / The Windows Podcast with Fexingo: Microsoft, PC, and Enterprise Windows Conversations / Windows 11 Quietly Mandates Enterprise Secure Boot Baseline
Transcript
- Lucas: If you manage Windows 11 Enterprise devices, there's a new Secure Boot baseline landing in preview builds that's going to change how you think about boot security. Microsoft is quietly mandating a specific set of Secure Boot policies — not just 'Secure Boot must be on,' but exactly which signatures are trusted at boot time. Luna: Right, this goes beyond the basic on/off toggle. So what's actually changing? Lucas: The core change is a new baseline policy that restricts which bootloaders and kernel drivers can load. Microsoft is publishing a set of allowed signing certificates — it's basically a whitelist. Anything not signed by one of those certificates won't boot. This targets legacy bootloaders, especially those used by some Linux distros or older Windows boot managers, and any unsigned kernel modules. Luna: So if you have a custom bootloader for a kiosk scenario or a recovery tool, that could break? Lucas: Exactly. And this isn't theoretical — the baseline is already in Windows 11 Enterprise 24H2 preview builds. IT admins who've enabled Secure Boot on those builds will start seeing boot failures if they have any non-compliant boot components. Microsoft's documentation says this baseline is 'recommended' for now, but the language in the security baseline settings suggests enforcement is coming. Luna: What's in the whitelist? Anything specific we know about? Lucas: Microsoft hasn't published the full list, but based on the preview documentation, it includes Microsoft's own certificates for Windows Boot Manager, the Windows OS loader, and a set of third-party certificates that have been vetted through the Microsoft UEFI CA program. Notably, it excludes many legacy certificates from hardware vendors that were used for older driver signing. Luna: That could be a headache for organisations running older hardware or custom boot environments. How do they audit compliance? Lucas: Good question. Microsoft is providing a PowerShell cmdlet — Get-SecureBootPolicy — that returns the current policy and its compliance status. There's also a new event log entry under microsoft windows kernel boot/Operational that logs any boot component that fails Secure Boot validation. IT teams can use these to check every device in their fleet. Luna: So it's not a surprise — you can proactively identify which machines will break. But the remediation path isn't always simple. Lucas: Right. For most standard Windows deployments, nothing changes. The default Windows bootloader is already signed correctly. The issues come with custom or third-party bootloaders. If you're running a Linux dual-boot scenario with GRUB, for example, you'd need a GRUB signed by a Microsoft-approved certificate. Some major Linux distributions have that, but many smaller ones don't. Luna: And what about kernel drivers? I imagine that's a bigger surface area. Lucas: It is. The baseline restricts which kernel-mode drivers can load at boot time. Drivers that are signed with an expired certificate or a certificate not in the whitelist will be blocked. This is aimed at rootkits and bootkits that load unsigned or malicious drivers early in the boot process. But it also means any legacy hardware driver that hasn't been resigned with a valid certificate will stop working. Luna: So this is another step in Microsoft's long-term push toward virtualization-based security and measured boot. What's the timeline? Lucas: The baseline is in preview now with 24H2 builds. Microsoft typically gives a year or so before enforcing changes in a future feature update. But given the security climate — with increased state-sponsored bootkit attacks — they may move faster. My bet is enforcement by late 2026 or early 2027. Luna: Which means IT admins should start auditing now. If you have devices that will break, you need a plan. Lucas: Absolutely. And this connects to something bigger. Microsoft is using Secure Boot as a foundation for other security features like Credential Guard and Hypervisor-Protected Code Integrity. If the boot chain isn't trusted, those higher-level protections are less effective. So this baseline is really about hardening the root of trust. Luna: That makes sense. If today was actually useful to you — and let's be real, if you manage Windows enterprise devices, this is the kind of heads-up that saves you from an outage — the way these shows stay ad-free is listener support. You can buy me a coffee at buy me a coffee dot com slash fexingo. Lucas: Yeah, it really helps. One coffee, no pressure, and it keeps the tech deep dives coming without any sponsor interruptions. We appreciate anyone who chips in. Luna: Alright, back to Secure Boot. So let's talk about what you should actually do if you're an IT admin today. First step? Lucas: First step: check which build you're on. If you're on 24H2 preview, run Get-SecureBootPolicy on a representative sample of devices. Look at the 'PolicyVersion' field — if it's anything other than matching the Microsoft baseline, you have a mismatch. Then check event log 5061 under microsoft windows kernel boot/Operational for any failures. Luna: And if you find failures? What's the fix path? Lucas: It depends. For standard Windows bootloader issues, a simple firmware update from the OEM often fixes it — they need to include the latest Microsoft UEFI CA certificate. For third-party bootloaders, you need to get a signed version from the vendor. For custom in-house tools, you'll need to sign them with a certificate that chains to an approved CA — either Microsoft's or one in the UEFI signature database. Luna: That's not trivial. And it's worth noting that this affects not just bootloaders but also Option ROMs on add-in cards — like some RAID controllers or network boot cards. Lucas: Great point. Those Option ROMs are also subject to Secure Boot validation. If your enterprise relies on a specific storage controller with an unsigned Option ROM, you'll need to work with the vendor to get a signed version. Some vendors have been slow to update, so this could be a real pain point. Luna: So the message is: don't wait. Start auditing now, talk to your hardware vendors, and plan for a transition. The security benefits are real, but the migration has to be managed. Lucas: Exactly. And I think one thing that's easy to overlook is that this baseline also affects virtual machines. If you're running Windows 11 Enterprise as a guest on Hyper-V or VMware, Secure Boot is often passed through from the host. So even VMs need to comply if the host enforces the baseline. Luna: That's a good callout. It's not just physical devices. So the scope is broader than it first appears. Lucas: Yeah. And that's why we're spending an episode on it. This is one of those quiet changes that could cause a lot of noise if you're not prepared. But if you're proactive, it's manageable. Luna: Alright, let's leave listeners with one action item: this week, run Get-SecureBootPolicy on your Windows 11 Enterprise devices and check the event log. That's it. You'll know where you stand. Lucas: And if you hit issues, reach out to your hardware vendor and Microsoft support early. The worst time to discover a boot failure is during a patching cycle. Plan ahead.