FIPS 140-3 Validation Maintenance

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 revalidation 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.

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. Historical 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 Historical list is for reference and should not support new procurement decisions. The current CMVP Management Manual allows an agency to make its own documented risk decision about continued use of a Historical module. 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 Interim Validation 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.

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 revalidation 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 covers administrative changes; VAOE changes Security Policy text for vendor-affirmed environments; NSRL covers changes the laboratory can show are non-security-relevant; ALG and OEUP cover algorithm and tested-environment updates; RBND covers rebrands; and UPDT, CVE, TRNS, and PHYS address specified security-relevant, vulnerability, transition, or physical changes. A change outside the allowed revalidation conditions needs Full Submission.

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.

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.