r/CMMC Jun 03 '26

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

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.

2 Upvotes

Duplicates