Code Signing Certificates Explained: What They Are, OV vs EV, and What Actually Changed

What a code signing certificate does

A code signing certificate proves who published a piece of software and guarantees the file wasn't altered after signing. It binds your verified identity (an organization, in nearly all cases now) to a cryptographic signature applied to an executable, installer, script, driver, or package.

When a user downloads your signed .exe, Windows checks the signature against the certificate chain and the publisher identity. If the file was modified after you signed it — corrupted in transit, or repackaged with malware — the signature breaks and the OS flags it. That's the whole point: the signature is a tamper-evident seal tied to a name a certificate authority has verified.

It's worth being precise about what this doesn't do. Signing your code does not prove the code is safe, bug-free, or malware-free. It proves provenance and integrity, not virtue. A signature tells a user "this really came from Publisher X and hasn't been changed" — it makes no promise about whether Publisher X writes good software.

How code signing works, step by step

The mechanism is a standard public/private key pair, the same asymmetric cryptography behind TLS, applied to a file instead of a connection.

1. Hashing. Your signing tool computes a cryptographic hash (a fixed-length fingerprint) of the file.
2. Signing. That hash is encrypted with your private key, which lives on the hardware token or HSM. The signature, plus your certificate, gets embedded in the file.
3. Timestamping. A trusted timestamp authority records when the signature was applied. This step matters more than people expect — see below.
4. Verification. On the user's machine, the OS recomputes the hash, decrypts the signature with the public key from your certificate, and compares. Match means intact and authentic. It also walks the certificate chain back to a trusted root.

Why timestamping is not optional

Timestamp your signatures. Without a timestamp, your signed software stops being trusted the moment your certificate expires — even builds you shipped years earlier. A timestamp pins the signature to a point in time when the certificate was valid, so the software keeps verifying long after the cert itself expires. Skipping it is one of the most common and most painful mistakes teams make, because the breakage shows up months later with no obvious cause. The exact flags — /tr and /td — are covered in our step-by-step guide to signing an EXE with SignTool.

OV vs EV code signing: the comparison that matters in 2026

There are two validation levels for publicly trusted code signing certificates: OV (Organization Validated, often just called "standard") and EV (Extended Validation). Both verify a real, registered organization — neither is issued to anonymous individuals anymore. The difference is in the depth of vetting and a few platform-specific requirements.

The single most important row is SmartScreen, because it's where most outdated advice will steer you wrong.

The SmartScreen change everyone still gets wrong

For years, the standard pitch for EV code signing was simple: an EV-signed application gets immediate Microsoft SmartScreen reputation, so users never see the "Windows protected your PC" warning, while OV-signed software has to earn that trust slowly through downloads. That was genuinely true, and it justified the EV price premium for many publishers.

It is no longer true. Microsoft changed how SmartScreen treats EV certificates in 2024, and as of Microsoft's current developer documentation, signing with an EV certificate no longer produces positive SmartScreen reputation by default. In Microsoft's own words on its developer docs, that behavior "no longer exists," and paying a premium for EV solely to skip SmartScreen warnings is no longer justified. Reputation now builds organically for both OV and EV signed software, based on download volume and usage history. Microsoft doesn't publish the threshold.

Why did this happen? Malware operators had turned EV certificates into a commodity — buying them through shell companies or stealing them specifically to inherit instant trust — so the instant-reputation shortcut became a liability rather than a safeguard. Treating all code signing certificates equally for reputation purposes closed that hole.

The practical takeaway: if your only reason to buy EV was to bypass SmartScreen, that reason is gone. Choose EV when you actually need it — chiefly for Windows kernel-mode drivers — or when an enterprise customer's procurement rules demand it. For the day-to-day side of the problem — how reputation is actually scored and how publishers make the warning go away — see our SmartScreen publisher reputation guide.

A reputation footgun to plan around

Reputation attaches to a specific certificate. When a certificate expires and you replace it, the new certificate has a different thumbprint and starts from zero reputation again — so warnings can reappear right after a renewal. Teams that ship continuously work around this by dual-signing releases with both the old and new certificate during the overlap window, letting the new cert accumulate reputation before the old one lapses. Switching CAs or rekeying resets reputation the same way. This matters more now that certificates issued from March 1, 2026 are capped at 460 days of validity, so these renewal-time resets come around roughly once a year instead of once every three.

The hardware key storage rule (since June 1, 2023)

You can no longer generate a code signing key in your browser, export it, and stash it in a file on a build server. The CA/Browser Forum's code signing Baseline Requirements, effective June 1, 2023, require the private key for both OV and EV certificates to be generated and held on a hardware crypto module certified to at least FIPS 140-2 Level 2 or Common Criteria EAL 4+, where the key is non-exportable.

In practice that means one of three provisioning routes:

• A CA-shipped hardware token — a secure USB device, often the default for a single signer.
• Your own compliant HSM — on-prem or cloud, which the CA must verify (typically via an audit/attestation letter) before issuing.
• A cloud signing service — the CA or a trusted provider operates the HSM, and you sign through their API or portal.

For a solo developer or a small team, the token route is cheapest but awkward to share. For a CI/CD pipeline running across multiple build agents, a physical USB token passed around machines is a genuine pain point, which is why cloud-based signing services and HSM-backed signing have become the practical default for automated builds. If you're wiring signing into GitHub Actions or Azure Pipelines, plan for a cloud or HSM model from the start rather than trying to virtualize a USB token. We compare all three arrangements — delivery time, team sharing, failure modes — in cloud code signing vs USB tokens.

Which one should you get?

A short decision guide:

• Distributing a normal Windows desktop app or installer? Standard (OV) code signing is enough. EV won't shortcut SmartScreen for you anymore, so don't pay for it on that basis alone.
• Signing Windows kernel-mode drivers? You need EV — Microsoft's driver submission process requires it.
• Selling into enterprises whose security policy mandates EV? Get EV; this is now one of the main legitimate reasons to choose it.
• Building in a CI/CD pipeline? The validation level matters less than your key-storage model. Choose a cloud signing service or HSM-backed setup over a single USB token.
• Signing macOS software? That's Apple's separate Developer ID / notarization system, not a CA-issued code signing certificate — different process entirely.

If you're weighing the options against price and validation timelines, it's worth reviewing the full code signing certificate options side by side before committing, since the right choice depends as much on how you build and ship as on the certificate tier. Teams automating signing in a pipeline should also read how ACME automates certificate renewal, and if you're still deciding between tiers, see EV vs standard code signing compared (article coming soon).

FAQ