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.
Classify each externally invoked service before describing the module as operating in an . The decisive questions are whether the service uses an approved or allowed security function or process in an approved manner, whether it needs an , and whether the CMVP lists the same service and indicator. This workflow is for module vendors, product security teams, validation teams, and procurement reviewers; the CST laboratory tests and evaluates the module, and CMVP determines validation acceptance.
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 even though they do not use a security function, or because a non-approved algorithm is present only with . 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 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 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 PBKDF-based key-derivation service cannot be indicated as approved if the PBKDF implementation lacks required CAVP evidence or self-tests.
This workflow helps 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 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 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 .
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; 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 owner keeps the published service rows aligned. The row outcome should say approved security service, allowed in without an indicator, allowed with and plaintext treatment, unavailable in approved mode, or held for CST laboratory review.
Decision outcomes: approved security service with indicator; allowed in with ; 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 , 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 row explains it, and which non-approved behavior is blocked, allowed with , or outside the .
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 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"
"Cryptographic modules that are validated under the CMVP will be considered as conforming to this standard"