FIPS 140-3 Approved-mode evidence workflow

FIPS 140-3 applies to cryptographic modules, not to every surrounding product feature. Start the evidence file with the validated or candidate module name and version, its cryptographic boundary, its operational environment, and the services exposed to operators, applications, or another module.

For approved-mode evidence, the service inventory is the control surface. CMVP guidance treats a service as an externally operator-invoked operation or function and explains that services may be documented differently from individual API calls. A single API can provide different services depending on parameters, and a service can invoke multiple API functions.

Approved mode is a set of services that includes at least one service using an approved security function or process and may include non-security-relevant services. It excludes non-approved security functions or processes. IG 2.4.C separately requires an indicator for each approved security service; not every service allowed to run in approved mode needs that indicator.

Classify each service into one of four evidence buckets: approved security service, non-security service allowed to run in approved mode, service using a non-approved algorithm with no security claimed, or service that is not available in approved mode. Record mixed or parameter-dependent behavior as separate rows. This prevents a customer-facing claim from implying that every callable cryptographic operation is approved.

FIPS 140-3 evidence should show how the operator, calling application, or another module can tell whether an approved security service is in use. CMVP guidance says the indicator can be externally accessible through the module status interface and does not have to be physical or human-readable only.

The Security Policy can explain how to interpret an indicator, but the description alone is not the indicator. Capture the module behavior: a return code, log message, status output, or another externally accessible signal. A configuration state is supporting evidence only when the module enforces it and the resulting indicator still identifies approved service use unambiguously.

CAVP certificates are evidence inputs, not substitutes for module validation. CMVP guidance states that algorithm validation certificates identify the algorithm implementation and tested operational environment, while module validation certificates identify the cryptographic module and its tested operational environment. SP 800-140B Rev. 1 explains that the vendor or lab selects the implemented capabilities from associated CAVP tests for the Security Policy's Tested Algorithms table.

For software, firmware, or hardware modules using embedded algorithm implementations, the evidence should show that the implementation was not modified during integration and that the CAVP-tested operational environment is identical to, or fully included in, the environment tested by the CST laboratory.

Keep this table structure in the evidence pack. It keeps the FIPS 140-3 claim tied to a service, an indicator, and a cited certificate or Security Policy entry.

Service | Classification | Indicator evidence | Certificate or policy evidence | Reviewer check

Encrypt customer data | Approved security service | Return code or status output showing approved use for the selected algorithm, key length, and mode | CAVP certificate entry plus module Security Policy service row | Does the indicator distinguish approved and non-approved parameter choices?

Show module status | Non-security service allowed in approved mode | Status interface output, if used by another approved service | Security Policy service list | Is the service being used only as status output, not as a security claim?

Use proprietary obfuscation for internal storage | Non-approved algorithm with no security claimed | Operator guidance showing data is treated as plaintext for FIPS purposes | Security Policy list of non-approved algorithms allowed in approved mode with no security claimed | Does the service avoid sharing keys or CSPs in a prohibited way?

Legacy or unsupported cryptographic service | Not available in approved mode | Disabled configuration, rejected call, or non-approved indicator | Security Policy and test evidence | Can an operator confuse this service with an approved security service?

For each row, name the module engineer who produced the trace, the cryptography reviewer who checked algorithm and SSP treatment, and the Security Policy owner who checked the final wording. Record pass, fail, or hold; a hold remains outside customer or procurement claims until the CST laboratory or CMVP-facing evidence resolves it.

Approved-mode evidence should be refreshed when a change can affect the module boundary, service classification, indicator behavior, algorithm implementation, operational environment, or Security Policy statements. The workflow is not a promise that a change is validation-neutral; it is a triage record for deciding what needs laboratory, CMVP, procurement, or customer review.

Treat binding or embedding another validated module as a separate evidence branch. CMVP guidance requires precise identification of an embedded or bound module by name, certificate number, and version, and it requires clear separation between the implementation under test and the externally validated module.

Retain the service call or API trace, indicator output, module and dependency versions, configuration, operating environment, CAVP record, Security Policy section, reviewer names, decision date, and next trigger. A screenshot of a mode setting is supporting context, not proof that a particular approved security service executed.