Start free trial

By Yair Knijn · May 14, 2025

Your code-signing key is from 2014 and has never been rotated. So was NVIDIA's.

Ask the head of engineering when your code-signing key was last rotated. Usually you get a pause, then a guess. It was minted years ago, it lives in a build server's certificate store or on someone's laptop, and nobody touches it because the last attempt threw trust warnings and slipped a release. The wrong assumption underneath all of that: a code-signing certificate is something you configure once. It is not. It is a standing authorization to ship software under your company's name, and it stays dangerous long after it stops looking active.

Whoever owns this risk rarely sees it on a dashboard. The cert is valid, builds are green, expiry is months out. So the failure mode people brace for, expiry, turns out to be the wrong one. The real one is theft of a key that should have been retired and destroyed long ago.

The NVIDIA leak: an old key Windows still trusted

In the February 2022 LAPSUS$ breach, two NVIDIA code-signing certificates were stolen and published. One was valid from 2011 to 2014, the other from 2015 to 2018. Both had already expired. It did not matter. Within days, VirusTotal samples showed them signing Cobalt Strike beacons, Mimikatz, backdoors, and remote access trojans, because expiry is not enforced everywhere it should be. Microsoft's driver-signing policy will load a driver signed with an end-entity certificate issued before July 29, 2015 that chains to a supported cross-signed CA, regardless of whether the cert later expired.

Now put your own org's name in that sentence. A key your team stopped thinking about in 2014 becomes a trusted signing oracle for kernel-mode malware in 2022, because it was retired but never destroyed, never revoked at the policy level, and still honored by the platform.

Why timestamping outlives the certificate

RFC 3161 timestamping exists so that a signature made while the certificate was valid stays valid after the cert expires. That is good for legitimate releases. An attacker holding the private key gets the same property: with a countersignature from a trusted Time Stamping Authority, malware signed today can appear signed inside the original validity window. Timestamping is a durability control, not a security one, which is exactly why a stolen key with timestamping access is the worse outcome. What limits the blast radius is revocation the platforms actually check, paired with keys that no longer exist to be stolen.

HSM storage and a real key ceremony

A private signing key sitting in a filesystem, a CI secret, or a developer keychain is extractable. A key generated inside a hardware security module is not: it signs on request and never leaves the boundary. The CA/Browser Forum baseline requirements have mandated hardware-backed key protection for code signing since June 2023, so for publicly trusted certs this argument is settled. For internal signing it is not, and that is exactly where old extractable keys pile up.

The HSM also makes rotation survivable. A documented key ceremony, generated in the module, operators recorded, invocation rights defined, turns rotation from a heroic one-off into a procedure you can repeat. Rotation breaks builds when nobody wrote down how the key was created or which systems pin it. Write that down once and the next rotation is a config change.

A revocation and rotation plan you can run

The plan that survives an incident is short, written, and rehearsed, so that on the day a key leaks you are not inventing it:

Automate Certificates keeps that inventory live per Environment: every signing certificate, its storage backing, its timestamping and revocation posture, and its rotation date in one place a reviewer can read instead of reconstruct from a failed build. To map your signing keys before an attacker does, book a demo.