A certificate or passkey only proves that someone holds a private key, not that the key was generated and kept in a secure element on a genuine device, so relying parties that care about key provenance need hardware key attestation and need to verify it correctly. Android Keystore, Apple's Secure Enclave, TPMs and FIDO authenticators can each sign a statement saying where a key lives and what state the device is in. Verifying those statements is where most implementations fail: wrong trust anchors, no revocation checks, verification on the device itself, or checking the format but not the policy. This guide compares the main attestation mechanisms, explains what each actually proves, and gives a verification and rollout approach for passkeys, device certificates and non-human identities bound to hardware. It is written for identity, PKI and mobile security engineers and builds on the Hardware Root of Trust Guide.
Key takeaways
- Attestation is evidence about a key, signed by the hardware vendor's chain. It answers "was this key created in secure hardware, on what kind of device, in what state", which possession of the key alone cannot.
- Verify on a server you trust, never on the device. Google states plainly that a compromised Android system could fake a passing result if verification happens on the device.
- Trust anchors and revocation are part of the check. Android publishes its attestation roots and a revocation status list; FIDO publishes a signed Metadata Service BLOB; AD CS keeps EK stores or an EKpub allowlist. Skipping these turns attestation into theatre.
- Pick the assurance level you actually need. TPM attestation in AD CS ranges from "EK Trusted on Use" (low) to an EKpub allowlist (high); WebAuthn ranges from none to enterprise attestation that identifies a specific authenticator.
- Attestation has a privacy cost. Attestation certificates can correlate users, so consumer services usually request none or indirect, while enterprises use direct or enterprise attestation on managed authenticators.
What key attestation proves
Every hardware key attestation scheme follows the same pattern. The relying party sends a fresh challenge. The device generates a key inside protected hardware and returns the public key together with a statement, signed by an attestation key the hardware vendor certified at manufacture or provisioning, that binds the challenge, the key and selected device properties. The relying party verifies the chain to a vendor root it trusts, checks revocation, checks the challenge, and then applies its own policy to the attested properties.
Attestation proves origin and properties at the moment of key creation. It does not prove the device is still healthy later, that the user is who they claim to be, or that the app calling the key is benign. Pair it with ongoing device posture signals and normal authentication.
Mechanisms compared
| Mechanism | Hardware | Evidence format | Trust anchor | Key attested properties |
|---|---|---|---|---|
| Android Key Attestation (Keystore, KeyMint) | TEE (TrustedEnvironment) or StrongBox secure element | X.509 chain whose leaf carries the extension OID 1.3.6.1.4.1.11129.2.1.17 (KeyDescription) | Google attestation roots published at android.googleapis.com/attestation/root | Security level, challenge, key authorisations, RootOfTrust (verified boot state, bootloader lock), app package and signing certificate digests, optional device IDs |
| Apple Managed Device Attestation | Secure Enclave | Leaf certificate with device properties in custom OIDs, via ACME device-attest-01 or a DevicePropertiesAttestation query | Apple Certificate Authority from the Apple Private PKI Repository | Genuine Apple hardware, hardware-bound key, serial and UDID (omitted for User Enrollment), sepOS version, freshness code |
| TPM key attestation (AD CS) | TPM 2.0 via the Microsoft Platform Crypto Provider | Attestation in the certificate request; the CA adds an issuance policy OID | EKCA and EKROOT stores, or an EKpub hash allowlist | Key is TPM protected; which trust model succeeded |
| WebAuthn and FIDO2 attestation | Security keys, platform authenticators, TPMs | Attestation statement formats: packed, tpm, android-key, android-safetynet, fido-u2f, apple, compound, none | FIDO Metadata Service (MDS3) or the RP's own list | Authenticator model via AAGUID, certification status, attestation type |
Android Key Attestation in depth
The app generates a key in AndroidKeyStore with a server supplied challenge set through setAttestationChallenge and sends the resulting certificate chain to the server. Google's guidance for the server side:
- Chain: verify each signature and that the root is one of the Google attestation roots. Accept the current published set rather than one hardcoded certificate: Google lists previously issued roots and a newer root that began signing chains on 1 February 2026.
- Extension placement: use the attestation extension from the certificate closest to the root; only the first occurrence is trustworthy, because a later one could come from an attacker extending the chain.
- Revocation: check every certificate serial against the status list at android.googleapis.com/attestation/status, where entries are
REVOKEDorSUSPENDEDwith reasons such asKEY_COMPROMISEorSOFTWARE_FLAW. Honour the Cache-Control header rather than fetching on every request. - Provisioning: devices launching with Android 16 use Remote Key Provisioning only, and RKP certificates have shorter validity, so check expiry.
- Library: Google recommends its attestation verification library over custom ASN.1 parsers because it handles edge cases such as expiry rules.
Fields to apply policy to
| Field | Values | Typical enterprise policy |
|---|---|---|
attestationSecurityLevel and keyMintSecurityLevel | Software (0), TrustedEnvironment (1), StrongBox (2) | Reject Software; require StrongBox for the highest value keys if the fleet supports it |
attestationChallenge | Echo of the server nonce | Must match a single use, short lived nonce |
RootOfTrust.verifiedBootState | Verified, SelfSigned, Unverified, Failed | Require Verified |
RootOfTrust.deviceLocked | Boolean | Require locked bootloader |
attestationApplicationId | Package names and versions, SHA-256 digests of signing certificates | Must match your app's package and signing certificate |
ID attestation (ATTESTATION_ID_*) | Brand, device, product, manufacturer, model, serial, IMEI, MEID | Use only for managed corporate devices where binding to inventory is needed |
Apple Managed Device Attestation
Managed Device Attestation is available on iOS 16, iPadOS 16.1, macOS 14 and tvOS 16 or later, on devices with an A11 Bionic chip or later and Macs with Apple silicon. It has two uses. During certificate enrolment, an ACME server can use the device-attest-01 challenge to confirm the device is genuine Apple hardware, is a specific device in the organisation's inventory, is managed by the organisation's MDM and has a hardware-bound private key in the Secure Enclave. Separately, the MDM can send a DeviceInformation query for DevicePropertiesAttestation, optionally with a DeviceAttestationNonce to force a fresh result.
- Freshness limit: a fresh attestation is limited to one per device every seven days; request one after OS updates and occasionally at random to catch devices misreporting properties.
- Hardware-bound keys: the key is removed when the device is erased or restored, so dependent profiles must be reapplied.
- Failure handling: a failed attestation still returns a response with missing OIDs or no attestation, and Apple notes the cause is not stated because the device may be lying. Treat it as lower trust: deny access, flag for investigation or wipe and revoke certificates.
- Threat model: Apple lists a compromised device lying about properties, replaying an outdated attestation, sending another device's identifiers, private key extraction for use on a rogue device, and hijacked certificate requests.
See the Apple Declarative Device Management and Managed Device Attestation Guide for the MDM configuration side.
TPM key attestation for device certificates
Windows clients can prove to an enterprise CA that a certificate request's RSA key is protected by a TPM. The CA records which trust model succeeded as an issuance policy OID in the certificate, so relying systems such as VPN or Wi-Fi can require it.
| Trust model | How the CA decides | OID added | Assurance |
|---|---|---|---|
| User credentials | Trusts the EKpub the user supplies, validated only by domain credentials | 1.3.6.1.4.1.311.21.32 "EK Trusted on Use" | Low |
| Endorsement certificate | Validates the TPM's EK certificate against EKCA and EKROOT stores; accepts every TPM from a trusted manufacturer | 1.3.6.1.4.1.311.21.31 "EK Certificate Verified" | Medium |
| Endorsement key allowlist | EKpub SHA-2 hash must be in an administrator managed folder registered with EndorsementKeyListDirectories | 1.3.6.1.4.1.311.21.30 "EK Verified" | High |
On the template, select the Key Storage Provider category with the Microsoft Platform Crypto Provider, then set the Key Attestation tab to "Required, if client is capable" while piloting and "Required" when enforcing. The feature supports RSA keys only and enterprise CAs only. Protect the EKpub allowlist folder: anyone who can write to it can enrol a device. See the AD CS Security Guide if it is in your estate.
WebAuthn and passkey attestation
WebAuthn Level 3, a W3C Recommendation dated 25 August 2026, defines four attestation conveyance preferences: none, indirect, direct and enterprise. Enterprise attestation may uniquely identify the authenticator and is intended for controlled deployments; user agents must not provide it unless the browser or authenticator configuration permits it for that RP ID. The specification's attestation types are Basic (batch), Self, AttCA, AnonCA and None.
- Basic or batch attestation: the attestation key is shared by a batch of the same model; the spec notes the UAF protocol requires at least 100,000 devices to share a certificate, which aids privacy but means a leaked key affects the whole batch.
- Self attestation: signed with the credential key itself, which proves nothing about the hardware; treat it like none for policy.
- AAGUID and metadata: the AAGUID identifies the authenticator model; look it up in the FIDO Metadata Service, whose MDS3 BLOB is a signed file at mds3.fidoalliance.org that FIDO suggests downloading monthly and verifying to the GlobalSign R46 root. Commercial relying parties accept the Metadata Usage Terms.
- Synced passkeys: where a policy requires attestation from specific hardware models, check what your passkey providers return before enforcing, or you will block users. See the FIDO2 and WebAuthn Internals Guide and the Passkey Rollout Guide.
Where identity fits: attestation for non-human identities
Attestation matters as much for machines as for people. A device certificate used for 802.1X or VPN, a mobile app's signing key for API calls, or a workload key on a server is a non-human identity, and attestation is what stops an attacker exporting the key or minting a lookalike on a rogue device.
- Device certificates: require a TPM or Secure Enclave attested key for Wi-Fi, VPN and MDM identities, and record the attestation result in the certificate (AD CS OIDs) or the inventory.
- App to API trust: bind API client keys to attested Android keys with matching
attestationApplicationId, so a cloned app or emulator cannot obtain the same trust. See the OAuth Attestation-Based Client Authentication Guide. - Workloads: server and confidential computing attestation is covered in the Workload Attestation Guide; the same verification discipline applies.
How to implement
- Define the decision: write down which access decision attestation feeds (enrol a passkey, issue a device certificate, trust an API client) and the minimum properties required.
- Choose trust anchors and revocation sources: Google roots and status list, Apple CA, EKCA and EKROOT or an EKpub allowlist, FIDO MDS3. Automate their refresh.
- Build server side verification: use vendor libraries where offered, issue single use nonces with short expiry, and log the full attestation result, not just pass or fail.
- Run in observe mode: collect attestation results for a pilot population without enforcing (AD CS "Required, if client is capable" is the built-in version) and measure how many devices fail and why.
- Enforce in rings: enforce for privileged users and corporate devices first, then the wider fleet, with a documented exception path for unsupported hardware.
- Roll back: keep enforcement as a policy flag so you can revert to observe mode if a root rotation, OS update or provider change causes mass failures.
Detection and measurement
- Verification failures by reason: chain untrusted, revoked or suspended certificate, challenge mismatch, software security level, unverified boot. A spike in one reason usually means a platform change or an attack tool.
- Revocation hits: any attestation chaining to a revoked key is a strong signal of a leaked attestation key or emulator.
- Duplicate identities: the same serial or EKpub appearing from two places, which Apple's threat model calls out as sending another device's identifiers.
- Stale attestations: devices whose last fresh attestation is older than policy.
Metrics: share of device certificates carrying an attestation OID or record; share of passkey registrations with a verified attestation where policy requires it; attestation verification failure rate per platform; days since trust anchor and MDS refresh; number of active exceptions.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | IA-3 Device Identification and Authentication; IA-5(2) Public Key-based Authentication; SC-12 Cryptographic Key Establishment and Management; SR-11 Component Authenticity; SI-7 Software, Firmware, and Information Integrity | Device identity, PKI authentication, key protection, genuine hardware, boot integrity |
| NIST CSF 2.0 | PR.AA-01; ID.AM-01; PR.DS-01 | Credentials for hardware managed, hardware inventory, data at rest protection |
| W3C WebAuthn Level 3 | Attestation conveyance, attestation types, attestation privacy | Passkey and security key attestation |
| MITRE ATT&CK | T1552.004 Private Keys; T1649 Steal or Forge Authentication Certificates | Threats hardware-bound, attested keys reduce |
| ISO/IEC 27001:2022 Annex A | 8.1 User end point devices; 8.24 Use of cryptography; 8.5 Secure authentication | Endpoint, cryptography and authentication controls |
Common failure patterns
- Verifying on the device: the result is only as trustworthy as the possibly compromised OS doing the checking.
- Hardcoding one root: Android root rotation in 2026 breaks verifiers pinned to a single certificate, and teams then disable checks to restore service.
- No revocation check: leaked attestation keys from older provisioning remain usable to forge "hardware" results until the status list is consulted.
- Accepting self or software attestation: treating a well-formed statement as proof of hardware even when the security level is
Softwareor the type is Self. - Low assurance by default: AD CS templates left on the user credentials model, so any domain user can vouch for any TPM.
- Reused or long lived challenges: nonces that are predictable or reusable let an attacker replay an old attestation from a genuine device.
Practitioner checklist
- Document which access decisions rely on attestation and the required properties.
- Verify attestation only on servers, with vendor libraries where available.
- Automate refresh of Google roots and status list, Apple CA, FIDO MDS3 and AD CS EK stores.
- Use single use, short lived challenges bound to the session.
- Reject
Softwaresecurity level, Self attestation and unverified boot where hardware is required. - Prefer the EKpub allowlist or EK certificate model over user credentials in AD CS for high value templates.
- Pilot in observe mode, then enforce in rings with a documented exception process.
- Monitor failure reasons, revocation hits and duplicate device identifiers.
Standards and references
- W3C: Web Authentication Level 3
- Android Open Source Project: Key and ID attestation
- Android Developers: Verify hardware-backed key pairs with key attestation
- Apple: Managed Device Attestation
- Microsoft: TPM Key Attestation
- FIDO Alliance: Metadata Service
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Hardware Root of Trust Guide · FIDO2 and WebAuthn Internals Guide · Apple Declarative Device Management and Managed Device Attestation Guide · Workload Attestation Guide · Wallet Unit Attestation and Device-Bound Keys Guide