Code signing basics — what Apple Notarization and Windows Authenticode actually certify

When you build a desktop app for distribution, macOS may greet users with “cannot be opened because the developer cannot be verified,” and Windows SmartScreen may show “Windows protected your PC” for an unrecognized publisher. Signing and notarizing an app is how you avoid these warnings, but what exactly does that signature prove — and what does it not prove? The distinction is easy to get wrong. Here’s a breakdown of two systems that look similar on the surface but play different roles: Apple’s Notarization and Windows’ Authenticode.

Note: Code signing is the umbrella term for attaching a cryptographic signature to an executable so that its author’s identity and the integrity of its contents (whether it’s been tampered with since signing) can be verified. The OS checks this signature before deciding whether to allow execution or show a warning.

What a signature proves — and what it doesn’t

The key thing to understand is that code signing certifies two things: identity and integrity. It does not certify safety.

• Identity: this executable was produced by the developer or organization named in the certificate
• Integrity: the file’s contents have not been altered by even a single byte since it was signed

A signed app carries no guarantee that it’s free of bugs or vulnerabilities. Signing is a mechanical way to verify “who made this, and has anyone tampered with it since” — it is not a review of whether the software itself is good. Keeping this distinction in mind makes it easier to understand what Notarization and SmartScreen reputation actually add on top.

Apple’s model: signing and Notarization are separate layers

macOS Gatekeeper actually checks two independent pieces of information.

1. Code signing (codesign): the developer uses the private key tied to an Apple-issued Developer ID certificate to embed a signature locally. That signature includes a hash of the entire app, so any modification after signing breaks verification.
2. Notarization: the signed app is uploaded to Apple’s servers, where it’s scanned automatically for known malicious patterns. If it passes, Apple issues a “notarization ticket,” which gets stapled to the app itself — allowing Gatekeeper to verify it offline, even with no network connection.

In other words, Notarization is not a replacement for signing — it’s an additional layer where Apple independently checks an already-signed app and attaches proof of that check to the app itself. Gatekeeper only allows a silent launch when both a valid signature and a valid notarization ticket are present.

Bundle signing order: inside out

A macOS .app bundle often contains more than just the main executable — frameworks and helper tools are commonly bundled as separate Mach-O binaries inside it. The signature over the whole bundle is computed from a hash that includes everything inside it, which means the inner binaries need to be signed individually first, and the outer .app bundle signed afterward.

Reverse that order and the outer signature ends up computed against binaries that were still unsigned at the time — verification will flag a content mismatch. Think of it as: finalize everything inside the box first, then seal the outer lid.

Windows’ model: Authenticode and the certificate chain

Windows’ Authenticode differs from Apple’s Developer ID in how certificates get issued. Apple is the sole issuer of Developer ID certificates, while Windows code-signing certificates are issued by third-party Certificate Authorities (CAs), and the OS trusts them by tracing an unbroken chain up to a trusted root certificate — meaning “this publisher was identity-verified by a CA the system already trusts.”

Certificates broadly fall into two tiers: OV (Organization Validation, confirming the organization exists) and EV (Extended Validation, a stricter identity check). EV certificates once carried an advantage of gaining SmartScreen trust immediately, but that distinction has shifted over time — it’s no longer accurate to simply say “EV means instant trust, OV means extra scrutiny.”

Without a timestamp, an expired certificate drags past signatures down with it

Another detail worth knowing is timestamping — embedding proof from a Timestamp Authority (TSA) at signing time. Skip it, and the moment the signing certificate expires, every binary ever signed with it (including older versions you shipped long ago) can be treated as having an invalid signature.

Add a timestamp, and a third party has recorded the fact that “this signature was made while the certificate was still valid” — so verification of that signed binary remains valid even after the certificate itself expires. macOS’s codesign has a --timestamp flag, and Windows signing tools have equivalent timestamp-server options. As a rule, distributed binaries should be signed with a timestamp.

SmartScreen reputation is a separate axis from the signature itself

An Authenticode signature only certifies who made the file and whether it’s intact — nothing more. Windows SmartScreen layers something else on top: a reputation score for the publisher’s certificate, built up from download volume and how long it’s been in use.

That means a correctly and validly signed app can still trigger a SmartScreen warning if the certificate is newly issued and hasn’t accumulated any track record yet. This isn’t a broken signature — it’s simply “trust as a publisher” that hasn’t built up yet, and it tends to fade as downloads accumulate over time. A signature-verification failure and a reputation-driven warning are different problems with different causes, and worth telling apart clearly.

Summary

Rather than “it’s signed, so it’s safe,” it’s more accurate to think of it as: signing is a mechanical way to verify identity and integrity, and reputation systems like SmartScreen run alongside it as a separate track-record check. Framing it that way makes the warnings you run into during distribution much easier to reason about.