FIPS 140-3 Approved and Non-Approved Mode Workflow

Do not start from a product feature list or a broad statement that the module is in FIPS mode. CMVP Implementation Guidance 2.4.C treats a service as an externally operator-invoked operation or function, and it explains that a service may map to one API call, a group of API calls, or different behavior based on input parameters.

The first workflow step is to list every callable service that can affect cryptographic behavior, including encryption, decryption, signature generation, verification, key establishment, random bit generation, authentication, on-demand self-tests, zeroisation paths, status output, and any service that exposes both approved and non-approved behavior.

For each service, decide which CMVP bucket it belongs in. Approved security services use approved or allowed security functions in an approved manner. Some services may run in the approved mode even though they do not use a security function, or because a non-approved algorithm is present only with no security claimed. Services that use non-approved and not-allowed security functions are not available for use in the approved mode.

This classification is not the same as saying the entire product is approved. FIPS 140-3 requires modules conforming to the standard to employ approved security functions, while the CMVP guidance requires the Security Policy to show approved and non-approved services and the indicators that apply.

Examples make the branches concrete. Showing module version or status is a Group 2 service and does not need an approved security service indicator unless another approved service uses it. Proprietary obfuscation can fit the no-security-claimed branch only when the data is treated as unprotected plaintext and the remaining FIPS requirements are met. A password-based key derivation function (PBKDF) service cannot be indicated as approved if the PBKDF implementation lacks required CAVP evidence or self-tests.

The indicator must let the operator determine whether an approved security service is in use. CMVP guidance gives return codes, log messages, status output, and global or shared indicators as examples, but it does not prescribe one design. A global indicator works only when it still identifies approved service use unambiguously.

A Security Policy description can explain how to interpret an indicator, but the description alone does not satisfy the indicator requirement. If approved and non-approved security services can run concurrently, or if different inputs can change whether a service is approved, a broad global indicator is not enough unless it still unambiguously identifies the approved security service.

Keep one row per service so procurement, lab, engineering, and audit reviewers can see the decision without reading the entire Security Policy.

Row fields: service name; operator-facing entry point; algorithm or process used; approved, allowed, no-security-claimed, or non-approved classification; CAVP certificate or evidence reference where applicable; key or CSP sharing result; indicator value and interface; Security Policy location; reviewer decision.

The module engineer owns the implemented service and indicator, the cryptography owner verifies the algorithm and key or CSP treatment, and the Security Policy owner keeps the published service rows aligned. The row outcome should say approved security service, allowed in approved mode without an indicator, allowed with no security claimed and plaintext treatment, unavailable in approved mode, or held for CST laboratory review.

Decision outcomes: approved security service with indicator; allowed in approved mode with no security claimed; non-security service with no indicator needed; not available in approved mode; unresolved pending lab or CMVP review.

Before relying on the result, compare the service row against the Security Policy, selected CAVP capabilities, applicable self-tests, operational environment, and any enforced configuration that prevents non-approved use. An approved algorithm does not make every use approved: the service context, parameter choices, security strength, key handling, and any usage restriction still apply.

The operator also has a role: CMVP guidance says the operator may need to retrieve, recognize, and act on the service indicator. For customer-facing or procurement evidence, show how a human operator, calling application, client process, or another module can obtain the indicator in the deployed configuration.

Most failures come from collapsing service-level evidence into a single product-level statement. The safer pattern is to say exactly which service is approved, which indicator proves it, which Security Policy row explains it, and which non-approved behavior is blocked, allowed with no security claimed, or outside the approved mode.

Be especially careful with services that can change approval status based on parameters, service combinations, concurrent execution, or operator-controlled use outside the module. Those cases need clearer indicators and Security Policy interpretation than modules that only expose approved services.