Code signing certificate lifetimes are shortening to 460 days

At a glance

What this is: This is a policy update on code signing certificate validity, with a mandated drop from 39 months to 460 days and an earlier cutoff for longer-issued certificates.

Why it matters: It matters because certificate lifecycle controls now affect software trust, renewal automation, and identity governance for machine identities and build systems as much as human access programmes.

By the numbers:

• The CA/B Forum has ordered the maximum validity for code signing certificates to be reduced from 39 months to 460 days.

👉 Read GlobalSign's update on code signing certificate validity changes

Context

Code signing certificates are machine identities used to prove that software was issued by a trusted source and has not been altered. When certificate validity shrinks, the core problem is not only renewal frequency, but the governance needed to keep trusted signing keys, issuance paths, and revocation handling under control across software build pipelines.

This change sits squarely at the intersection of identity security and software trust. Teams that already struggle with secrets rotation, certificate inventory, or build-system privilege will feel the operational impact first, because certificate lifecycles are becoming shorter than many organisations' current renewal and offboarding practices.

The result is a familiar pattern: stronger trust assumptions at the platform level, but more room for failure in the operational layer. That makes code signing governance a lifecycle problem, not just a PKI administration task.

Key questions

Q: What breaks when code signing certificate lifetimes are shortened without automation?

A: Renewal deadlines become operational failure points, and expired certificates can block releases or force rushed reissuance. The bigger risk is that teams discover missing ownership only when a build fails. Automation, inventory accuracy, and clear revocation paths are what prevent shorter lifetimes from turning into deployment disruption.

Q: When should organisations prioritise code signing certificate renewal controls over new signing tooling?

A: Prioritise renewal controls first when certificate expiry, ownership, and deployment dependencies are unclear. New tooling does not fix missed renewals if the organisation cannot identify which certificates exist, who owns them, and where they are used. Control the lifecycle before adding more complexity.

Q: What do security teams get wrong about shorter certificate validity windows?

A: They often treat expiry as a security control on its own. Expiry helps only if keys are protected, revocation is fast, and certificate inventory is accurate. Otherwise, shorter validity simply increases the number of opportunities for failure without reducing trust abuse meaningfully.

Q: Who is accountable when a trusted signing certificate is misused?

A: Accountability sits with the team that owns the signing identity, the release process, and the key protection model, not just the certificate issuer. Governance frameworks such as NIST SP 800-53 and Zero Trust expect clear control ownership for authentication, access, and system integrity.

Technical breakdown

Why shorter code signing lifetimes change trust operations

A code signing certificate is a cryptographic identity bound to a signer, a key pair, and a trust chain. Shortening its lifetime does not change the mathematics of signing, but it reduces the time a compromised key or abused certificate can remain valid. In practice, the security gain depends on whether issuance, storage, and rotation are automated. Manual renewal turns a security policy into an operational risk because missed expirations can interrupt releases, while delayed revocation leaves a compromised signing identity usable longer than intended.

Practical implication: treat code signing certificates as managed identities with lifecycle automation, not as static infrastructure artifacts.

Certificate lifecycle management and the renewal bottleneck

As certificate validity contracts, the renewal interval becomes a control point. That affects certificate discovery, owner assignment, approval workflows, and revocation readiness. A mature programme needs accurate inventory of where code signing certificates live, who owns them, which build pipelines use them, and how replacement keys are generated and deployed. Without that visibility, shorter lifetimes can create hidden failure modes, including expired signing keys in CI/CD and emergency reissuance outside normal governance.

Practical implication: build a certificate inventory that ties each signing certificate to an owner, workload, renewal date, and revocation path.

Software supply chain risk and signing key protection

Code signing is part of the software supply chain because it helps recipients decide whether to trust an update or binary. If an attacker obtains a signing key or abuses a valid certificate, malicious code can appear legitimate long enough to bypass basic trust checks. Shorter validity windows help, but they do not solve weak key protection, poor separation of duties, or build-system privilege exposure. The real control question is whether signing keys are isolated, monitored, and rotated with the same discipline as other high-value secrets.

Practical implication: harden signing-key storage and access with the same controls used for privileged credentials and release-signing workflows.

Threat narrative

Attacker objective: The attacker aims to distribute malicious software under a trusted signature so that recipients accept it as authentic.

1. Entry occurs through exposure or theft of a code signing key, a compromised build system, or misuse of a valid signing certificate within the software release process.
2. Escalation follows when the attacker uses that trusted signing identity to sign malicious or altered binaries, making the payload appear legitimate to downstream users and controls.
3. Impact occurs when signed malware or tampered software is distributed through trusted channels, extending compromise across endpoints, update systems, or customer environments.

NHI Mgmt Group analysis

Certificate lifetime compression is a governance change, not a PKI footnote. Shorter validity windows force organisations to prove they can discover, assign, renew, and retire signing certificates without relying on manual memory or tribal knowledge. That shifts the control burden from occasional issuance to continuous lifecycle management. For IAM and security teams, the real question is whether certificate governance is integrated with identity ownership and offboarding discipline.

Machine identities are being regulated through expiry, but expiry alone does not create security. A shorter-lived certificate reduces the exposure window, yet a compromised signing key remains dangerous for as long as it is trusted. The same logic that applies to NHI secrets applies here: lifecycle control matters only when issuance, storage, rotation, and revocation all work together. Practitioners should treat code signing certificates as governed non-human identities.

Certificate sprawl creates a renewal debt that many programmes are not measuring. As validity periods shorten, hidden dependencies in build systems, release pipelines, and vendor tooling become more visible. That reveals whether organisations have a real inventory of trusted signing identities or only an incomplete list of certificates. The practical conclusion is that ownership and inventory quality now determine whether shorter lifetimes improve security or simply increase operational outages.

Software trust is moving toward tighter time boundaries and lower tolerance for stale credentials. That direction aligns with broader identity security trends in which standing trust is being replaced by more ephemeral, reviewable controls. For teams managing both human and machine identity, the implication is clear: lifecycle enforcement will increasingly shape whether software trust remains defensible.

Signing-key protection has become part of identity governance for software delivery. The boundary between PKI administration and identity security is shrinking. If release systems can use a key to establish trust, then access to that key deserves privileged control, auditability, and revocation discipline. Practitioners should align certificate controls with the same governance model used for high-risk service accounts and privileged automation.

What this signals

Certificate governance is converging with NHI lifecycle management. As signing credentials become shorter lived, teams need the same discipline they apply to service accounts and API keys: discover, assign, rotate, and retire. That is why the operating model matters more than the certificate format itself, and why lifecycle ownership should be visible in the same governance workflows as other privileged non-human identities.

Shorter validity also raises the value of accurate inventory and offboarding. If a signing identity cannot be located quickly, expiry becomes a paper control rather than a security control. The practical lesson for identity programmes is to fold code signing into the broader NHI register, then map it to controls aligned with NIST SP 800-53 Rev 5 Security and Privacy Controls and certificate governance rather than treating it as a separate PKI task.

For practitioners

• Map every signing certificate to an owner and expiry path Create a live inventory of code signing certificates, tied to application, repository, pipeline, business owner, and next renewal date. Include issuance source and revocation contact so that shorter lifetimes do not create orphaned certificates or missed renewals.
• Automate renewal and reissuance workflows Replace manual calendar reminders with certificate management automation that can trigger renewal, reissue, validation, and deployment before expiry. Prioritise build and release systems where a single missed certificate can interrupt software delivery.
• Protect signing keys as privileged secrets Store code signing keys in hardened systems, restrict access to release operators, and separate key use from general admin access. Monitor signing activity so that unexpected use of a trusted key is detectable before malicious binaries propagate.
• Test revocation and replacement procedures Run controlled exercises for certificate compromise, expiration, and emergency replacement. Verify that revocation, reissuance, and trust-store updates work across all environments that consume signed software.

Key takeaways

• Shorter code signing lifetimes reduce exposure windows, but they also expose weak lifecycle governance in release pipelines and certificate ownership.
• The evidence from NHI research shows why this matters: most organisations still lack full visibility and disciplined offboarding for machine identities.
• The control priority is no longer just issuance, but inventory, renewal automation, signing-key protection, and reliable revocation.

Key terms

• Code Signing Certificate: A code signing certificate is a digital certificate used to sign software and prove that a binary or update came from a trusted publisher. It binds a cryptographic identity to signing activity, allowing recipients and platforms to verify integrity and provenance before execution.
• Certificate Lifecycle Management: Certificate lifecycle management is the set of processes used to issue, renew, rotate, replace, and revoke certificates before they expire or become risky. In security programmes, it must include accurate inventory, owner assignment, and automated renewal to avoid outages and trust gaps.
• Signing Key: A signing key is the private cryptographic key used to create a digital signature on software or other trusted artefacts. Because whoever controls the key can generate trusted signatures, it should be protected like a privileged secret and monitored for misuse.
• Software Supply Chain Trust: Software supply chain trust is the confidence that code, updates, and build outputs came from an authorised source and were not tampered with in transit. It depends on signing, access control, and the integrity of the systems that create and release software.

What's in the full article

GlobalSign's full article covers the operational detail this post intentionally leaves for the source:

• The specific dates that affect new issuance, renewals, and the sunset of 2-year and 3-year code signing certificates.
• The provider-facing transition details for existing certificates that remain valid until their original expiry date.
• The practical guidance GlobalSign gives customers for certificate inventory review and renewal preparation.
• The policy context behind the CA/B Forum timetable and how it aligns with broader certificate-lifetime reductions.

👉 GlobalSign's full post covers the implementation dates, renewal impact, and certificate transition details.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, secrets management, and workload identity. It gives practitioners a practical way to connect machine identity controls with broader IAM and security operations.