Apple made a list. Santa still checks it twice

macOS Golden Gate 27 shipped in early September with App Settings, letting device management control which binaries run. We built Santa for this over a decade ago, 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 allows one third-party app and Apple binaries without a Team ID:

{
  "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 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, 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 don’t report denied executions to device management.

Santa’s Monitor mode allows unknown binaries, records the ones it would block, and uploads those events to the sync server. In Workshop you can search those events across the fleet and see the most frequently blocked binaries in a report. 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. 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 can allow an exact ad hoc-signed build of an internal tool without a Developer ID. With transitive rules 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. In Standalone 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 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, 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. You can block osascript with one Signing ID rule and use Workshop tags to exempt groups that need it.

Santa also has CEL rules, 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, 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.