Sigstore vs Code Signing Certificates: What Each One Can Actually Prove

If you already know the answer is “an installer that end users double-click,” the rest of this page is background reading and the code signing certificates My-SSL issues through Certum are the part you actually need. Everyone else: the differences below are worth ten minutes, because picking the wrong one is usually discovered late, on a release day.

What is Sigstore, and what does it sign?

Sigstore is a free, open-source signing system maintained under the Open Source Security Foundation. Rather than handing you a long-lived certificate and a private key to guard, it authenticates you through an identity you already have — a GitHub account, a CI workflow — issues a certificate valid for roughly ten minutes, signs with a key that never leaves memory, and records the event in a public, append-only log.

Three components do the work. Fulcio is the certificate authority: it accepts an OpenID Connect token, checks it, and issues a short-lived X.509 certificate binding that identity to a freshly generated key pair. Rekor is the transparency log, an immutable ledger that records the signature and the certificate so anyone can later confirm the signing happened while the certificate was still valid. Cosign is the client most people actually run, and since version 3 it reads and writes the standardised Sigstore bundle format.

The part that surprises people coming from traditional PKI is that there is no key to lose. The private key exists for the duration of one signing operation and is discarded; what persists is the log entry proving the identity that signed. That inverts the usual threat model. There is no token in a drawer, no HSM credential in a secrets manager, and nothing an attacker can steal from you after the fact — but equally, no long-lived key you can point at as “yours” the way a certificate holder can.

What gets signed is deliberately broad: container images, arbitrary blobs such as release tarballs and installers, SBOMs, and build provenance attestations describing which workflow produced which file. In every case the signature and certificate are stored as a bundle beside the artifact or in the registry that holds it. That storage choice is harmless for a container image and decisive for a Windows executable, for reasons the Windows section gets to shortly.

How the trust model differs from a CA-issued certificate

Both issue X.509 certificates with a code signing extended key usage. What differs is what the certificate binds, and who trusts the root. A code signing certificate binds a vetted organisation to a key you hold for up to 460 days, and its root ships inside operating systems. A Fulcio certificate binds an OIDC identity to a key that exists for ten minutes, and its root reaches Sigstore clients only.

That difference cascades into everything else. Expiry, for one: a code signing certificate needs an RFC 3161 timestamp so signatures keep verifying after the certificate lapses, while Sigstore leans on the Rekor log entry to prove the signature landed inside its ten-minute window. Different machinery, the same goal — a signature that outlives the certificate behind it.

Revocation splits the same way. A CA can revoke a code signing certificate and backdate the effective date to a suspected compromise, which retroactively invalidates signatures made after that moment, including on software already installed. Sigstore has no equivalent lever and does not need one in the same way: the certificate expired minutes after issuance, so the question becomes whether you still trust the identity in the log entry, which is a policy decision made by whoever is verifying.

There is one more asymmetry worth naming, because it decides most real arguments. Identity in Sigstore is an account — repo owner, workflow, email address. Identity in a code signing certificate is an organisation that a CA checked against registry records and a callback, which is why the publisher name in a Windows dialog reads as a company rather than a username. Neither is more honest; they answer different questions.

Does a Sigstore signature stop the Unknown Publisher warning?

No. As of August 2026, Sigstore’s Fulcio root is not part of the Microsoft Trusted Root Program, and Windows Authenticode only honours signatures chaining to a CA that is. A Sigstore signature also lives in a separate bundle file rather than inside the executable’s own signature slot, so Windows never reads it in the first place. Sign an installer with Sigstore alone and users still see Unknown Publisher.

It is worth separating the two failures, because fixing one would not fix the other. Authenticode expects the signature to be embedded in the file’s security directory, appended to the binary itself; that is what SignTool writes and what Windows parses on launch. Cosign produces a detached bundle sitting next to the file. Nothing in the double-click path goes looking for a second file, so the signature could be perfect and Windows would still report the executable as unsigned.

Suppose you solved that and got the signature into the right slot. Windows would then walk the chain and require a root in the Microsoft Trusted Root Program, plus the code signing EKU with OID 1.3.6.1.5.5.7.3.3. Fulcio issues certificates with that EKU, but its root is distributed through Sigstore’s own trust root to Sigstore-aware clients, not through Microsoft’s program. The chain terminates in something Windows has never been told to trust, and the verdict is the same warning you started with — the familiar Unknown Publisher dialog.

Reputation is a third, separate layer that neither option buys outright. Even a correctly Authenticode-signed installer can trip SmartScreen until the publisher accumulates download history, which is a genuinely common surprise for teams who expected a certificate to switch the warning off on day one. We wrote up what actually moves that needle in the guide to SmartScreen publisher reputation. The short version: a certificate is the entry ticket, not the whole answer — and Sigstore does not even get you to the door, because SmartScreen has no notion of a Sigstore identity to build reputation against.

If the reason you were hoping Sigstore would work is that you would rather not buy and babysit a hardware token, that problem has a different solution. Cloud-based code signing keeps the key in a certified HSM and signs over an API, so a CI job can sign without anything physical in the room, and Microsoft’s own managed service takes a comparable approach — the trade-offs are laid out in Azure Trusted Signing versus a code signing certificate.

Where Sigstore is the right tool

Sigstore wins wherever the verifier is software you can point at a policy: package registries, container runtimes, admission controllers, and CI pipelines. Those verifiers were built in the last few years, they already understand Sigstore bundles, and several now expect them by default. For that audience Sigstore is not merely adequate — it is better than a purchased certificate, because it costs nothing and leaves no key to steal.

The adoption is concrete rather than aspirational. PyPI turned on Sigstore-backed attestations for trusted publishers in late 2024. npm publishes build provenance through the same machinery, and Trusted Publishing reached general availability in July 2025, attaching a provenance attestation automatically when a package is published over OIDC. GitHub’s artifact attestations are Sigstore under the hood, and Homebrew uses them to bind each bottle to the workflow that built it. Cosign v3 verifies all of these with one command.

There is a second category worth flagging: anything an auditor or a downstream consumer needs to trace rather than launch. Build provenance, SBOM signatures, internal artifact promotion between environments — all of it is verified by tooling you control, so the trust root question never reaches an operating system. If your compliance requirement is “prove this binary came from this commit through this pipeline,” Sigstore answers it more directly than a code signing certificate does, because the provenance is the point rather than a side effect.

One honest caveat. Because verification depends on Sigstore-aware tooling, “signed with Sigstore” only means something where somebody is actually checking. Publishing an attestation that no consumer verifies is a good habit rather than a control. It is still worth doing — the habit is what makes the control possible later — but do not confuse the two when writing a security claim.

Where you still need a code signing certificate

You need a publicly trusted code signing certificate whenever an operating system stands between your file and a human being. Windows executables, installers, DLLs, drivers, PowerShell scripts and Java archives are all checked by software that ships with the platform and trusts a fixed list of roots. No amount of transparency-log evidence substitutes, because the component doing the checking was never taught to look for it.

Two rows in that table catch people out. Kernel drivers need more than a certificate — Microsoft has to countersign the driver through its own portal, and the certificate is the credential that gets you into the process rather than the end of it; the sequence is walked through in how to sign a Windows driver. And macOS is the row where the honest answer is “neither”: Gatekeeper wants an Apple-issued Developer ID plus notarization, so a certificate bought from any commercial CA will not help you there.

The practical consequence for cross-platform teams is three signing paths, not one. That sounds worse than it is in practice, because each path is automatable and only the Windows one involves a purchase decision. It does mean any plan that starts “we will just use Sigstore for everything” needs revisiting before the first desktop release rather than after the support tickets arrive.

Using both on the same release

Running both is normal, and for anything that ships a desktop installer alongside packages or images it is the sensible default. The two signatures do not overlap or conflict: Authenticode is embedded in the binary for the operating system to read, while the Sigstore bundle travels with the release for registries, auditors and downstream pipelines. Adding the second one costs a pipeline stage, not a decision.

A workable order of operations is to Authenticode-sign first, then let Sigstore attest the already-signed artifact. That way the provenance statement covers the exact bytes users will download, hashes included, and you avoid the awkward case where the attestation describes an unsigned intermediate that nobody ever receives. If you attest first and sign afterwards, the hash in the log entry no longer matches the shipped file, which is a confusing thing to debug six months later.

Both steps belong in CI rather than on a laptop. The Sigstore half is naturally at home there, since the workflow identity is the thing being signed with. The Authenticode half needs the key to be reachable from the runner without a token plugged into a machine under someone’s desk, which is precisely the problem cloud signing solves — the setup patterns are covered in code signing in CI/CD pipelines.

What each one costs you

Sigstore costs nothing and takes little effort: no purchase, no validation, no key custody, and a few lines in a workflow file. A code signing certificate costs money and calendar time — organisation or individual validation with documents, a private key required to live inside certified hardware since June 1, 2023, and renewal at least every 460 days for certificates issued on or after March 1, 2026.

The last row is the one you are actually paying for. Everything above it favours Sigstore, and none of it matters if the file has to satisfy Windows. That is an uncomfortable value proposition to write down as a reseller, but it is the accurate one, and pretending otherwise is how people end up buying a certificate for a container image that never needed it.

On the certificate side, the shortened validity is the change most worth planning around, since it turns renewal into a recurring operational task rather than a three-yearly afterthought — the timeline and its knock-on effects are in code signing certificate validity, and current market figures sit in code signing certificate prices. Individual maintainers on non-commercial projects should also look at the open-source code signing tier, which exists precisely for people who find themselves needing Authenticode without a company behind them.

Which one do you need?

Ask one question: when a human opens this file, does an operating system inspect it? If yes, you need a code signing certificate for Windows or an Apple Developer ID for macOS, and Sigstore cannot stand in. If no — because the consumer is a registry, a runtime or a pipeline — Sigstore is the better answer, and a purchased certificate buys nothing those consumers read.

Most teams find they answer both ways within a single release. The desktop installer meets Windows; the container image and the published package never do. That is not a compromise or a hedge, it is just what happens when one repository produces artifacts for audiences with different verifiers, and it is why the two technologies have coexisted rather than one displacing the other.

Where this reliably goes wrong is the assumption that free signing at the registry layer will eventually cover the desktop layer too. It has not, and there is no announced plan for it to. Budget for the certificate if you ship software people install, and enjoy the fact that the other half of your supply chain is genuinely free to secure.