A workflow for classifying module services, indicators, and Security Policy evidence before relying on an approved-mode claim.
Use it to separate approved security services, allowed no-security-claimed behavior, and services that cannot run in the approved mode.
Structured answer sets in this page tree.
Cited legal and guidance references.
This workflow is for product security, validation, and procurement teams reviewing a FIPS 140-3 cryptographic module. It focuses on a narrow question: for each externally invoked service, can an operator unambiguously tell whether the service uses an approved cryptographic algorithm, security function, or process in an approved manner, and does the Security Policy document the same classification?
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.
Use this workflow to turn service classification, indicator behavior, and Security Policy rows into evidence that reviewers can inspect.
Convert approved and non-approved service classification into owner-assigned evidence requests and review checkpoints.
Use cited NIST and CMVP source material to resolve service-indicator, non-approved algorithm, and Security Policy questions.
Review module services, indicators, approved-mode assumptions, and unresolved validation questions with Sorena.
The indicator must let the operator determine whether an approved security service is in use. CMVP guidance allows different indicator designs, including return codes, log messages, status bits, status interfaces, query functions, LEDs, or a global indicator when the module only supports approved services in an approved manner.
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.
Use 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.
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 a team relies on the workflow result, compare the service row against the Security Policy, algorithm certificate evidence, self-test coverage, operational environment, and any module configuration that prevents non-approved use. A service can be implemented with an approved algorithm and still fail the approved-service indicator logic if required testing, self-tests, or documented limits are missing.
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.
"description in the security policy alone"
"shall not share the same keys"
"operator of the module to retrieve"
"validation-search"
"cryptographic modules that conform"