In recent iterations of macOS, Apple has aggressively tightened operating system security, deprecating legacy Kernel Extensions (Kexts) in favour of modern System Extensions. These modern frameworks run in user space rather than kernel space, significantly improving system stability. However, when deploying enterprise software such as endpoint detection and response (EDR) agents, VPN clients, or advanced networking tools, these extensions require explicit user approval via the Privacy & Security preference pane before they can operate. In an enterprise environment, relying on end-users to manually approve critical security software is unacceptable. Administrators must automate this approval process using Mobile Device Management (MDM) configuration profiles.
The Evolution from Kexts to System Extensions
Historically, software requiring deep system access relied on Kexts. Apple introduced User Approved Kernel Extension Loading (UAKEL), requiring manual interaction to load them. Today, Kexts are heavily restricted, and developers are mandated to use System Extensions.
While the underlying architecture has changed, the management challenge remains the same: silently approving the extension without user intervention. MDM profiles allow administrators to whitelist specific developers or individual extensions, ensuring security software deploys and activates seamlessly.
Understanding the Team ID and Bundle Identifier
To construct a configuration profile that approves a System Extension, you must identify two crucial pieces of information from the software vendor:
- Team Identifier (Team ID): A unique, 10-character alphanumeric string assigned by Apple to the software developer (e.g.,
EQHXZ8M8AV). - Bundle Identifier: The specific reverse-DNS name of the extension itself (e.g.,
com.vendor.product.extension).
If you do not know these values, you can extract them from an endpoint where the software is already installed by running the systemextensionsctl list command in the macOS Terminal.
Creating the System Extension Policy Profile
Modern MDM platforms, such as Jamf Pro, Kandji, or Microsoft Intune, provide graphical interfaces for creating System Extension profiles. When configuring the payload, you are manipulating the com.apple.system-extension-policy domain.
You have three primary methods for approval within the profile:
- Allowed System Extensions: This is the most granular and secure method. You must specify both the developer’s Team ID and the exact Bundle Identifier of the extension. Only that specific extension is approved.
- Allowed Team Identifiers: This method is broader. By providing only the Team ID, you approve any current or future System Extension signed by that specific developer. This is useful for vendors with rapidly changing extension bundles, but carries a slightly higher risk.
- Allowed System Extension Types: You can explicitly allow specific types of extensions (such as Network Extensions or Endpoint Security Extensions) from specific developers, providing a middle ground between strict bundle approval and blanket developer approval.
Managing Legacy Kernel Extensions (Kexts)
If your organisation still relies on older software that utilises legacy Kexts, you must deploy a separate Kernel Extension Policy profile (com.apple.syspolicy.kernel-extension-policy). The logic is identical: you whitelist the Kext using the developer’s Team ID and the specific Bundle Identifier.
However, there is a critical caveat for modern Macs. On Macs equipped with Apple Silicon (M1/M2/M3 chips), Kexts cannot be loaded simply by pushing an MDM profile. The Mac must first be booted into macOS Recovery, and the local security policy must be manually downgraded from “Full Security” to “Reduced Security”, checking the box to allow user management of kernel extensions. Only after this manual, physical intervention will the MDM Kernel Extension Policy take effect. This deliberate friction underscores Apple’s push toward modern System Extensions.
Deployment and Verification
When the configuration profile is pushed to the macOS fleet, the OS intercepts the approval requirement. When the enterprise application attempts to load its System Extension, macOS checks the active MDM policies. Finding a match for the Team ID and Bundle Identifier, the OS silently authorises the extension to load, entirely bypassing the Privacy & Security prompt.
Administrators can verify the successful application of the policy locally on a managed Mac by executing profiles list in the Terminal to confirm the payload installation, followed by systemextensionsctl list to verify the extension status indicates [activated enabled].