This week is all about adding an additional layer of protection to the enrollment of Windows devices. That additional layer of protection is Windows enrollment attestation. Windows enrollment attestation is focused on making the process of enrolling into Microsoft Intune more secure and trustworthy for Windows devices. It relies on using the Trusted Platform Module (TPM) to store the private keys of the MDM certificate from Microsoft Intune and the access token from Microsoft Entra. That information is attested during the enrollment of Windows devices, making it less prone to tampering. That should provide better protection against attackers that for example steal an Intune MDM certificate. This blog post will start with a brief introduction about Windows enrollment attestation, followed with the central insights and the available remote actions.
Important: Windows enrollment attestation is not supported for VMs, not even with vTPMs. Physical devices only.
Introducing Windows enrollment attestation
When looking at the enrollment of Windows devices, the security of that enrollment process becomes more and more important. That’s exactly where Windows enrollment attestation comes into play. Windows enrollment attestation adds an additional layer of security to the enrollment process of Windows devices, with the focus on making it more secure and trustworthy. That additional security and trustworthiness is achieved by relying on storing the private keys of the MDM certificate and the access token on the local TPM. That information is retrieved during the registration with Microsoft Entra, followed with the attest and enrollment with Microsoft Intune. Attesting the availability of that information in the TPM makes sure that only trusted Windows devices can perform the enrollment with Microsoft Intune. The great part is that the information can now also be actually used during the enrollment of Windows devices. A new property is available per device that can be used to create a filter. That new property is device.IsTpmAttested and that can be used to create a filter that can be used with enrollment restrictions.
Note: Windows enrollment attestation can be used to prevent enrollment of Windows devices that are not attested.
Verifying Windows device attestation status
The good thing is that the device attestation status is now also available in a report. That report provides an overview of the attestation of all Windows devices within the environment and is available in the Microsoft Intune admin center via Reports > Device management > Device attestation status. An example is provided below in Figure 1. That example is filtered to show a few of the most important and most impactful properties, being Device Model, OS Version and Device Attestation Status. The latter is of course pretty obvious as it indicates the status of the device attestation. The other two properties are important as only physical devices are supported and only Windows versions after a specific version.
Note: Of course the availability of TPM 2.0 is also important, but that’s pretty standard nowadays.
Attesting Windows devices remotely
When devices are showing as not successfully attested, for whatever reason, a remote action can be triggered to attest the device. That action can be triggered via the Device attestation report, as shown below in Figure 2, by simply selecting the device and clicking on Attest. That will trigger a remote action similar to any remote action for a device. It will also be visible within the Device actions status overview of the device, as the initiateMobileDeviceManagementKeyRecovery action. That action will initiate an MDM key recovery and TPM attestation that basically locally on the device triggers the InitiateRecovery action of the DMClient CSP (and a bit more).
Filtering Windows devices based on the attestation
The best part of Windows device attestation is the enrollment part, making it Windows enrollment attestation. That provides us with the ability to verify before the enrollment of a device, if that device is attested. For that, the new property IsTpmAttested is available. That property is not yet available, but can be configured via the rule syntax. That filter rule can then be used to configure specific enrollment restrictions. The following steps walk through the process of creating a filter rule for devices that are not attested.
- Open the Microsoft Intune admin center portal navigate to Devices > Organize devices > Filters
- On the Devices | Filters page, click Create > Managed devices
- On the Basics page, specify a unique name for the filter, select Windows 10 and later as platform and click Next
- On the Rules page, as shown below in Figure 3, edit the rule syntax, specify device.IsTpmAttested -eq “False” and click Next
- On the Review + create page, verify the configuration and click Create
After the creation of the filter, it can be used to block the enrollment of the devices that match that filter. In other words, devices that have not successfully attested. That can be achieved by using a Device enrollment restriction. When a device is being enrolled that is not successfully attested, an error will show similar to the header image.
More information
For more information about Windows enrollment attestation, refer to the following docs.
- Windows enrollment attestation | Microsoft Learn
- DMClient CSP | Microsoft Learn
- initiateMobileDeviceManagementKeyRecovery action – Microsoft Graph beta | Microsoft Learn
- Boost security with Microsoft Intune device attestation | Microsoft Intune blog
Discover more from All about Microsoft Intune
Subscribe to get the latest posts sent to your email.
Thanks for the clear write-up Peter!
One part I wasn’t able to distill is how the certificates are initially provisioned to the TPM – e.g. are they doing something nice like ACME with DA or is a cert generated on the infra side and then somehow either pre-installed or provisioned during autopilot enrolment – have you found that?
I would say the latter. It’s, however, not really clear documented. I know that Rudy looked a little bit under the hood and wrote this story: https://call4cloud.nl/2024/07/istpmattested-enrollment-attestation/
Regards, Peter
Thank you! That does seem to confirm that the cert is initially created outside of the TPM.
It is pretty unclear if Windows Enrollment Attestation occurs during a User Driven Autopilot provisioning or if it is only triggered during self-deploying and pre-provisioning.
It’s for all physical devices with TPM2.0.
Regards, Peter
My question is not about the type of TPM, but about when this attestation occur. Will a user will be allowed to perform a user driven Autopilot if this enrollment restriction is in place? I mean will the TPM will be attested before Intune enrollment kicks in during a user driven Autopilot provisioning?
It’s also for user driven deployments. That’s why I mentioned “all devices”.
Regards, Peter