FIPS 140-2 becomes Historical on 21 September 2026. Here's what it means for your PCI and DORA audit.
There is a date on the calendar this quarter that most small financial institutions haven't put on theirs: on 21 September 2026, NIST moves every FIPS 140-2 validation to Historical status.
If your institution runs on vendor hardware and software — HSMs, VPN appliances, core banking modules, payment terminals — some of the cryptographic modules inside them almost certainly carry a FIPS 140-2 certificate. After 21 September, those validations are no longer current.
What actually happens on that date
FIPS 140-2 is the U.S. government standard under which cryptographic modules have been validated for the last two decades. Its successor, FIPS 140-3, has been the only standard accepting new validations for several years. On 21 September 2026 the transition completes: every remaining FIPS 140-2 certificate moves to the Historical list maintained by NIST's Cryptographic Module Validation Program.
"Historical" has a precise meaning: the validation is no longer recommended for procurement by federal agencies. It is a status change in a database — and a signal to everyone downstream who relies on that database.
What it does not mean
Let's be precise, because fear is not a compliance strategy:
- Your systems will not stop working on 22 September.
- Historical status does not mean the cryptography inside the module is broken.
- There is no regulation that fines a community bank for having a FIPS 140-2 module in production on that date.
If a vendor tells you otherwise, they are selling urgency, not accuracy.
Why it still lands on your desk
Here is the uncomfortable part: even though the date itself is a federal procurement signal, it propagates into the world of small financial institutions through four channels that are very much active:
1. Your PCI DSS assessment. PCI DSS 4.0.1, requirement 12.3.3 — mandatory since 31 March 2025 — requires you to maintain a documented inventory of your cipher suites and protocols and to actively track their viability, with a review at least every 12 months. A validation status change on the modules you rely on is exactly the kind of event this requirement expects you to notice and document. An assessor who asks "how did your cryptographic inventory reflect the FIPS 140-2 transition?" is asking a fair, in-scope question.
2. DORA, if you touch the EU. DORA (Regulation (EU) 2022/2554, Art. 9(4)(d), with its technical standard — RTS (EU) 2024/1774, Arts. 6–7), in force since 17 January 2025, requires financial entities — including small ones — to maintain a documented policy on encryption and cryptographic controls, a register of certificates, and provisions for updating cryptography as cryptanalysis develops. Same logic: a dated, public change in the validation status of widely deployed crypto modules is something a documented policy should have a process for absorbing.
3. Your examiners and your insurer. U.S. examiners increasingly ask about cryptographic risk management as part of routine IT exams, and cyber insurers have started adding quantum-readiness questions to renewal questionnaires. Neither expects you to have migrated anything yet. Both expect you to know what you have.
4. Your vendors' roadmaps. Vendors are re-validating under FIPS 140-3 on their own schedules. If you don't know which of your critical modules are affected, you can't ask your vendors the one question that matters: what is your re-validation timeline, and what does it mean for our stack?
The actual to-do is smaller than it sounds — and bigger than this date
Notice what all four channels have in common. None of them requires new cryptography. All of them require the same thing: a current inventory of the cryptography you already run, and a documented process for tracking its viability.
That is worth stating plainly, because it is also the first step of a much larger transition that is already scheduled. NIST's draft migration guidance (IR 8547) plans to deprecate RSA-2048 and ECC P-256 after 2030 and disallow them after 2035. And for data that must stay confidential for years — loan files, customer records — the "harvest now, decrypt later" pattern means recorded traffic can be decrypted retroactively once those algorithms fall. The industry-wide survey data shows the gap clearly: 68% of security leaders call managing cryptographic assets extremely complex, and only 41% are actually preparing (Entrust/Ponemon, 2026).
This summer supplied a live illustration of why "tracking viability" is a process, not a checkbox. In July 2026 an AI-assisted research effort at Anthropic found a previously unknown weakness in HAWK — a post-quantum signature candidate that had survived two years and two rounds of expert review in NIST's additional-signatures process. The scheme's own authors verified the attack and withdrew HAWK from the process, and NIST confirmed that the already-standardised algorithms (ML-KEM, ML-DSA) are unaffected. Nothing running in production was touched — HAWK was a research-stage candidate, never deployed, and schemes at that stage are outside the scope of assessments like ours. The structural lesson is the point: cryptographic assurance is continuous re-verification, not a certificate issued once.
The institutions that treat 21 September as an inventory trigger — not a fire drill — will have quietly completed step one of the quantum transition while their peers are still reading vendor brochures.
A 30-day checklist for a compliance officer
- Ask your vendors which of their modules carry FIPS 140-2 (vs 140-3) validations, and what their re-validation timeline is. Put the answers in writing.
- Refresh your cipher suite and protocol inventory (PCI DSS 12.3.3 already requires it; if it doesn't exist yet, this is the reason to start).
- Check your external TLS perimeter — it is the part of your cryptographic footprint you can inventory today, without touching anything internal.
- Note which of your data must remain confidential past 2030. That subset defines your real exposure to harvest-now-decrypt-later.
- Add a line to your crypto policy describing how validation status changes (like this one) get noticed, assessed, and documented.
- Put 21 September in the file. When your assessor or examiner asks, the answer is a dated paragraph, not a scramble.
We run quantum-readiness assessments for small and mid-size financial institutions: an inventory of your cryptography, each gap mapped to the exact requirement that makes it an audit item, and a prioritised migration roadmap — in the language your auditor works in. You can start with a free external scan of your public perimeter or see a sample report. An assessment of this kind helps you demonstrate readiness and address inventory and crypto-agility expectations; it is an attestation by us, not an accredited certification, and it does not substitute a formal audit.