{ "id": "0faaa075-8706-4385-8f71-e1af9b16f8a6", "created_at": "2026-04-06T00:06:50.057108Z", "updated_at": "2026-04-10T03:20:57.047683Z", "deleted_at": null, "sha1_hash": "b9199ee3e62cfbd041962e65a2ecdcde9ddfd7ad", "title": "Technical Note TN2459: User-Approved Kernel Extension Loading", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 128869, "plain_text": "Technical Note TN2459: User-Approved Kernel Extension Loading\r\nPublished: 2018-04-19 · Archived: 2026-04-05 18:31:21 UTC\r\nTechnical Note TN2459\r\nmacOS High Sierra 10.13 introduces a new feature that requires user approval before loading new third-party\r\nkernel extensions. This feature will require changes to some apps and installers in order to preserve the desired\r\nuser experience. This technote is for developers who ship kernel extensions to users and system administrators\r\nwho need to install kernel extensions.\r\nIntroduction\r\nmacOS High Sierra 10.13 introduces a new feature that requires user approval before loading newly-installed\r\nthird-party kernel extensions (KEXTs). When a request is made to load a KEXT that the user has not yet\r\napproved, the load request is denied. Apps or installers that treat a KEXT load failure as a hard error will need to\r\nbe changed to handle this new case.\r\nApproval is automatically granted to third-party KEXTs that were already present when upgrading to macOS High\r\nSierra.\r\nNote that approval doesn't guarantee that a KEXT is compatible and won't panic the system. The reason this\r\nfeature exists is to give users more control over what KEXTs will load, which should reduce the number of panics.\r\nIn-Depth Explanation\r\nThis feature enforces that only kernel extensions approved by the user will be loaded on a system. When a request\r\nis made to load a KEXT that the user has not yet approved, the load request is denied and macOS presents the\r\nalert shown in Figure 1.\r\nFigure 1  Blocked kernel extension\r\nhttps://developer.apple.com/library/archive/technotes/tn2459/_index.html\r\nPage 1 of 6\n\nThis prompts the user to approve the KEXT in System Preferences \u003e Security \u0026 Privacy as shown in Figure 2.\r\nFigure 2  User approval to load a KEXT\r\nhttps://developer.apple.com/library/archive/technotes/tn2459/_index.html\r\nPage 2 of 6\n\nhttps://developer.apple.com/library/archive/technotes/tn2459/_index.html\r\nPage 3 of 6\n\nThis approval UI is only present in the Security \u0026 Privacy preferences pane for 30 minutes after the alert. Until\r\nthe user approves the KEXT, future load attempts will cause the approval UI to reappear but will not trigger\r\nanother user alert.\r\nThe alert shows the name of the developer who signed the KEXT so the user has some information to decide\r\nwhether to approve the KEXT. This name comes from the Subject Common Name field of the Developer ID\r\nApplication certificate used to sign the KEXT. Because of this, developers are encouraged to provide an\r\nappropriate company name when requesting KEXT signing identities.\r\nWhen the user approves a KEXT, they are at the same time approving these other KEXTs signed by the same\r\nTeam ID:\r\nIf the approved KEXT is located in an application's bundle, all other KEXTs signed by the same Team ID\r\nin the same application's bundle are also approved.\r\nIf the approved KEXT is located in the app's sub-directory inside /Library/Application Support , all\r\nother KEXTs signed by the same Team ID found in that same sub-directory are also approved.\r\nAll KEXTs in /Library/Extensions signed by the same Team ID are also approved.\r\nOnce approved, the KEXT will immediately be loaded or added to the prelinked kernel cache, depending on what\r\naction was blocked. Subsequent requests to load the KEXT will proceed silently as on previous macOS versions.\r\nhttps://developer.apple.com/library/archive/technotes/tn2459/_index.html\r\nPage 4 of 6\n\nApproved KEXTs are tracked in a system-wide policy database through the team identifier in the KEXT's code\r\nsignature and the bundle identifier from the KEXT's Info.plist , so updating a KEXT that has already been\r\napproved will not trigger a new approval request.\r\nHow This Affects KEXT Developers\r\nInstallers and applications that load kernel extensions may need to be revised to gracefully handle the kernel\r\nextension failing to load. Many products treat a KEXT loading failure as a hard failure. Some prompt the user to\r\nreinstall, some present a cryptic error message, and some simply don't function.\r\nStarting with macOS High Sierra, installers and apps that load KEXTs should expect that KEXT loading will fail\r\nif the user hasn't approved their KEXT. Instead of treating this as an error, the user should be informed that they\r\nmay need to approve the KEXT.\r\nTo determine if a KEXT has failed to load because it does not have user approval:\r\nIf you are using kextutil or kextload , check for the exit code 27. In addition, kextutil will produce\r\nthe error message System policy prevents loading the kernel extension.\r\nIf you are using the KextManager APIs in IOKit/kext/KextManager.h , check for the result code\r\nkOSKextReturnSystemPolicy .\r\nHow This Affects Enterprise App Distribution\r\nFor enterprise deployments where it is necessary to distribute software that includes kernel extensions without\r\nrequiring user approval, there are two options:\r\nIf your workflow is based on imaging, boot into Recovery OS and use the spctl kext-consent\r\ncommand. For detailed information about the spctl command, run the command spctl help . This\r\ncommand can either disable the user approval requirement completely or specify a list of Team IDs whose\r\nKEXTs may be loaded without user approval. The spctl command works in any installation\r\nenvironment, including Recovery OS and from NetBoot/NetInstall/NetRestore images.\r\nNote that the Team ID list maintained by spctl is separate from the system-wide policy database.\r\nFor workflows that leverage Mobile Device Management (MDM), please see the AppleCare support article\r\nPrepare for changes to kernel extensions in macOS High Sierra.\r\nTo reiterate, all third-party KEXTs that were already installed at the time of upgrading to macOS High Sierra are\r\nautomatically approved and don't require any user action.\r\nDocument Revision History\r\nhttps://developer.apple.com/library/archive/technotes/tn2459/_index.html\r\nPage 5 of 6\n\nDate Notes\r\n2018-04-19 Updated for MDM changes in macOS 10.13.4.\r\n2017-09-08 Updated for macOS High Sierra beta 8.\r\n2017-08-04 Updated for macOS High Sierra beta 4.\r\n2017-07-12 Updated for macOS High Sierra beta 3.\r\n2017-06-19\r\nNew document that describes the user-approved kernel extension loading feature\r\nintroduced in macOS High Sierra.\r\nSource: https://developer.apple.com/library/archive/technotes/tn2459/_index.html\r\nhttps://developer.apple.com/library/archive/technotes/tn2459/_index.html\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://developer.apple.com/library/archive/technotes/tn2459/_index.html" ], "report_names": [ "_index.html" ], "threat_actors": [], "ts_created_at": 1775434010, "ts_updated_at": 1775791257, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/b9199ee3e62cfbd041962e65a2ecdcde9ddfd7ad.pdf", "text": "https://archive.orkl.eu/b9199ee3e62cfbd041962e65a2ecdcde9ddfd7ad.txt", "img": "https://archive.orkl.eu/b9199ee3e62cfbd041962e65a2ecdcde9ddfd7ad.jpg" } }