FIPS 140-2 Is Historical: What It Means for Code Signing

What actually happened on September 21, 2026

NIST closed a five-year transition. CMVP stopped accepting new FIPS 140-2 submissions on September 22, 2021, and modules already validated kept their active listing for up to five years after that. On September 21, 2026 that window shut, and every remaining FIPS 140-2 certificate moved to the Historical list at once — regardless of the level it was validated at or the year it was issued. FIPS 140-3 is now the only standard a module can be newly validated against.

The word that causes the trouble is "Historical". It sounds like an expiry and reads, in most vendor emails, like one. CMVP's own framing is narrower: agencies should not include Historical modules in new procurements, and the programme continues to support their purchase and use for existing systems. Nobody's validation report was withdrawn, no test result was reversed, and the hardware on your desk did not change.

That distinction is worth holding onto for the rest of this article, because almost every question people are asking this week collapses once you separate the three statuses. A module whose validation was revoked is out. A module whose validation went Historical is a module you should think twice about writing into a new federal purchase order.

Does your code signing token stop counting?

No. Nothing in the Code Signing Baseline Requirements makes your certificate's standing depend on a module's current CMVP listing. Section 6.2.7.4.1 requires a Hardware Crypto Module "with a unit design form factor certified as conforming to at least FIPS 140-2 Level 2 or Common Criteria EAL 4+". That clause describes a certification the device was granted, in the past tense. A token validated in 2019 was certified as conforming in 2019, and still was on September 22, 2026.

The revocation rules point the same way. Section 4.9 sets out the circumstances under which a CA must or may revoke a code signing certificate — key compromise, a subscriber breach of the agreement, a certificate found to be signing malware, and the rest of that list. A listing status change at a validation programme is not among them, and no CA has a mechanism that would notice one.

The date that does govern your certificate is its own. Since March 1, 2026, code signing certificates have been capped at 460 days rather than the previous 39 months, so most publishers are now renewing on a roughly annual rhythm. If you are trying to work out when you next have to think about your token, that number is the one to diary, and it has nothing to do with NIST.

What the code signing rules actually name

The Code Signing Baseline Requirements set hardware requirements in three separate places, at three different levels, and — this is the part worth checking yourself — only one of them has been updated to name FIPS 140-3. Version 3.11.0, dated June 16, 2026, names "FIPS 140-2 level 3, FIPS 140-3 level 3, or an appropriate Common Criteria Protection Profile or Security Target, EAL 4 (or higher)" in section 6.2.7.1, which governs the CA's own keys. The Signing Service clause and the subscriber clause still name FIPS 140-2 alone, each with Common Criteria EAL 4+ as the alternative.

Read literally, that leaves an odd result: a brand-new HSM validated in 2026 carries a FIPS 140-3 certificate, and FIPS 140-3 is named in the clause covering the CA's keys but not in the clause covering yours. In practice CAs treat FIPS 140-3 as satisfying a "meets or exceeds" requirement written against its predecessor, and the verification methods in section 6.2.7.4.2 — CA-shipped hardware, key attestation, a prescribed library and module combination, an IT audit, a cloud subscription report, or an agreement to use a Signing Service — are all about proving where the key lives rather than about citing a certificate number.

Since the text has not caught up, do not reason from the standard alone when money is involved. Before you buy a module on the strength of its FIPS 140-3 certificate, ask the CA you intend to buy the certificate from to confirm in writing that they will accept it for key attestation. It is a one-line question to a support queue and it removes the only real ambiguity in this whole topic.

The Common Criteria half of the sentence

Common Criteria EAL 4+ is the other way to satisfy the subscriber clause, and NIST's calendar has no bearing on it. Common Criteria is evaluated under national schemes rather than by CMVP, so nothing about a CC certificate changed on September 21, 2026. A token holding a valid EAL 4+ certificate satisfied section 6.2.7.4.1 the day before the sunset and satisfies it now, with no reference to FIPS at all.

This is not an academic branch. The token most commonly shipped with code signing certificates, the SafeNet eToken 5110, is sold in more than one variant: the CC model carries Common Criteria EAL5+ and eIDAS qualified signature device certification, while the FIPS model carries FIPS 140-2 Level 3. Many European buyers have been holding the CC variant for years without ever having a stake in the FIPS transition. If you are not sure which one is in your drawer, the model name is printed on the body of the token, and SafeNet Authentication Client will report the device it sees under its token information panel.

Buying a token or HSM after the sunset

Ask for a certificate number, and check it on the issuing programme's own list. Two answers stand on their own for code signing: an active FIPS 140-3 certificate at Level 2 or higher, or a Common Criteria certificate at EAL 4+. What you want to avoid is a datasheet line that says "FIPS validated" with no number, no level and no indication of which firmware revision was tested.

The firmware detail catches people out more than the standard does. Vendors validate a specific hardware and firmware combination, not a product name, so a model that has shipped for six years may have three validations behind it covering three firmware revisions, with the unit in the box running a fourth. Ask which revision the certificate covers and which one is being shipped to you, in the same message.

One more thing worth building into the same decision: whatever you buy now will still be on your desk when post-quantum signing algorithms start appearing in tooling. A module that can take a firmware update is worth a premium over one that would have to be replaced outright.

Where cloud signing changes the question

Cloud signing moves the hardware obligation off your desk entirely. Under section 6.2.7.3, a Signing Service must protect subscriber private keys in a Hardware Crypto Module conforming to at least FIPS 140-2 level 3 or Common Criteria EAL 4+ — a level higher than the bar for your own token — and that obligation belongs to the operator, who is audited against it. You hold no module, so you have no module to re-validate, and the FIPS transition becomes your provider's procurement problem rather than yours.

That is a real difference for anyone who has been putting off a hardware decision. Certum's cloud code signing, for instance, keeps the key inside its own HSM environment, where it cannot be exported or moved to third-party infrastructure, and the attestation a CA needs comes from the service rather than from a device you have to post between offices. If you are weighing that against buying hardware, our overview of cloud and token delivery for code signing certificates sets out what each option costs and what each one asks of your build process.

The trade is not free. Cloud signing gives you a service dependency, an authentication flow to integrate into CI, and a provider whose audit you are relying on. The comparison of cloud signing against a USB token goes through those trade-offs in detail, including what each option does to an unattended build.

Who actually has to do something

Buyers with a written FIPS obligation, and nobody else. If you sell into US federal agencies, or your customer contract, FedRAMP package or internal security policy names FIPS validation as a purchasing condition, the sunset changes which modules you can put in a new procurement. If you are a software publisher with a working token and a current certificate, the date passed without consequence for you.

When there is an obligation, the wording of the clause decides the answer, not the standard. A clause that requires "FIPS 140-2 or FIPS 140-3 validated" hardware is satisfied by what you already own. A clause that requires a module to appear on the CMVP active validation list is not, and that is the one case in this article where somebody genuinely has to buy new hardware. Find out which of the two you signed before you spend anything.