Centralisation is usually the better governance model when certificates are short-lived, because ownership, key custody, and audit logging become easier to enforce. Embedded team workflows can still work, but only if they operate inside a shared policy for inventory, hardware-backed key storage, and automated renewal. Without that, accountability fragments quickly.
Why code signing governance changes when certificates are short-lived
code signing is not just a build-time technical step. It is a governance control over who can mint trusted software, which keys are allowed to do it, and how quickly those keys can be withdrawn or rotated when something changes. When certificates are short-lived, the control only works well if ownership, renewal, and audit evidence are centralised enough to be consistent.
In practice, centralisation helps because signing authority becomes easier to inventory and review. A shared model gives security and platform teams a single place to enforce key custody, logging, renewal cadence, and exception handling, instead of trying to reconcile many different team-level procedures.
Embedded ownership can still be defensible when teams ship independently, but then the organisation is really operating a federated governance model. That model needs common standards for certificate issuance, access approval, hardware-backed key storage, and renewal automation, otherwise the operational burden shifts to individual teams and control quality becomes uneven.
What embedded signing gets right, and where it usually fails
Embedded workflows are attractive because they keep release responsibility close to the people changing the code. They can reduce handoffs, remove bottlenecks, and fit fast-moving delivery pipelines. The catch is that release speed and trust assurance are not the same thing, so convenience alone is not a good ownership model.
The failure mode is fragmentation. One team may keep a clean renewal process while another quietly extends certificate life, stores keys in software, or relies on ad hoc approvals. Over time, that creates inconsistent blast radius, unclear accountability, and an audit trail that is hard to defend when a signing key or certificate is questioned.
This is why short-lived certificates push organisations toward stronger lifecycle discipline, not merely a different location for the key. If embedded teams are allowed to own signing, they still need the same policy backbone that a central service would provide: clear inventory, enforced storage controls, and renewal that is system-driven rather than memory-driven. The certificate lifecycle view in Machine Identity, PKI and Certificate Lifecycle Guide is directly relevant because the control problem is lifecycle management, not just issuance.
How to decide on the operating model
The best choice is usually not “centralise everything” or “let every team manage its own keys.” It is to centralise the policy, trust boundary, and audit model, then decide how much execution can safely be delegated. If the signing key can affect many products, many release trains, or externally trusted artifacts, the governance case for central control is stronger.
Centralisation is the safer default when the organisation needs tight evidence of custody, revocation, and renewal. That is especially true for code signing because compromise is high impact and the trust is broad: a single signing key can legitimize malicious or modified binaries until trust is revoked. Supply-chain compromises like SolarWinds supply chain compromise show why release trust is not a local team concern once signed artifacts are downstream dependencies for many customers.
Embedded ownership works best when the team cannot bypass shared controls. If the organisation permits local execution, it should still require hardware-backed key storage, delegated but logged renewal, inventory of every signing identity, and immediate revocation paths. Incidents such as NVIDIA code-signing certificates stolen 2022 and AnyDesk breach 2024 are reminders that compromised signing material can force broad trust resets, not just a narrow cleanup in one team.
Risk and Threat Considerations
Code signing concentrates trust, so weak ownership becomes an attack path. If teams can mint or store signing keys inconsistently, an attacker who steals one key, compromises one build system, or abuses one renewal process may gain the ability to distribute trusted malware or tampered releases.
Failure mechanism: Decentralized custody, poor inventory, or non-standard renewal lets a signing identity persist longer than intended, hides where the private key lives, and delays revocation or reissuance after compromise.
Impact: Malicious or altered software can be trusted by downstream systems and customers until trust is revoked, which can expand the incident from a single team compromise into an organisation-wide supply chain event.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST SP 800-57 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Code signing depends on lifecycle control of signing keys and certificates. |
| AU-2 — Audit Events | The question hinges on enforcing consistent logging and accountability for signing actions. | |
| CM-5 — Access Restrictions for Change | Code signing governs who may authorize trusted software changes. | |
| Recommendation — Manage signing credentials centrally and enforce rotation, revocation, and inventory. Log certificate issuance, renewal, use, and revocation events for every signing identity. Restrict who can approve and execute signing for release artifacts. | ||
| NIST SP 800-57 | Key Management | Short-lived code signing certificates require disciplined key lifecycle management. |
| Recommendation — Define key custody, cryptoperiods, rotation, and destruction for signing keys. | ||
| CIS Controls v8 | CIS-5 — Account Management | Signing governance depends on owned, reviewable access to privileged signing material. |
| Recommendation — Inventory signing access and remove unused or orphaned signing accounts. | ||
Practitioner Guidance
What to prioritise: Treat the trust boundary as the primary design decision, not the team org chart. If one signing identity can affect multiple products or environments, centralise policy and custody first, then delegate only the parts that remain observable and revocable.
What to verify: Confirm that every signing certificate and key has a named owner, a current inventory record, hardware-backed storage where required, and an automated renewal path that does not depend on individual engineer attention. If any of those are missing, the model is already drifting toward unmanaged decentralisation.
Common mistake: Assuming “embedded in the team” means “closer to the code, therefore safer.” The real question is whether the team can prove custody, revoke quickly, and produce audit evidence without hunting across repos, laptops, and local scripts.
Practitioner takeaway: Centralise the trust controls even if you do not centralise every workflow, because code signing is only as governable as its weakest custody, renewal, and revocation path.
Related resources from NHI Mgmt Group
- How should organisations govern code signing across multiple engineering teams?
- What breaks when organisations keep treating code review as the primary security control for AI assisted development?
- Should organisations keep code search and embeddings local when using AI development tools?
- When should organisations centralise security prioritisation across development and operations teams?