Why does centralised signing authority matter for software supply chain governance?

Why centralised signing authority is a governance control, not just an admin preference

Software signing is a trust decision about which code can ship under the organisation’s name. When signing authority is centralised, the organisation can set one policy for who may sign, what may be signed, which certificates are in use, and how revocation happens. That makes signing a governed control point instead of a scattered convenience.

A central authority also creates one place to enforce separation of duties between builders, approvers, and release operators. Without that boundary, local teams can accumulate their own signing paths, which makes it harder to prove who authorised a release, whether the signer was still valid, and whether the signed artefact matches the intended release process.

Centralisation matters because code signing is only as trustworthy as the lifecycle around the key or certificate. The organisation needs inventory, renewal, rotation, and revocation discipline around signing material, which is why supply-chain guidance such as SLSA and secure development practices in NIST SSDF (SP 800-218) both emphasise controlled provenance rather than ad hoc release signing.

What breaks when signing authority is decentralised

Decentralised signing paths create shadow authority. A regional team, business unit, or contractor can end up with a legitimate-looking signing route that sits outside the central inventory, outside standard approval, and sometimes outside normal offboarding. That is not just an operational nuisance, it weakens the governance story for every artefact signed that way.

Once multiple teams can source certificates or keys independently, policy drift follows. Different teams may use different certificate issuers, different expiry windows, different storage controls, or different release gates. The result is uneven assurance, because the security team cannot confidently answer the basic questions of what was signed, by whom, under which authority, and with what revocation path.

Decentralisation also expands the blast radius of compromise. If a signing key, token, or certificate leaks from one local workflow, an attacker may be able to produce trusted-looking releases that users, internal systems, or downstream integrators accept by default. For a supply-chain view of that failure mode, the central lesson in GitHub code signing certificate theft 2022 is that stolen access can turn signing material into long-lived brand trust abuse.

How central authority improves auditability, revocation, and release trust

Central signing gives security and compliance teams a single control plane for evidence. They can see which identities can request signing, which certificates are live, where the keys are stored, and whether release signatures map back to approved build systems. That makes audits faster and makes exception handling visible instead of tribal knowledge.

It also improves revocation and rotation. If signing authority is fragmented, certificate replacement and emergency revocation tend to be delayed because each local owner behaves differently. A central model lets the organisation revoke one authority, rotate one protected key path, and invalidate one class of signing permission consistently. That consistency is what keeps a signing incident from becoming a drawn-out trust failure.

The same governance logic is why broader supply-chain controls such as the OpenSSF ecosystem focus on provenance, artifact integrity, and release hygiene. Central signing is one of the practical ways to make those controls measurable rather than aspirational.

Risk and Threat Considerations

When signing authority is decentralised, the main risk is not only error, it is unauthorised trust creation. An attacker, insider, or careless local operator who can reach an alternate signing path may be able to publish code that appears officially sanctioned, bypass normal release review, or delay detection because the artefact looks valid.

Failure mechanism: Shadow signing paths weaken inventory, policy enforcement, and revocation, which allows untracked certificates or keys to survive after ownership changes, incidents, or environment sprawl.

Impact: Trusted but unauthorised software can reach users and internal systems, creating integrity loss, audit gaps, and a larger blast radius if a local signing credential is stolen or misused.

Practitioner Guidance

What to verify: Confirm that every production signing event flows through one approved authority, one inventory of active certificates or keys, and one revocation process. If any team can sign outside that path, treat it as a control exception, not a local optimisation.

What good looks like: The release pipeline should be able to show who requested signing, which identity approved it, which protected key or certificate was used, and when rotation or revocation will occur. If that evidence cannot be produced quickly, the authority is not truly centralised.

Practitioner takeaway: Centralised signing authority is valuable because it converts code signing from a distributed trust habit into an auditable control, and in supply-chain governance, auditable control is what makes trust enforceable.

Related resources from NHI Mgmt Group

• Why does dependency depth matter in software supply chain governance?
• Why does cryptographic inventory matter in software supply-chain governance?
• Why do shorter code-signing lifetimes matter for software supply chain security?
• Why do dashboards matter in NHI governance?