This blog will cover the latest features in MDM Enrollment Version 6.0 and explain their significance for device attestation, virtual TPMs, and Intune. We’ll break down how this enrollment version update changes policy responses, what it means for Azure Attestation, and where support for Cloud PCs and vTPM scenarios seems to be headed.
Introduction
If you’ve tried running Windows Autopilot on a virtual machine or attempted to use device enrollment attestation with Microsoft Cloud PCs, you’re familiar with the issue. TPM attestation is required, but neither virtual TPMs nor Cloud PCs support it. Enrollment fails before you even get started, and for a long time, there was no way around it.
If you want more background on why device attestation matters, take a look at my other article:
MDM Enrollment Version 6 appears to be Microsoft’s first step toward addressing this gap. Although there is no official announcement, the protocol changes, new attestation nodes, and WIL features, such as VTpmAttestation, all suggest that the groundwork is being laid for future vTPM and Azure attestation support. But is it actually ready, and what can we prove today?
What is Enrollment Version?
When a Windows device enrolls in Intune, it doesn’t just send credentials and get a management profile. There’s a protocol handshake (Discovery), and a key part of that is the Enrollment Version. This number defines which features and policy schemas are supported during enrollment and management.
Note:
[MS-MDE2] (Mobile Device Enrollment Protocol Version 2) is the official Microsoft protocol specification that governs this process.
The “EnrollmentVersion” is a value exchanged between the device and the server during protocol negotiation. It determines which features and attestation capabilities are enabled for that enrollment session.
- Enrollment Version 5.0 is what almost every Windows environment has used since Windows 10 first launched. It sets the classic baseline for device management, policy delivery, and certificate handling.
- Enrollment Version 6.0 is a newer protocol version that introduces expanded policy support, especially for attestation scenarios and Azure integration.
The Enrollment Version is not just a number. It informs both the device and the MDM server of the expected level of capability. Higher versions enable new policy nodes, new security flows, and (eventually?) support for features such as virtual TPM attestation and Azure-backed trust.
Why This Even Matters
Classic MDM enrollment treats attestation as a hard requirement in certain scenarios. That works on real hardware, but virtual TPMs in VMs or Cloud PCs just cannot meet the strict attestation requirements. Enrollment Version 6 brings the first technical steps toward solving this, at least on paper.
Introducing EnrollmentVersion 6.0
Looking at recent builds and the dmenrollengine.dll, something stands out. In some cases, the device now requests Enrollment Version 6.0, but it doesn’t always receive it, only if the enrollment server (Intune) supports that version (GetServerHighestSupportedVersion).
If the server doesn’t support 6.0, the discovery response falls back to Enrollment Version 5.0. So why would a device request version 6.0? The answer lies in new features that have started to surface, most notably VTpmAttestation. (which is a name that makes me wonder what is coming)
The CreateDiscoveryMessage function checks the request version and looks for certain flags. If VTpmAttestation is detected, the device switches to request Version 6.0. This signals that the device wants to perform TPM attestation using the new policy logic. In plain terms, if the vTPM attestation feature is enabled, the device will try to use Enrollment Version 6.0.
What Enrollment Version 6 Changes: The Real Detail
So, what exactly changes with EnrollmentVersion 6.0? The most significant update comes in how TPM azure attestation is handled.
A new attestation node appears in the policy schema.
Instead of just having fields under privateKeyAttributes, there’s now an attestation node, with its own attributes:
- attestationFailureBehavior: Decides if enrollment fails, retries, or continues if attestation fails.
- operationTimeout: Controls how long the device keeps trying attestation before giving up.
- azureAttestation: Contains fields for a nonce, relying party ID, and endpoint URI, all needed for a cloud-based attestation flow.
These attestation nodes are only present if Enrollment Version 6 is used and supported by the server.
If not, you’re stuck with the old structure.
If both classic and attestation nodes are present, the new attestation nodes take precedence.
For example, if both privateKeyAttributes/OperationTimeout and attestation/operationTimeout are sent, the client uses the attestation version.
New Attestation Policies: With Version 6.0, the GetPoliciesResponse message can return new policies like attestationFailureBehavior and operationTimeout—critical for controlling what happens if attestation fails. These aren’t present in the 5.0 response.
Is This Real Attestation or Just Ignore and Continue?
Right now, here’s what really happens. If attestationFailureBehavior is set to IgnoreOnError, the client skips over any attestation errors and keeps enrolling. There’s no actual attestation occurring for vTPMs in this case; it’s merely a policy workaround.
The logic is clear:
- FailonError vs. IgnoreonError: A critical new addition is how attestation failures are handled. Depending on the policies sent by the server, the client can either fail the enrollment process if attestation fails (FailonError), or continue with a warning (IgnoreonError). This flexibility was missing in Version 5.0.
After spotting this code, the core purpose of this new “Enrollment Version 6.0” becomes clearer. Enrollment Version 6 focuses on Azure Attestation, where the client utilizes the nonce, relying party, and endpoint specified in the policy to communicate with Microsoft’s Attestation service and obtain a trusted response. Enrollment Version 6 is the only way for this new flow to be negotiated, but this attestation behavior flow is not yet enabled in production.
Connecting the Dots: Azure Attestation
These new attestation nodes are not just protocol details; they are direct hooks into the Microsoft Azure Attestation platform. As explained in my call4cloud deep dive, Azure Attestation is Microsoft’s answer for evaluating trust in devices, virtual machines, and cloud PCs.
When your policy contains nonce, relyingPartyId, and endpointUri under the attestation node, the client is instructed to communicate directly with Azure Attestation to validate device security. This is the only scalable and secure way to hopefully support vTPM and Cloud PC attestation. Until the server starts sending these values, however, the enrollment client cannot utilize Azure Attestation.
Reality Check: What Happens Today
Even though Windows now requests Enrollment Version 6 (as you’ll see in any Fiddler trace), the server is not yet sending the new attestation nodes in live policy responses.
No attestationFailureBehavior, no operationTimeout for modern attestation, and no Azure Attestation details. The live GetPoliciesResponse still looks like it did under Enrollment Version 5.0.
This means that while the groundwork is in place, Microsoft has not yet enabled real Azure-based attestation and vTPM support in production. There is no official confirmation or public roadmap, only protocol changes, feature flags like VTpmAttestation, and hints in the documentation.
Why This Is About VTpmAttestation (And Why It Matters)
While the real purpose of Enrollment Version 6 is to modernize device attestation using new Azure-backed services, another detail stands out. Alongside these attestation changes, we’ve started to see the VTpmAttestation feature appear in code and policy discussions.
This is not official documentation about this feature. Still, it clearly signals that Microsoft is laying the groundwork for vTPM and Cloud PC scenarios as part of its future attestation plans.
The protocol and policy schema now support these flows, and client-side logic is already present. The server-side is not yet active, and there has been no public statement from Microsoft. However, all technical evidence points in this direction. As soon as Microsoft enables the new attestation nodes and activates Azure Attestation for device enrollment, support for secure vTPM and Cloud PC onboarding may become possible???
What’s Next
As soon as these new policy nodes and Azure Attestation fields show up in real tenants, I will post a detailed breakdown of the flow, the logic, and what it means for Autopilot, Cloud PCs, and modern Windows enrollment.
If you want to understand what VTpmAttestation is really about, and why it matters for the next phase of device management, watch out for the next blog!