Expired Code Signing Certificates are code signing certificates whose validity period has ended, so they are no longer trusted for signing new software or scripts. After expiry, they may still appear in old signed artefacts, but they cannot establish fresh signature trust and should be removed from active signing workflows.
What expired code signing certificates mean
An expired code signing certificate no longer establishes fresh trust for new releases, but it can still matter operationally because old signed artefacts may remain in circulation. The key security question is not whether the certificate once validated, but whether any build, release or script workflow still depends on it today.
In practice, expiry is a lifecycle boundary. Teams often discover the issue only when a release pipeline fails, a signing tool refuses to sign, or downstream platforms stop accepting newly produced packages. That makes expired certificates as much a delivery and trust problem as a cryptographic one.
Why expiry matters for software trust
Code signing is meant to prove origin and integrity at the moment software is created and distributed. Once the certificate has expired, that trust signal no longer extends to new signing events, even if the private key still exists. The artefact may still look legitimate to a casual observer, but the certificate cannot be relied on as an active trust anchor.
This matters because attackers and insiders alike can abuse ambiguity around old signing material. A stale certificate in a signing system can confuse release engineering, weaken change control, or delay the recognition that a signing path is no longer valid. If the private key is also exposed, the certificate's expiry does not eliminate the broader abuse risk around historical trust and legacy artefacts.
For readers who want the operational context around code signing trust, NHIMG’s Code Signing Security Guide covers key protection, timestamping, revocation and signing workflow hygiene.
How organisations check exposure
Exposure checks start with inventory: identify every certificate used for signing applications, drivers, scripts, containers or release artefacts, then confirm which ones are expired, near expiry, or still referenced by automation. The practical issue is often not the certificate itself, but the number of systems that still assume it is valid.
Teams should also review where signed artefacts are published and consumed. Old packages in mirrors, download portals, developer repositories and installer caches may continue to circulate long after the certificate expires, so validation failures can appear unevenly across environments.
Because expiry and renewal are lifecycle problems, authoritative guidance on cryptoperiods and key handling is useful when deciding what should be retired, rotated or renewed. NIST SP 800-57 Key Management is the clearest external reference for key lifecycle discipline, while the CA/Browser Forum baseline requirements help frame certificate issuance and revocation expectations for publicly trusted certificates.
Remediation and compensating controls
When expiry is approaching or has already occurred, the immediate fix is to move signing to a currently valid certificate and remove expired material from active pipelines. If replacement cannot happen immediately, organisations should constrain use of the old certificate, document what artefacts were signed before expiry, and prevent new signing jobs from depending on it.
Where the certificate was part of a broader compromise or misuse scenario, remediation is not limited to renewal. The signing key, associated access paths and any dependent workflows may need to be rotated or rebuilt, and releases produced during the questionable period may need to be reissued.
NHIMG’s Compromised Code Signing Certificate Playbook is a useful companion when expiry overlaps with suspected theft, misuse or revocation decisions.
Detection, verification and trust restoration
After expiry, detection should focus on whether signing still occurs with the retired certificate, whether any artefacts were created after the validity window closed, and whether consumers are still trusting legacy signatures for critical software. Timestamping can preserve proof that a signature was created before expiry, but it does not make an expired certificate suitable for new signing.
Post-patch or post-rotation review should also confirm that release tooling, build runners, HSM-backed workflows and developer machines no longer hold usable copies of the old signing path. If the certificate was ever exposed outside the intended control boundary, the review should extend to downloaded artefacts, source repositories and package repositories where stale trust can linger.
For deeper incident context, NHIMG’s Signing keys and certificates in breaches and Private Keys in Repositories Guide help explain how exposed signing material persists and how teams should validate cleanup.
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 and risk surface, while NIST SP 800-57, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | Defines cryptoperiod and lifecycle handling for signing keys and certificates. |
| Recommendation — Set cryptoperiods, retire expired signing material, and align renewal with lifecycle policy. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers lifecycle control of credentials and related authentication material used in signing workflows. |
| Recommendation — Manage signing secrets through controlled issuance, rotation, revocation, and retirement. | ||
| CIS Controls v8 | CIS-5 — Account Management | Supports disciplined lifecycle management for privileged signing access and related credentials. |
| Recommendation — Inventory and remove stale signing access paths and credentials from active use. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Expired certificates often sit alongside long-lived signing secrets that outstay their intended use. |
| NHI-01 — Improper Offboarding | Expired signing certificates should be removed from workflows when they are no longer valid. | |
| Recommendation — Shorten signing secret lifetimes and remove expired certificate dependencies from pipelines. Offboard retired signing material from build and release processes immediately. | ||
Related resources from NHI Mgmt Group
- What breaks when code signing certificates are left to manual renewal?
- Why do code-signing certificates need stricter lifecycle controls than ordinary certificates?
- How should organisations govern code signing certificates for software releases?
- What breaks when code-signing certificates are resold or reused by attackers?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org