What Is Device Attestation? Apple, Android and Windows Explained

Device attestation is hardware-backed proof of what a device is and what state it is in. Instead of trusting what the device says about itself, a server asks the device's secure hardware (the Secure Enclave on Apple devices, the TPM on Windows PCs, the hardware-backed keystore on Android) to sign a statement, and a vendor service vouches that the signature came from genuine hardware. Apple calls its version Managed Device Attestation, Android has key attestation and the Play Integrity API, and Windows uses TPM-based health attestation.

Why device attestation matters

Most device checks rely on data the device reports: its serial number, OS version, whether it is encrypted. Malware or a cloned identity can lie about all of those. Attestation closes that gap. The claim is signed by a key that lives in secure hardware and cannot be copied out, so a server can trust that:

• the request comes from a real device of a known make, not an emulator or a stolen certificate on another machine;
• properties such as the serial number or boot state are what the hardware says they are;
• a certificate issued to the device is tied to that device's hardware and cannot be moved.

That is why zero trust access and certificate-based Wi-Fi, VPN and MDM enrollment increasingly ask for it.

Apple: Managed Device Attestation

Managed Device Attestation lets an MDM or certificate server get proof, from Apple, about a device's identity. Apple describes the flow in its Platform Security guide:

1. The server asks for attestation, through the MDM or through an ACME certificate request.
2. The operating system asks the Secure Enclave for a hardware attestation.
3. Apple's attestation servers check it and return an attestation certificate that states properties such as the serial number and UDID.
4. The MDM or ACME server validates that certificate before it trusts the device or issues it a certificate.

With ACME, the Secure Enclave can also generate the key pair for the device certificate. The private key is bound to the hardware: Apple notes it cannot be exported and does not survive a backup and restore, even onto the same device. The ACME payload uses P-256 or P-384 keys. Apple's deployment guide lists where hardware-bound identities can be used, including MDM, Wi-Fi (802.1X), VPN and Kerberos.

Android: key attestation and Play Integrity

Key attestation

On Android, an app or management agent can create a key in the hardware-backed Keystore and ask for an attestation certificate chain. The chain, signed by a Google root, says that the key lives in secure hardware and records facts about the device, such as whether the bootloader is locked and the OS patch level. A server checks the chain against Google's root certificates. This is described in Android's developer documentation on key and ID attestation.

Play Integrity API

The Play Integrity API answers a different question for apps: is this a genuine Android device with Google Play, running an unmodified app? It replaced the older SafetyNet Attestation API.

Windows: TPM-based health attestation

Windows PCs measure the boot process into the TPM: firmware, boot loader, Secure Boot state, BitLocker and more. With device health attestation, those measurements are sent to an attestation service, which checks them and reports whether the device booted in a trusted state. Microsoft documents this as part of Windows device health attestation and Microsoft Azure Attestation; MDM and conditional access policies can then require a healthy result before a device reaches company resources. The report is signed by an attestation key that is rooted in the TPM's endorsement key, which is set at manufacture; that is what makes the report trustworthy.

How the three compare

Device attestation in MDM and zero trust

In practice, attestation shows up in three places:

• Enrollment. The MDM checks that a device is genuine before it trusts the enrollment.
• Certificates. Device certificates for Wi-Fi, VPN or SSO are issued to hardware-bound keys, so a stolen certificate is useless on another machine.
• Access decisions. A zero trust policy grants access only to devices whose attested state (boot integrity, OS version, management) meets the rules.

Support depends on the device and OS version and on whether your MDM and certificate server implement it, so check both before you build a policy around it. For the wider picture, see zero trust architecture.

Related reading: zero trust architecture and what is mobile device management.