Software Notarization

What software notarization does

Software notarization is a distribution-time trust check, not a development-time quality guarantee. It helps an operating system decide whether a binary or installer came through a trusted signing process and whether it should be allowed, warned on, or blocked.

That distinction matters because notarization is usually about provenance and tamper resistance, while code signing alone may not tell a user or platform whether a package was scanned, reviewed, or prepared for safe distribution. In practice, notarization adds a second layer of trust around the delivery artifact itself.

Why notarization matters for software supply chains

For publishers, notarization reduces the chance that users receive altered installers, repackaged binaries, or software that appears legitimate but has been modified after release. It is most valuable when distribution happens outside a tightly controlled app store or managed deployment channel.

For recipients, it creates a stronger signal that the file they downloaded matches the publisher’s intended release path. That is especially important for endpoint security posture, because a trusted-looking installer can still be a convenient delivery vehicle for malware if integrity checks are weak or bypassed.

How notarization is verified in practice

Verification usually happens at the point of execution or installation, when the operating system evaluates the artifact’s signature, trust chain, and any associated security policy. If the file has been tampered with after notarization, that trust relationship should fail or degrade into a warning state.

Organisations should treat notarization as one control in a broader release assurance process. The strongest assurance comes when notarization is paired with package integrity checks, release provenance, and a distribution workflow that makes it hard to swap in an unreviewed binary after the fact.

For macOS environments, the operational context around notarization is covered in macOS Security Guide for Enterprises, which also addresses Gatekeeper, XProtect, and related enterprise hardening controls.

Limits, failure modes, and operational trade-offs

Notarization does not make software inherently safe. A malicious or vulnerable program can still be notarized if the publisher process itself is abused, compromised, or used to distribute harmful code. It also does not replace secure development, code review, or malware scanning.

It is best understood as a trust-preserving control at the distribution boundary. If the upstream signing key, build pipeline, or release account is compromised, notarization can end up certifying the wrong artifact, which is why provenance and release governance matter as much as the notarization step itself.

Failure mechanism: The control fails when attackers alter the artifact before signing, steal the signing workflow, or substitute a different binary after a legitimate notarization step.

Impact: Users and fleet tooling may trust a package that has been tampered with, increasing the likelihood of malware delivery, persistence, or unsafe software installation.

Related resources from NHI Mgmt Group

• Why does notarization reduce risk for some macOS software but not for scripts and unsigned installer paths?
• How should security teams handle exposed secrets in modern software pipelines?
• What is the difference between software supply chain risk and NHI risk?
• Why do leaked secrets need a different reporting path than ordinary software bugs?