Mac, iPhone and iPad fleets are secured mostly by hardware and operating system mechanisms that administrators cannot see in a console, so policies are often written on assumptions about what Apple devices protect rather than on how they actually work. Apple's own Platform Security guide (August 2026 edition) describes those mechanisms in detail: the Secure Enclave, the boot chain and its security modes, the signed system volume, System Integrity Protection, Data Protection classes and FileVault keys, and managed device attestation. This guide explains that architecture for security architects, endpoint engineers and auditors, and shows which parts you can verify, which parts management can change, and where the guarantees stop. Day-to-day macOS configuration (Gatekeeper, TCC, persistence, detection) is covered in the macOS Security Guide for Enterprises and is not repeated here.
Key takeaways
- The Secure Enclave holds the keys, not the operating system. Device-unique hardware keys stay inside its AES engine and public key accelerator, and file keys are unwrapped there and never exposed to application processor software, even if the main kernel is compromised.
- Boot security on Apple silicon is a per-OS policy. Full, Reduced and Permissive Security are recorded in a LocalPolicy signed by the Secure Enclave, and weakening it needs physical presence in recoveryOS, so remote malware cannot lower it.
- The system volume is sealed. Since macOS 11 the signed system volume hashes every byte of system content into an Apple-signed Merkle tree, and a Mac with a broken seal will not boot normally.
- Data Protection class decides when data is readable. Most third-party app data defaults to Class C (protected until first unlock), which protects against reboot attacks but not against a running, unlocked device.
- Attestation lets you prove posture. Managed device attestation (macOS 14, iOS 16 and later) has the Secure Enclave and Apple's servers vouch for OS versions, SIP state and boot configuration, and binds certificates to hardware keys.
The hardware root of trust: Apple SoC and the Secure Enclave
The Secure Enclave is a dedicated subsystem inside the Apple system on chip, isolated from the main application processor. It is present on Apple silicon Macs, Intel Macs with the T2 chip, iPhone 5s and later, iPad Air and later and other Apple devices.
| Component | What it does | Why it matters to defenders |
|---|---|---|
| Secure Enclave Processor and sepOS | A dedicated core running an Apple-customised L4 microkernel, clocked lower to resist clock and power attacks | A kernel exploit on the main OS does not by itself expose Secure Enclave secrets |
| Boot ROM | Immutable code that verifies sepOS before running it | Tampered Secure Enclave firmware does not run |
| UID and GID keys | UID is unique per device, fused at manufacture and inaccessible to Apple and suppliers; GID is shared per SoC model | Data encrypted to the UID cannot be decrypted off the device, so chip-off attacks on storage fail |
| AES engine | Inline encryption on the path between flash and memory using hardware keys software can use but not read | File encryption has no performance excuse to be turned off |
| Public key accelerator | RSA and ECC with keys that stay in hardware; supports OS-bound keys (Sealed Key Protection) derived from the UID and the sepOS hash | Keys can be bound to a specific, trusted software state |
| Memory Protection Engine | Encrypts and authenticates Secure Enclave memory, with anti-replay from A11 and S4 onward | Physical memory attacks on the enclave are detected and halt it |
| Secure Storage Component and counter lockboxes | Dedicated non-volatile storage; Gen 2 (devices from autumn 2020) adds counter lockboxes that store a passcode verifier and attempt count | Passcode guessing is limited in hardware and exceeding the limit (for example 10 attempts on iPhone) erases the protected data |
The Secure Enclave protects passcode-protected data, Face ID, Touch ID and Optic ID templates and file system keys. It is also what makes hardware-bound credentials possible: a private key generated in the Secure Enclave cannot be copied to another device. That is the basis for platform credentials such as passkeys and Platform SSO keys. See the macOS Platform SSO and Directory Binding Guide.
Boot chain and startup security policy
How a Mac with Apple silicon boots
- Boot ROM starts the chain of trust and verifies the next stage.
- Low-Level Bootloader (LLB) verifies and loads paired firmware for storage, display and other controllers, loads the LocalPolicy and checks its anti-replay value against the Secure Storage Component so an older, weaker policy cannot be replayed.
- LocalPolicy records the chosen boot and runtime security settings and is signed by the Secure Enclave with a key that stays on that Mac.
- iBoot loads macOS-paired firmware, verifies and locks any Auxiliary Kernel Collection (third-party kexts) if the policy allows it, and verifies the root hash of the signed system volume.
- The kernel mounts the file system only after the signed system volume check passes. Any verification failure sends the Mac to recoveryOS.
The three security modes
| Mode | What it allows | How it is set | When to accept it |
|---|---|---|---|
| Full Security (default) | Only the newest signed macOS available at install; signatures are personalised to the Mac's chip ID (ECID), which blocks rollback | Default; Startup Security Utility in recoveryOS | The standard for every managed Mac |
| Reduced Security | Older macOS versions with global signatures (which may have unpatched vulnerabilities) and third-party kernel extensions in an Auxiliary Kernel Collection | Startup Security Utility in recoveryOS with administrator authentication | Only where a business-critical kext has no system extension replacement |
| Permissive Security | Boot objects signed locally by the Secure Enclave, such as custom kernels; needed to turn off SIP | Command-line tools such as csrutil in recoveryOS only, with explicit acceptance | Research and development devices, never production |
- Physical presence: changes that significantly weaken security require entering recoveryOS by holding the power button, which Apple describes as making the change possible only for a person with physical access. Apple silicon Macs do not use a firmware password for this reason.
- Per-OS policy: each installed OS has its own LocalPolicy, and booting from external media needs an authenticated restart from recoveryOS to create one.
- Data stays protected under weaker modes: when a custom kernel or untrusted OS is loaded in Permissive Security, some decryption keys become unavailable so the trusted OS's data stays protected.
- Kernel extensions are on the way out: Apple encourages developers to move to system extensions and plans to remove kext support, so treat any Reduced Security exception as temporary.
Operating system integrity: SSV, SIP and code signing
| Mechanism | Protects | Enforced by | Can it be turned off? |
|---|---|---|---|
| Signed system volume (macOS 11 and later; iOS and iPadOS 15 and later) | Every byte of system content, through SHA-256 hashes in a Merkle tree whose root (the seal) is Apple-signed | Bootloader (Apple silicon) or kernel (T2 Macs) before mounting; hashes checked on every read | On macOS only with FileVault off and a lower security mode; never on iOS and iPadOS |
| System Integrity Protection (on by default since OS X 10.11) | Critical file system locations made read-only through mandatory access controls | Kernel, for every process including those with administrative privileges | Only from recoveryOS, which on Apple silicon means Permissive Security |
| Kernel Integrity Protection (Apple silicon) | The kernel in memory | Hardware | No |
| Code signing | Executables when memory-mapped as code | Kernel | No, it complements SSV |
Two consequences matter for administrators. First, root on macOS is not all-powerful: SIP stops even administrative processes from modifying protected locations, and the seal stops offline modification of the system volume. Second, because the system volume is sealed and verified, macOS 11 and later no longer needs to encrypt it; FileVault protects the data volume, where user and application data lives.
On top of this sits Apple's malware stack: notarisation (with ticket revocation), Gatekeeper checks on first launch, and XProtect, a YARA signature engine with a remediation engine, updated independently of OS updates and checked daily by default. On macOS 15 and later the Endpoint Security API reports Gatekeeper bypasses and XProtect detections, which EDR tools can forward. See the macOS Detection and Response Guide.
Data Protection and FileVault
Data Protection classes
| Class | Constant | When data is readable | Mac behaviour |
|---|---|---|---|
| A: Complete Protection | NSFileProtectionComplete | Only while unlocked; the class key is discarded about 10 seconds after locking (with Require Password set to Immediately) | Key discarded when the last user logs out |
| B: Protected Unless Open | NSFileProtectionCompleteUnlessOpen | New files can be written while locked using elliptic curve key agreement; per-file key wiped when the file closes | Available while any user is logged in |
| C: Protected Until First User Authentication | NSFileProtectionCompleteUntilFirstUserAuthentication | After the first unlock following a restart, until the next restart | Uses a volume key available while mounted, similar to FileVault |
| D: No Protection | NSFileProtectionNone | Whenever the device is running; protected only by the UID, mainly to allow fast remote wipe | Not supported on macOS |
Class C is the default for third-party app data not assigned a class. For iPhone and iPad apps handling sensitive corporate data, ask developers and vendors which class they use: a device that has been unlocked once since boot exposes Class C data to anyone who can run code on it. See the iOS and iPadOS Enterprise Security Guide and the iOS App Security Guide.
FileVault keys and management
- Secure Token: a key encryption key wrapped with a user's password, which lets that user unlock the FileVault volume. In macOS 11 the first user's initial password grants one.
- Bootstrap Token: generated and escrowed to the device management service at the first login by a Secure Token user (from macOS 10.15.4). It grants Secure Tokens to other users, including mobile and managed administrator accounts, and on Apple silicon authorises kernel extension and software updates. The MDM server therefore holds a credential with real power over every Mac: protect it like a privileged secret.
- Recovery keys: Apple states that an institutional recovery key is no longer recommended; on Apple silicon it cannot access recoveryOS and target disk mode is unsupported. Escrow a personal recovery key to device management instead. See the Disk Encryption Guide.
- Remote unlock: on Apple silicon with macOS 26 or later, FileVault can be unlocked over SSH after a restart if Remote Login is enabled, which helps headless Macs but adds an SSH path to the pre-boot state that needs the same controls as any SSH access.
Proving device state: managed device attestation
Managed device attestation lets a device prove its identity and security posture with a certificate chain from Apple's attestation servers to the Apple Enterprise Attestation Root CA. It is supported on iOS and iPadOS 16, macOS 14, tvOS 16, watchOS 9 and visionOS 1.1 or later; Macs must have Apple silicon and iPhone and iPad need A11 Bionic or later.
| Attested property | Use in access decisions |
|---|---|
| Serial number and UDID (omitted under User Enrollment) | Bind a certificate or session to a known corporate device |
| OS, iBoot, LLB and sepOS versions | Deny access from devices below a minimum patch level |
| SIP status, secure boot configuration and whether third-party kexts are allowed (macOS 14 and later, Apple silicon) | Treat Macs in Reduced or Permissive Security or with SIP off as non-compliant |
| Freshness code | Prove the attestation was generated for this request, preventing replay |
- Hardware-bound certificates: with ACME and the
device-attest-01challenge, the certificate's key pair (P-256 or P-384) is generated in and bound to the Secure Enclave, so it cannot be exported, and it is removed on restore. If it is the MDM client identity, the device unenrols on restore. - Zero trust: Apple's guidance pairs an ACME certificate for the connection with ongoing attestation of device properties, and lets the issuing service evaluate trust before issuing. That moves device identity from a copyable certificate to a hardware-bound machine identity. See the Apple Declarative Device Management and Managed Device Attestation Guide and the ACME and Automated Certificate Management Guide.
Turning the architecture into policy
What to require and how to check it
| Requirement | Check on the device | Check at scale |
|---|---|---|
| Full Security on every Apple silicon Mac | bputil -d displays the LocalPolicy | Managed device attestation secure boot property; MDM inventory |
| SIP enabled | csrutil status | Attestation SIP property; MDM or EDR inventory |
| FileVault on with escrowed personal recovery key | fdesetup status | MDM FileVault and escrow reports |
| Bootstrap Token escrowed | profiles status -type bootstraptoken | MDM device record |
| Supported OS version | sw_vers | Attested OS version; MDM inventory |
| No third-party kexts outside approved exceptions | kmutil showloaded | Attestation kext property |
Rolling it out
- Baseline: inventory hardware (Apple silicon, T2, older Intel), OS versions, security mode, SIP, FileVault and Bootstrap Token status from MDM.
- Remove exceptions: list every Mac in Reduced or Permissive Security and every kext that requires it; plan replacement with system extensions and give each exception an owner and expiry date.
- Fix key management: escrow personal recovery keys and Bootstrap Tokens, retire institutional recovery keys, and test recovery on a pilot Mac before you need it.
- Add attestation: pilot ACME certificates with
device-attest-01for Wi-Fi, VPN or MDM identity on a test group, confirm the identity provider or network access control reads the attested properties, then expand. - Enforce: make conditional access or network access depend on attested posture, starting in report-only mode and reviewing failures.
- Rollback: attestation-based policies can be returned to report-only; certificate profiles can be reissued with software keys if a hardware-bound rollout fails, at the cost of exportability.
Decision guidance
- Intel Macs: T2 Macs share the Secure Enclave and SSV but use a different boot process and cannot use managed device attestation; Intel Macs without T2 lack most of these protections. Prioritise replacement for high-risk users.
- Small organisations: MDM inventory checks of SIP, FileVault and OS version cover most of the value; attestation can follow.
- Large or regulated estates: hardware-bound device certificates with attestation give auditable proof that only managed, healthy devices reach corporate resources.
Measuring it
- Full Security rate: percentage of Apple silicon Macs in Full Security (target 100 percent outside approved exceptions).
- Integrity rate: percentage of Macs with SIP on and an intact signed system volume.
- Key escrow: percentage of Macs with an escrowed personal recovery key and Bootstrap Token.
- Attested access: percentage of device certificates that are hardware-bound and issued after attestation.
- Exception age: number of Reduced Security exceptions past their expiry date.
Framework mapping
| Apple mechanism | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | CIS Controls v8.1 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|---|
| Secure boot, LocalPolicy, SSV | SI-7, SI-7(9) Verify Boot Process | PR.PS-01 | 4 Secure Configuration | A.8.9 Configuration management |
| Secure Enclave key storage | SC-12, SC-28 Protection of Information at Rest | PR.DS-01 | 3 Data Protection | A.8.24 Use of cryptography |
| FileVault and Data Protection | SC-28 | PR.DS-01 | 3 Data Protection (encryption on end-user devices) | A.8.1 User endpoint devices |
| Managed device attestation | IA-3 Device Identification and Authentication | PR.AA-01 | 1 Inventory and Control of Enterprise Assets | A.5.9 Inventory of information and other associated assets |
| Notarisation, Gatekeeper, XProtect | SI-3 Malicious Code Protection | DE.CM-09 | 10 Malware Defenses | A.8.7 Protection against malware |
Common failure patterns
- Reduced Security left behind: a Mac lowered once for a legacy kext stays in Reduced Security long after the vendor shipped a system extension, still able to boot older, vulnerable macOS versions.
- Institutional recovery keys only: organisations relying on an IRK find on Apple silicon that it cannot unlock the volume from recoveryOS or target disk mode, and data is lost when a user forgets the password.
- Bootstrap Token not escrowed or poorly protected: without it, managed administrator accounts cannot unlock FileVault and updates need user action; with it but with weak MDM admin controls, whoever controls the MDM controls every Mac. See the Stryker Intune wiper attack for what a hijacked device management administrator can do.
- Assuming encryption protects a running device: FileVault and Class C protect data at rest after a restart; they do not protect a logged-in or once-unlocked device from malware running as the user.
- Copyable device certificates: software-generated certificates in profiles can be exported and reused from other machines; use hardware-bound keys with attestation where devices support it.
- Treating root as game over or as all-powerful: policies that ignore SIP and SSV either overstate the impact of an admin compromise or miss that an attacker's real goal is to lower the security mode or abuse TCC grants.
Practitioner checklist
- Require Full Security on Apple silicon Macs and track every Reduced Security exception with an owner and expiry.
- Confirm SIP is enabled fleet-wide from MDM, EDR or attestation data.
- Escrow FileVault personal recovery keys and Bootstrap Tokens, and retire institutional recovery keys.
- Restrict and monitor administrator access to the MDM server, which holds Bootstrap Tokens and recovery keys.
- Ask app vendors which Data Protection class sensitive data uses on iPhone and iPad.
- Pilot ACME certificates with device-attest-01 and hardware-bound keys for network and MDM identity.
- Use attested OS version, SIP and boot state in conditional access, starting in report-only mode.
- Plan replacement of Intel Macs without T2 for high-risk users.
- Forward Endpoint Security events for Gatekeeper bypass and XProtect detections to the SIEM.
Standards and references
- Apple: Apple Platform Security guide
- Apple: The Secure Enclave
- Apple: Boot process for a Mac with Apple silicon
- Apple: Signed system volume security
- Apple: Data Protection classes
- Apple: Managing FileVault
- Apple: Managed device attestation
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: macOS Security Guide for Enterprises · macOS CIS and mSCP Compliance Guide · Jamf Guide · macOS TCC and Privacy Permissions Management Guide