How to Implement Apple Device Enrollment Program (DEP) Anchor Certificates for MDM Pinning

Apple’s Automated Device Enrollment (ADE), formerly known as the Device Enrollment Program (DEP), is the foundation of Zero-Touch deployment for macOS and iOS. When a new Mac connects to the internet during the Setup Assistant, it contacts Apple’s activation servers (iprofiles.apple.com). Apple then directs the Mac to download its management profile from your organization’s Mobile Device Management (MDM) server.

However, this initial connection to the MDM server occurs before the device has any corporate trust established. If a sophisticated attacker performs a Man-in-the-Middle (MitM) attack during this critical window (e.g., via DNS spoofing on a rogue Wi-Fi network), they could present a fraudulent TLS certificate, intercept the enrollment, or force the Mac to enroll in a malicious MDM.

To prevent this, enterprise administrators must configure Anchor Certificates within their Apple Business Manager (ABM) portal, strictly pinning the cryptographic identity of the MDM server to the hardware during enrollment.

Understanding DEP Anchor Certificates

An Anchor Certificate acts as a cryptographic hardcode. When you upload an Anchor Certificate to Apple Business Manager, Apple injects that certificate into the JSON payload delivered to the Mac during the Setup Assistant phase.

When the Mac attempts to connect to your MDM server (e.g., mdm.internalcorp.com), it will only trust the TLS connection if the MDM server presents a certificate chain that mathematically leads back to the exact Anchor Certificate provided by Apple. If the TLS certificate does not match the Anchor—even if it is a perfectly valid certificate issued by a public CA like Let’s Encrypt—the Mac will abort the enrollment, neutralising the MitM attack.

Step 1: Extracting the Certificate Chain

To configure the anchor, you must provide the certificate of the Certificate Authority (CA) that issued your MDM server’s TLS certificate. Depending on your security posture, this could be the Root CA, or an Intermediate CA.

If your MDM server uses a public certificate (e.g., DigiCert), you need the DigiCert Root. If you use an internal PKI (e.g., Microsoft AD CS), you need your internal Root CA.

You can extract the exact certificate chain currently presented by your MDM server using the openssl CLI on a macOS or Linux terminal:

openssl s_client -showcerts -connect mdm.internalcorp.com:443 < /dev/null

This command outputs the entire certificate chain in PEM format. Look for the last certificate in the chain (usually the Root or Intermediate CA) bounded by -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----. Copy this text and save it to a file named mdm_anchor.pem.

Step 2: Uploading the Anchor to Apple Business Manager

Once you possess the correct PEM certificate, you must upload it to Apple to bind it to your MDM server definition.

1. Log in to Apple Business Manager (business.apple.com) with an Administrator or Device Enrollment Manager role.
2. Click your name in the bottom-left corner and select Preferences.
3. Under Your MDM Servers, select the MDM server you wish to secure.
4. Click Edit.
5. In the settings pane, locate the Anchor Certificates section.
6. Click Upload and select the mdm_anchor.pem file you created in Step 1.
7. Click Save.

Step 3: Configuring the MDM Payload (Jamf / Workspace ONE)

Apple Business Manager passes the anchor to the device, but your MDM platform must also be aware of the strict trust requirement, especially if you are using an on-premises MDM or an internal PKI.

In your MDM console (e.g., Jamf Pro):

1. Navigate to Settings > Global Management > Automated Device Enrollment.
2. Select your DEP instance.
3. Ensure that the Trust Profile section contains the same Root CA certificate. This ensures that after the initial connection, the Mac permanently installs the Root CA into its System Keychain, allowing subsequent MDM commands and agent downloads to succeed securely.

Step 4: Handling Certificate Rotation

The most dangerous operational risk of Anchor Certificates is TLS rotation. If your public CA rotates its Intermediate or Root certificate, or if your internal PKI expires, and your MDM server begins presenting a new certificate before you update Apple Business Manager, all new device enrollments will instantly fail with an untrusted network error.

The Safe Rotation Workflow:

1. Obtain the new Root/Intermediate CA certificate that will issue your future MDM TLS certificate.
2. Upload this new certificate to Apple Business Manager alongside the old one. (ABM supports multiple Anchor Certificates simultaneously).
3. Wait at least 24 hours. Apple caches DEP profiles globally; uploading early ensures that all Macs waking up will receive both the old and new trust anchors.
4. Apply the new TLS certificate to your MDM server/load balancer.
5. Once you verify enrollments are succeeding with the new certificate, you can safely delete the old Anchor Certificate from Apple Business Manager.

Conclusion

As Zero-Touch deployment becomes the enterprise standard, the initial network connection between a bare-metal Mac and the MDM server becomes a prime target for interception. By configuring DEP Anchor Certificates, administrators cryptographically pin the identity of the MDM server directly into Apple’s activation payload, ensuring that devices can only ever enroll into legitimate corporate infrastructure, regardless of the physical network they boot on.