Federal agencies in the United States and Canada rely on a single certification pipeline to decide which cryptographic tools are trustworthy enough to protect government data. That pipeline, the Cryptographic Module Validation Program, is now in the middle of a multi-year transition from an older security standard to a newer one, and the deadlines involved will determine which encryption products agencies can legally deploy in the coming years.
What the Program Actually Does
CMVP is run jointly by the National Institute of Standards and Technology, part of the US Department of Commerce, and the Canadian Centre for Cyber Security, a division of the Communications Security Establishment. Its job is narrow but consequential: confirm that a given cryptographic module - the software or hardware component that performs encryption - actually meets a defined set of security requirements before government agencies are allowed to buy or use it. Testing is not done by NIST or the Canadian center directly. Instead, independent Cryptographic and Security Testing Laboratories, accredited through NVLAP, run the technical evaluations and submit results for CMVP review. Since the program began, more than 5,000 modules have gone through this process, with over 1,000 currently active.
This matters because Federal law, specifically 15 U.S.C. § 278g-3, requires US agencies to use validated cryptographic protection for their information systems. A module that has not been through CMVP is treated as offering no protection at all - from a compliance standpoint, unvalidated encryption is functionally the same as sending data as plain, unprotected text. If a cryptographic module's validation is revoked, agencies must stop using it immediately.
The Shift From FIPS 140-2 to FIPS 140-3
The program has been migrating from FIPS 140-2 to the newer FIPS 140-3 standard since September 2020. This is not an overnight switch - it involves overlapping windows during which vendors could still submit under the old standard while the new one ramped up. CMVP stopped accepting new FIPS 140-2 submissions as of September 2021, and by April 2022 it would only process FIPS 140-2 paperwork that did not alter a module's existing sunset date. The practical effect is that any new cryptographic product being validated today must go through FIPS 140-3.
Modules already validated under FIPS 140-2 are not immediately obsolete. Agencies in both countries can continue relying on them to protect controlled unclassified information - or, in Canada's terminology, Designated Information - through September 21, 2026. After that date, those FIPS 140-2 certificates move to a Historical list, meaning they can still support existing systems but can no longer be used to stand up new ones. NIST has explicitly advised agencies to keep using FIPS 140-2 modules until FIPS 140-3 replacements are actually available, rather than rushing a transition before the market catches up.
Why the Backlog Matters Beyond Government IT
Validation programs like CMVP sit upstream of a much wider technology market. Vendors that sell encryption components into government contracts, cloud infrastructure, or regulated industries often need CMVP validation to be competitive, which means delays in the certification pipeline ripple outward into procurement timelines across the private sector too. To address this, CMVP introduced a two-year interim validation option in June 2024 for modules submitted before January 2024, alongside automated processing of submissions formatted to SP 800-140Br1. Both changes are aimed squarely at reducing a validation backlog that had built up as demand for FIPS 140-3 certification outpaced testing capacity.
For organizations that build or buy cryptographic products - not just government suppliers - the transition is a reminder that security compliance is rarely static. Standards evolve, certificates expire, and products validated years ago eventually need re-certification against newer requirements. Anyone procuring encryption technology for regulated environments should track where a given module sits in this lifecycle, since a currently active certificate today does not guarantee eligibility for new deployments a few years from now.