Treat signing certificates as governed non-human identities with clear ownership, issuance, rotation, revocation, and secure storage. If the private key is loose or the certificate lifecycle is unmanaged, the signature proves access to the key rather than trustworthy origin. HSMs and vaults reduce that exposure.
How to govern signing certificates as part of the build identity model
Signing certificates should be managed as identity-bearing assets, not as static technical artifacts. That means naming a clear owner, defining where private keys live, setting issuance criteria, and documenting exactly which build systems or pipelines are allowed to use them. The certificate should have a purpose, scope, and expiry that fit the build trust model, not the other way around.
For teams managing code-signing or build-signing trust, lifecycle discipline matters as much as cryptography. A certificate that can sign release artifacts, container images, or build outputs is a trust boundary, so unmanaged sprawl creates hidden blast radius. Certificate inventory, approval, rotation, and revocation should be part of the same operational model that governs access to the signing key.
Build teams usually get better outcomes when they treat signing authority as a tightly bounded non-human identity and align it with the broader certificate lifecycle guidance in Machine Identity, PKI and Certificate Lifecycle Guide. The practical question is not only whether the certificate works, but whether the system can prove when it should still work, when it must stop, and who can recover it safely after compromise.
What secure storage and rotation should look like for build certificates
Private keys should be protected so the build platform can use them without exposing them broadly to engineers, CI jobs, or adjacent services. HSM-backed or vault-backed storage reduces the chance that a stolen disk image, shell session, or misconfigured secret store turns into a signing key theft event. The goal is to keep signing capability usable while making key export and casual reuse difficult.
Rotation should be planned, not improvised. For build systems, that usually means short enough validity to limit exposure, but long enough to avoid constant operational churn. If rotation is delayed, the signing certificate becomes a long-lived trust anchor that may survive ownership changes, pipeline redesign, or a forgotten dependency long after the original risk has shifted.
A useful reference point is NIST SP 800-57 Key Management, which frames key lifecycle, cryptoperiods, and destruction as operational requirements rather than afterthoughts. Teams can also compare their storage model against Cryptographic Key Management Guide when deciding how to classify, inventory, and rotate signing keys.
Modern certificate operations also benefit from understanding workload identity patterns, especially when build services need scoped trust rather than broad secret access. In that context, Guide to SPIFFE and SPIRE is useful because it shows how attested workload identity and trust bundles can reduce reliance on ad hoc certificate handling.
What can go wrong when signing certificates are mishandled
The main failure mode is that the signature stops proving origin and starts proving only key access. If an attacker can copy the private key, they can sign malicious code, tamper with build artifacts, or impersonate a trusted build process. If the certificate remains valid after compromise, downstream systems may continue to trust poisoned outputs until revocation or reissue is fully propagated.
Build pipelines are especially exposed when signing keys sit too close to general CI/CD infrastructure, because compromise of the runner, repository, or orchestration layer can become compromise of the trust anchor itself. That is why signing certificates should be treated as high-value credentials with a much smaller blast radius than ordinary deployment secrets.
The risk is not abstract. Incidents such as GitHub code signing certificate theft 2022 and AnyDesk breach 2024 show how stolen signing material can force revocation, password resets, and trust recovery work that reaches far beyond the initial compromise. For build teams, the lesson is that certificate compromise is a release-integrity incident, not just a secrets-handling problem.
When the issue is supply-chain impact rather than only local key theft, TeamCity CVE-2023-42793 SVR exploitation 2023 is a strong reminder that build infrastructure compromise can place attackers next to signing materials and other release-critical credentials. The point is to shrink the number of systems that can ever reach the key, not merely to store the key somewhere encrypted.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-57 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | SP 800-57 Part 1 — Key Management | Signing certificates depend on key lifecycle, cryptoperiods, and rotation discipline. |
| Recommendation — Define cryptoperiods, rotation, and destruction rules for signing keys before release use. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate private keys are authenticators whose lifecycle must be controlled. |
| Recommendation — Manage signing-key issuance, storage, rotation, and revocation as controlled authenticators. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Build signing relies on protected cryptographic keys and controlled certificate use. |
| Recommendation — Apply cryptographic key protection and lifecycle controls to all signing material. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Signing credentials become high-risk when certificates or keys remain valid too long. |
| NHI-02 — Secret Leakage | A leaked signing key lets attackers impersonate trusted build output. | |
| Recommendation — Shorten key lifetimes and automate renewal before signing credentials age out. Store signing keys in hardened vaults and prevent export from build hosts. | ||
Practitioner Guidance
What to prioritise: Start with ownership, storage boundary, and revocation path. If you cannot answer who approves issuance, where the private key is held, and how fast a compromised certificate can be invalidated, the process is not yet controlled enough for release signing.
What to verify: Confirm that the build system can sign only the intended artifacts, that the private key is non-exportable or vault-gated where possible, and that certificate expiry, renewal, and revocation are tested before production use. Verify that old certs are not lingering in backup images, CI variables, or developer workstations.
Common mistake: Teams often protect the certificate file but ignore the lifecycle. That creates a brittle control where the security posture depends on one secret remaining undiscovered, rather than on a managed trust process that can survive rotation and compromise.
Practitioner takeaway: Treat build signing as a controlled trust service, not a convenience secret, and design the key path so compromise is detectable, rotation is routine, and revocation is operationally immediate.
Related resources from NHI Mgmt Group
- How should security teams manage code signing as a program instead of just protecting certificates?
- How should security teams protect software signing keys and certificates in the build pipeline?
- How should teams reduce the risk of orphaned service accounts and stale tokens?
- How should security teams build a cryptographic inventory across cloud and CI/CD systems?