FIPS 140-2 Goes Historical: What New Purchases Need

Both dates appear in official material because they describe opposite sides of the transition. Saying that the “sunset is September 21” is reasonable shorthand for the final day of active acceptance. Saying that certificates “move on September 22” describes the administrative event. Procurement documents should avoid ambiguity by stating both.

The transition changes what buyers should select for a new system. It does not cause an already deployed firewall, encrypted drive, VPN client, or hardware security module to stop functioning at midnight. NIST explicitly distinguishes historical from revoked status and supports continued use of historical 140-2 modules for existing systems. Agencies still make deployment and risk decisions, and a contract can impose a narrower condition, but the program transition itself is not a mandatory physical replacement event.

FIPS 140 validation applies to a defined cryptographic module. The validated boundary may be a hardware device, firmware component, software library, or a combination. The certificate identifies a module name and version, vendor, security level, tested operational environments, algorithms, and other conditions. The security policy explains how the module is configured and operated in its approved mode.

That boundary is why product-family language is dangerous. A manufacturer can sell several appliances that use related code, but only certain builds may incorporate the validated module exactly as tested. A certificate for a software library does not automatically validate every application that calls it. A certificate covering firmware version 4.2 does not prove that version 5.0 is included. A certificate’s vendor name may also differ from the brand on the product after an acquisition or OEM arrangement.

The buyer’s job is not to become a cryptographic laboratory. It is to establish a traceable match between the proposed line item and the public CMVP record. Ask the supplier to identify the certificate and explain how the quoted configuration maps to the validated boundary. Then independently open the certificate and security policy.

CMVP uses different status terms for different facts.

An active validation appears on the active list and, subject to its details, can be used for new and existing systems. A historical certificate has moved off the active list because of age or a program transition. NIST says historical status does not mean the certificate was revoked; however, the certificate may not reflect current guidance and the module is generally an existing-system option rather than the default for a new system. A revoked validation is no longer valid for demonstrating conformance to the FIPS 140 standards.

Do not collapse these statuses into “certified” and “not certified.” The difference affects acquisition. If an agency is maintaining an installed system, a historical 140-2 module may be acceptable under CMVP guidance. If it is defining a new system after the transition, the procurement team should specify an active 140-3 validation unless the agency’s authorized security officials document another path.

“Existing system” also deserves careful treatment. Adding capacity to an established architecture, replacing a failed unit with an identical spare, and building a new enclave from old designs are not necessarily the same scenario. NIST provides the program rule; the agency decides how it applies to the planned system and risk decision. Put that interpretation in the procurement file instead of relying on an oral assumption.

The market uses several phrases that sound official but answer different questions.

“FIPS compliant” is often a vendor assertion. It may mean that a product uses approved algorithms, exposes a configuration intended for federal use, or includes a module that is undergoing validation. None of those descriptions proves that an active CMVP certificate covers the quoted build.

“FIPS capable” usually indicates that a setting can be enabled. It does not show that administrators actually enable and maintain the approved mode. “FIPS algorithms” can refer to algorithm testing, which is not the same as module validation. “Pending” or “in process” means the validation is not complete. NIST’s Modules in Process list can support planning, but an entry is not an issued certificate and completion timing can change.

The meaningful request is concrete: provide the FIPS 140-3 certificate number, module and version, security policy, validated operational environment, and instructions for operating in approved mode for this exact configuration. If the supplier cannot answer, treat the validation as unverified.

A vague solicitation line such as “must be FIPS compliant” invites incomparable responses. A better requirement identifies the data and function in scope, requires an active validation appropriate to the acquisition date, and asks for evidence with the offer.

For example, the requirement can ask the offeror to provide the active FIPS 140-3 certificate number for the cryptographic module used to protect data at rest, the exact module version, the product-to-module mapping, and the approved-mode configuration instructions. It can require notification before any substitution or update that changes that mapping. The agency’s security team should approve the wording because the right boundary depends on the architecture.

Avoid specifying a security level by habit. FIPS 140-3 defines four security levels, but a higher number is not automatically necessary for every use. Identify the threat, physical environment, key-handling needs, and governing baseline. Over-specification can exclude adequate products; under-specification can buy a certificate that does not address the relevant risk.

When an exact 140-3 option is not available, do not quietly accept a marketing statement. Record the market research, the available 140-2 or in-process alternatives, the delivery impact, and the authorized decision. The CMVP transition page acknowledges that replacement 140-3 options may be limited in some categories. That context supports a documented conversation, not an automatic exception.

The fastest way to waste budget is to treat the historical transition as a fleet-wide recall. Build an inventory first. For each module, record the system, mission owner, data protected, product and version, certificate number and status, approved-mode configuration, support date, exposure, and planned replacement cycle.

Then sort the inventory into practical groups:

This approach separates a date-driven paperwork update from a genuine security gap. It also lets procurement combine crypto transition work with normal server, network, endpoint, and storage lifecycles.

For awards planned before September 22, review whether delivery and deployment will occur after the transition. A contract awarded on September 20 for a new system installed in November can create an avoidable interpretation problem. The program, contracting, and security owners should agree on the relevant milestone and write it down.

For solicitations already released, issue a clarification or amendment if the language says only “FIPS 140-2.” For evaluations underway, request certificate evidence consistently from all offerors under the acquisition rules. For purchase orders not yet placed, revalidate configurations and alternates. For delivered items, capture serials, versions, and configuration evidence during acceptance.

Do not rely on quote validity to preserve compliance. A valid commercial price does not freeze a certificate status or guarantee the delivered firmware. The acceptance checklist should test what arrived.

Make certificate verification part of receiving, not just source selection. The delivery package should identify the shipped part number and installed software or firmware, the module name and version, the certificate number, the security policy, and the approved-mode configuration. Capture serial numbers and a dated configuration report where the system supports it.

Have the security team reproduce the CMVP search independently. Confirm that the certificate is active for a new system, that the validated operational environment fits, and that no caveat excludes the planned service. If the vendor cites several certificates, require a short mapping that explains which module protects each function.

Then test the mode. For an appliance, verify the setting and the services disabled when approved mode is enabled. For a software module, confirm that the application loads the expected library and does not silently fall back to a nonvalidated provider. For storage, verify that keys, recovery, and management follow the approved design.

Record any mismatch as an acceptance defect. A substitute model, emergency firmware update, or revised software build may be operationally reasonable, but it must return to security and contracting for an explicit decision. This is also where support terms matter: ask how the manufacturer communicates certificate changes, security-policy revisions, and replacement builds during the warranty period.

Individual certificate checks are necessary but can become unmanageable across hundreds of devices. Add module status to the configuration or asset system and group products by vendor, platform, certificate, business service, and refresh date. A certificate transition then becomes a searchable population rather than a manual email exercise.

Assign owners for high-consequence categories such as remote access, key management, storage encryption, and boundary protection. Track the planned 140-3 replacement, validation evidence, delivery risk, and agency decision for any historical module that remains. Review the portfolio quarterly and after major vendor updates. This lets buyers combine replacements with scheduled lifecycle work instead of creating disruptive one-off projects.