Notarized Developer ID is a macOS code signing and distribution model in which an app is signed with a Developer ID certificate and then checked by Apple’s notarisation service before release. The notarisation step verifies the app for known malware and signing integrity, and Gatekeeper uses the result when deciding whether to allow execution.
What Notarized Developer ID Means in Practice
Notarized Developer ID is more than a certificate label, it is a release trust model. Apple’s notarisation step adds a pre-distribution check that helps Gatekeeper decide whether a macOS app should run, so the term refers to both signing provenance and Apple’s additional review of the packaged app before users launch it.
That extra trust signal matters because a signed app without notarisation can still be blocked or warned on modern macOS, while a notarised build is treated as having passed Apple’s malware and integrity checks at the time of submission. In practice, the model sits between development signing and end-user execution policy.
How the Signing and Notarisation Chain Works
The workflow has three relevant stages: the developer signs the app with a Developer ID certificate, Apple scans and notarises the submitted build, and the operating system later consults that result when the app is opened. The important point is that notarisation does not replace code signing, it builds on it.
This means the security value comes from combined provenance and review. Code signing tells macOS who produced the software, while notarisation gives the platform a stronger basis for allowing execution. If either step is weak, the chain becomes less trustworthy even when the app still appears to be “signed.”
Why This Model Exists
Apple introduced notarisation to reduce the spread of malware and tampered macOS software without relying only on reputation or user caution. For distributors, it is a way to show that the app was checked before release; for users, it reduces the odds of launching obviously malicious or altered software.
The model also creates a clearer distribution boundary. Instead of treating every signed binary as equally trustworthy, macOS can apply a release-time trust decision that reflects both developer identity and Apple’s own inspection of the artefact. That is especially useful for software distributed outside the Mac App Store.
What Can Go Wrong When Notarisation Is Absent or Misused
Notarisation is only as strong as the signing key, the build pipeline, and the integrity of the packaged artefact. If an attacker steals a Developer ID key, compromises the build process, or substitutes a malicious update before release, the resulting software may look legitimate even though the trust chain has been abused.
Release engineering mistakes also matter. Re-signing at the wrong stage, re-packaging after review, or shipping a different binary than the one submitted for notarisation can undermine the protection the model is supposed to provide. That is why the security question is not just “is it signed?” but “is the released artefact still the one that was checked?”
Practical Checks for Organisations
Teams should verify that the software inventory includes the exact macOS artefacts they ship, how those artefacts are signed, and whether the submitted and released binaries match. They should also review where signing keys live, who can use them, and whether build and release systems prevent unauthorised modification.
For readers who want a broader control lens on signing, secrets, and release integrity, the SLSA framework is useful for thinking about provenance, while the NIST SP 800-53 Rev 5 Security and Privacy Controls catalogue is useful for mapping code integrity, access control, and audit expectations around the release process. For implementation hygiene, the OWASP Cheat Sheet Series is a practical reference for secure handling of signing-related secrets and release workflow discipline.
Risk and Threat Considerations
The main risk is trust-chain compromise: if signing keys, build systems, or release artefacts are abused, attackers can distribute software that appears legitimate enough to bypass normal user hesitation. That makes notarisation valuable, but also a high-value target for supply-chain abuse.
Failure mechanism: An attacker steals or misuses a Developer ID certificate, tampers with the build pipeline, or swaps the artefact after notarisation so the checked binary is not the one that reaches users.
Impact: Users may execute malicious macOS software that inherits real-looking trust signals, increasing the chance of malware delivery, persistence, and brand damage.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | macOS notarisation depends on release provenance and artefact integrity. |
| Recommendation — Use SLSA practices to preserve build provenance and verify the released artefact matches the reviewed one. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Notarisation exists to verify software integrity before execution. |
| IA-5 — Authenticator Management | Developer ID certificates and related signing material require lifecycle control. | |
| Recommendation — Apply SI-7 to detect and block unauthorized changes to signed release artefacts. Protect, rotate, and revoke signing credentials under IA-5 to limit certificate abuse. | ||
Practitioner Guidance
Why practitioners should care: Treat notarisation as part of the release integrity boundary, not as a standalone guarantee of safety. The trust decision depends on the signing key, the submitted build, and the released package all remaining aligned.
Common misunderstanding: Teams often assume that “notarised” means “safe.” In reality, it means Apple checked the app at a point in time, so secure key custody, controlled build steps, and release verification still matter.
Practitioner takeaway: Preserve provenance end to end, because notarisation is strongest when the signing identity, the scanned artefact, and the shipped binary are the same object.
Related resources from NHI Mgmt Group
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