Notifications
Clear all
Topic starter
24/06/2026 7:07 pm
TL;DR: The CA/Browser Forum has reduced the maximum validity period for publicly trusted code-signing certificates from 39 months to 460 days, effective March 1, 2026, according to DigiCert. The real issue is not shorter certificates but the assumption that manual renewal and static signing workflows can keep pace with faster rotation.
NHIMG editorial — based on content published by DigiCert: Understanding the New Code-Signing Certificate Validity Change
Questions worth separating out
Q: How should teams prepare for shorter code-signing certificate lifetimes?
A: Teams should first inventory every signing certificate, owner, and renewal path, then remove any manual dependency that could delay re-issuance.
Q: What breaks when code-signing renewals are still handled manually?
A: Manual renewal breaks when the organisation cannot guarantee that someone will notice expiry in time.
Q: How do security teams know if certificate lifecycle automation is working?
A: It is working when renewals happen predictably, outages from expiry disappear, and ownership is visible in policy rather than tribal knowledge.
Practitioner guidance
- Inventory every code-signing certificate and owner Create a complete map of signing certificates, issuance dates, expiration dates, system owners, and the build pipelines that consume them.
- Automate renewal inside release pipelines Move issuance and renewal into pipeline logic or managed signing services so certificates rotate without waiting for manual tickets or calendar reminders.
- Review private key storage and token dependence Assess where private keys live, who can access them, and whether hardware-token workflows are creating unnecessary friction.
What's in the full article
DigiCert's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for updating code-signing renewal calendars before March 1, 2026.
- Practical comparison of hardware-token workflows versus cloud-based signing services for renewal.
- Operational guidance on integrating ACME or DigiCert APIs into build pipelines.
- Policy updates for key rotation, revocation, and certificate ownership in release processes.
👉 Read DigiCert's analysis of the 460-day code-signing certificate change →
Code-signing certificates at 460 days: are your workflows ready?
Explore further
25/06/2026 4:15 am
Shorter certificate lifetimes expose identity lifecycle debt, not just operational inconvenience. The move from 39 months to 460 days compresses the time available for renewal, review, and re-issuance. That matters because many organisations still treat code-signing certificates as occasional assets rather than governed machine identities. The implication is that certificate lifecycle control now sits inside the core identity programme, not beside it.
A few things that frame the scale:
- The average time to detect a compromised machine identity: 214 days, according to The Critical Gaps in Machine Identity Management report.
- Only 38% have automated certificate lifecycle management in place, according to The Critical Gaps in Machine Identity Management report.
A question worth separating out:
Q: Who should own code-signing certificate governance in the organisation?
A: Ownership should sit jointly with identity, security, and release engineering, because code signing affects trust, access, and software delivery at the same time. A single technical owner is rarely enough. The accountable team must define renewal policy, approve key handling, and ensure revocation can happen without delay.
👉 Read our full editorial: Code-signing certificate validity is shrinking to 460 days
