Why we sign every build, and what a signature actually proves

When you download a desktop application and the operating system shows a publisher name instead of a warning, something specific has happened. A certificate authority checked that a real, registered company asked for a certificate, that company signed the file, and the operating system verified the signature has not been broken since. None of that says the software is good, or safe, or does what it claims.

What it does say is that a named legal entity is attached to the file, and that entity can be found. That is a smaller claim than most people assume, and a more useful one.

Reputation attaches to identity, not to files

The part that surprises teams shipping their first signed application is that trust does not accumulate on the application. It accumulates on the certificate identity. Every release signed by the same organisation name contributes to the same reputation record. Change the organisation name, or move to a certificate issued to a slightly different legal entity, and that record does not follow you. You start again.

This has a practical consequence that shapes how a company should be set up long before it ships anything. The name on the certificate has to be the name on the incorporation certificate, and it has to stay that way. Not the product name. Not a trading name. The registered entity.

Two chains, both required, doing different jobs

Signing an installer covers the moment a user first runs it. It does nothing for the update that arrives three weeks later over the network. Those need their own verification, and it should not depend on the same trust chain, because the failure modes are different. A certificate can expire or be revoked; an update payload can be tampered with in transit by something that never touches the certificate.

So there are two chains. One is the operating system's, and it decides whether the user sees a warning. The other is ours, and it decides whether the application will install what it just downloaded. Both run permanently. Neither substitutes for the other.

Keys live in hardware, and that is not optional

Since June 2023, industry rules require code-signing private keys to be held in validated hardware rather than as a file on a build machine. This changed how release pipelines are built, because a key that cannot be copied also cannot be handed to a continuous integration runner in an environment variable. Signing becomes a service the pipeline calls, not a secret the pipeline holds.

It is a genuine constraint and it is worth the friction. The most common way signing identity gets stolen is not a sophisticated attack on the certificate authority. It is a key that was sitting on a machine more people had access to than anyone remembered.

The unglamorous part

Most of the work in establishing a signing identity is not engineering at all. It is proving the company exists: business registration, a verifiable address, a phone number a human answers, a public website that agrees with all of it. Verifiers cross-check those against each other, and the check fails on inconsistency rather than on absence.

The constraint is almost always in the small print under the submit button.

We would rather spend that time up front than discover a mismatch during a release. A signature is only as good as the identity behind it, and identity is administrative work.