Validation Process Flow
Process from Vendor to Validation
The figure below illustrates the interactions that happen between Vendor, CST Lab, and CMVP. The MIP list indicates one of fives steps in the process for each validation. Each step is addressed in the figure and the legend below. For more information, please refer to Section 4 of the Management Manual. 
The steps for the cryptographic module validation life cycle include:
Step 1 - IUT.
The vendor submits the cryptographic module for testing to an accredited CST laboratory under a contractual agreement. Cryptographic module validation testing is performed using the Derived Test Requirements (DTR). If the CST laboratory has any questions or requires clarification of any requirement in regards to the particular cryptographic module, the laboratory can submit Requests for Guidance (RFG) to NIST and CCCS as described in the Management Manual Section 2.5 Request for Guidance from CMVP.
Step 2 - Review Pending.
Once all the testing requirements have been completed, a validation submission is prepared. The Cost Recovery fees are addressed prior to or with the submission as applicable.
Step 3 - In Review.
The validation submission is sent to CMVP. After any applicable payment has been processed, two reviewers are assigned to perform the initial review of the documents. One of the reviewers is identified as the point of contact (POC) for CMVP to interact with the CST laboratory to address comments.
Step 4 - Coordination.
The coordination process will continue until all comments and/or questions have been satisfactorily addressed.
Step 5 - Finalization.
Once the cryptographic module has been validated, and the associated vendor information has been confirmed by the laboratory, the validation information is posted to the CMVP Validation List at the CMVP website: Search.
FIPS Validation and Updates, Patches, and CVEs
We often get the question whether patching/updating a FIPS validation module (particularly when there is a significant security-related reason such as addressing a CVE) will invalidate that module’s FIPS status. The original version would maintain its validation but the new version that includes the patch/update would not be validated. Changing the code of the module results in that portion being untested and the CMVP is only able to make validation assurances for the tested configuration. As noted in our guidance:
The tested/validated module version, operational environment upon which it was tested, and the originating vendor are stated on the validation certificate. The certificate serves as the benchmark for the module-compliant configuration. (FIPS 140-2 IG G.5, FIPS 140-3 Management Manual 7.9)
However, we strongly recommend patching to safeguard the security of systems and data, noting that organizations must use their own Vulnerability, Patch and Risk Management programs, policies and procedures to make those decisions within the context of their organization. Simply, this is not a decision the CMVP has either the information necessary or the authority to make.
To reestablish those assurances as quickly as possible and minimize the risk, we also strongly recommend that vendors quickly have a CMVP certified lab test and submit an update for their module that reflects the patching/updating. The CMVP has an expedited processes in place to handle these updates when they are in response to a published CVE (see FIPS 140-2 IG G.8 Scenario 3A, and FIPS 140-3 Management Manual 7.1.11 CVE).
To summarize, the CMVP would agree that quickly addressing a known risk and then following up with an expedited validation of the updated module is generally the best and recommended way to minimize the overall security risk for government agencies.
