What actually happens when you press "Erase All Content and Settings"

1The whole thing in three sentences

EACS is a cryptographic erase, not a reinstall. The MDM sends an EraseDevice command; the Mac asks the Secure Enclave to destroy the one key that unlocks the Data volume, creates a fresh empty Data volume, and reboots straight into Setup Assistant on the same macOS it was already running. It then does an ordinary Automated Device Enrollment handshake — activate, fetch its enrollment profile from Apple, install our MDM payload, get a client identity cert — and it's back.

2The command, and the token that gates it

Pressing the button in SimpleMDM queues a standard MDM EraseDevice command (Apple's canonical schema lives in apple/device-management, device.erase.yaml). The key that decides the erase strategy is ObliterationBehavior (String, macOS 12.0+):

On M-series and T2 Macs running macOS 12+, the default path is EACS. The key has no effect on pre-T2 Intel — those have no Secure Enclave, so there's no key to destroy, and they always take the slow reinstall/obliterate route.

3The erase: one key, thrown away

This phase is pure local cryptography and generates essentially zero network traffic. Here's the mechanism, straight from Apple's Platform Security guide:

1. On the internal SSD, the Data volume's file-system key is wrapped by an effaceable / media key that lives under the Secure Enclave's anti-replay protection.
2. EACS tells the Enclave to destroy that key. That single act renders the entire Data volume "cryptographically inaccessible" — every file becomes undecryptable ciphertext instantly, with no overwrite of the flash. Anti-replay guarantees the old key can't be resurrected.
3. A new random file-metadata key is generated — Apple's wording is that the metadata key is created "when the operating system is first installed or when the user completes Erase All Content and Settings."
4. A fresh, empty Data volume is created (observed at roughly 300 MB afterward).

"…the best way to securely erase its entire contents is to destroy its encryption key … anti-replay techniques to ensure that previous keys can't be reused." Destroying the key "renders all files cryptographically inaccessible."

4What survives, what dies

Because the OS itself is never rebuilt or re-downloaded, the machine reboots directly into Setup Assistant on the pre-existing macOS. This is the reason there's no swscan / swcdn / InstallAssistant / mesu traffic, and the reason it's fast.

5Reboot → Setup Assistant → re-enroll

Now the network wakes up. Setup Assistant walks a fixed sequence: activate the hardware, ask Apple "who owns me and where do I enroll?", then enroll against our MDM. Supervised ADE Macs on macOS 11+ can Auto Advance through this with no human at the keyboard — which is exactly what a headless CI mini needs.

1. Activation — the device authenticates itself to Apple and gets its activation record.
2. ADE / DEP lookup — the device fetches its Activation Record, which names our MDM's enrollment URL and the ADE config (skip keys, supervision, non-removable enrollment).
3. MDM enrollment — the device connects to our MDM URL and installs the enrollment profile, which minimally contains:
   • root + intermediate certs to establish SSL trust,
   • a client identity certificate — via an ACME payload (Apple's current recommendation), a SCEP payload, or a PKCS #12 container,
   • the MDM payload itself.
4. The device becomes supervised, and enrollment is complete. (Our story continues in the deep dive from here: SimpleMDM pushes the SCEP profile, the cert lands in the keychain, and the bootstrap PKG fetches vault.yaml.)

6The network traffic, in order

Everything Apple-side is HTTPS on TCP 443 except APNs. Here's the full wire sequence from reboot to enrolled:

APNs is the one that trips up firewalls: devices connect out on TCP 5223 (with 443 as fallback), while the MDM server pushes on TCP 2197 (the legacy provider ports 2195/2196 were retired in Nov 2020). All of it lives inside Apple's 17.0.0.0/8 block.

7The MDC1 allowlist

For our locked-down datacenter network, the takeaway is refreshingly small:

8Apple Silicon vs T2 Intel

Our fleet is M-series, so the fast cryptographic-erase path is what we get every time. The T2 column matters only as context for why a stray "it's downloading forever" reprovision is worth investigating.

9What changed, by macOS version

10What we couldn't nail down

In the spirit of the deep dive's honesty, here's what this page is not certain about:

• The internal daemon that orchestrates EACS on Apple Silicon. Apple doesn't document whether it's remotemanagementd driving an obliterator/eraseinstall helper, or something else, or how that differs process-level from T2. Treat any specific daemon name as folklore until confirmed live in a log stream / sysdiagnose.
• The exact ~300 MB residual Data-volume figure. Single well-regarded third-party source (eclecticlight.co), empirical observation — not an Apple number.
• The precise interleaving of the SCEP/ACME cert exchange vs. MDM CheckIn. Reconstructed from the profile structure; not pinned to a primary source line.

11Sources

Primary + corroborating, all confirmed via adversarial cross-check:

• Apple Platform Security guide — Data protection (the cryptographic-erase mechanism)
• Apple device-management schema — device.erase.yaml + EraseDeviceCommand
• Apple deployment — Secure & Bootstrap Tokens (the EACS authorization gate)
• Apple developer — Deploying MDM enrollment profiles (profile contents, ACME/SCEP/PKCS#12)
• Apple — Use Apple products on enterprise networks (the host/port allowlist)
• Apple deployment — Configure your network for device management (APNs ports)
• Eclectic Light Co. — Erase All Content and Settings does what it says (2025, the SSV-survives / ~300 MB observations)