Managed Device Attestation for Apple devices
Managed Device Attestation is a feature in iOS 16, iPadOS 16.1, macOS 14, tvOS 16 or later. Managed Device Attestation provides strong evidence about which properties of a device can be used as part of a trust evaluation. This cryptographic declaration of device properties is based on the security of the Secure Enclave and the Apple attestation servers.
Managed device attestation helps protect against the following threats:
A compromised device lying about its properties
A compromised device providing an outdated attestation
A compromised device sending a different device’s identifiers
Private key extraction for use on a rogue device
An attacker hijacking a certificate request to trick the CA into issuing the attacker a certificate
For more information, see the WWDC22 video What’s new in device management.
Supported hardware for Managed Device Attestation
Attestations are issued to only devices that meet the following hardware requirements:
iPhone, iPad and Apple TV devices: With the A11 Bionic chip or later.
Mac computers: With Apple silicon.
There are no changes to Managed Device Attestation for Apple Watch and Apple Vision Pro.
Managed Device Attestation with ACME certificate enrolment requests
An organisation’s issuing Certification Authority (CA) ACME service can request an attestation of the enrolling device’s properties. This attestation provides strong assurances that the properties of the device (for example, the serial number) are legitimate and not spoofed. The issuing CA’s ACME service can cryptographically validate the integrity of the attested device properties and optionally cross-reference them against the organisation’s device inventory and, upon successful verification, confirm that the device is the organisation’s device.
If attestation is used, a hardware-bound private key gets generated inside the device’s Secure Enclave as part of the certificate-signing request. For this request, the ACME-issuing CA can then issue a client certificate. This key is tied to the Secure Enclave and is therefore available only on a specific device. It can be used on iPhone, iPad, Apple TV and Apple Watch with configurations supporting specification of a certificate identity. On a Mac, hardware-bound keys can be used for authentication with MDM, Microsoft Exchange, Kerberos, 802.1X networks, the built-in VPN client and built-in network relay.
Note: The Secure Enclave has very strong protections against key extraction, even in the case of a compromised Application Processor.
These hardware-bound keys are automatically removed when erasing or restoring a device. Because the keys are removed, any configuration profiles relying on those keys won’t work after a restore. The profile must be applied again to get the keys recreated.
Using ACME payload attestation, MDM can enrol a client certificate identity using the ACME protocol that can cryptographically validate that:
The device is a genuine Apple device
The device is a specific device
The device is managed by the organisation’s MDM server
The device has certain properties (for example, the serial number)
The private key is hardware bound to the device
Managed Device Attestation with MDM requests
In addition to using managed device attestation during ACME certificate enrolment requests, an MDM solution can issue a DeviceInformation query requesting a DevicePropertiesAttestation property. If the MDM solution wants to help ensure a fresh attestation, it can send an optional DeviceAttestationNonce key, which forces a fresh attestation. If this key is omitted, the device returns a cached attestation. The device attestation response then returns a leaf certificate with its properties in custom OIDs.
Note: Serial number and UDID are both omitted when using User Enrolment to protect the user’s privacy. The other values are anonymous and include properties such as the sepOS version and the freshness code.
The MDM solution can then validate the response by evaluating that the certificate chain is rooted with the expected Apple Certificate Authority (available from the Apple Private PKI Repository), and if the hash of the freshness code is the same as the hash of the freshness code provided in the DeviceInformation query.
Because defining a freshness code generates a new attestation — which consumes resources on the device and Apple’s servers — usage is limited currently to one DeviceInformation attestation per device every seven days. An MDM solution should not immediately request a fresh attestation every 7 days. It’s not considered necessary to request a fresh attestation unless a device’s properties have changed; for example, an update or upgrade to the operating system version. Plus an occasional random request for a fresh attestation may help catch a compromised device that is trying to lie about those properties.
Handling failed attestations
Requesting an attestation may fail. When that happens, the device still responds to the DeviceInformation query or ACME server’s device-attest-01 challenge, but some information is omitted. Either the an expected OID or its value is omitted, or the attestation is omitted entirely. There are many potential reasons for a failure, such as:
A network issue reaching the Apple attestation servers
The device hardware or software may be compromised
The device is not genuine Apple hardware
In these last 2 cases, the Apple attestation servers refuse to issue an attestation for properties that they can’t verify. There is no trustworthy way for the MDM solution to know the exact cause of a failed attestation. This is because the only source of information about the failure is the device itself, which may be a compromised device that’s lying. For this reason, responses from the device don’t indicate the reason for the failure.
However, when Managed Device Attestation is used as part of a zero trust architecture, the organisation can calculate a trust score for the device, with a failed or unexpectedly stale attestation lowering that score. A lowered trust score triggers different actions, such as denying access to services, flagging the device for manual investigation, or compliance escalations by wiping it and revoking its certificates when necessary. This ensures an appropriate response to a failed attestation.