A maintenance guide for keeping FIPS 140-3 certificate claims tied to the validated module, tested environment, Security Policy, and algorithm evidence.
Use it before publishing certificate claims after product releases, firmware changes, operating-environment updates, or dependency changes.
After any product, module, firmware, software, platform, dependency, or vulnerability change, decide whether the shipped implementation still matches the validated cryptographic module. Compare the module name and version, boundary, tested operational environments, services, Security Policy, algorithm evidence, caveats, and live CMVP status. If the change affects the validated scope or a FIPS 140-3 requirement, pause the existing claim until the vendor and an accredited Cryptographic and Security Testing (CST) laboratory select and complete the applicable CMVP path.
1
Section 1
Anchor maintenance on the validated module
FIPS 140-3 validation applies to a cryptographic module, not automatically to the whole product that contains or calls it. Start with the public CMVP entry and Security Policy: module name, version, type, boundary, overall and section ratings, approved and non-approved services, tested operational environments, caveats, certificate status, and sunset date.
Keep a separate release-to-module record for each product that depends on the module. Record the shipped binary or hardware identifier, product build, deployment environment, how the product invokes approved services, and the exact public wording. NIST states that a product containing an embedded validated module cannot claim that the product itself is validated, and FIPS validation does not assure that the product invokes the embedded module correctly.
Assign ownership before release. Engineering supplies the build and change evidence; the module vendor owns the controlled validation documentation and engages the CST laboratory; the CST laboratory evaluates and tests the applicable scenario; CMVP accepts or rejects the submission and updates the public record; and the release or assurance owner approves only wording that matches the live evidence.
Record the CMVP certificate number, module name, module version, Security Policy version, and validation status before approving a public claim.
Map each product SKU, service build, firmware image, or package version to the exact validated module it uses.
Check whether the release changes the cryptographic boundary, module interfaces, roles, services, approved-mode behavior, self-tests, or sensitive security parameter (SSP) handling.
Withhold customer-facing FIPS 140-3 wording when the changed implementation cannot be traced back to the validated module evidence.
Set recurring checks at release approval, procurement renewal, certificate sunset review, dependency-status review, and each published CMVP algorithm or guidance transition that affects the module.
Explains that certificates are issued for cryptographic modules, that a containing product cannot claim itself validated, and that correct product use of an embedded module is outside the validation scope.
2
Section 2
Check certificate status before relying on it
Check the live CMVP record rather than relying on an old certificate image, copied Security Policy, or inherited supplier statement. Active is the default status for a newly validated module. means the record is no longer Active because it reached its sunset date or was affected by current guidance or a programmatic transition; it is not the same as revocation. Revoked means the validation is no longer valid and may not be cited to demonstrate FIPS 140 conformity.
FIPS 140-3 warns that the list is for reference and should not support procurement decisions. The current CMVP validated-modules guidance distinguishes procurement for new systems from legacy systems: Federal agencies should not include Historical modules in new systems, but may procure them for legacy systems. Separately, agencies may make a risk determination about continued use based on where and how the module is used. A bound or embedded relying module can inherit Historical status from the existing validated module, so track both records.
A standard FIPS 140-3 validation is normally Active for five years. An is also Active but has a two-year sunset because CMVP reviewed the submission for completeness after the CST laboratory fully tested it. Do not calculate status from those periods alone: the live entry controls, and a transition, flaw decision, or dependency can change status earlier.
Verify the module on the public CMVP list before procurement responses, audit evidence, and customer trust-center updates.
Do not approve a module for a new system. For legacy-system procurement or continued use, record the intended system, live certificate status, applicable agency policy and risk decision, transition plan, and any relevant algorithm or guidance change.
Stop citing a Revoked validation to demonstrate conformity; escalate replacement and customer-notification decisions under the applicable contract and agency policy.
For embedded validated modules, capture the embedded module certificate number, version, and status next to the top-level module evidence.
Update public wording when a certificate moves status, a dependency certificate changes status, or the product no longer ships the validated module version.
Record the status-check date, sunset date, validation history, transition exposure, and named owner for the next check.
Current CMVP guidance distinguishes Historical-module procurement for legacy systems from inclusion in new systems and separately addresses continued-use risk decisions.
Recommended next step
Review validation maintenance evidence
This guide helps keep certificate status, module scope, operational-environment evidence, and customer-facing FIPS 140-3 wording in sync after releases.
Classify changes that can disturb the validation claim
Trigger a change review when the module, its certificate evidence, or the product's reliance on that evidence changes. Excluded components remain inside the cryptographic boundary: CMVP guidance requires if an excluded component changes and requires the overall module version to change.
Operational-environment changes also need a recorded comparison. For software modules, the tested environment includes the operating system, platform, processor, and any hypervisor. Do not assume that a new processor bit size, accelerator, operating-system release, hypervisor, compiler result, or platform is covered because the module source code is unchanged.
Classify the change with a CST laboratory against section 7.1 of the current CMVP Management Manual. Vendor Update (VUP) covers administrative changes; Vendor Affirmed Operational Environment (VAOE) changes Security Policy text for affirmed environments; Non-Security Relevant (NSRL) covers changes the laboratory can show are non-security-relevant; Algorithm Update (ALG) and Operational Environment Update (OEUP) cover qualifying algorithm and tested-environment updates; Rebrand (RBND) covers rebrands; and Update (UPDT), Common Vulnerabilities and Exposures (CVE), Algorithm Transition (TRNS), and Physical Enclosure (PHYS) address specified security-relevant, vulnerability, transition, or physical changes. A change outside the allowed conditions needs Full Submission.
Treat boundary, excluded-component, embedded-module, and bound-module changes as maintenance triggers.
Treat operating system, platform, processor, processor algorithm accelerator, processor algorithm implementation, virtualization, compiler, and tested-environment changes as evidence triggers for software, firmware, and hybrid modules.
Treat algorithm implementation, entropy source, deterministic random bit generator (DRBG), approved service indicator, and non-approved service changes as certificate-claim triggers.
Do not treat a source-code change as vendor affirmation of a new environment. The Management Manual sends source modifications to a laboratory-assessed scenario such as NSRL, OEUP, or UPDT.
Record one disposition: no impact to the validated module shown; product evidence or wording update only; CST laboratory assessment needed; CMVP submission needed; or the public claim must remain paused pending a new validation.
Retain the route rationale, regression or full-testing evidence, CAVP and ESV updates, submitted Security Policy, CMVP correspondence, validation history, and the date the public record changed.
Section 7.1 defines the current full-validation and revalidation scenarios and assigns impact evaluation and testing responsibilities to the vendor and CST laboratory.
4
Section 4
Maintain the evidence pack that supports the claim
The maintenance pack should show the relationship between the changed product and the validated module. It needs enough detail for a release owner, customer assurance team, vendor, or CST laboratory to identify the deployed module and reproduce the impact decision.
Keep algorithm and module evidence separate. CAVP tests implementations of approved cryptographic algorithms; CMVP validates the defined cryptographic module. The CMVP certificate detail links the module to its CAVP algorithm references. A CAVP certificate alone does not support a FIPS 140-3 module claim, and a buyer usually verifies the module through the public CMVP record and its Security Policy.
Release linkage: product version, firmware or software build, shipped module binary or component version, and customer-facing claim text.
Boundary evidence: diagrams, component list, excluded-component rationale, embedded or bound module references, roles, services, and approved-mode indicators.
Environment evidence: tested operating environments, platform assumptions, processor or accelerator assumptions, and any operational-environment update rationale.
Algorithm evidence: CAVP certificate numbers referenced by the module record, algorithm versions, tested environments, entropy-source and DRBG evidence, and any vendor-affirmed methods or environments that the Security Policy identifies.
Explains that a certificate detail record includes module information, CAVP algorithm references, Security Policies, certificate material, and vendor links when provided.
5
Section 5
Customer-facing wording must not outrun the certificate
Do not publish a claim that no longer matches the public record or shipped configuration. Avoid saying that a product is FIPS 140-3 validated unless the product and validated cryptographic module are the same defined object. When a product contains the module, identify the module name, version, and certificate and state that the product uses it; do not imply that CMVP validated the containing product or its integration.
Make maintenance review a publication control. Before a trust-center entry, datasheet, RFP response, support article, or sales answer is released, the evidence owner should check the module identity, live status, caveats, tested or affirmed environment, Security Policy, product mapping, and approved-service use. Pause wording that cannot be tied to those facts.
Name the module and certificate instead of implying that every product feature, deployment, or service environment is validated.
Do not cite an old certificate, copied supplier statement, or inactive dependency without checking current public status.
Do not reuse CAVP certificates after an algorithm implementation or tested operational environment changes unless the evidence still matches.
Do not promise validation, , or certificate updates on a fixed calendar. FIPS 140-3 says review timing depends on coordination among the vendor, testing laboratory, and CMVP, and the public IUT and Modules in Process lists do not establish a completion date.
Official explanations of module-versus-product claims and Active, Historical, Revoked, and sunset status.
Explains that certificates are issued for cryptographic modules, that a containing product cannot claim itself validated, and that correct product use of an embedded module is outside the validation scope.
Defines Active, Historical, Revoked, and sunset status for public validation records.
Show 1 more
Explains how a containing product may reference an embedded validated module without claiming that the product itself is validated.
April 9, 2026 official management source for validation status, Interim Validation, participant responsibilities, public process lists, vendor or user affirmation, and the section 7.1 submission scenarios.
Section 4.7 explains Historical and Revoked validations; section 7.1 supplies the current revalidation submission scenarios.
Section 7.1 defines the current full-validation and revalidation scenarios and assigns impact evaluation and testing responsibilities to the vendor and CST laboratory.
Current CMVP guidance distinguishes Historical-module procurement for legacy systems from inclusion in new systems and separately addresses continued-use risk decisions.
Explains that a certificate detail record includes module information, CAVP algorithm references, Security Policies, certificate material, and vendor links when provided.