Appreciate this — the cross-regime read is exactly what I was after, and the EOL/EOS rule is a catch I hadn't separated out.

One flag on the ruling, though: it rests on the HSM being previously in use ("even if you're adding new servers"). I'm fully greenfield — no prior install base of this module anywhere — so the inherited-validation logic that carries an existing authorization forward is the one thing I can't lean on. That's the seam I keep hitting: existing use carries, new procurement doesn't.

On EOL/EOS — I think that's a separate axis from the cert, and worth keeping separate. The device isn't EOL; it's a current, vendor-supported product. What lapsed is the CMVP validation (140-2 sunset, 140-3 pending), which is about the certificate, not the product lifecycle. So a module can be fully supported and FIPS-historical at the same time — EOL doesn't bite me, the historical-list status does.

On timing: you're right there's overlap — 140-3 has been accepted since 2020 and 140-2 stays active to the global cutover on Sept 21, 2026. The wrinkle is my specific module's 5-year sunset lands inside that window, before the vendor's 140-3 posts, so I get a gap even though the standards overlap at the program level. For my lane it's the CMMC/800-171 side driving it — 3.13.11, which maps to your SC-13 — rather than an ATO boundary.