Understanding the Normative Roles of Cryptographic Standards and Guidance

A standards system, not a document stack

A useful starting point is to separate three kinds of statements:

1. Technical security requirements — what the cryptographic module must do or resist.
2. Conformity assessment requirements — how a laboratory determines whether those requirements are met and what evidence a vendor must provide.
3. CMVP program policy and operations — how the CMVP applies the scheme, administers submissions, and interprets issues encountered in real implementations.

The central architecture is:

• FIPS 140-3 establishes the U.S. Federal standard and its adoption of the ISO-based scheme.
• ISO/IEC 19790 contains the baseline cryptographic-module security requirements.
• ISO/IEC 24759 translates those requirements into vendor-evidence and laboratory-test requirements.
• The SP 800-140 series is the CMVP’s U.S./Canadian validation profile: it modifies or replaces specified ISO annexes and test/evidence sections.
• Implementation Guidance (IG) provides CMVP clarifications and interpretations, often for specific technologies or recurring assessment problems.
• The CMVP Management Manual governs the programmatic process: participation, submissions, review, and validation administration.

The official FIPS text is worth reading carefully because it frames this as a Federal standard whose technical content is distributed across the ISO standards and CMVP-controlled publications.

The process illustration below depicts the same structure. Read it as a flow of requirements and evidence, rather than as a simple hierarchy in which every document has the same kind of authority.

The left side shows the technical chain. ISO/IEC 19790 feeds ISO/IEC 24759; the SP 800-140 publications intervene at defined points. The right side shows the institutional chain: CMVP requirements and the Management Manual guide the accredited laboratory’s assessment and CMVP review. The diagram’s most important practical lesson is that a validation conclusion is assembled through traceable evidence and independent assessment, not inferred from a product’s design intent or from an algorithm certificate alone.

The role of each authority

FIPS 140-3: Federal adoption, applicability, and the CMVP framework

FIPS 140-3 is a Federal Information Processing Standard approved under U.S. statutory authority. It establishes the standard’s applicability to Federal use of cryptography for protecting sensitive information; identifies the CMVP as the validation authority; establishes four qualitative security levels; and points to the governing ISO standards and CMVP publications.

It is therefore wrong to describe FIPS 140-3 as merely a cover sheet for ISO/IEC 19790. It is the instrument that makes this ISO-based framework the relevant Federal standard and specifies the CMVP-controlled documents that modify defined parts of the ISO material.

At the same time, FIPS 140-3 does not reproduce the detailed technical requirements that consultants repeatedly analyze for a module boundary, interfaces, roles, self-tests, physical security, or lifecycle assurance. For those, the primary baseline is ISO/IEC 19790.

A precise consulting statement is:

FIPS 140-3 establishes the Federal cryptographic-module standard and incorporates an ISO-based technical and assessment framework, as tailored by CMVP publications.

Avoid the less precise statement, “The module complies with FIPS 140-3 because it implements AES.” An approved algorithm is neither a complete module-conformity argument nor a substitute for validation.

ISO/IEC 19790: the baseline technical requirements

ISO/IEC 19790 specifies the security requirements for cryptographic modules. Its core is organized around eleven requirement areas, including module specification, interfaces, roles and services, software/firmware security, operational environment, physical security, non-invasive security, sensitive security parameter management, self-tests, lifecycle assurance, and mitigation of other attacks.

It also defines four security levels. A module’s claim is not simply a product-wide “Level 3 design quality” label; it must be assessed according to the selected levels and requirements across the applicable areas. Later modules will unpack that requirement-area logic in detail.

For a consultant, ISO/IEC 19790 is usually where the answer begins when the question is:

• “What does the module need to protect?”
• “Which interface classifications are required?”
• “What are the requirements for an operator role or authentication mechanism?”
• “What controls apply at this selected security level?”

The important qualification is baseline. The applicable CMVP profile may modify particular annex content, so one cannot stop at an ISO annex without checking whether a relevant SP 800-140 publication changes it.

ISO/IEC 24759: derived tests and vendor evidence

ISO/IEC 24759 specifies the methods used by testing laboratories to assess conformance to ISO/IEC 19790. It also defines information vendors must provide as supporting evidence. In the FIPS 140-3 scheme, it is not an optional laboratory handbook: it is part of the formal basis for determining conformity.

A concise distinction is:

• ISO/IEC 19790: “What must be true of the module?”
• ISO/IEC 24759: “What must the vendor show, and how does the laboratory assess it?”

This distinction matters in engagements. Suppose ISO/IEC 19790 requires that a module perform a specified security function. ISO/IEC 24759 then drives questions such as:

• What implementation description is needed?
• What test evidence will substantiate the behavior?
• What observable result must the laboratory verify?
• Which vendor-provided artifacts make the claim assessable?

Do not characterize ISO/IEC 24759 as creating unrelated product-security features. Its central role is to make assessment objective, repeatable, and consistent among laboratories—while the CMVP may tailor its vendor-evidence and test requirements through the SP 800-140 series.

The SP 800-140 series: CMVP’s specified modifications and replacements

“NIST SP” is a publication series, not a single category with one universal legal effect. In this ecosystem, the SP 800-140 series has a particularly specific role: it records CMVP modifications or replacements to identified parts of ISO/IEC 19790 and ISO/IEC 24759.

The distinction within the series is important:

The verbs matter:

• A publication may modify only the explicitly identified ISO text. The ISO text remains relevant elsewhere.
• A publication may replace or supersede a specified annex or test section. In that defined area, a consultant must use the CMVP publication rather than treating the underlying ISO annex as controlling.
• A CMVP SP does not generally replace the entirety of ISO/IEC 19790 or ISO/IEC 24759.

For example, a question about whether an algorithm is Approved under the CMVP profile belongs in the SP 800-140C and related applicable CMVP policy context—not in a generic reading of ISO/IEC 19790 Annex C alone. Conversely, the core interface requirement areas are not displaced merely because an SP 800-140 publication exists.

Other NIST Special Publications can also matter because a requirement, an Approved security function, or CMVP guidance invokes them. Their role must be determined from that explicit invocation. Do not assume that every NIST SP is automatically a direct cryptographic-module validation requirement.

Implementation Guidance and the Management Manual: operational authority with distinct purposes

The CMVP’s own explanation of the process provides a useful boundary between technical requirements, implementation interpretation, and program administration.

Implementation Guidance: interpretation in the CMVP scheme

CMVP Implementation Guidance clarifies or interprets requirements and assurance measures. It is often technology-specific because generic standards text must be applied to real architectures: software modules running on complex operating systems, virtualized environments, entropy constructions, hardware designs, hybrid cryptographic boundaries, or algorithm transitions.

IG commonly answers questions of this kind:

• How should a requirement be applied to this technical architecture?
• What CMVP interpretation governs a recurring implementation pattern?
• What evidence or limitation is expected for a particular technology?
• How should a term or validation condition be understood in a CMVP assessment?

IG is not simply educational commentary. For a validation engagement within its scope, it is CMVP policy guidance that can materially affect a module’s implementation, evidence package, security policy, laboratory test plan, and validation outcome.

However, it should not be treated as though it silently rewrites all of ISO/IEC 19790. A sound analysis identifies:

1. the underlying ISO requirement or CMVP-tailored requirement;
2. the IG that interprets its application;
3. the technology and configuration to which the IG applies; and
4. the effect on the module or submitted evidence.

This chain prevents a frequent consulting error: citing an IG identifier as a free-standing answer without naming the governing requirement and scope.

CMVP Management Manual: the program’s operating procedures

The CMVP Management Manual is a standalone program document. Its role is procedural and administrative: it defines how the CMVP operates the validation program and governs aspects of participation, submission processing, review, and certificate management.

The Management Manual answers questions such as:

• What is the program’s submission and review process?
• What are the relevant obligations of a laboratory or vendor in program operations?
• How are validation artifacts or status handled?
• What program rules apply to the handling of a validation?

It is not the primary source for a technical statement such as “the module must perform this self-test” or “this authentication mechanism is Approved.” For those, begin with the relevant technical standards and CMVP SP publications, then consult IG if a CMVP interpretation is needed.

This separation is useful when triaging a finding:

A consultant’s source map

When a client asks a seemingly simple FIPS 140-3 question, do not begin by searching across documents for a familiar phrase. First classify the question.

A compact source-map notation is useful in review notes and client advice:

For example, this is not yet a conclusion about any particular module, but it is the shape of a defensible analysis:

The order is analytical, not a rigid hierarchy. The rule is to use each source for the job it was designed to perform. The next lesson will add the essential control: determining which edition, revision, transition policy, and guidance version are currently applicable before relying on the source map.

A practical habit for consulting deliverables is to label every substantive assertion by role, not merely by document name:

• Requirement: ISO/IEC 19790 clause or an applicable CMVP replacement.
• Evidence/test obligation: ISO/IEC 24759 clause as modified by the relevant SP.
• CMVP interpretation: applicable IG, with stated scope.
• Program procedure: Management Manual.
• Federal applicability / scheme basis: FIPS 140-3.

That labeling makes review meetings far more productive. It exposes whether a disagreement is actually about a security requirement, evidence sufficiency, the applicability of guidance, or a program-process rule.

Key takeaways

FIPS 140-3 establishes the Federal standard, CMVP framework, applicability, and adoption of the ISO-based scheme. ISO/IEC 19790 is the baseline technical-requirements standard; ISO/IEC 24759 defines the associated laboratory test methods and vendor evidence. The SP 800-140 series provides CMVP-specific modifications or replacements at explicitly identified ISO annexes and test sections.

Implementation Guidance clarifies how requirements and assurance measures apply, often in technology-specific circumstances. The CMVP Management Manual governs the programmatic process rather than serving as the primary technical-requirements source.

Most importantly, “normative” is not a license to cite a document without context. A high-quality answer identifies the question type, the baseline source, the applicable CMVP modification, the test/evidence implication, and any interpretation that governs the specific architecture.

Next, you will learn how to verify source currency, effective dates, supersession, and applicability—turning this role map into advice that is not only well reasoned, but current.