Activation Lock on M1, M2, M3, and M4 Macs: what changed across chip generations#

Activation Lock enforcement on Apple silicon happens in the Low-Level Bootloader, before macOS loads. The LLB verifies that a valid LocalPolicy exists on the boot volume and that its anti-replay values match the Secure Storage Component on the silicon. No valid policy, no macOS boot. The mechanism is identical from M1 through M4. (Apple Platform Security)

What has changed across the M1-to-M4 era is not the boot chain but the OS around it: Erase All Content and Settings in Monterey, console-level Activation Lock controls for organizations in Sequoia, and the parts-pairing extension in Tahoe 26 that brings Activation Lock down to component level.

This post is the chip-by-chip technical reference: how the lock is enforced on Apple silicon, what changed at each macOS release, and what the recent Tahoe parts-pairing change means for buyers and refurbishers.

The Apple silicon boot chain#

On Apple silicon, the first stage that runs after the immutable Boot ROM is the Low-Level Bootloader. The LLB's job is to verify two things before handing control to iBoot:

1. A valid LocalPolicy exists on the boot volume.
2. Anti-replay values in the LocalPolicy match what is stored in the Secure Storage Component on the silicon.

A LocalPolicy is a signed configuration describing the security policy for a boot volume (Full Security, Reduced Security, or Permissive), plus settings around kernel extension policy, MDM enrollment, and so on. The anti-replay values prevent an attacker from rolling back to an older, weaker policy by replacing the policy blob on disk.

If a LocalPolicy exists and verifies, the LLB hands off to iBoot, which loads macOS. If no LocalPolicy exists (a freshly erased Mac, for example), the LLB boots to recoveryOS, which detects the Mac is not activated and contacts Apple's activation server for an activation certificate.

The activation certificate combines a local cryptographic key, generated and held in the Secure Enclave, with a RemotePolicy certificate returned by Apple's servers. The local key proves the certificate is bound to this specific Mac. The RemotePolicy carries Apple's authoritative statement about whether the Mac is locked, who it is bound to, and what policy is allowed. Together they construct a valid LocalPolicy and the Mac can boot.

When a Mac is Activation-Locked, the server-side handshake fails. recoveryOS displays the "Activate Mac" screen and refuses to construct a usable LocalPolicy without credentials. The LLB will not boot macOS. That is the lock, in one paragraph.

The Secure Enclave on Apple silicon#

On T2 Intel Macs, the Secure Enclave lives in a separate T2 Security Chip alongside the Intel CPU. On Apple silicon, the Secure Enclave is integrated into the same SoC as the main CPU cores. There is no separate T2 chip.

The functional role is the same: store the cryptographic identity that binds the device to its activation state. The enclave generates and holds the device-specific key that participates in the activation handshake. It holds the encryption keys for the storage. It enforces the security policy.

Storage on Apple silicon is hardware-encrypted regardless of FileVault state. The SSD controller encrypts every block with a key derived from the Secure Enclave's device key, which never leaves the enclave in plaintext. A thief who pulled the NAND chips and read them with external equipment would see ciphertext only. Reflashing macOS does not help, because the lock state is enforced before macOS loads, by the LLB, with reference to the RemotePolicy from Apple's servers. The integrated-storage architecture that makes the SSD non-replaceable in the normal sense is covered in the unified-memory and integrated-storage explainer.

This is the architectural reason Apple silicon has no published bypass. The lock is not a software flag macOS reads. It is a server-issued certificate the LLB verifies before macOS even starts loading.

What is the same across M1 to M4#

The LLB / LocalPolicy / RemotePolicy mechanism has not changed across chip generations. Every Apple silicon Mac, from M1 (November 2020) through M1 Pro/Max/Ultra (2021), the M2 family (2022 onward), the M3 family (2023 onward), and the M4 family (2024 onward), uses the same enforcement architecture for Activation Lock.

There is no "M1 bypass" or "M2 bypass" that does not also apply to M3 or M4. The boot chain is closed and the cryptographic root of trust is consistent across generations.

What has changed: the macOS layer around the lock#

The bootloader stayed put. The OS layer added features at each release:

macOS Big Sur 11 (November 2020). Activation Lock arrived on Apple silicon when the M1 launched. The Find My network for Mac also debuted, broadcasting rotating encrypted BLE beacons relayed by nearby Apple devices. A Mac with Find My network enabled can be located even when asleep, offline, or erased, as long as Bluetooth is on and residual battery power remains.

macOS Monterey 12 (October 2021). Erase All Content and Settings shipped for T2 and Apple silicon Macs. EACS is the correct preparation flow for handoff: it signs the user out of iCloud, turns Find My off, disarms Activation Lock, destroys the per-device cryptographic keys, and restarts the Mac to a clean Hello Setup Assistant in one operation. Recovery Lock also arrived on Apple silicon as the equivalent of the obsolete Intel firmware password, gating startup modifiers like the boot picker.

macOS Ventura 13 (October 2022). EACS relocated to System Settings → General → Transfer or Reset.

macOS Sonoma 14 (September 2023). DFU revive and restore could be initiated from Finder on a host Mac without Apple Configurator 2. Useful for repair workflows; neither operation clears Activation Lock.

macOS Sequoia 15 (September 2024). Apple Business Manager and Apple School Manager gained the ability to turn Activation Lock on or off directly in the console for organization-owned devices, provided the device was in ABM/ASM before the lock was set. Before Sequoia, an org had to remove the device from ABM/ASM entirely to clear the lock.

macOS Tahoe 26 (2025). Repair Assistant gained parts-pairing / unfinished-repair checks tied to Activation Lock on Apple silicon. The lock architecture extends down to component level.

The Tahoe parts-pairing extension#

Starting with macOS Tahoe 26, Apple extended Activation Lock down to individual internal components to prevent cannibalizing stolen Macs for parts. When a qualifying component (logic board, display assembly, security module) is transferred from a donor Mac that was Activation-Locked at disassembly, the part carries its locked state to the recipient machine.

Integration and calibration run through the macOS Repair Assistant. If a part is locked to another user's Apple Account, Repair Assistant halts calibration. That makes the part ineligible for official calibration, AppleCare, or warranty service. Uncalibrated parts may still function but frequently operate in a degraded state: missing full security features, missing performance optimizations, missing privacy assurances tied to the secure pairing.

The practical consequence for the secondary market: even the parts of a locked Mac are problematic. The pre-Tahoe pattern where a stolen-and-locked Apple silicon Mac could be sold for the value of its logic board is now constrained by component-level lock state. Salvage value narrows considerably.

For refurbishers and repair shops, this means donor parts now need provenance: where did the part come from, was the source Mac released from the original owner's Apple Account before disassembly, will Repair Assistant accept it? A part with unknown provenance is a higher risk than it used to be. The economics shift in detail in macOS Tahoe Repair Assistant and the new parts-harvest economics for refurbishers.

What DFU does and does not change#

DFU on Apple silicon has two modes:

• Revive updates firmware and recoveryOS only, preserving user data on the SSD.
• Restore updates firmware and recoveryOS, and erases the SSD, reinstalling macOS from an IPSW image.

Both run via Apple Configurator 2 with the target Mac in DFU mode tethered to a host Mac, or via Finder on macOS Sonoma 14 and later.

Neither clears Activation Lock. A DFU restore removes Recovery Lock (the Apple silicon equivalent of the obsolete Intel firmware password), but the Activation Lock record lives on Apple's servers and is tied to the hardware identity. After a successful DFU restore the Mac contacts the activation servers, discovers it is still locked, and presents the Activation Lock screen in Setup Assistant.

DFU is a repair tool, not a workaround. The legitimate-owner path past the Activation Lock screen remains the same: personal Apple Account credentials, the local user's previously used device password, or an MDM-escrowed bypass code entered via Recovery Assistant → Activate with MDM key.

What this means for buyers#

The chip generation is not the question that matters for Activation Lock. The mechanism is the same from M1 through M4. What matters is:

1. Whether the seller has actually released the Mac from their account before the handoff. The pre-purchase verification is a clean live boot to Setup Assistant with Wi-Fi connected to force the activation check. See the Activation Lock check walkthrough for the on-device steps.
2. On a 2025-or-newer Apple silicon Mac running Tahoe 26, whether any internal parts were transferred from a locked donor at some point in the machine's history. Repair Assistant calibration logs and system_profiler output can surface this, though full provenance is hard to establish from outside the original repair workflow.
3. Whether the Mac was ever enrolled in an organization's MDM. The MDM enrollment prompt that survives wipe and DFU is separate from Activation Lock and survives both EACS and DFU restore.

A 2024 M4 MacBook Pro and a 2020 M1 MacBook Air sit in the same Activation Lock architecture. A clean live boot is a clean live boot on either. The post-2025 wrinkle is component-level parts-pairing, and the practical answer there is the same as the rest of Mac security verification: trust the live boot, verify the System Information panes, and ask explicitly about repair history.