Skip to main content
Managed Device Attestation, India

Your access policy trusts a certificate. Can it tell whether that certificate is still on the laptop you issued it to?

Most Indian enterprises now gate sensitive systems on a device certificate, and almost none can answer that question. Managed Device Attestation closes the gap in silicon: the key is minted inside the Secure Enclave and never leaves it, so the certificate carries evidence about the hardware instead of a claim the device makes about itself. Three named attacks stop working the day you turn it on. We assess whether your estate can actually run it, then deploy it. Remote-first from Gachibowli, Hyderabad.

Book an attestation readiness reviewSee what it proves
Apple Managed Device Attestation for Indian 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.

  • Silicon decides who is eligible, and there is no way to argue with it. A11 Bionic or newer on iPhone, iPad and Apple TV; Apple silicon on Mac. An Intel MacBook is simply out, permanently, so wherever Intel still makes up a real share of your fleet, your addressable population is capped until procurement moves it.
  • Then the OS bar: iOS 16, iPadOS 16.1, macOS 14, tvOS 16 or newer. Teams pinned to older builds because one line-of-business application refuses to move are excluded too, and unpinning them is somebody else project with its own politics.
  • The certificate authority is where the real effort sits. Attestation runs over ACME only, so a SCEP shop needs an issuing path that speaks ACME, an authority that can actually validate what the device attests, and a window where both protocols run side by side.
  • None of this adds up to a refusal. It usually adds up to a dated plan pinned to your hardware refresh rather than a rollout you start this quarter, and one afternoon of counting tells you which of those two you are holding.
What attestation adds

Eight things to understand before you design around it.

Every certificate-based trust model rests on an assumption nobody tests: that the key is where you put it. Copy the key to another machine and the certificate keeps working, and your policy engine cannot tell. These eight points are what changes when the silicon vouches for the key instead.

Evidence, not assertion

Apple positions this as strong evidence about device properties that a trust evaluation can rely on. Put plainly: an ordinary enrolment takes the device at its word, while an attested one arrives with proof the device could not have manufactured.

The key is generated in the Secure Enclave

The private key is created hardware-bound, inside the Secure Enclave, by the operating system itself. Apple rates these keys as very strongly protected against extraction even when the Application Processor has been compromised, which is a bar software key storage simply cannot reach.

Three specific attacks it defeats

Apple names them: a compromised handset misreporting its own properties, a compromised handset presenting identifiers belonging to a different device, and a key lifted off one machine to stand up a rogue one. All three land against ordinary certificate estates. None survive attestation.

ACME rather than SCEP

Attestation only works over ACME, which Apple presents as the modern successor to SCEP for requesting and installing certificates. If your issuing infrastructure speaks SCEP today, budget for that migration as real work, because it gates everything else here.

HardwareBound and Attest are the two switches

Two keys in the ACME payload carry the whole feature. HardwareBound ties the private key to that specific device. Attest set to true makes the device send attestations describing itself and the key it just generated to the ACME server. Everything else is plumbing around those two.

Attested properties reach the certificate

Your management service asks for DevicePropertiesAttestation through a DeviceInformation query, and what comes back is written into custom OIDs on the leaf certificate, sepOS version and freshness code included. The evidence lives in the certificate, not in a log somewhere.

Freshness is enforced and rate limited

Send the optional DeviceAttestationNonce key when a cached answer will not do, and the device produces a fresh attestation. Just remember the ceiling: one DeviceInformation attestation per device per seven days. Design a weekly rhythm, not a polling loop.

Privacy is preserved under User Enrolment

Under User Enrolment, both the serial number and the UDID drop out of the attestation for privacy reasons. An employee-owned iPhone can therefore supply hardware-backed proof to your policy engine while staying untrackable as an individual device.

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.

  • Operating system minimums come first: iOS 16, iPadOS 16.1, macOS 14, tvOS 16 or newer. Anything frozen on an older release for compatibility reasons has to be freed before its attestation can feed an access decision.
  • Chip minimums come second and bite harder: A11 Bionic upward for iPhone, iPad and Apple TV, Apple silicon for Mac. Plenty of Indian offices still run Intel MacBooks bought in the 2019 to 2020 window, and those machines will never attest, whatever you do to them.
  • ACME is mandatory here. A SCEP-only certificate estate is looking at an infrastructure workstream with its own owner, its own timeline and its own testing, not a checkbox someone ticks during a maintenance window.
  • One consolation: the ACME payload itself reaches much further than attestation does, covering iOS, iPadOS, Shared iPad, macOS in both device and user modes, tvOS, watchOS 10 and visionOS 1.1. The migration you fund for attestation modernises issuance for the ineligible devices too.
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.

Eligibility is assessed before anything is recommended

We count your fleet against the chip and OS minimums before proposing anything at all. When a meaningful share of it falls short, the recommendation you get is a dated plan rather than a project kickoff, because a rollout that can only reach half your users is not worth your money.

The ACME move is its own workstream

Since attestation runs over ACME and nothing else, a SCEP shop is really buying two projects. We price and schedule the certificate authority work separately, with its own owner, because burying it inside an Apple workstream is precisely how these deployments stall at the halfway mark.

It connects to an actual access decision

Evidence nobody reads is wasted money. The engagement therefore includes the conditional access or network policy that treats an attested certificate differently from an ordinary one, because without that consumer you have paid for a better certificate that changes nothing about who gets in.

Monitoring is designed within the published limits

The weekly per-device ceiling is a design input, not an obstacle to route around. We build the checking cadence to sit inside it and keep the freshness nonce for the decisions that genuinely need a live answer, which is why our deployments do not start failing quietly in month two.

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-2

    Eligibility and gap analysis

    We reconcile your asset inventory against both minimums and come back with two numbers: how many devices can attest today, and what it would take to move the rest. That second list, not the technology, is what sets your schedule.

    • 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-5

    ACME certificate authority

    The heavy phase. Your authority needs to issue over ACME and, crucially, to check the attestations it receives rather than merely accepting them. Issuing policy, certificate lifetimes and the validation logic are all decided here.

    • 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-8

    Payload configuration and pilot

    Now the Apple side, which is the quick part. Both payload switches go on, the key type and size pairing gets validated against what hardware binding actually permits, and a pilot group enrols so we can inspect real certificates.

    • 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-10

    Trust evaluation and operations

    The attested identity starts driving real access decisions, and we document the unglamorous cases: what happens when someone swaps a laptop, downgrades an OS, or drops out of eligibility mid-quarter. Monitoring is built to respect the weekly query budget.

    • 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 an RBI-supervised or client-audited environment.

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 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. In a BYOD-heavy Indian workforce, 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 Indian 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.
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

    Your eligible population is decided by silicon and OS build, not by anything we configure. Intel Macs are permanently excluded, so this step produces a hard number that shapes every decision after it.

  2. 2

    Assess the certificate authority position

    Three questions about your authority: can it issue over ACME, can it validate the attestations that arrive, and what would running alongside your existing SCEP issuance look like while the migration completes.

  3. 3

    Design the payload and key material

    Both payload switches are set deliberately, and the key type and size pairing is chosen against what hardware binding permits rather than copied from a template that happened to work somewhere else.

  4. 4

    Pilot and verify the attested properties

    A pilot group enrols and we open the certificates they receive, looking for the attested properties written into the custom OIDs. Reading the artefact beats trusting a green tick in a console, because only the artefact proves the chain held end to end.

  5. 5

    Connect it to a trust decision and operate it

    Finally the policy that acts on the attested identity goes live, monitoring is tuned to the weekly query budget, and we write down what your service desk does when a device stops qualifying after a repair or a replacement.

Straight answers

What organisations ask about Managed Device Attestation.

It supplies strong evidence about device properties that your trust evaluation can lean on, in Apple own framing. The everyday consequence is a shift in who is doing the vouching. Today your MDM asks a device what it is and writes down the reply. With attestation the reply arrives with hardware-generated proof attached, checked through the issuing chain, and then baked into the certificate the device shows at the door. The device stops being the source of truth about itself.

Two gates, and a device has to clear both. Software: iOS 16, iPadOS 16.1, macOS 14, tvOS 16 or newer. Hardware: A11 Bionic or better in iPhone, iPad and Apple TV, and Apple silicon in any Mac. An Intel Mac fails permanently no matter how current its macOS build is, and since a lot of Indian offices are still working through an Intel-era MacBook fleet, that single fact usually sets the entire programme timeline. So counting eligible devices is step one for us, before any design discussion, because the count decides whether you are buying a rollout or a roadmap.

For any device that is going to attest, yes. Apple requires ACME for this feature and positions it as the modern replacement for SCEP when requesting and installing certificates. If everything you issue today comes out of a SCEP pipeline, treat this as its own project: stand up ACME issuance, teach the authority to validate what the device attests, and run both protocols together while you migrate. Teams that file this under configuration rather than infrastructure are the ones whose attestation programme quietly dies at sixty percent, so we scope it separately, with a named owner and its own dates.

Inside the Secure Enclave, hardware-bound, created there by the operating system and never handed out. Apple rates the extraction resistance as very strong even where an attacker owns the Application Processor, and that single property is what the whole security case rests on. Compare it with a key sitting in a software keystore: root the machine, copy the key, install it elsewhere, and the certificate keeps opening doors from hardware you have never seen. Your infrastructure would have no way of noticing.

Three, and Apple names each one. First, a compromised device inventing its own posture, which is what makes an OS-version check meaningless when the thing reporting the version is the thing you are trying to measure. Second, a compromised device presenting identifiers that belong to another machine, the classic clone. Third, someone extracting the private key and standing up a rogue device with it. Every one of these works against a normal certificate rollout, and every one of them lands hardest exactly where organisations have invested most in device-based access control.

The two payload keys that carry the feature. Add HardwareBound and the private key is tied to that device. Set Attest to true and the device sends the ACME server attestations covering both itself and the key it just created. Switch on both and an ordinary certificate enrolment becomes an attested one. You pick them together with KeyType and KeySize, where the options are RSA plus the ECSECPrimeRandom curves P-192, P-256, P-384 and P-521, and the sizes that are legal depend both on the type you chose and on whether the key is hardware bound. That combination is worth validating in a pilot rather than assuming.

The attested properties land in custom OIDs on the leaf certificate itself, sepOS version and freshness code among them. That matters more than it sounds: the proof rides along with the certificate instead of evaporating after the issuance handshake, so anything downstream that can parse a certificate can read what the hardware vouched for. It is also our acceptance test on a pilot. We do not take the management console word for it, we pull an issued certificate and look for the attested properties in it.

Yes to both, and they pull in opposite directions. The optional DeviceAttestationNonce key forces the device to produce a brand new attestation, which is what you want when a cached answer would be worthless for the decision in front of you. Against that, the current ceiling is one DeviceInformation attestation per device every seven days. So your posture checking has to think in weeks, with the nonce held in reserve for the moments that genuinely warrant it. Build the monitoring around that budget and it behaves; build it as a polling loop and it will hit the wall immediately.

It does, and the privacy behaviour is the reason it fits Indian workplaces so well. Choose User Enrolment and the attestation deliberately leaves out both serial number and UDID. The employee personal iPhone can still hand your policy engine hardware-backed proof, while remaining impossible to single out as a specific device. Getting real assurance for the company without acquiring the ability to track the individual is a rare combination in device security, and it is why this is one of the few genuinely strong controls we can recommend without reservation inside a BYOD programme.

Coverage runs across iOS, iPadOS, Shared iPad, macOS in device and user modes, tvOS, watchOS 10 and visionOS 1.1. Notice that this list is wider than the set of devices that can actually attest, since attestation is fenced in by the chip and OS minimums. The useful consequence for budget conversations is that nothing is stranded: the ACME work you fund to enable attestation on eligible hardware also brings modern certificate issuance to the machines that cannot attest yet, and those machines inherit it automatically when they are replaced.

Frequently the answer is not yet, and we would rather tell you that than bill you for a partial rollout. When a large slice of the fleet is Intel Macs or pre-A11 iPhones, what you actually need is a schedule tied to procurement, not a deployment that can never cover more than a fraction of your users. Three things are still worth doing immediately, though: count the eligible devices, assess where your certificate authority stands on ACME, and design the mixed state where eligible hardware carries attested certificates while everything else carries conventional ones. That mixed state is where every organisation lives during the transition anyway, so designing it deliberately costs nothing extra.

Whichever system actually decides who gets in, which in most Indian enterprises means a conditional access policy or a network access control platform. This is the part teams forget: an attested certificate that nothing treats differently from an ordinary one has bought you precisely nothing, so we design the consuming policy inside the same engagement rather than leaving it as a follow-up nobody funds. Timelines land around six to ten weeks, almost entirely driven by where your certificate authority starts. Scoped per engagement with a quote on request. The first step needs nothing from us at all: open your asset inventory and count Apple silicon Macs and A11-or-later iPhones. Enquiries are answered within 4 business hours, and managed clients hold a 30 minutes response SLA.
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 Entra

The identity and conditional access layer that typically consumes a device trust signal.

Learn more

Apple device management India

The management foundation attestation builds on: enrolment routes, supervision and the estate discipline.

Learn more

macOS security hardening

The wider Mac security posture, of which hardware-backed device identity is one layer.

Learn more
References

Official documentation

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, and we will tell you which one you are looking at. Enquiries answered within 4 business hours.

Book an attestation readiness reviewExplore Apple device management