Gatekeeper is the launch-time enforcement layer that blocks or warns on untrusted software, while notarization is Apple’s pre-distribution review and approval process for third-party code. A notarized app may still face Gatekeeper checks, but notarization mainly adds Apple’s malware scan and ticketing evidence. The two controls overlap, but they are not the same mechanism.
How Gatekeeper and notarization differ in macOS
Gatekeeper and notarization both help reduce the risk of untrusted software on macOS, but they operate at different points in the software trust chain. Gatekeeper is the local enforcement decision made when a user opens an app or other downloadable executable. Notarization is Apple’s upstream review and signing attestation process that helps an app earn trust before distribution.
The practical difference is timing and purpose. Gatekeeper decides whether code should run on a Mac right now, based on trust evidence and policy. Notarization helps establish that trust evidence in advance by showing Apple has scanned the software and issued a notarization ticket. One is enforcement, the other is pre-distribution validation.
That distinction matters because a notarized app is not automatically exempt from launch-time checks. A developer can have code that is notarized but still blocked or warned on a device if the package is damaged, altered, quarantined, or otherwise fails local policy. Likewise, Gatekeeper is not a substitute for malware review during release engineering, because it evaluates the launch event rather than the publisher’s entire build and release process.
What each control is trying to prove
Notarization is designed to answer a supply-chain question: should Apple treat this third-party code as sufficiently reviewed to be distributed to users? The answer is backed by Apple’s malware scanning and a notarization ticket that can be checked later. It is a precondition for smoother distribution, not a guarantee that the software is harmless in every context.
Gatekeeper is designed to answer an endpoint question: should this software be allowed to launch on this machine under current trust conditions? It uses local signals such as whether the app is identified, where it came from, and whether the system should prompt or block based on policy. This is why a developer may need both a clean notarization process and a clean launch path.
For a broader view of how Apple desktop controls fit into enterprise hardening, the macOS Security Guide for Enterprises covers Gatekeeper alongside other macOS security mechanisms that defenders need to understand together.
Why the difference matters operationally
Teams often misread notarization as “approved forever” or Gatekeeper as “just a user prompt.” Neither assumption is accurate. Notarization can improve confidence in software provenance, but it does not remove the need to verify that the exact artifact a user receives is the same artifact that was notarized. Gatekeeper, meanwhile, is part of the last mile of enforcement and may still stop execution even when the publishing workflow looked correct.
This separation is useful when debugging install and launch failures. If a package was notarized but users still see blocking behaviour, the issue may be with quarantine metadata, code tampering, packaging errors, or an execution context that does not satisfy local policy. If an app is not notarized, distribution friction will usually be much higher, but that still does not tell you whether the code would otherwise be allowed to run in a controlled environment.
Mac fleet owners should therefore treat notarization as a build and release control, and Gatekeeper as an endpoint trust control. That mental model prevents confusion when troubleshooting app rollout, support tickets, and developer exceptions.
Risk and Threat Considerations
The main risk is assuming one control covers the other. If teams rely only on notarization, they may overlook local launch restrictions or package tampering after approval. If they rely only on Gatekeeper, they may miss weaknesses in how third-party software is produced, signed, or redistributed before it ever reaches the endpoint.
Failure mechanism: A trusted-looking app can still be altered, repackaged, or delivered in a way that causes local trust checks to fail, while a weak release process can allow malicious or modified code to be distributed even before launch-time enforcement is reached.
Impact: The result can be blocked installs, user bypass attempts, inconsistent fleet behaviour, or the mistaken belief that a Mac application is safe because it passed only one of the two trust stages.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | Applies because Gatekeeper and notarization both help control malicious software execution risk. |
| CM-5 — Access Restrictions for Change | Applies because app trust and launch policy are part of controlled software change on managed Macs. | |
| Recommendation — Use SI-3 to block or detect malicious code before it executes on endpoints. Use CM-5 to restrict and review software changes before they reach production devices. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | Applies because both controls reduce the chance that malicious or untrusted code runs on endpoints. |
| Recommendation — Deploy malware defenses that inspect, block, and alert on untrusted executable content. | ||
| ISO/IEC 27001:2022 | A.8.7 — Protection Against Malware | Applies because the question is about preventing malicious code execution on macOS. |
| A.8.19 — Installation of Software on Operational Systems | Applies because notarization and Gatekeeper both influence what software can be installed or run. | |
| Recommendation — Implement malware-protection measures that cover software acquisition and execution. Control software installation so only approved and verified apps reach operational systems. | ||
Practitioner Guidance
What to verify: Confirm which stage failed before changing policy. If the problem appears at distribution time, inspect the signing and notarization workflow; if it appears at launch time, inspect quarantine state, packaging integrity, and the local Gatekeeper decision path.
Decision rule: Treat notarization as evidence of upstream review, not as the final runtime permit. Treat Gatekeeper as the final local enforcement check, not as proof that the software was well built or well reviewed.
What practitioners underestimate: Troubleshooting gets much easier when release engineering and endpoint policy ownership are separate. The common mistake is to assume one team can fix both, when the failure may sit in different parts of the software trust chain.
Practitioner takeaway: Use notarization to raise confidence in third-party code before it ships, and use Gatekeeper to enforce trust at launch, because they solve adjacent but distinct problems.
Related resources from NHI Mgmt Group
- How should security teams evaluate macOS notarization as part of a layered endpoint defence strategy?
- What are the signs that macOS notarization is being applied too narrowly to materially improve endpoint security?
- How should security teams monitor macOS security updates in XProtect and Gatekeeper without waiting for Apple to document them?
- How should security teams respond when macOS malware steals passwords or Keychain data?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org