Why ACME Is the Right Certificate Enrollment Protocol for Your iOS Devices

Imagine this: an employee loses their iPhone on a Friday evening. By Saturday morning, someone has used that device to authenticate to your corporate Wi-Fi and connect to your VPN — because the SCEP certificate on the phone has no hardware binding whatsoever. The certificate works perfectly on any device that holds it. Your security team has no visibility that the phone is no longer in authorized hands until Monday, when IT is notified. The breach window is 60 hours.

This is not a hypothetical. It is the fundamental architectural weakness of SCEP — the protocol that has managed enterprise certificates for over two decades. The certificate is portable. The device is not verified. The trust model is broken.

Apple’s native ACME support in iOS 16, combined with Managed Device Attestation (MDA), closes this gap permanently. Every certificate is anchored cryptographically to the specific physical hardware that enrolled for it, inside the device’s Secure Enclave. The certificate cannot be copied, exported, or used on any other device — ever.

In this guide, we discuss why ACME supersedes SCEP for Apple device certificate management, how the protocol works end-to-end, what you can do with these certificates once issued, and how BastionXP makes ACME deployment seamless for your organization.

SCEP vs. ACME: Understanding the Difference

SCEP has served enterprise PKI for over two decades. At its core, SCEP enables devices to enroll for certificates by pointing them at a PKI gateway URL accompanied by a shared secret. Your MDM delivers a configuration payload to managed devices, and devices independently contact the SCEP server to request a certificate. It works — but the model has some fundamental trust gaps. For a detailed technical comparison, see ACME Device Attestation: The Modern Zero Trust Alternative to SCEP.

What SCEP Gets Right — and Where It Falls Short

SCEP’s strength is simplicity and broad compatibility. Nearly every MDM platform supports it, configuration is straightforward, and it has a long track record in enterprise environments. For organizations with fully managed device fleets on trusted networks, SCEP has historically been good enough.

Where it struggles is in a Zero Trust model. The shared secret embedded in the MDM payload is the only gate between a device and your CA. If that secret is intercepted — or if the device is compromised after enrollment — there is no mechanism to detect that the certificate was issued to an untrustworthy endpoint. Private keys are also stored in the device’s software keystore, meaning they can be extracted from a jailbroken device. Once a certificate is issued, SCEP has no ongoing role in verifying that the device remains in a healthy, compliant state.

How ACME Raises the Bar

ACME (Automated Certificate Management Environment) was standardized in RFC 8555 and later extended by Apple with Managed Device Attestation (MDA) in iOS 16 and iPadOS 16.1. Where SCEP relies on a shared secret, ACME uses one-time nonces — server-issued tokens that expire after a single use, eliminating the shared secret exposure risk entirely.

More importantly, ACME with Device Attestation introduces hardware-level device attestation before any certificate is issued. The device must prove to Apple’s attestation servers that it is a genuine, non-tampered Apple product, and that the private key for the certificate was generated inside the Secure Enclave — the dedicated hardware security coprocessor that is physically isolated from the device’s main processor. That key can never be exported, copied, or extracted, even from a jailbroken device.

The practical result: an ACME certificate issued by BastionXP is cryptographically bound to the specific piece of hardware that enrolled for it. If the device is lost, stolen, or decommissioned, revoking the certificate in BastionXP immediately and permanently invalidates access — with no risk that the certificate has been copied elsewhere.

Lifecycle Automation

SCEP automates initial enrollment but typically leaves certificate renewal as a manual or MDM-triggered operation. ACME automates the entire lifecycle — issuance, renewal, and revocation — without any human intervention after the initial policy is set. BastionXP re-evaluates device compliance at every renewal cycle, so a device that drifts out of policy has its certificate renewal blocked automatically until the issue is resolved.

What Is the ACME Protocol?

ACME (Automated Certificate Management Environment) is an IETF-standardized protocol published in RFC 8555, originally developed by the Internet Security Research Group (ISRG) for the Let’s Encrypt public CA. Apple extended ACME with its own Managed Device Attestation (MDA) framework in iOS 16, making it the definitive certificate enrollment protocol for Apple device fleets.

For a complete technical walkthrough of how ACME protocol works, see our dedicated guide. At its core, ACME operates over HTTPS using JSON messages. It automates the full certificate lifecycle — from initial enrollment, through renewals, to revocation — with no human intervention required after the initial policy is configured.

Core Components of the ACME Protocol

ACME Server (URL) The ACME server endpoint hosted by your CA (or BastionXP’s managed PKI). Devices communicate with this URL to initiate and complete certificate orders.

One-Time Nonce Each ACME request uses a server-issued nonce (one-time token) to prevent replay attacks. This replaces the static shared secret used in SCEP.

device-attest-01 Challenge Apple extended the base ACME protocol with a custom challenge type — device-attest-01 — not present in the base RFC 8555 specification. When BastionXP’s ACME server issues this challenge, the device responds by generating a key attestation through Apple’s servers that proves Secure Enclave residency and hardware authenticity. This challenge type is what makes ACME fundamentally different from SCEP — there is no equivalent mechanism in SCEP’s protocol model.

Secure Enclave The private key associated with the issued certificate is generated inside the device’s Secure Enclave — a dedicated hardware security processor — and can never be exported.

Device Attestation Before issuing a certificate, the ACME server challenges the device to cryptographically prove its identity against Apple’s attestation servers, confirming hardware authenticity.

Apple’s Secure Enclave: The Hardware Root of Trust

Apple’s Secure Enclave is a dedicated security coprocessor embedded in every iPhone, iPad, and Mac. It operates with its own isolated CPU and memory, completely separate from the device’s main application processor. This isolation is fundamental — even if the main OS is compromised, the Secure Enclave and its contents remain protected.

For ACME certificate enrollment, the Secure Enclave serves a critical function: the private key for the certificate is generated inside the Secure Enclave and never leaves it. The key cannot be extracted, exported, or copied. This means a certificate issued via ACME is cryptographically bound to the specific physical device that enrolled for it — achieving true device-bound identity.

How ACME Certificate Enrollment Works: End-to-End

The ACME enrollment flow for iOS devices involves coordination between your MDM, the device, Apple’s attestation servers, and BastionXP’s ACME CA. Here is the complete workflow:

Step 1 — MDM Pushes ACME Configuration Payload Your MDM (Intune, Jamf, Workspace ONE, Kandji) delivers an ACME configuration payload to the managed device. The payload contains the BastionXP ACME server URL and a one-time token identifying the specific enrollment request — no shared secret is included.

Step 2 — Device Registers an ACME Account The device generates an asymmetric key pair and registers an account with the BastionXP ACME server. The device presents the one-time token from the MDM payload as proof of the enrollment authorization.

Step 3 — Device Requests a Certificate Order The device submits a certificate order to the BastionXP ACME server, specifying a permanent-identifier — the device’s unique hardware identifier — as the certificate subject. This triggers the device-attest-01 attestation challenge.

Step 4 — ACME Server Issues Attestation Challenge BastionXP’s ACME server returns a device-attest-01 challenge to the device. The device must prove that (a) a private key resides in Secure Enclave, and (b) the device is a genuine, non-tampered Apple product.

Step 5 — Device Generates Key in Secure Enclave & Contacts Apple’s Attestation Server The iOS device generates a new key pair inside the Secure Enclave and contacts Apple’s attestation infrastructure. Apple’s server returns a signed attestation object containing the device’s serial number, hardware properties, and proof that the key lives in Secure Enclave.

Step 6 — BastionXP Verifies Attestation & Device Compliance BastionXP’s ACME service receives the attestation response and validates it against Apple’s root certificate chain. Simultaneously, BastionXP’s policy engine cross-references the device’s serial number against your MDM’s device inventory to confirm the device is actively managed and compliant with your security policies.

Step 7 — Device Submits CSR and Certificate Is Issued With attestation verified, the device generates a Certificate Signing Request (CSR) signed with the Secure Enclave key and sends it to BastionXP. BastionXP’s CA signs and issues the certificate, which is installed on the device. The private key never leaves the hardware.

Understanding Apple Managed Device Attestation (MDA)

Managed Device Attestation is Apple’s enterprise extension of ACME, introduced alongside the ACME protocol support in iOS 16. MDA allows your ACME server to request cryptographic proof of a device’s attributes — serial number, hardware model, OS version, and Secure Enclave integrity — during the certificate enrollment process.

MDA works by having the device generate a key attestation through Apple’s attestation servers. The attestation is a cryptographically signed document that confirms:

• The key was generated on a genuine Apple device (not a simulator or emulator)
• The key resides in the device’s Secure Enclave and cannot be extracted
• The device’s serial number and hardware identifiers are authentic
• The Secure Enclave is functioning correctly and has not been compromised

For MDM-managed devices, BastionXP additionally verifies that the enrollment request originated from a legitimate MDM push — preventing rogue enrollment attempts even from devices that possess a valid one-time token.

What Can You Use ACME-Issued Certificates For?

This is the question that matters most. Once BastionXP has issued a hardware-attested certificate to your iOS device, that certificate becomes a cryptographically strong identity credential usable across your entire access stack — replacing passwords wherever they appear.

Wi-Fi Authentication (802.1X / EAP-TLS) Deploy certificate-based authentication to your WPA2/WPA3-Enterprise wireless networks. When a device connects to corporate Wi-Fi, its ACME certificate proves both user identity and device hardware authenticity to your RADIUS server — with no password prompt and no credential phishing surface. Only devices holding a valid, hardware-bound certificate can join the network.

VPN Authentication Replace password-plus-MFA VPN authentication with device certificate auth for IKEv2, IPsec, and SSL VPN gateways. The private key never leaves the Secure Enclave, so even if a device is stolen, the certificate cannot be extracted and replayed from another machine. A VPN server connected to a RADIUS server can support EAP-TLS authentication using hardware-bound certificate to access the corporate network.

Zero Trust Network Access (ZTNA) As part of a Zero Trust architecture for mobile devices, BastionXP’s ZTNA policy engine evaluates the hardware attestation attributes embedded in each certificate on every access request — not just at login. A device that fell out of compliance after the certificate was issued will be denied access at the next policy evaluation, even if its certificate hasn’t yet expired.

Mutual TLS (mTLS) for Internal Web Apps and APIs Client certificates authenticate devices to internal web applications and microservices via mutual TLS (mTLS) authentication without exposing credentials. The server verifies the client certificate against BastionXP’s CA, gaining cryptographic assurance of both the user and the specific device making the request.

Automatic Renewal and Instant Revocation

Two of ACME’s most operationally significant advantages over SCEP are its certificate renewal automation and its revocation model. Both are fundamentally better than what SCEP delivers — and both matter enormously at fleet scale.

Automatic Certificate Renewal

Before a certificate’s validity period expires, the MDM may automatically trigger a config profile push to the device (For eg: Jamf’s Automated Redistribution), so that the device initiates a new ACME order with BastionXP’s server without any IT intervention.

Critically, BastionXP re-evaluates device compliance at every renewal cycle, not just at initial enrollment. A device that has fallen out of compliance since the last certificate was issued — OS downgrade, jailbreak detection, MDM unenrollment, failed screen-lock policy — will have its renewal blocked until the issue is remediated. The certificate expires, access is revoked, and the device is effectively quarantined from the resources it was accessing. No manual revocation action required.

Migrating from SCEP to ACME: A Phased Approach

Most organizations reading this guide are currently running SCEP. Before committing to a timeline, review the ROI of switching from SCEP to ACME Device Attestation to build the business case internally. The good news: SCEP and ACME can coexist during a transition period, so there is no forced fleet-wide cutover. BastionXP supports both protocols simultaneously from the same platform.

Phase 1 — Audit Your Fleet Identify which devices in your fleet are running iOS 16+ (ACME-capable) versus older OS versions. BastionXP’s device inventory view, cross-referenced with your MDM, gives you this breakdown instantly.

Phase 2 — Run Parallel Enrollment Profiles Deploy ACME configuration profiles to your iOS 16+ device groups while retaining SCEP for any devices that cannot yet support ACME. Devices in the ACME group begin receiving hardware-attested certificates immediately.

Phase 3 — Let SCEP Certificates Expire Naturally As existing SCEP certificates approach their renewal dates, redirect those devices to the ACME enrollment flow instead of renewing through SCEP. This avoids a disruptive mass re-enrollment event.

Phase 4 — Sunset SCEP Once your managed fleet has fully transitioned to ACME-issued certificates, retire the SCEP configuration payload and shared secrets from your MDM. Remove the SCEP gateway from your network perimeter.

Compliance and Regulatory Alignment

Hardware-attested certificate enrollment isn’t just a security improvement — it directly satisfies requirements across the major compliance frameworks your organization is likely subject to:

NIST SP 800-207 (Zero Trust Architecture) Hardware-bound device identity satisfies the “device trust” pillar of NIST’s Zero Trust model. Certificates that cryptographically verify device hardware provide the non-repudiable device identity signal NIST 800-207 requires for resource access decisions.

CIS Controls v8 ACME with MDA directly implements CIS Control 1 (Inventory and Control of Enterprise Assets) via hardware-verified device identity, and CIS Control 12 (Network Infrastructure Management) via certificate-based 802.1X network access control.

CMMC / FedRAMP Defense contractors and federal agencies subject to CMMC Level 2+ or FedRAMP Moderate/High requirements need strong device authentication and auditable PKI. BastionXP’s ACME issuance logs, certificate inventory, and OCSP revocation provide the audit trail these frameworks require.

HIPAA / SOC 2 Type II Healthcare organizations and service providers can demonstrate access control (HIPAA §164.312(d)) and logical access safeguards using BastionXP’s certificate issuance records, compliance enforcement at renewal, and automatic revocation tied to MDM unenrollment.

Deploying ACME Certificate Enrollment with BastionXP

BastionXP includes a fully managed ACME CA as part of its Zero Trust platform. There is no separate PKI infrastructure to stand up — BastionXP handles the ACME server, Apple attestation verification, policy enforcement, and certificate issuance in a single unified service.

Configuration Overview

Deploying BastionXP ACME for your iOS fleet involves three primary steps:

1. Configure your Certificate Authority in BastionXP. For enterprise deployments requiring strict enrollment control, BastionXP supports ACME External Account Binding (EAB) to authenticate ACME clients before certificate issuance. Define certificate templates specifying validity period, key usage, Subject Alternative Names, and custom attributes drawn from your IdP (Okta, Entra ID, Google Workspace).

2. Create an ACME enrollment policy. Define which devices are eligible for certificate issuance, what device compliance criteria must be met, and how issued certificates should be scoped by user role or department.

3. Push the ACME configuration payload via your MDM. BastionXP generates a ready-to-deploy .mobileconfig payload with your ACME server URL and enrollment token. Upload this to Jamf, Intune, Workspace ONE, or Fleet DM and assign it to your target device groups.

Here are the sample input values for the various certificate profile attributes:

# BastionXP ACME Configuration Payload (.mobileconfig)
PayloadType:           com.apple.security.acme
DirectoryURL:          https://your-company-name.bastionxp.com/authority/:authority-id/acme/:acme-server-id/directory
ClientIdentifier:      $SERIALNUMBER
Subject:
  - CN: $SERIALNUMBER
  - O:  Your Organization Name
  - OU: Sales
KeyType:               ECSECPrimeRandom
KeySize:               384
HardwareBound:         true          # Forces Secure Enclave key generation
Attest:                true      # Requires Apple MDA

Native MDM Integrations

BastionXP integrates natively with major Apple MDM platforms (such as Jamf, Fleet DM, and Intune), ensuring device compliance posture from your MDM is evaluated as part of the ACME attestation flow — continuously, not just at enrollment time.

Is ACME Better Than SCEP for iOS? The Verdict

Apple’s decision to build ACME support natively into iOS 16’s MDM framework is a clear signal: ACME is the future for Apple device certificate management. SCEP remains supported for backwards compatibility, but organizations investing in Zero Trust security architecture should be migrating to ACME for the following reasons:

1. Hardware-bound identity is non-negotiable in Zero Trust. For the business case on why certificate-based authentication outperforms passwords for enterprise devices, see our dedicated guide. SCEP certificates can be installed on any device that possesses the shared secret. ACME certificates are cryptographically bound to the specific physical device that enrolled — an attacker cannot reuse or copy the certificate to another device.

2. The private key never leaves the device. SCEP stores keys in the software keystore, which can be extracted on jailbroken devices. ACME keys in Secure Enclave cannot be extracted regardless of device compromise state.

3. Continuous compliance, not point-in-time enrollment. BastionXP evaluates device compliance at every certificate renewal — not just at initial enrollment. A device that fell out of compliance will have its certificate renewal blocked until the issue is resolved.

4. Instant revocation closes the stolen-device window. SCEP has no automated revocation tied to MDM status. BastionXP’s ACME integration revokes certificates the moment a device is marked lost or unenrolled — propagating via OCSP in seconds across every access system.

5. One certificate, many access vectors. ACME certificates work across Wi-Fi (802.1X), VPN, ZTNA, mTLS web apps, and S/MIME — reducing credential sprawl and giving security teams a single, unified identity signal across all access paths.

6. MDA supports Zero Trust access architectures. Certificates issued via ACME with MDA carry verifiable device attributes that can be evaluated by your ZTNA policy engine, Wi-Fi RADIUS, VPN, and SSO systems — providing a continuous hardware-attested identity signal across all access vectors.