Latest / The Windows Podcast with Fexingo: Microsoft, PC, and Enterprise Windows Conversations / Windows 11 Quietly Mandates Enterprise Device Attestation for VPN Access
Transcript
- Lucas: If you manage enterprise VPNs on Windows, there's a quiet mandate coming that might force you to rethink your entire remote access setup. Starting with Windows 11 version 24H2 and Server 2025, Microsoft is deprecating the old Remote Access role in favor of a new one that requires device attestation for every connection. Luna: Device attestation meaning the VPN server checks that the client machine has a healthy TPM and a valid health certificate before it even allows the tunnel to form? Lucas: Exactly. It's not optional. If you try to configure a traditional username and password VPN on a new Windows Server build, the wizard actually blocks you. You have to set up Network Policy Server with health policies that require TPM attestation, or the connection fails with a generic 'access denied'. Luna: That's a big shift. Most enterprises I talk to still use RADIUS with PEAP-MSCHAPv2 or even just a shared secret for their VPN. They don't have a PKI for machine certificates. Lucas: Right. And that's the core tension here. Microsoft's direction is zero trust—don't trust the device just because it has a username. Verify that it's actually your hardware, running your software, with no tampering. But the infrastructure to do that—Active Directory Certificate Services, proper TPM provisioning, Windows Hello for Business—that's a heavy lift for a lot of IT teams. Luna: Quick honest thing—we can keep digging into these details because a handful of listeners chip in monthly through buy me a coffee dot com slash fexingo, and that directly funds the research time for episodes like this. So thanks if you're one of them. Lucas: Yeah, it makes a real difference. And if today's tech conversation gave you something usable, you know where to find us. All right, back to the attestation rollout. Luna: So when exactly does this become mandatory? I've seen some conflicting dates. Lucas: The official cutover is June 24, 2026—that's today actually. As of this date, new installations of Windows Server 2025 with the Remote Access role will only support the attestation-based connection method. Existing servers on older Windows Server versions aren't forced to update, but Microsoft has announced that all future cumulative updates for Server 2022 will gradually deprecate the legacy VPN protocol handlers. Luna: So enterprises on Server 2022 have a grace period, but anyone deploying fresh hardware today is stuck. Lucas: Correct. And I think the real story isn't the date itself—it's what happens when IT teams try to set this up for the first time. I talked to a manufacturing company in Ohio last week that has 800 field workers connecting via a classic SSTP VPN. They tried to migrate to the new attestation model and hit three roadblocks: no certificate authority, no TPM 2.0 on about 200 of their older laptops, and no process to issue health certificates at scale. Luna: That's a pretty common profile. Mid-sized enterprise, mixed hardware fleet, no dedicated PKI admin. How did they even know about the mandate? Lucas: They found out when their new Server 2025 test box wouldn't accept the old connection. The setup wizard literally has a checkbox that says 'allow connections without device attestation' but it's grayed out unless you install a separate legacy feature pack that Microsoft has flagged as deprecated. So the option exists, but it's clearly not the path forward. Luna: And that legacy feature pack—how long will it be supported? If a company relies on that, they're just kicking the can. Lucas: That's the thing. The legacy pack is only guaranteed through October 2027, which lines up with the extended support end date for Server 2022. After that, no more security updates for the old VPN stack. So the real deadline for most enterprises is actually October 2027, not June 2026, but the clock starts ticking the moment you try to deploy a new server. Luna: Let's talk about what device attestation actually checks. Is it just TPM presence, or does it also verify firmware versions, Secure Boot state, that kind of thing? Luna: So basically, if a device has been jailbroken or has an unsigned driver, that machine can't connect to the corporate VPN. That's a strong security boundary. Lucas: It is. And honestly, it's a good thing for security posture. But the operational friction is real. I've seen IT admins who spent days setting up a simple VPN now spending weeks just designing the PKI hierarchy. One hospital system I know had to stand up a separate offline root CA just to meet the attestation requirements, because their existing CA was an enterprise CA that had been running for 15 years and had some trust issues. Luna: And those trust issues—were they related to certificate revocation lists that were never properly published? Lucas: Exactly. Their CRL distribution point was a shared folder on a domain controller that had been decommissioned. So when the NPS tried to validate the health certificate, it couldn't check revocation status, and the connection was denied. That's a classic gotcha that the documentation doesn't highlight well. Luna: What about alternatives? If an enterprise doesn't want to build a full PKI, can they use a third-party VPN that still supports traditional auth? Lucas: Sure. Cisco AnyConnect, Palo Alto GlobalProtect, even WireGuard-based solutions don't require Windows device attestation. But if you're using Microsoft's Remote Access role—which is what most SMBs and mid-market firms rely on—you're tied to the new model. And even third-party solutions are starting to add attestation checks via API integrations with Windows Defender for Endpoint or Intune compliance policies. Luna: So the direction is clear, even if the path varies. Let's talk about the cost. Standing up a proper PKI with two-tier CA, auto-enrollment, and TPM provisioning—what's the ballpark for a 1,000-user shop? Lucas: For the software licensing alone, if you don't already have Windows Server CALs and Enterprise CA rights, you're looking at maybe $5,000 to $10,000 in initial licensing. But the real cost is time. A skilled infrastructure engineer can set up a basic two-tier CA in a week. But for most IT generalists, it's a month-long project with multiple test cycles. And then you have to touch every endpoint to ensure TPM 2.0 is enabled and that the attestation identity key is properly provisioned. Luna: And let's not forget that some older devices won't even have TPM 2.0. What does Microsoft say about those? Lucas: Officially, Windows 11 requires TPM 2.0 for the OS itself, so any device running Windows 11 should have it. But in practice, many enterprises bought Windows 10 devices that had TPM 2.0 but disabled in firmware. So the attestation check fails because the TPM isn't initialized. Microsoft's guidance is to enable TPM in BIOS and then run the 'Get-Tpm' PowerShell cmdlet to verify. If the TPM is not ready, you can't get a health certificate. Luna: That's another hidden cost. The help desk time to go through every laptop and enable TPM, especially if they're remote workers. Lucas: Right. And that's why I think this quiet mandate is going to catch a lot of organizations off guard. The June 2026 date is already here, but the real wave of pain will hit when they try to replace an aging VPN server or when a security audit flags non-compliance. I've already seen a few MSPs sending out panic emails to clients about this. Luna: So what's your advice for an IT manager listening today? First steps? Lucas: First, check if you're using the Windows Remote Access role. If so, inventory your VPN servers and note their OS version. If any are Server 2025 or you plan to upgrade soon, you need to start the PKI project now. Second, run a script to check TPM status on all domain-joined Windows 11 machines—use the 'Confirm-SecureBootUEFI' and 'Get-Tpm' cmdlets. Third, pilot the attestation flow with a small test group before rolling out widely. And fourth, consider whether you want to stick with Microsoft's stack or migrate to a third-party VPN that gives you more control over authentication methods. Luna: One thing I'd add: if you're using Azure ad joined devices, you can leverage Microsoft Entra ID's device-based conditional access policies to require attestation as part of the VPN connection, rather than building your own PKI. That might be a simpler path for cloud-first orgs. Lucas: Good point. The hybrid approach—using Intune to deploy a device compliance policy that checks attestation and then using a third-party VPN that integrates with Intune—could save a lot of complexity. At the end of the day, Microsoft is signaling that trust is moving from 'who you are' to 'what you have and what state it's in.' And that shift is irreversible. Luna: Even if it makes our jobs harder in the short term. Lucas: Yeah. But the alternative—letting an attacker use a compromised device to pivot into the corporate network—is worse. So we adapt.