A procurement workflow for checking whether a supplier crypto claim is supported by the right FIPS evidence: CAVP algorithm testing, CMVP module validation, tested environment, Security Policy scope, and approved-mode operation.
Use it to turn vague "FIPS compliant" claims into certificate numbers, boundaries, configurations, change triggers, and retention records backed by NIST sources.
Structured answer sets in this page tree.
Cited legal and guidance references.
Use this workflow when a product, cloud service, appliance, library, or supplier proposal claims FIPS-approved cryptography. The review is not satisfied by the word "FIPS" in a data sheet: procurement needs to know whether the claim is an algorithm implementation tested under CAVP, a cryptographic module validated under CMVP, a validated module used in approved mode, or an internal policy target that still needs evidence.
Separate four claims before reviewing any certificate. An approved algorithm standard such as AES or SHA is not the same thing as a CAVP-tested implementation. A CAVP algorithm certificate is not the same thing as a CMVP module certificate. A CMVP certificate still has a boundary, version, tested operating environment, approved services, and usage conditions. Procurement wording should mirror that exact scope.
Ask the supplier to identify the delivered product or service component that performs the cryptographic operation, then map the claim to evidence. If the supplier only provides a marketing statement such as "FIPS compliant crypto," treat it as incomplete until the implementation name, certificate number, module name, version, operating environment, and Security Policy are available.
A useful procurement package asks for the evidence a reviewer can tie to a shipped configuration. The CMVP IG states that algorithm validation certificates identify the validated algorithm implementation and tested operating environment, while module validation certificates identify the validated module and tested operating environment. That distinction should drive the intake form and the contract exhibit.
For software, firmware, and hybrid modules, pay close attention to operating environments. The IG says the CAVP-tested operating environment must be identical to, or fully included in, the environment used for module testing when a validated algorithm implementation is embedded in a module undergoing FIPS 140-3 testing. That makes CPU architecture, OS, firmware build, accelerator use, and deployment mode procurement evidence, not background detail.
Use this workflow to convert supplier "FIPS compliant" statements into certificate checks, Security Policy constraints, approved-mode controls, and change-review tasks.
Convert certificate checks, Security Policy review, approved-mode evidence, and change triggers into accountable tasks.
Use cited NIST source material to resolve CAVP, CMVP, operating-environment, and approved-mode questions before acceptance.
Review the cryptographic boundary, supplier evidence, certificate fit, and procurement acceptance criteria with Sorena.
Use CAVP evidence to prove that a named algorithm implementation was tested. Use CMVP evidence to prove that a cryptographic module was validated against FIPS 140-3. A product can include a tested algorithm without the whole delivered module being validated, and a validated module can contain usage limits that procurement must preserve in implementation instructions.
The review output should therefore avoid broad labels. Say "uses AES implementation covered by CAVP certificate X in operating environment Y" or "uses cryptographic module Z validated under CMVP certificate N when configured according to Security Policy S," rather than converting either certificate into a blanket product approval.
Approved mode is a configuration and service-use question, not just a certificate lookup. The CMVP IG describes approved mode as a set of services that includes at least one approved security function or process and excludes non-approved security functions. Procurement reviewers should therefore ask how the delivered system enters approved mode, how operators can tell which mode is active, and which services are outside the allowed claim.
The public Security Policy is the practical review anchor. It should identify approved and non-approved services, algorithm certificates, roles, interfaces, operating rules, and caveats. If the supplier claim depends on a mode switch, an approved service indicator, or operator guidance, those details belong in the procurement acceptance record.
Procurement evidence expires operationally when the delivered configuration changes, even if the public certificate still exists. The CMVP IG includes examples where changes to versioning, excluded components, operating environments, processor acceleration, or embedded validated modules can require validation or revalidation analysis. The buyer should make those triggers part of supplier notice obligations and internal change control.
Retain the evidence in a way that lets future auditors reconstruct the accepted claim. Store the public source URL, certificate identifier, Security Policy version, supplier attestation, product version, operating environment, reviewer decision, and rejection notes together. When a supplier ships a cryptographic update, rerun the review rather than copying the previous acceptance forward.
Use this operating table in intake notes or contract review. Each row should produce an auditable record, not just a yes/no answer.
1 | Claim intake | Procurement and security | Supplier FIPS claim, product/version, crypto component inventory | Is this an algorithm claim, module-validation claim, approved-mode claim, or internal target?
2 | Certificate match | Security reviewer | CAVP/CMVP certificate IDs, implementation names, module names, versions, tested operating environments | Does the public evidence match the delivered configuration?
3 | Security Policy review | Product security and operations | Security Policy, approved services, service indicators, caveats, operator guidance | Can the deployment operate inside the validated boundary and approved-mode conditions?
4 | Change-control acceptance | Procurement, engineering, supplier owner | Supplier notice clause, release record, rejected-evidence log, reassessment trigger list | What changes force the evidence to be reviewed again?
"The validation certificate serves as a benchmark"
"validation-search"
"Agencies should develop plans for the acquisition"