FIPS 140-3 Validation Maintenance Change Workflow

FIPS 140-3 validation is about a cryptographic module, not a whole product by default. The intake step should name the module, module version, certificate number or validation reference, module type, security level claims, operational environment, and the Security Policy version that supports the public claim.

Not every product release changes the validated module, but every release that may affect the module baseline needs a documented comparison. If the change affects module code, versioning, FIPS 140-3 assertions, tested operational environments, algorithms, SSPs, approved security services, self-tests, security states, or certificate dependencies, route it through the vendor and CST laboratory before reusing the claim.

Classify the change first by where it occurs. A change inside the cryptographic boundary, in an excluded component inside that boundary, in a bound or embedded validated module, or in the tested operational environment carries different evidence consequences than a change in unrelated product code.

CMVP guidance makes several consequences explicit. Changes to excluded components require the overall module version to change, and an implementation that embeds another validated module must identify that module by name, certificate number, and version in the Security Policy and validation test report. The Management Manual then determines which submission scenario can cover the change.

Software and firmware changes need a specific branch in the workflow because CMVP guidance distinguishes complete image replacement from software or firmware loading. A complete replacement can be treated as a new module, while loaded code associated with, bound to, modifying, or required by the validated module can trigger load-test expectations before execution.

Review algorithm and vulnerability evidence in the same maintenance pass. Reused CAVP evidence depends on the algorithm implementation and environment. Under the April 9, 2026 Management Manual, the CVE scenario can also cover narrowly scoped security-relevant maintenance or bug fixes, but it cannot introduce new features or cryptography; a fix that changes an algorithm implementation may require new CAVP testing.

Use this workflow as the intake record for a validation-maintenance review. It does not replace the CMVP Revalidation Change Document or let the product team choose a submission result without a CST laboratory.

The main branches are specific. VUP covers administrative changes that do not affect FIPS 140-3 requirements. VAOE covers vendor-affirmed operational-environment changes. NSRL covers changes that affect assertions but are non-security-relevant. ALG covers qualifying algorithm updates without module code changes, and OEUP covers qualifying tested operational-environment updates. RBND applies when an unchanged module is rebranded from an already validated original-equipment-manufacturer module. PTSC covers a qualifying port of a previously validated sub-chip cryptographic subsystem to another single-chip construct. UPDT may cover security-relevant changes only when no measured change category exceeds the Management Manual's 30 percent limit. CVE covers narrowly scoped security-relevant vulnerability, maintenance, or bug fixes without new features or cryptography. TRNS is limited to security-relevant changes made solely in response to a published CMVP algorithm transition. PHYS covers changes only to the protective physical enclosure with no operational module change. Changes outside the revalidation criteria require a full submission.

Step 1: the product security owner confirms the module name, version, certificate reference, Security Policy version, and product build, then checks whether the public claim is about that exact FIPS 140-3 module.

Step 2: the module engineering owner reviews the boundary diagram, service table, changed components, and operational-environment list to decide whether the change touches the validated boundary, excluded components, embedded modules, or tested environment.

Step 3: the cryptography owner reviews CAVP certificate numbers, approved-service indicators, entropy or DRBG records, and self-test evidence to confirm that approved algorithm and approved-service claims are still supported.

Step 4: the release or vulnerability owner reviews software or firmware loading evidence, CVE applicability, mitigation notes, and customer wording. The vendor and CST laboratory then assess all applicable Management Manual scenarios: FS, INTU, VUP, VAOE, NSRL, ALG, OEUP, RBND, PTSC, UPDT, CVE, TRNS, or PHYS. Pause the claim if the changed implementation no longer matches the public validation record.

The output should be a narrow evidence packet that explains whether the changed implementation can continue using the existing FIPS 140-3 claim. It should not overstate a new validation, guarantee acceptance by CMVP, or turn internal release approval into a public compliance certificate.

When the classification is uncertain, the safest content action is to withhold or qualify the public claim until the vendor, CST laboratory, or CMVP-facing evidence supports it. The record should show exactly which source of uncertainty remains: boundary, version, operational environment, software loading, CAVP evidence, CVE status, Security Policy text, or certificate status.