--- title: "Apple made a list. Santa still checks it twice" description: "macOS 27 adds native allow and deny lists for binaries. Apple is right that Macs need execution control, but a managed fleet needs more than a list." doc_version: "1" last_updated: "2026-10-22" canonical: "https://northpole.security/blog/macos-27-app-settings" --- [Back](https://northpole.security/blog) Research • September 30, 2026 • By Russell Hancox ![Apple made a list. Santa still checks it twice](https://northpole.security/images/blog/macos-27-app-settings-hero.jpg) ![](https://northpole.security/images/home/divider-band-top.svg) macOS Golden Gate 27 shipped in early September with [App Settings](https://developer.apple.com/documentation/devicemanagement/allowing-and-denying-apps-and-binaries), letting device management control which binaries run. We built [Santa](https://northpole.dev) for this [over a decade ago](https://github.com/google/santa), and we’re glad to see Apple add execution control to macOS. ## What Apple shipped The declarative device management configuration `com.apple.configuration.app.settings` accepts `AllowedBinaries`, `DeniedBinaries`, or both on supervised Macs only. A deny list blocks listed binaries while other production-signed software keeps running. An allow list permits only listed binaries and core OS components. macOS stops running binaries that no longer match the policy. Apple enforces this through its own Endpoint Security client, the same library Santa is built on. Rules match `CDHash`, `TeamID`, `SigningID`, `PathPrefix`, and `SigningState` (such as `DeveloperID` or `AppStore`). Allow entries require `CDHash` or `TeamID` because Signing IDs aren’t unique across developers. In allow mode, `AlwaysAllowManagedApps` lets MDM-deployed apps run without listing them individually. [Apple’s example](https://developer.apple.com/documentation/devicemanagement/allowing-and-denying-apps-and-binaries) allows one third-party app and Apple binaries without a Team ID: JSON ``` { "Type": "com.apple.configuration.app.settings", "Payload": { "Allowed": { "AllowedBinaries": [ { "TeamID": "XXXXXXXXXX", "SigningID": "com.example.app" }, { "TeamID": "*APPLE*" } ] } } } ``` ## Why this matters Detection-first security assumes you can spot bad software after it starts. [Gatekeeper and notarization](https://support.apple.com/en-us/102445) check that an app comes from an identified developer and Apple’s automated scan found no known malicious content when the app was submitted. In July, Jamf Threat Labs [reported on CrashStealer](https://www.jamf.com/blog/crashstealer-macos-infostealer-analysis/), an infostealer delivered through a fake video conferencing app. Its installer cleared Gatekeeper on first launch with a valid Developer ID and stapled notarization ticket. Allowlisting blocks unapproved software, signed or not. We see Apple’s decision as an endorsement of that approach. ## Where it falls short for a fleet App Settings can enforce an allowlist. Running one across thousands of Macs also means planning the rollout, supporting developers, and handling exceptions. ### You roll it out blind There’s no monitor or audit mode to learn what your fleet runs before enforcing a policy. Blocked users see an alert, but Apple’s [declarative status items](https://github.com/apple/device-management/tree/release/declarative/status) don’t report denied executions to device management. Santa’s [Monitor mode](https://northpole.dev/features/binary-authorization/#client-mode) allows unknown binaries, records the ones it would block, and [uploads those events](https://northpole.dev/features/sync/) to the sync server. In Workshop you can [search those events](https://docs.workshop.cloud/events) across the fleet and see the most frequently blocked binaries in a [report](https://docs.workshop.cloud/reports). You build policy from what people run, move groups to Lockdown mode when ready, and keep seeing every block. ### Developers can’t run their own code Any allow or deny list, even an empty one, [blocks unsigned, ad hoc-signed, and development-signed binaries](https://support.apple.com/guide/deployment/dep001044b08). Apple checks this before your rules, so no rule can make an exception. On Apple silicon, `clang` and `go build` ad hoc sign output by default: freshly compiled programs won’t launch under either list. Santa’s [`CDHASH` rules](https://northpole.dev/features/binary-authorization/#cdhash) can allow an exact ad hoc-signed build of an internal tool without a Developer ID. With [transitive rules](https://northpole.dev/features/binary-authorization/#allowlist-compiler) enabled, Santa creates an allow rule when an allowed compiler writes a new binary. The rule applies only on that machine, so developers can build and run their own code in Lockdown mode. ### Users hit a wall Apple’s generic block alert says the organization prevented execution. There’s no custom message, help link, or exception request, leaving false positives to the help desk. Santa’s block dialog supports per-rule messages and links to your own page with the blocked binary’s details. In Workshop, blocked users can approve an app themselves, ask peers to vote, or request a designated approver’s permission. Every step is [audited](https://docs.workshop.cloud/approval-workflows). In [Standalone mode](https://northpole.dev/features/binary-authorization/#client-mode), users can approve unknown software on their Mac with Touch ID or their password. ### Rules leave little room for exceptions If a binary matches both Apple lists, deny wins. You can’t block a Team ID and exempt one tool. Adding an allow entry also switches the whole Mac to allow mode. The reverse works: allow a Team ID and deny one of its apps. Rules match signing identity and path, not launch context. Apple’s [core policy](https://support.apple.com/guide/deployment/dep001044b08) decides the outcome for protected locations like `/bin`, `/usr/bin`, `/usr/libexec`, and most of `/System` before consulting your rules. Of the binaries in the sealed OS, only deferred ones, such as apps in `/Applications` and `/System/Applications`, reach your rules. That puts `curl`, `zsh`, and `osascript` out of reach of your rules, though malware frequently uses them. Stealers use `osascript` for fake password dialogs. Some [run entirely as shell and AppleScript](https://www.netskope.com/blog/macos-clickfix-lures-deploy-applescript-stealer-persistent-rat), without dropping a compiled binary of their own. They steal data before writing their code to disk. Santa checks your rules before allowing Apple platform binaries by default. It never blocks a small set of critical system processes, including `xpcproxy` and `tccd`. Santa evaluates rules from most specific to broadest: CDHash, binary hash, Signing ID, certificate, then Team ID. [A Signing ID allow rule beats a Team ID block rule](https://northpole.dev/features/binary-authorization/#rule-layering). You can block `osascript` with one Signing ID rule and use [Workshop tags](https://docs.workshop.cloud/tags) to exempt groups that need it. Santa also has [CEL rules](https://northpole.dev/features/binary-authorization/#cel), which can add conditions on each launch’s arguments, environment, user, and working directory. Workshop also lets CEL rules look at a process’s ancestors and apply time windows. Our [CEL cookbook](https://northpole.dev/cookbook/cel/), for example, blocks `osascript` when its arguments ask for a hidden password dialog. Rules that inspect arguments can’t see a script piped in on standard input, though. For most users, the Signing ID block is the stronger control. ## Where App Settings fits For kiosks, labs, or shared front-desk Macs with stable software and no development, an allow list plus `AlwaysAllowManagedApps` may be enough. For knowledge workers and engineers, you need to update the policy safely, handle exceptions, and see what it blocks. Effectively and efficiently managing this only increases in complexity and importance as you scale. Based on our 10+ years experience managing allowlisting on over 100,000 devices for one organization, we know Santa and Workshop are the right tools for the job. Santa Workshop Allowlisting macOS Security Endpoint Protection ## You may also like [ ![EDR Freeze on macOS](https://northpole.security/images/blog/edr-freeze-hero.jpg) Research • June 18, 2026 EDR Freeze on macOS EDR Freeze came to Windows via debugging tricks. macOS has its own version using pid\_suspend, and one subscription call stops it ](https://northpole.security/blog/edr-freeze)[ ![Announcing Santa and Workshop 2026.9](https://northpole.security/images/blog/release-2026.9/release-2026.9-hero.jpg) Releases • October 15, 2026 Announcing Santa and Workshop 2026.9 Santa and Workshop 2026.9 add process annotations that make Lockdown livable for developers, DNS rules, security key approvals, and much more ](https://northpole.security/blog/release-20269)[ ![Announcing Santa and Workshop 2026.8](https://northpole.security/images/blog/release-2026.8/release-2026.8-hero.jpg) Releases • September 10, 2026 Announcing Santa and Workshop 2026.8 Santa and Workshop 2026.8 add time based rules, a top-level Tags section, file access process overrides, sequence signals, and Nix package rules ](https://northpole.security/blog/release-20268) ## Sitemap - [Home](https://northpole.security/index.md) - [Workshop](https://northpole.security/workshop.md) - [Santa](https://northpole.security/santa.md) - [Features](https://northpole.security/features.md) - [Cookbook](https://northpole.security/cookbook.md) - [Docs](https://northpole.security/docs.md) - [Blog](https://northpole.security/blog.md) - [Glossary](https://northpole.security/glossary.md) - [About](https://northpole.security/about.md) - [Contact](https://northpole.security/contact.md)