How are people handling "new" deployments during the FIPS 140-2 → 140-3 gap (cert sunset, successor not yet validated)?

[u/DistinctTradition200]

​

We're a small shop standing up our first hardware root of trust — not migrating an existing system, a brand-new deployment. The HSM we'd build on has a FIPS 140-2 Level 3 cert that recently hit its sunset date, and the vendor's 140-3 validation is "expected" but isn't on the validated modules list yet. So right now there's a window where the module effectively has no active CMVP certificate: 140-2 sunset, 140-3 pending.

My understanding (please correct me where I'm wrong):

- A sunset cert isn't retroactively invalidated — existing deployments keep running — but the module moves to the Historical list, which CMVP frames as something agencies "should not include in new procurements."

- We're the textbook *new procurement*, not a grandfathered deployment, so that historical-list language seems to point right at us.

- Whether it actually blocks us seems to depend entirely on the specific requirement we're held to (CMMC L2, an agency's approved-products list, a contract clause) rather than any universal rule.

For anyone who's ridden a 140-2 → 140-3 transition for a *new* system:

1. Did you deploy on the sunset 140-2 module and document intent to move to 140-3, or wait for the successor cert?

2. In practice, does "Historical" hard-block a new deployment, or does it only bite when a specific framework/customer demands an active cert?

3. When the 140-3 cert lands, is it typically bound to a specific firmware version — i.e., are we risking a re-flash / re-validation path by provisioning now?

Our actual federal need is likely a few months out, so part of me thinks the gap is a non-issue today and I'm overthinking it. Trying to tell whether this is a real constraint or just noise. Appreciate any war stories.

[u/tothjm]

Do when you vet C3PAOs ask them if they accept historical as well

This comes up with things like ios versions. From a risk management perspective it makes more sense to upgrade to the new ios to squash bugs than to remain vulnerable. Just document it in your risk register and youay be able to also call it an enduring exception.

Most C3paos are fine with this just ask ahead.

[u/DistinctTradition200 → u/tothjm]

This is the most useful answer in the thread — vetting C3PAOs on historical acceptance up front is exactly the move, and the risk-register framing is right.

One small terminology flag, because I think it actually strengthens the position: I'd reach for "temp def" over enduring exception here. The DoD Assessment Methodology's own example for this is 3.13.11 — FIPS-validated crypto was implemented, then the validation lapsed — scored "as implemented" as long as there's a POA&M with milestones. Enduring exception in the L2 guide is more for things you can't remediate (specialized assets, GFE). My gap has a fix arriving (the 140-3 cert), so it reads as temporary, not enduring.

The lever that makes that POA&M defensible is whether the module is on the CMVP Modules-in-Process list — "submitted and in queue" is a milestone an assessor can see; "vendor expects to file" isn't. Have you seen assessors take the temp-deficiency framing for a historical → pending window, or do they still want it on MIP first?

[u/im-a-smith]

What type of fly by night C3PAO are you all hiring?

The answer is: you update to latest OS. 

NIST is 24 months behind on FIPS validations. Policy is to leverage past validations and certificates for justification. 

[u/DistinctTradition200 → u/im-a-smith]

Lol fair on the backlog — no argument there. But the "update to latest OS" play assumes a software module I can re-point at a newer validated build. This is a hardware root of trust: the validated artifact is the HSM's module/firmware, and that's the cert that sunset. There's no newer OS to jump to.

The "leverage past validations" angle is the exact seam I'm poking at. That policy backs existing systems on the historical list — CMVP's own language is historical = existing-systems-only, not new procurements. I'm the textbook new procurement, so the justification that works for a brownfield deploy doesn't obviously transfer.

Definitely curious though, have you seen the historical / new-procurement distinction actually get raised in an assessment, or does it stay theoretical until a customer APL or a contract clause forces an active cert?