Mac notarization is Apple’s code-signing review process for macOS software. The developer submits an app or installer so Apple can scan it for known malware and attach a notarisation ticket that macOS can check before and during execution, alongside code signing and Gatekeeper checks.
How Mac notarization works
Mac notarization is a distribution-time review step, not a runtime antivirus product. A developer submits macOS software to Apple, Apple scans it for known malware, and if it passes, Apple issues a notarization ticket that macOS can check before launch and during execution. That ticket complements code signing and Gatekeeper, which together shape how macOS decides whether software is trustworthy enough to open.
Why notarization exists
The main purpose of notarization is to reduce the chance that obviously malicious or tampered Mac software reaches users with a valid-looking signature. Code signing proves who built the package, but it does not by itself prove the software is safe. Notarization adds a second trust step that helps Apple and macOS enforce a baseline safety check at the point where software is distributed and first run.
For enterprise fleets, that matters because macOS is often a business endpoint platform, not a personal device. macOS Security Guide for Enterprises covers the wider controls that notarization sits alongside, including Gatekeeper, XProtect, FileVault, SIP, and managed deployment patterns.
What notarization does and does not guarantee
Notarization is best understood as a screening and reputation checkpoint, not a guarantee of benign behaviour. It can help block known malware and malformed packages, but it cannot prove that software is free of logic flaws, later supply-chain compromise, or authorised-but-abusive behaviour. A clean notarization result also does not mean the app is appropriate for every environment, because local policy, permissions, and least-privilege design still matter.
In practice, notarization sits inside a layered macOS trust model. Apple’s own platform security material explains how code signing, Gatekeeper, and other platform checks work together, while enterprise teams still need to decide which software sources are allowed and how packages are introduced into the fleet.
Operational impact for developers and defenders
For developers, notarization changes release engineering: the build pipeline must produce signed, reviewable artifacts and preserve trust through packaging and distribution. For defenders, it gives a useful control point for intake policy, but it does not replace software vetting, allowlisting, or endpoint monitoring. If a package bypasses normal distribution channels, or if an approved app is later altered, the surrounding controls become just as important as the original notarization ticket.
Because notarization is tied to macOS execution controls, defenders should treat it as part of a broader device trust posture rather than a standalone approval stamp. That is especially true in managed environments where configuration profiles, MDM policy, and user-install exceptions can alter the practical exposure of a Mac estate.
How to think about it in a security programme
Mac notarization is most useful when it is treated as one layer in a disciplined software trust and endpoint governance model. Teams should expect it to reduce commodity malware risk, but not to solve software authenticity, post-release compromise, or policy enforcement by itself. It is strongest when paired with strict software provenance, controlled distribution, and endpoint protections that continue to verify trust after installation.
That broader trust model is why Apple platform controls and enterprise hardening guidance matter together, not separately. Notarization helps answer, "Should this Mac software be allowed to start?", while adjacent controls answer whether the device remains hardened, monitored, and recoverable if the answer was wrong.
Risk and Threat Considerations
Notarization reduces but does not remove software intake risk. The main exposure is false confidence: organisations may assume a notarized Mac app is safe, even though the package can still be unwanted, overprivileged, or later compromised through supply-chain tampering.
Failure mechanism: If an attacker can get malicious or altered software signed, packaged, or distributed through a trusted channel, notarization may only confirm that the artifact passed Apple’s review at that moment, not that its behaviour is benign over time.
Impact: The result can be endpoint compromise, persistence through trusted software paths, and a weaker ability to distinguish legitimate Mac software from software that merely appears trusted.
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 | Notarization screens Mac software for known malware, aligning with malicious-code intake control. |
| CM-5 — Access Restrictions for Change | Notarization supports controlled software introduction and change approval on endpoints. | |
| Recommendation — Use SI-3 to scan Mac software for malicious content before allowing execution. Apply CM-5 to restrict unauthorised software changes and installs on Macs. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Notarization is most effective when software intake is inventoried and governed. |
| CIS-10 — Malware Defenses | Notarization is a malware-exposure reduction step for macOS application delivery. | |
| Recommendation — Inventory Mac software and allow only approved notarized applications. Combine Mac notarization checks with layered malware defenses on endpoints. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Controlled macOS software trust depends on managed endpoint configuration and deployment. |
| Recommendation — Manage Mac software trust settings through controlled configuration baselines. | ||
Practitioner Guidance
Why practitioners should care: Treat notarization as an intake control that supports endpoint trust, not as a substitute for software approval and provenance review. For Mac fleets, the meaningful decision is how notarization fits with code signing, source control, and managed deployment policy.
What to watch for: Pay close attention to software that is newly introduced, re-packaged, side-loaded, or exempted from normal distribution processes, because those are the situations where notarization provides the least practical reassurance.
Related resources from NHI Mgmt Group
- What is the difference between system integrity protection and notarization for Mac apps?
- How should teams govern Mac devices without creating a separate admin model?
- How should organisations govern Mac authentication and endpoint control together?
- Why do traditional DLP tools struggle in Mac and SaaS environments?
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 November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org