Notarization is Apple’s review and ticketing process for macOS software that is intended to increase trust in executables. It can block known bad code, but it is not a permanent guarantee. If a notarization ticket is revoked or a sample is re-signed, the same malware family may still reappear.
Expanded Definition
Notarization is Apple’s trust review and ticketing workflow for macOS software, used to signal that a binary has passed a security check before it is distributed or run. It is a gate, not a certificate of innocence.
The practical boundary matters: notarization can reduce exposure to known malicious code and can support ecosystem trust, but it does not make software permanently safe. A notarized app can still be harmful if it is repackaged, if a ticket is revoked, or if the underlying sample changes after review. In that sense, the term is often misunderstood as “Apple approval,” when it is closer to “Apple has seen this artifact and attached a trust signal.”
In macOS security discussions, notarization sits alongside code signing and Gatekeeper, but it should not be confused with either one. Code signing establishes publisher identity and integrity, while notarization reflects a point-in-time review outcome. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames integrity and software trust as part of a broader control set, not a single vendor mechanism.
One common implementation reality is that trust decisions age quickly. If defenders treat notarization as a permanent allowlist, they can miss the difference between a verified distribution event and the software’s current behaviour.
Examples and Use Cases
Notarization appears in several everyday macOS workflows:
- Distributing a commercial desktop app that must pass Apple’s review before users can install it with fewer security prompts.
- Publishing an internal macOS tool so employees can open it without immediate quarantine friction, while still maintaining a review trail.
- Shipping an update to an existing app, where the new build needs its own notarization ticket even if the previous release was accepted.
- Tracking whether a sample identified as suspicious was later re-signed and redistributed, which can complicate incident response and reputation-based blocking.
These cases show why notarization is best treated as part of a software trust workflow, not as a standalone assurance. It helps reduce friction for legitimate software, but it also creates a dependency on Apple’s review, ticketing, and revocation posture.
For teams that manage macOS fleets, the useful question is often not “was it notarized?” but “is the current artifact the same one that was reviewed, and is it still trusted?” That distinction affects deployment policy, user messaging, and whether additional validation is needed before execution.
Security Implications
When notarization is misunderstood, organisations can over-trust software that only passed a historical review. The result is a false sense of safety, especially when malware is repackaged, re-signed, or distributed through channels that bypass the original ticket context.
A second failure mode is revocation lag or incomplete enforcement. If defenders do not continuously validate the current trust state, a revoked sample may remain runnable in some environments, or a variant may slip through because it no longer matches the original detection assumptions. That widens the blast radius from a single download to a broader distribution and persistence problem.
The practitioner signal is simple: notarization should inform trust decisions, but it should never replace file provenance checks, allowlist discipline, or endpoint telemetry. If the same family of malware can reappear under a new signature or package, then the control worked only for the first artifact, not for the threat lifecycle.
For defenders, this means policy should distinguish between “reviewed once” and “currently trusted.” The security value comes from treating notarization as one layer in a larger integrity model rather than as a permanent approval state.
Security, Operational and Governance Implications
Operationally, notarization creates a governance question: who decides what is trusted, for how long, and under what revalidation conditions? That matters for software distribution, incident response, and exception handling in managed macOS environments.
It also affects recovery workflows. If a ticket is revoked, teams need a clear path to identify impacted endpoints, quarantine suspicious binaries, and confirm whether a re-signed sample is functionally the same threat. Without that discipline, revocation becomes a paper control instead of a containment control.
From a broader security perspective, notarization is most effective when paired with telemetry, software inventory, and execution control. It supports trust, but governance must decide how much trust it earns and how quickly that trust expires.
For organisations that distribute software internally, the practical implication is that notarization should be embedded into release management, not treated as a final sign-off. The control is strongest when it is continuously checked against the current artifact, current threat intelligence, and current endpoint state.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 2 — Inventory and Control of Software Assets | Notarization affects software trust and approved execution of macOS binaries. |
| CIS 10 — Malware Defenses | Notarization is used to reduce exposure to malicious or repackaged executables. | |
| Recommendation — Maintain a current software inventory and permit only trusted, authorised macOS software builds. Combine malware defenses with execution controls to block untrusted or re-signed binaries. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Notarization supports integrity and trust of software artifacts that process or protect data. |
| PR.PS — Platform Security | macOS notarization is a platform trust control for application execution. | |
| Recommendation — Protect software integrity by validating trusted artifacts before they run in production. Use platform security controls to verify and constrain which macOS apps may execute. | ||
| MITRE ATT&CK | T1553.002 — Subvert Trust Controls: Code Signing | Malware can abuse signing and repackaging to retain trust after review. |
| Recommendation — Hunt for signed or re-signed malicious binaries and validate trust assumptions continuously. | ||
Related resources from NHI Mgmt Group
- Who is accountable for confirming whether an eNotary certificate meets state notarization requirements?
- What do security and compliance teams get wrong about remote notarization and digital signing?
- What is the difference between eSignature and remote online notarization in regulated workflows?
- How should organisations implement remote online notarization without weakening identity assurance or fraud controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
