ES1.8 macOS Security Architecture

What macOS gives you for free

TCC (Transparency, Consent, and Control) is macOS’s permission framework for sensitive resources. Applications must be explicitly granted access to: the camera, microphone, contacts, calendar, photos, full disk access, screen recording, accessibility features, and the Desktop/Documents/Downloads folders. TCC prompts are enforced by the kernel — an application cannot bypass TCC by running as root. Even with root access, TCC-protected resources require explicit user consent or an MDM-managed TCC profile. This is stronger than anything Windows provides natively: there is no Windows equivalent that prevents a root-level process from reading the user’s documents folder.

Gatekeeper prevents the execution of unsigned or unnotarized applications downloaded from the internet. When a user downloads an application, macOS checks its code signature and notarization status. Unsigned applications are blocked by default (the user must explicitly override through System Settings). Notarization means Apple has scanned the binary for known malware before the developer distributed it. This provides a baseline prevention layer against commodity malware — unsigned malware is blocked before execution.

SIP (System Integrity Protection) prevents modification of protected system directories (/System, /usr, /bin, /sbin) even by processes running as root. SIP is enforced by the kernel and can only be disabled by booting into Recovery Mode — it cannot be disabled remotely. This means an attacker with root access on a running macOS system cannot modify system binaries, cannot replace system frameworks, and cannot install rootkits in protected directories. The attacker must either find a SIP bypass (rare, high-severity vulnerabilities that Apple patches aggressively) or persist in non-protected locations.

The Endpoint Security Framework is Apple’s API for security tools to receive kernel-level event notifications. It provides: process execution events, file system events, network events, and authentication events — similar to what ETW provides on Windows. Defender for macOS uses the ES Framework for its real-time protection and EDR telemetry. The ES Framework replaced the deprecated Kernel Extension (kext) model, providing security tools with stable, supported kernel-level visibility without the risks of loading third-party kernel code.

TCC: the permission model that changes endpoint security

Transparency, Consent, and Control (TCC) is macOS’s permission framework that restricts application access to sensitive data and system resources. Unlike Windows (where any application running as the user can access the user’s files, camera, microphone, and contacts), macOS requires explicit user consent through TCC prompts before an application can access: the camera, microphone, screen recording, accessibility features (which enable keystroke monitoring), full disk access (which enables reading other applications’ data), contacts, calendar, photos, and location.

For endpoint security, TCC creates both a protection and a constraint. The protection: malware on macOS cannot silently access the camera, keylog through accessibility APIs, or read browser credential stores without triggering a TCC prompt that the user must approve. The constraint: MDE for macOS itself needs TCC permissions to function. Specifically, MDE requires Full Disk Access (to scan files across the filesystem), System Extensions (to monitor system events — replacing the deprecated kernel extensions), and Network Extension (to monitor and filter network traffic for web protection).

Deploying MDE’s TCC permissions requires MDM (Intune). Without MDM, the user receives TCC prompts when MDE tries to access protected resources, and they must manually approve each one. With Intune, the TCC permissions are deployed as a configuration profile — the permissions are granted silently through the MDM channel, and the user never sees the prompts. This is why macOS endpoint security at enterprise scale requires Intune enrollment, not just MDE installation.

The attacker’s perspective on TCC: an attacker who gains code execution on macOS faces TCC restrictions that Windows attackers do not encounter. Keylogging requires an accessibility permission TCC grant. Screen capture requires a screen recording TCC grant. Reading Safari passwords requires full disk access. If the attacker does not have these grants (and they typically do not — they inherit the permissions of the process they compromised), they must either: bypass TCC (exploit a TCC vulnerability — these exist but are patched aggressively by Apple), social-engineer the user into granting TCC permissions, or operate within the permissions the compromised process already has. TCC significantly constrains post-exploitation activity on macOS compared to Windows.

System Integrity Protection and Gatekeeper

System Integrity Protection (SIP) prevents modification of system-protected files and directories even by the root user. The directories /System, /usr (except /usr/local), and /sbin are protected. An attacker with root access cannot: modify system binaries (to establish persistence through binary replacement), load unsigned kernel extensions (to install rootkits), or modify the kernel cache. SIP can only be disabled from macOS Recovery Mode — requiring physical access to the machine. For endpoint security, SIP means that even a fully compromised macOS system with root access cannot modify the OS itself, limiting persistence options to user-level mechanisms (launch agents, login items) rather than system-level modifications.

Gatekeeper prevents execution of applications that are not from the App Store or a verified developer (Apple’s notarization process). When a user downloads an application from the internet, Gatekeeper checks: is the application signed with a valid Developer ID certificate? Has the application been notarized by Apple (submitted for automated malware scanning and approved)? If either check fails, Gatekeeper blocks execution. The user can override Gatekeeper for individual applications (right-click → Open), but this requires deliberate action — drive-by downloads and phishing payloads are blocked by default.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Check SIP status
csrutil status

# Check Gatekeeper status
spctl --status

# Check TCC database (requires Full Disk Access)
sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db "SELECT client, auth_value, service FROM access;" 2>/dev/null

# Check if Defender for macOS is installed and running
mdatp health 2>/dev/null

The Endpoint Security framework: Apple’s official security API

Starting with macOS 10.15 Catalina, Apple replaced kernel extensions (kexts) with the Endpoint Security (ES) framework for security tool integration. The ES framework provides an authorised, user-space API for security tools to: monitor process execution (process creation, termination, exec), file system events (file create, modify, delete, rename, mount), network events (socket connections, DNS resolution), and authentication events (authentication attempts, credential changes).

MDE for macOS uses the ES framework as its primary telemetry source — it registers for the event types it needs and receives kernel-level notifications through the ES API without requiring a kernel extension. This is more stable than the kext approach (kexts could cause kernel panics if buggy) and more secure (the ES API limits what the security tool can access to specific event categories, unlike kexts which had unrestricted kernel access).

The practical implication: MDE on macOS has different detection capabilities than MDE on Windows because the ES framework provides different event types than Windows ETW. Some events available through ETW have no ES equivalent, and vice versa. Specific gaps: macOS ES does not provide the equivalent of Windows registry events (macOS uses property lists, not a registry). macOS ES provides different network event granularity than Windows ETW. And macOS ES’s process monitoring captures different metadata fields than Windows DeviceProcessEvents. The result: KQL hunting queries written for Windows DeviceProcessEvents may need adaptation for macOS — the table names are the same in MDE Advanced Hunting, but the available fields and event types differ.

Launch agents and launch daemons: macOS persistence. Where Windows has registry run keys and scheduled tasks, macOS uses launch agents (per-user, ~/Library/LaunchAgents/) and launch daemons (system-wide, /Library/LaunchDaemons/). Each is a property list (.plist) file that specifies a programme to run at user login (agents) or system startup (daemons). An attacker who drops a malicious .plist in LaunchAgents gains persistence that survives reboot. MDE for macOS monitors these directories for new .plist file creation — the ES framework’s file monitoring captures the event, and MDE alerts if the .plist points to a suspicious binary.

Troubleshooting

“Defender for macOS requires Full Disk Access and users keep denying the TCC prompt.” Deploy the TCC configuration profile through Intune. MDM-managed TCC profiles grant permissions silently without user prompts. Create an Intune configuration profile for macOS that grants Full Disk Access, Accessibility, and system extension permissions to the Defender for macOS application. Module ES13 covers the full macOS deployment process.

“We can’t install the Defender for macOS system extension on managed devices.” System extensions require user approval on macOS Ventura+ unless an MDM-managed System Extension profile is deployed. The Intune profile must include the team ID and bundle identifier for Microsoft’s system extension. Without this profile, users see a prompt that blocks the extension installation until they approve it in System Settings.

“Does MDE for macOS detect kernel-level rootkits?” macOS SIP and Secure Boot prevent most kernel-level persistence. On Apple Silicon Macs, the Secure Enclave validates boot chain integrity before the kernel loads. Traditional kernel rootkits that modify kernel memory or load unsigned kernel extensions are effectively impossible on modern macOS with SIP enabled. MDE for macOS focuses on user-space detection through the Endpoint Security framework, which covers the attack surface that remains accessible after SIP and Secure Boot constrain kernel-level modification.