CISSP Domain 3: What FIPS 140-2 Going Historical Actually Means

Sep 14, 2026
 

CISSP Domain 3: What FIPS 140-2 Going Historical Actually Means

FIPS 140-2 certificates moved to the historical list. NIST's transition page puts it on September 22, 2026; several write-ups say the 21st. Pick whichever you like, because the date is the least interesting thing about it.

Here is what did not happen that day: nothing about the mathematics changed. The algorithm running on your systems the day before is the same algorithm running the day after. No cipher was weakened. No key length became insufficient. No module started producing worse output.

And yet a great deal of the reaction treated it as though something had broken. That gap — between what changed and what people thought changed — is the whole CISSP Domain 3 lesson, and it is exactly the shape of a well-written exam question.

What historical status actually does

NIST is unusually direct about this. Its own FIPS 140-3 transition page states that the CMVP "supports the purchase and use of these modules for existing systems," and that federal agencies decide for themselves when they move to 140-3-only modules.

Read that carefully. You are not required to rip out a historically-validated module. You are not out of compliance on the morning of the transition. The thing you lose is the ability to lean on that certificate to support new federal acquisitions.

That is a procurement constraint. It is not a cryptographic one. Conflating the two is the error, and the exam will happily offer it to you as an answer that sounds responsible.

The three claims — and only one of them is evidence

This is the distinction that decides most FIPS questions, and in my experience it is the one missed more often than any other in Domain 3. There are three different things people say when asked whether their cryptography is validated, and they are not interchangeable:

The claim What it sounds like What it actually proves
Algorithm claim "We use AES-256." That you named an approved algorithm. Nothing more.
Configuration claim "We run it in an approved mode, with approved key sizes and an approved RNG." That you believe the module is operating in its approved configuration. Still your assertion.
Validation evidence "Certificate #____, for this module, at this version, on this operating environment." That an accredited lab tested this specific thing and the CMVP issued a certificate for it.

Only the third is evidence. The first two are statements about intent.

This matters more than it sounds, because a validation certificate is scoped tightly: to a specific module, at a specific version, on a specific operational environment. Change the version, change the platform, or run the module outside its approved mode, and you are no longer operating the thing that was validated — even though every sentence you would say about your algorithm remains true.

A candidate who answers "we use AES-256" has answered the algorithm question and left the evidence question untouched. On the exam, the evidence question is very often the one being asked.

Why "we'll just get revalidated" is not a plan

The obvious response to a certificate going historical is to get the module validated under 140-3. That is the right destination. It is not a lever you can pull on demand.

SafeLogic, a CMVP testing lab, publishes the timings: an average of 367 days for FIPS 140-2 validation, against 542 days for FIPS 140-3. That is a 42% increase, and it means a validation decision made today lands somewhere in the second half of next year.

So the realistic sequence, when a vendor's module is not going to be revalidated before you need it, is not technical at all:

  1. Identify the gap precisely — which module, which version, which environment, and what it is protecting.
  2. Document it as a known, dated, scoped exception rather than an oversight.
  3. Take it to the risk owner for formal acceptance, with the timeline the queue actually implies rather than the one you would prefer.

Step three is the one candidates skip, and it is the one the CISSP cares about most. Cryptographic risk that cannot be remediated on your schedule becomes a risk management decision — which means it belongs to a named accountable person, in writing, with an expiry date on the acceptance.

The crossover trap

Domain 3 questions built on this incident resolve across several domains, and knowing which is which is worth more than any single fact here:

The question Where it actually lives
Is this module validated, and at what version and platform? Domain 3 — cryptographic solutions and lifecycle
Who accepts the risk that it will not be revalidated in time? Domain 1 — risk management and risk treatment
The vendor cannot commit to a revalidation date at all Domain 1 — supply chain risk management
How long must this data stay confidential? Domain 2.4 — data lifecycle and retention
Where are the keys held, and who can use them? Domain 3 — key management, HSM
How do we know this certificate has not been revoked? Domain 3 — PKI lifecycle: CRL, OCSP, OCSP stapling

A well-written distractor is usually true, correctly stated, and answering a question from the column on the right that you were not actually asked.

Where post-quantum fits

The episode covers this at length and it is worth stating the connection here, because it is the same reasoning applied to a longer clock.

"Harvest now, decrypt later" is the assumption that an adversary captures encrypted traffic today and stores it until a cryptographically relevant quantum computer can open it. Whether that is a live threat to you is not a question about quantum computing. It is a question about how long your data must stay confidential — which is a Domain 2.4 retention question wearing a Domain 3 costume.

If the answer is eighteen months, you have a different problem than if the answer is thirty years. NIST's post-quantum standards — ML-KEM for key establishment, ML-DSA and SLH-DSA for signatures — are the destination. The confidentiality horizon is what tells you how urgently you need to get there.

And note the pattern repeating: the same validation queue that makes 140-3 migration slow will apply to post-quantum modules too. Planning that assumes instant availability of a validated implementation is planning that has not looked at the queue.

The uncomfortable part

Nobody did anything wrong here. The CMVP published the transition schedule years in advance. NIST said plainly that existing systems can keep running. The labs publish their timings. Every piece of information needed to respond calmly was available before the date.

The panic came from reading a validation-status change as a cryptographic event. That is a Domain 3 comprehension failure, and it is the kind the exam is built to find.

If you can say, for one system you own, which module is validated, at what version, on what platform, and who accepted the risk if it is not — you are fine. If you cannot, that is the work, and it is the same work whether or not a certificate went historical.


Listen to the full episode: CISSP Cyber Training Podcast — FIPS validation, cryptographic lifecycle and key management, PKI revocation, cryptanalysis categories, and the post-quantum standards, plus exam-style questions built to teach the trap rather than the answer.

Studying for the CISSP? CISSP Cyber Training runs three tiers — Accelerator for self-paced study, Pro for the full question bank and monthly office hours, and the Sprint Cohort for candidates working to a booked exam date.


Shon Gerber, CISSP — Former Commander, 177th Information Aggressor Squadron · Former CISO · Fractional CISO · Founder, CISSP Cyber Training

Sources: FIPS 140-3 Transition Effort, NIST CSRC · What Happens on September 21, 2026, SafeLogic

CISSP Cyber Training Academy Program!

Are you anĀ ambitiousĀ Cybersecurity or IT professionalĀ who wants to take yourĀ careerĀ to a wholeĀ new levelĀ by achieving the CISSP Certification?Ā 

LetĀ CISSP Cyber TrainingĀ help you pass the CISSP Test theĀ first time!

LEARN MORE | START TODAY!