Gatekeeper, XProtect and Notarization on macOS

Once the operating system itself is protected by System Integrity Protection, the next question is what third-party code is allowed to run. macOS answers this with several cooperating layers: the quarantine attribute marks untrusted downloads, Gatekeeper evaluates them against code signing and notarization rules, and XProtect and XProtect Remediator look for known malware. This guide explains each layer on macOS 15 Sequoia and macOS 26 Tahoe, shows how to verify them from the command line, and covers MDM control and optional allowlisting with Santa.

The layers at a glance

Quarantine

When a quarantine-aware app such as a browser, mail client or messaging app writes a downloaded file, it adds the com.apple.quarantine extended attribute. That attribute records which app downloaded the file and when, and it is what triggers Gatekeeper's first-launch assessment.

xattr -l ~/Downloads/Example.dmg
xattr -p com.apple.quarantine ~/Downloads/Example.dmg

Two consequences matter for defenders. First, software that arrives without the attribute, for example through curl, some command-line package managers, or copied from certain file systems, does not get Gatekeeper's first-launch check. Second, users and installers can strip the attribute, which is why Gatekeeper alone is not an allowlisting control.

Code signing and Developer ID

Every app distributed outside the Mac App Store should be signed with a Developer ID certificate issued by Apple to a registered developer. The signature binds the code to a team identifier and makes any modification after signing detectable.

Inspect a signature:

codesign -dv --verbose=4 /Applications/Example.app

Useful fields in the output include Identifier, Authority (the certificate chain, which should end at Apple Root CA and start with Developer ID Application: ...), TeamIdentifier, and whether the hardened runtime is enabled. Check integrity with:

codesign --verify --deep --strict --verbose=2 /Applications/Example.app

For installer packages, use pkgutil:

pkgutil --check-signature ~/Downloads/Example.pkg

Notarization and stapling

Notarization is an automated Apple service. Developers upload a signed build, Apple scans it for known malicious content and checks signing requirements such as the hardened runtime, and if it passes, Apple issues a ticket. Gatekeeper can look that ticket up online, or the developer can staple it to the app, disk image or package so it can be validated offline.

Notarization is not an App Store review. It says the build was scanned and signed correctly; it does not say the software is appropriate for your environment.

Check Gatekeeper's verdict on an app:

spctl -a -vv /Applications/Example.app

/Applications/Example.app: accepted
source=Notarized Developer ID
origin=Developer ID Application: Example Corp (TEAMID1234)

Check whether a notarization ticket is stapled (requires the Xcode command line tools):

xcrun stapler validate /Applications/Example.app

A source of Notarized Developer ID is what you want for third-party apps. Mac App Store apps report their own source, and rejected means Gatekeeper would block the app if it were quarantined.

Gatekeeper policy and the Sequoia change

In System Settings > Privacy & Security, the "Allow applications from" setting offers App Store only, or App Store and identified developers. The latter is the practical baseline for most organizations; the former is stricter and suitable for kiosk-like or tightly scoped Macs.

Before macOS Sequoia, users could bypass a Gatekeeper warning on an unnotarized app with Control-click and Open. That shortcut no longer works. In Sequoia and later, the user must try to open the app, then go to System Settings > Privacy & Security, click Open Anyway for that app and authenticate as an administrator. This adds friction for users and is a helpful signal in security awareness training: a website instructing users to go into System Settings to open something is a classic social-engineering pattern.

Managing Gatekeeper with MDM

Two payloads are relevant:

A typical baseline payload:

<dict>
    <key>PayloadType</key>
    <string>com.apple.systempolicy.control</string>
    <key>EnableAssessment</key>
    <true/>
    <key>AllowIdentifiedDevelopers</key>
    <true/>
</dict>

Adding DisableOverride removes the Open Anyway escape hatch entirely. That is appropriate when all software is delivered through your MDM or self-service portal, and it will generate helpdesk tickets if it is not. See the MDM and configuration profiles guide for delivery details.

XProtect and XProtect Remediator

XProtect is Apple's built-in signature-based malware detection. It uses YARA-based rules to check apps when they are first launched, when they have changed on disk, and when its signatures are updated. Its rules ship in the XProtect.bundle under /Library/Apple/System/Library/CoreServices/ and are updated independently of full macOS releases.

XProtect Remediator runs periodic background scans for specific malware families and can remove what it finds. On macOS 13 and later, its detections and remediations are also surfaced as Endpoint Security events, so EDR tools can report them; see unified logging and Endpoint Security.

XProtect is valuable but reactive: it only knows families Apple has already analyzed. Keep it current by leaving automatic installation of security responses and system data files enabled, as discussed in the software updates guide.

Allowlisting and Santa

Gatekeeper enforces "signed and notarized", not "approved by us". Organizations that need real application control can add a binary authorization layer. Santa is an open-source binary authorization system for macOS, originally developed at Google and now maintained by North Pole Security. It uses the Endpoint Security framework to evaluate every execution against rules based on binary hash, signing certificate, team identifier, or signing identifier.

Santa runs in two modes:

• Monitor mode logs executions and blocks only what is explicitly blocklisted. Start here to learn what your fleet runs.
• Lockdown mode blocks anything not explicitly allowlisted. This is strong but demands a mature process for approving new software.

Check the local state with santactl status. Rules are normally distributed from a sync server rather than managed by hand.

When designing allowlists, prefer team identifier or signing identifier rules over certificate or hash rules for vendor software: hashes change with every update, while a team identifier survives version bumps. Keep hash rules for unsigned internal tools.

Verify it

spctl --status
spctl -a -vv /Applications/Example.app
codesign -dv --verbose=4 /Applications/Example.app
xcrun stapler validate /Applications/Example.app
defaults read /Library/Apple/System/Library/CoreServices/XProtect.bundle/Contents/Info.plist CFBundleShortVersionString

Expected Gatekeeper status:

assessments enabled

Compare the XProtect version against other Macs in your fleet; a Mac that lags far behind usually has update settings or network restrictions that also affect other security content.

Common pitfalls

• Treating notarization as endorsement. It is a malware scan and signing check, not a statement that the software is safe for your environment.
• Disabling Gatekeeper to "fix" an install problem. Resolve the specific app instead.
• Ignoring non-quarantined execution paths. Command-line installs and scripts skip Gatekeeper's first-launch check; cover them with EDR or Santa.
• Hash-based allowlists for vendor apps, which break on every update.
• Enabling DisableOverride without a software catalog, which pushes users toward workarounds.

Checklist

• Gatekeeper enabled via com.apple.systempolicy.control, App Store and identified developers at minimum
• Override policy decided deliberately and documented
• XProtect and security data updates installing automatically
• XProtect Remediator events collected by your EDR or logging pipeline
• Signature and notarization checks part of your software intake process
• Optional: Santa in monitor mode, moving to lockdown for high-risk groups