Resolving Requirement Conflicts Using Source Hierarchy and Applicability Rules

Start with roles, not a simplistic document ranking

A useful but incomplete instinct is to arrange sources in a vertical hierarchy and assume that the “higher” source always wins. That shortcut fails because CMVP documents are designed to interact through expressly defined substitutions and modifications.

The CMVP process diagram is best understood as a dependency map rather than an organizational chart: ISO/IEC 19790 supplies core module requirements; ISO/IEC 24759 converts those into assertions, vendor evidence, and test evidence; the SP 800-140 series makes CMVP-specific adaptations; and IG addresses interpretation in concrete technical situations.

Study the official CMVP explanation of this interaction before applying the method below.

The practical model is:

The plus signs do not mean that every source creates another independent obligation. They mean that a valid conclusion is assembled in layers.

The three layers

This yields an important consulting rule:

A change in required evidence or test procedure is not automatically a change in the underlying security requirement.

Conversely, a vendor cannot argue that the general wording of a base requirement overrides an applicable CMVP modification to the test or evidence requirement. If SP 800-140 changes the vendor evidence or test evidence for a particular assertion, that modified procedure is the procedure the laboratory must apply.

Read the verbs that establish authority and scope

When reconciling sources, terms such as shall, must, and shall not matter. But the most decisive words are often those that establish the document’s relationship to another source:

• “Modifies only those requirements identified” means the original material remains in effect except at the specific points changed.
• “Modifies vendor evidence and test evidence” means the security assertion is not necessarily changed; the proof and assessment method may be.
• “Replaces” or “supersedes in its entirety” means the identified CMVP document displaces the specified ISO annex or ISO/IEC 24759 paragraph for CMVP purposes.
• “Clarification” or “interpretation” in IG means that the guidance must be read with the assertion and relevant derived requirement, not isolated as a free-standing technical preference.

The official CMVP page is unusually clear on this distinction. SP 800-140 modifies the test and vendor-evidence requirements of ISO/IEC 24759. SP 800-140A and SP 800-140B make targeted changes in their specified documentation domains. By contrast, SP 800-140C through SP 800-140F are described as replacing their corresponding ISO annex domains and specified ISO/IEC 24759 paragraphs.

That difference produces two fundamentally different resolution patterns.

Pattern 1: Targeted modification

Suppose an ISO/IEC 19790 requirement $R$ is represented in ISO/IEC 24759 by:

• an assertion $A$, expressing the security claim to be assessed;
• vendor evidence requirement $VE$; and
• test evidence procedure $TE$.

If an applicable SP 800-140 provision modifies $VE$ and $TE$, the result is:

Do not conclude that the base requirement was weakened merely because the CMVP now asks for different evidence, a different test sequence, or additional test documentation. The relevant question is whether the modified evidence and test procedure still demonstrate conformance to $A$ and, ultimately, $R$.

Pattern 2: Explicit replacement

Now consider a requirement area governed by an ISO annex that CMVP explicitly replaces. The official CMVP page states, for example, that SP 800-140C replaces ISO/IEC 19790 Annex C and supersedes ISO/IEC 24759 paragraph 6.15. SP 800-140D, E, and F have corresponding replacement roles for their stated subject areas.

Here the reasoning is different:

A vendor should not cite the original Annex C, D, E, or F language as controlling merely because it appears in ISO/IEC 19790. The CMVP’s published framework expressly establishes the replacement for that domain.

This is a genuine resolution of a source conflict: it is not based on a consultant’s preference, but on the exact replacement language and the subject matter it covers.

Implementation Guidance: controlling interpretation within its scope

IG is often misunderstood in two opposite ways:

1. “IG is only guidance, so we can ignore it if ISO wording seems broader.”
2. “The newest IG is always controlling, even if it concerns another technology or module type.”

Both are errors.

CMVP describes IG as clarification and guidance for an assertion or group of assertions, often to help laboratories and vendors apply requirements to a particular cryptographic-module implementation or technology. When a current IG is applicable to the module and issue, it is the CMVP’s relevant interpretation for that case. In practice, a lab and vendor should not substitute a private interpretation for it.

Yet IG must be read carefully. It normally answers a bounded question. Its applicability can depend on details such as:

• the module’s physical embodiment;
• whether the module is software, firmware, hardware, or hybrid;
• the module boundary and the location of the relevant function;
• a claimed security level;
• approved versus non-approved mode;
• a particular algorithm, parameter set, protocol construction, or operational environment;
• the submission’s date and state; and
• stated preconditions, alternatives, exclusions, or documentation consequences.

Therefore, treat an IG as a conditional rule:

If any element is unknown, the correct result is not “IG does not apply.” It is applicability unresolved.

What IG can and cannot do in your analysis

An applicable IG can:

• resolve ambiguous terminology in an assertion;
• determine how a requirement applies to a specific technology;
• identify a CMVP-accepted implementation approach;
• specify expected evidence, documentation, or testing treatment;
• clarify conditions under which a feature is permitted, excluded, or represented in the security policy.

An IG should not be treated as silently removing a base requirement simply because its example is narrower, more practical, or framed around a specific implementation technique. If the conclusion seems to be that a core security obligation has disappeared, stop and look for:

1. an explicit replacement or modification in the applicable SP 800-140 document;
2. exact IG language that establishes the intended treatment and its scope;
3. a source-version or transition issue; or
4. an unresolved policy question requiring laboratory and CMVP clarification.

A disciplined conflict-resolution method

Use the following sequence whenever a vendor, laboratory, or reviewer says that two CMVP sources “contradict” one another.

1. State the decision, not merely the topic

“Does the requirement apply?” is too vague. Reframe it as a decision that can be tested:

For the identified module configuration, submitted under the stated validation context, what implementation behavior, evidence, and laboratory test treatment are required for this assertion?

This wording forces separation of the security outcome from the evidence and assessment method.

2. Freeze the case facts

Write down only facts that affect applicability:

• module name, version, and cryptographic boundary;
• embodiment and operational environment;
• relevant service, algorithm, interface, or sensitive security parameter;
• claimed mode and applicable security level;
• validation state: early design, laboratory assessment, CMVP review, or post-validation change;
• decision date, submission date where relevant, and source retrieval date.

A surprising proportion of “requirement conflicts” are actually fact-pattern conflicts. One party is discussing a general-purpose software module, while another is relying on guidance applicable only to a bounded firmware implementation or a particular claimed mode.

3. Extract the source chain precisely

For each source, record:

Do not quote a paragraph without its identifier and revision baseline. Likewise, do not use an IG title as a substitute for reading its scenario and resolution.

4. Classify the apparent conflict

Before trying to reconcile the texts, put the issue in one of these categories.

The word conflict should be reserved for the last category. Most cases are resolved earlier by identifying a modification, replacement, scope condition, or obsolete source.

5. Test whether the result still satisfies the security outcome

After applying the DTR and IG, ask one final question:

Does the resulting implementation and evidence still demonstrate the security property required by the controlling base requirement, unless that requirement area has been expressly replaced?

This check guards against a common failure mode: treating a checklist item as the objective. Evidence is not the security property; it is the means by which a laboratory evaluates the claimed property.

Worked analysis: two different “conflicts”

Case A: an explicit Annex replacement

A vendor is assessing a sensitive-parameter establishment method. Its internal design note cites ISO/IEC 19790 Annex D and concludes that the method is acceptable. The laboratory responds that the CMVP treatment is governed by SP 800-140D. The vendor argues that ISO/IEC 19790 is the base standard and therefore must prevail.

This is not an interpretive disagreement. It is an explicit substitution question.

1. Identify the domain. The issue is approved sensitive-parameter generation and establishment methods.
2. Check the CMVP relationship statement. The official CMVP page states that SP 800-140D replaces ISO/IEC 19790 Annex D and supersedes ISO/IEC 24759 paragraph 6.16.
3. Apply the scope condition. If the method falls within that Annex D subject area, evaluate it against the applicable SP 800-140D treatment.
4. Read any relevant IG. An IG may clarify a particular construction, validation path, or documentation condition. It does not revive the displaced Annex D treatment.
5. Document the conclusion.

A defensible conclusion is:

The vendor’s reliance on ISO/IEC 19790 Annex D is not controlling for this CMVP decision because SP 800-140D expressly replaces Annex D and supersedes the corresponding ISO/IEC 24759 test paragraph. The assessment must use the applicable SP 800-140D requirement set, together with any current and applicable IG.

Notice the precision: this conclusion does not claim that all ISO/IEC 19790 requirements are displaced. It applies only to the expressly replaced domain.

Case B: a derived test requirement and IG seem stricter than the base text

Consider a generic requirement $R$ for which ISO/IEC 24759 provides assertion $A$, vendor evidence $VE$, and test evidence $TE$. The applicable SP 800-140 DTR changes the required evidence and laboratory procedure to $V{E}^{\prime }$ and $T{E}^{\prime }$. A current IG then explains, for a defined implementation technology, what documentation and observations are sufficient to satisfy $V{E}^{\prime }$ and $T{E}^{\prime }$.

A vendor says:

The base requirement does not explicitly require this extra artifact, so the IG and DTR demand too much.

The correct analysis is:

1. The base requirement defines the outcome $R$.
2. ISO/IEC 24759 creates an assessable assertion $A$ and a default evidence/test path.
3. The applicable DTR validly modifies that evidence/test path for CMVP.
4. The applicable IG explains how the DTR is implemented for this technology.
5. The additional artifact is not necessarily a new security objective. It may be required evidence that allows the laboratory to determine whether $R$ is met.

The conclusion is:

The base requirement has not been overridden. The CMVP-derived test requirement modifies the assessment evidence and procedure for the identified assertion. Because the module matches the IG’s scope conditions, the IG-defined documentation treatment applies. The vendor must provide the artifact or demonstrate an equally permitted route stated in the governing sources; a general reading of the base requirement is not sufficient to disregard the applicable DTR and IG.

This pattern will recur throughout consulting engagements: self-test evidence, operational-environment claims, algorithm status, boundary documentation, and physical-security evidence can all produce the same structure.

When not to resolve it yourself

A consultant’s job is to resolve apparent conflicts rigorously, not to manufacture policy. Escalation is appropriate when all of the following are true:

• the sources are current and correctly identified;
• the module’s facts are sufficiently stable;
• both source provisions are genuinely in scope;
• the texts prescribe incompatible treatment or leave a material gap; and
• the conclusion affects design, testing, scope, schedule, or certificate representation.

At that point, prepare a short issue package for the laboratory rather than sending an unbounded question. Include:

1. a concise description of the module and configuration;
2. the exact decision needed;
3. the base requirement and ISO/IEC 24759 assertion, $VE$, and $TE$;
4. the exact applicable SP 800-140 provision;
5. the IG identifier, scope, and relevant text;
6. the factual reason each source appears applicable;
7. your proposed resolution and its impact; and
8. the required decision date.

For an in-contract validation, route the question through the contracted accredited laboratory and use the established CMVP process where clarification is needed. Do not treat an informal historical email, a prior lab practice, or an archived draft manual as a substitute for current official policy.

Reusable work product: the source-conflict resolution record

Add the following compact record to your consulting toolkit. It is deliberately more focused than a full requirements traceability matrix; its purpose is to make policy reasoning reviewable before it becomes a design or schedule commitment.

A high-quality record distinguishes these two statements:

• Fact: “SP 800-140 modifies the test and vendor-evidence requirement for the identified assertion.”
• Conclusion: “Therefore, the laboratory must use the modified CMVP evidence and test treatment for this module configuration.”

That distinction makes review easier and protects the advice if a source revision, scope fact, or transition condition later changes.

Key takeaways

An apparent conflict among a base requirement, a DTR, and IG is usually a question of role and applicability, not a contest of document titles.

• Preserve the base security outcome unless an applicable CMVP source explicitly replaces the relevant requirement domain.
• Apply SP 800-140 modifications exactly where they are authorized and identified, particularly for vendor evidence and laboratory test evidence.
• Treat a current, in-scope IG as the CMVP interpretation for the defined technology and case; do not generalize it beyond its stated conditions.
• Distinguish a real conflict from additive evidence, explicit replacement, a scope mismatch, or a version mismatch.
• Escalate only after building a precise source-and-facts record that shows why an authoritative answer is necessary.

Next, you will turn this reasoning into a full trace: from a normative security requirement, through its applicable test procedures and evidence, to the IG and documentation that make the requirement demonstrable in a validation package.