We value your privacy

We use cookies to analyse site traffic and improve your experience. You can accept all cookies or reject non-essential ones. See our Privacy Policy for details.

GR IT SERVICES
  • Contact
Get a quote
  2. Apple device management
  3. Managed Device Attestation
Managed Device Attestation, UAE

A certificate proves somebody had the key. Attestation proves which piece of hardware generated it.

Managed Device Attestation provides strong evidence about device properties for a trust evaluation. The private key is generated inside the Secure Enclave, and it protects against three specific attacks that a normal device certificate does not.

Book an attestation readiness reviewSee what it proves
Apple Managed Device Attestation for UAE organisations
  • Secure EnclaveWhere the hardware bound key is generated
  • ACMERequired when using attestation
  • iOS 16+With A11 Bionic or later
  • 7 daysCurrent attestation query limit per device
The honest framing

This is not a setting. For most estates it is a programme with a hardware dependency.

We would rather say that up front than start work that can only ever cover part of the population.

  • The hardware floor is absolute. iPhone, iPad and Apple TV need the A11 Bionic chip or later, and Mac needs Apple silicon. Intel Macs cannot participate at all, so in an estate with meaningful Intel presence the eligible population is fixed until the refresh cycle moves it.
  • The software floor is iOS 16, iPadOS 16.1, macOS 14 or tvOS 16 or later. Devices held back on older releases for application compatibility are outside the capability, and resolving that is usually a separate piece of work with its own owner.
  • The certificate infrastructure requirement is the largest single item. Use of ACME is required when using Managed Device Attestation, so a SCEP based estate needs an ACME issuing path, a validation capability at the authority and a coexistence period.
  • None of that means the answer is no. It means the answer is often a dated plan tied to the refresh cycle rather than a deployment starting this month, and knowing which one you are looking at is worth an afternoon of assessment.
What attestation adds

Eight things to understand before you design around it.

Device certificates have been the standard trust signal for years, and they share a weakness: a certificate proves possession of a key, not that the key still lives on the device it was issued to. Attestation closes that gap in hardware.

Evidence, not assertion

Apple describes it as providing strong evidence about which properties of a device can be used as part of a trust evaluation. The difference from a normal enrolment is that the device is no longer simply telling you what it is and being believed.

The key is generated in the Secure Enclave

The operating system generates a hardware bound private key inside the Secure Enclave. Apple states such keys have very strong protections against key extraction, even in the case of a compromised Application Processor, which is a materially higher bar than software key storage.

Three specific attacks it defeats

A compromised device lying about its properties. A compromised device sending a different device identifiers. Private key extraction for use on a rogue device. Each of those is achievable against a conventional certificate deployment and none of them against attestation.

ACME rather than SCEP

Apple describes ACME as a modern alternative to SCEP, a protocol for requesting and installing certificates, and states that use of ACME is required when using Managed Device Attestation. Estates on SCEP therefore have a certificate infrastructure change to plan.

HardwareBound and Attest are the two switches

If HardwareBound is added, the private key is bound to the device. If Attest is true, the device provides attestations describing the device and the generated key to the ACME server. Those two payload settings are what turn certificate enrolment into attested enrolment.

Attested properties reach the certificate

A device management service can issue a DeviceInformation query requesting a DevicePropertiesAttestation property, and attested properties are returned in custom OIDs on the leaf certificate, including the sepOS version and the freshness code.

Freshness is enforced and rate limited

A management service can send an optional DeviceAttestationNonce key which forces a fresh attestation. Usage is currently limited to one DeviceInformation attestation per device every seven days, so continuous polling is not the design pattern.

Privacy is preserved under User Enrolment

Serial number and UDID are both omitted when using User Enrolment, to protect the user privacy. Personally owned devices can therefore participate in attestation without surrendering the identifiers that would make the device individually trackable.

The eligibility question

Not every device in your estate can do this. Check before you design.

Attestation has hardware and software floors, and both are absolute rather than negotiable.

  • The software floor is iOS 16, iPadOS 16.1, macOS 14 or tvOS 16 or later. Estates with devices held back on older releases for application compatibility reasons need that resolved before attestation can form part of an access decision.
  • The hardware floor is the A11 Bionic chip or later for iPhone, iPad and Apple TV, and Apple silicon for Mac. Intel Macs cannot participate, which for many UAE organisations still running Intel hardware is the constraint that shapes the rollout timeline.
  • Use of ACME is required when using Managed Device Attestation. If your certificate infrastructure is SCEP based, that is a genuine project rather than a setting change, and it belongs in the plan as its own workstream with its own timeline.
  • The ACME payload is supported across iOS, iPadOS, Shared iPad, macOS device, macOS user, tvOS, watchOS 10 and visionOS 1.1, so the payload reach is broad even where attestation eligibility is narrower.
Ask us to check your estate
How we approach it

Four things that decide whether attestation is worth doing now.

This is one of the few Apple capabilities where the honest answer is sometimes not yet. The hardware floor and the certificate authority requirement are real constraints.

We assess eligibility before recommending anything

iOS 16, iPadOS 16.1, macOS 14 or tvOS 16 or later, with A11 Bionic or later on iPhone, iPad and Apple TV and Apple silicon on Mac. Where a substantial part of the estate falls below those floors, the honest answer is to plan for it rather than start it.

We treat the ACME move as its own workstream

Use of ACME is required when using Managed Device Attestation. For an estate on SCEP that is a certificate infrastructure project with its own timeline and risk, and pretending it is a payload change is how these deployments stall halfway.

We connect it to an actual access decision

Attestation provides strong evidence for a trust evaluation, which means it only pays back if something consumes that evidence. We design the access policy that uses the attested identity, otherwise the work produces a better certificate that nothing treats differently.

We design monitoring within the published limits

Attestation usage is currently limited to one DeviceInformation attestation per device every seven days, and a nonce forces freshness when needed. Monitoring designed against that limit works, monitoring designed as continuous polling does not.

How a deployment runs

Four phases across roughly six to ten weeks.

Longer than most Apple work, because the certificate authority side usually needs changing. The Apple configuration itself is the small part.
  1. 01
    Weeks 1 to 2

    Eligibility and gap analysis

    Which devices meet iOS 16, iPadOS 16.1, macOS 14 or tvOS 16 and the A11 Bionic or Apple silicon hardware floor. That produces an eligible population and a remediation list, and the remediation list usually drives the timeline more than anything else.

    • Eligible device population identified
    • Intel Mac and pre-A11 hardware listed for replacement
    • OS version remediation plan agreed
    • Current certificate infrastructure documented
  2. 02
    Weeks 3 to 5

    ACME certificate authority

    Use of ACME is required when using Managed Device Attestation, so any SCEP based infrastructure needs an ACME path. This is the substantial workstream, and it involves the certificate authority, the issuing policy and the validation of attested properties.

    • ACME issuing capability established or confirmed
    • Attestation validation designed at the issuing authority
    • Certificate policy and lifetimes agreed
    • Coexistence with existing SCEP issuance planned
  3. 03
    Weeks 6 to 8

    Payload configuration and pilot

    HardwareBound binds the private key to the device and Attest instructs the device to provide attestations describing the device and the generated key to the ACME server. KeyType and KeySize are set together, since valid sizes depend on the type and on hardware binding.

    • ACME payload configured with HardwareBound and Attest
    • KeyType and KeySize combination validated
    • ClientIdentifier strategy agreed
    • Pilot group enrolled and certificates verified
  4. 04
    Weeks 9 to 10

    Trust evaluation and operations

    The attested certificate becomes an input to access decisions, and the operational side covers what happens when a device becomes ineligible. Attestation queries are limited to one per device every seven days, so monitoring is designed around that rather than against it.

    • Access policy consuming the attested identity
    • Attestation query cadence within the published limit
    • Failure and ineligibility handling documented
    • Rollout to the wider eligible population
Where this matters

Six situations where attestation changes the security position.

The pattern is an organisation whose access control already depends on device identity, and which has never asked how strong that identity actually is.

A financial services firm gating access on device trust

Where a device certificate is the gate to sensitive systems, the strength of that certificate is the strength of the control. Attestation moves it from an assertion the device makes to evidence about the hardware, which is a materially different claim in a review.

An organisation building a zero trust access model

Zero trust designs treat device posture as a signal, and a signal is only as good as its provenance. Attested properties returned in custom OIDs including the sepOS version give the policy engine something verifiable rather than something reported.

A business worried about cloned device identity

A compromised device sending another device identifiers is a real attack against conventional certificate deployments. Attestation defeats it specifically, and it is worth knowing that this is a named threat Apple designed against rather than a theoretical concern.

An estate where certificates live in software key storage

Private key extraction for use on a rogue device is the third named threat. A hardware bound key generated in the Secure Enclave resists extraction even where the Application Processor is compromised, which software key storage cannot claim.

A BYOD programme that still needs device assurance

Serial number and UDID are omitted under User Enrolment to protect privacy, so a personally owned device can present attested evidence without surrendering identifiers that make it individually trackable. That combination is rare and useful.

An organisation modernising away from SCEP

ACME is described by Apple as a modern alternative to SCEP and is required for attestation. Organisations already considering that migration can carry attestation as part of the same programme rather than paying the transition cost twice.

Three positions

How UAE organisations establish that a device is really theirs.

The right column is still common and it is the weakest position, because it treats a network location or a username as evidence about hardware.
Hardware identity proven
Attested device certificatesYes
Conventional device certificatesNo
No device identityNo
Key extraction resisted
Attested device certificatesSecure Enclave protected
Conventional device certificatesDepends on storage
No device identityNot applicable
Identifier spoofing defeated
Attested device certificatesYes
Conventional device certificatesNo
No device identityNo
Property misreporting defeated
Attested device certificatesYes
Conventional device certificatesNo
No device identityNo
Usable as a trust evaluation input
Attested device certificatesStrong evidence
Conventional device certificatesWeak evidence
No device identityNone
Protocol
Attested device certificatesACME
Conventional device certificatesCommonly SCEP
No device identityNot applicable
Works on Intel Mac
Attested device certificatesNo
Conventional device certificatesYes
No device identityYes
Preserves privacy under BYOD
Attested device certificatesSerial and UDID omitted
Conventional device certificatesAs configured
No device identityNot applicable
Effort to deploy
Attested device certificatesWeeks, CA dependent
Conventional device certificatesUsually already in place
No device identityNone
Defensible in a security review
Attested device certificatesYes
Conventional device certificatesPartially
No device identityNo
Feature
Attested device certificates
Conventional device certificates
No device identity
Hardware identity proven
YesNoNo
Key extraction resisted
Secure Enclave protectedDepends on storageNot applicable
Identifier spoofing defeated
YesNoNo
Property misreporting defeated
YesNoNo
Usable as a trust evaluation input
Strong evidenceWeak evidenceNone
Protocol
ACMECommonly SCEPNot applicable
Works on Intel Mac
NoYesYes
Preserves privacy under BYOD
Serial and UDID omittedAs configuredNot applicable
Effort to deploy
Weeks, CA dependentUsually already in placeNone
Defensible in a security review
YesPartiallyNo
What changes

Conventional device certificates against attested certificates.

The left column is how most estates issue device identity today. The differences are in what an attacker can do, not in what an administrator sees day to day.
PropertyConventional certificateWith Managed Device Attestation
Proves possession of a keyYesYes
Proves which hardware generated the keyNoYes
Key protected against extractionDepends on storageSecure Enclave protected
Survives a compromised application processorNot necessarilyKey extraction still resisted
Device can claim another device identifiersPossibleDefeated
Device can misreport its propertiesPossibleDefeated
Enrolment protocolCommonly SCEPACME required
Attested properties in the certificateNoCustom OIDs including sepOS version
Freshness controlNoneDeviceAttestationNonce
Identifiers under User EnrolmentAs configuredSerial and UDID omitted
How an engagement runs

Five steps, and the first can end the conversation honestly.

If the estate does not meet the hardware floor, the right recommendation is a plan and a date rather than a deployment. We say so rather than starting work that cannot finish.
  1. 1

    Establish eligibility across the estate

    iOS 16, iPadOS 16.1, macOS 14 or tvOS 16 or later, with A11 Bionic or later and Apple silicon on Mac. Intel Macs cannot participate at all, so the eligible population is a hardware fact rather than a configuration outcome.

  2. 2

    Assess the certificate authority position

    Use of ACME is required when using Managed Device Attestation. We establish whether an ACME issuing capability exists, whether it can validate attestations, and what a transition from SCEP would involve including a coexistence period.

  3. 3

    Design the payload and key material

    HardwareBound to bind the private key to the device, Attest to have the device provide attestations describing the device and the generated key to the ACME server, and a KeyType and KeySize combination that is valid given both settings.

  4. 4

    Pilot and verify the attested properties

    Certificates issued to a pilot group and inspected for the attested properties in custom OIDs, including the sepOS version and the freshness code. Verification at the certificate rather than in the console is what proves the chain actually worked.

  5. 5

    Connect it to a trust decision and operate it

    An access policy that consumes the attested identity, monitoring designed within the one attestation per device every seven days limit, and a documented path for devices that become ineligible through hardware replacement or a downgrade.

Straight answers

What organisations ask about Managed Device Attestation.

Apple describes it as providing strong evidence about which properties of a device can be used as part of a trust evaluation. The practical difference is that the device is no longer simply asserting what it is, with your infrastructure taking that assertion on trust.

Devices with iOS 16, iPadOS 16.1, macOS 14 or tvOS 16 or later. iPhone, iPad and Apple TV additionally require the A11 Bionic chip or later, and Mac requires Apple silicon. Intel Macs cannot participate regardless of the macOS version they run.

Yes. Apple states that use of ACME is required when using Managed Device Attestation, and describes ACME as a modern alternative to SCEP for requesting and installing certificates. For a SCEP based estate that is a genuine infrastructure workstream.

The operating system generates a hardware bound private key inside the Secure Enclave. Apple states such keys have very strong protections against key extraction, even in the case of a compromised Application Processor, which is the core of the security argument.

Apple names three: a compromised device lying about its properties, a compromised device sending a different device identifiers, and private key extraction for use on a rogue device. All three are achievable against conventional certificate deployments.

Two ACME payload settings. If HardwareBound is added, the private key is bound to the device. If Attest is true, the device provides attestations describing the device and the generated key to the ACME server. Together they turn certificate enrolment into attested enrolment.

Attested properties are returned in custom OIDs on the leaf certificate, including the sepOS version and the freshness code. That means the evidence travels with the certificate rather than existing only as a transient check at issuance time.

Yes. A device management service can send an optional DeviceAttestationNonce key, which forces a fresh attestation. That matters where a stale attestation would be an acceptable answer to a question you are asking about the device right now.

Yes. Usage is currently limited to one DeviceInformation attestation per device every seven days. Monitoring and posture checks therefore have to be designed around a weekly cadence rather than as continuous polling of the attestation endpoint.

Yes, and with a privacy protection. Serial number and UDID are both omitted when using User Enrolment to protect the user privacy, so a personally owned device can present attested evidence without exposing the identifiers that make it individually trackable.

RSA and ECSECPrimeRandom curves including P-192, P-256, P-384 and P-521. The valid KeySize values depend on the KeyType and on whether HardwareBound is set, so those settings are chosen together rather than independently.

The ACME payload is supported across iOS, iPadOS, Shared iPad, macOS device, macOS user, tvOS, watchOS 10 and visionOS 1.1. Payload availability is therefore broader than attestation eligibility, which is bounded by the hardware and OS floors.

Often not yet, and we will say so. Where a significant part of the estate is Intel Mac or pre A11 hardware, the sensible output is a plan tied to the refresh cycle rather than a deployment that can only ever cover part of the population.

Whatever makes your access decisions, typically a conditional access or network access policy. Attestation only pays back when something treats the attested certificate differently from an ordinary one, so that consumer is part of the design rather than a later step.

We scope by estate size, eligibility percentage and whether an ACME issuing capability already exists. The free first step: count how many of your Macs are Apple silicon and how many iPhones are A11 Bionic or later. That percentage decides whether this is a project or a plan.

It changes how they are issued and what they prove. The certificate still performs the same role in your access control, but it now carries attested evidence about the hardware in custom OIDs rather than resting on the device assertion alone.

In practice most organisations have to, because eligibility is bounded by hardware. A coexistence period where eligible devices carry attested certificates and the remainder carry conventional ones is the normal shape of a transition.

It needs to issue through ACME and to validate the attestation the device provides. That validation is the part that makes the evidence meaningful, so confirming the authority can perform it is an early question rather than a late one.

No. A device management service can send an optional DeviceAttestationNonce key when it wants to force a fresh attestation. Whether you need that depends on whether a stale attestation would be an acceptable answer to the question you are asking.

Serial number and UDID are omitted under User Enrolment to protect privacy, so a personally owned device can present attested evidence without exposing identifiers that make it individually trackable. That combination is unusual and genuinely useful.
Readiness assessment

Fifteen questions that determine whether this is a project or a setting.

If the answers in the first two groups are good, this is a few weeks of work. If they are not, the hardware and certificate authority questions set the timeline.

Device eligibility

  • Are iPhones and iPads on iOS 16 or later?
    iPadOS 16.1 for iPad.
  • Are they A11 Bionic or later?
    A hardware floor.
  • Are Macs on Apple silicon?
    Intel cannot participate.
  • Are Macs on macOS 14 or later?
    The software floor.
  • Any Apple TV in scope?
    tvOS 16 or later.

Certificate infrastructure

  • Do we have an ACME issuing capability?
    Required for attestation.
  • Are we currently on SCEP?
    Then this is a project.
  • Can the CA validate attestations?
    The critical capability.
  • What certificate lifetime do we want?
    Decide with the policy.
  • How will SCEP and ACME coexist?
    Usually a transition period.

Design

  • Will we set HardwareBound?
    Binds the key to the device.
  • Will we set Attest to true?
    Enables the attestation itself.
  • Which KeyType and KeySize?
    Valid sizes depend on both.
  • Do we need the nonce for freshness?
    Forces a fresh attestation.
  • Have we planned around the seven day limit?
    One query per device.
Related reading

The pages around this one.

Microsoft Cloud PKI

Certificate issuance for managed devices.

Learn more

Conditional Access

What consumes a device trust signal.

Learn more

macOS management

The wider Mac management picture.

Learn more
Next step

Count how many of your Macs are Apple silicon and how many iPhones are A11 Bionic or later.

That percentage decides whether Managed Device Attestation is a deployment you can start now or a plan tied to your refresh cycle. Both are legitimate answers.

Book an attestation readiness reviewCall +971 56 613 2743

Related Services

Explore more solutions that work great with this service

Microsoft Cloud PKI

Retire the certificate server, NDES and the Intune connector

Learn more

Entra Conditional Access

The control that decides who reaches your data

Learn more

macOS Management Dubai

FileVault, admin rights, updates and the Rosetta deadline

Learn more

Apple Device Management

Mac and iPhone fleets, encryption, patching and the September cycle

Learn more

iPhone and iPad Management

Remove company data from a phone you do not own

Learn more

Account-driven User Enrolment

Apple BYOD enrolment where the employee owns the device.

Learn more

Managed Apple Accounts

Org owned Apple identity, federation and the published service exclusions.

Learn more

Device Enrolment

Which path, which reset, and what you can enforce after

Learn more
GR IT SERVICES

Leading IT services provider in Dubai,
delivering enterprise-grade solutions
for businesses across the UAE.

Microsoft CSP PartnerCISGuard

Get the Helpdesk app

Raise and track IT tickets from your phone.

Download on the App StoreGet it on Google Play
Learn more about the app

Microsoft 365

  • Microsoft 365 Administration
  • M365 Reporting & Auditing
  • Microsoft 365 Licensing
  • Microsoft Copilot
  • Microsoft 365 Apps
  • Windows 365 Cloud PC
  • Microsoft SharePoint
  • Outlook & Exchange

Security

  • Microsoft Defender
  • Microsoft Purview
  • Microsoft Intune
  • Microsoft Entra
  • Compliance Manager
  • Cybersecurity Audits
  • Copilot for Security
  • Microsoft Sentinel
  • Microsoft Priva

Infrastructure

  • Google Workspace
  • Cloud Migration Services
  • Data Analytics & BI
  • Active Directory
  • Server Management
  • Apple Business
  • Apple Jamf Pro
  • IP Telephone
  • Data Backup
  • Website Development

IT Services

  • Managed IT Services
  • IT Support Dubai
  • IT AMC Dubai
  • New Office IT Setup
  • IT Relocation
  • Remote IT Support
  • On-Call IT Support
  • Startup IT Business Kit
  • Disaster Recovery & BC

Company

  • About Us
  • Careers
  • Contact
  • Blog

Contact

  • Iris Bay Tower, Office 903,
    Business Bay, Dubai, UAE
  • +971 56 613 2743
  • hello@gritservices.ae
  • gritservices.ae

© 2026 GR IT Services. All rights reserved.

Privacy PolicyTerms of UseCookie Policy