Cybersecurity Certification Roles and Responsibilities

The core separation: design, independent assessment, validation decision

The CMVP model has three deliberately distinct functions:

1. The vendor creates the module, defines what it is claiming, and supplies truthful, controlled evidence.
2. The accredited Cryptographic and Security Testing Laboratory (CSTL) independently assesses the module against the applicable requirements and prepares the validation submission.
3. The CMVP Validation Authorities review the CSTL submission and make the validation decision. The CMVP is jointly managed by NIST and the Canadian Centre for Cyber Security (CCCS).

This separation is not administrative formality. It is the basis for independent assurance. If the entity performing conformance testing designed the implementation or authored its original design evidence, it would be assessing its own work.

The following shorthand is useful in client-facing plans:

The most precise formulation is:

The laboratory is not merely a courier between the vendor and CMVP. It must independently determine whether the module conforms to the applicable requirements, including requirements not fully covered by algorithm testing. Equally, the CMVP does not rerun the CSTL’s complete test campaign; it reviews the submission and asks whether the assessment and evidence demonstrate conformance.

Assign responsibilities by deliverable and decision

A consultant should avoid assigning responsibility at the vague level of “documentation” or “testing.” Instead, assign each atomic action in the trace record.

For a given claim, ask five questions:

1. Who produces the underlying technical fact or evidence?
2. Who independently examines or tests it?
3. Who reviews the submitted assessment package?
4. Who has authority to decide the issue?
5. What event requires escalation, and through whom?

The table below is a practical responsibility model. “Authority” means the party that makes the relevant formal decision, not necessarily the party that performs the most work.

A useful accountability rule is:

The vendor owns the truth of the module; the CSTL owns the independence and quality of the assessment; the CMVP owns the validation decision.

This avoids two costly failures:

• The vendor says, “The lab wrote the policy, so it owns its accuracy.”
• The laboratory says, “The vendor supplied the document, so its content is presumed correct.”

Neither position is defensible. The vendor must stand behind the technical content. The CSTL must assess whether that content accurately represents the Implementation Under Test and meets applicable requirements.

A narrow but important CSTL documentation exception

The Management Manual permits a CSTL, in defined circumstances, to create or consolidate certain documents such as a finite state model, security policy, entropy assessment report, entropy public-use document, and administrator or non-administrator guidance. This is not permission for the CSTL to invent a design, fill gaps from assumption, or take ownership of vendor evidence.

The conditions matter:

• The work must occur after module design and development.
• The content must be consolidated or reformatted from existing vendor information.
• The CSTL must be able to map the resulting material back to original vendor source documentation.
• The CSTL must maintain that mapping in validation records.
• The CMVP must be notified at submission of CSTL-generated documentation.

In a consulting engagement, treat this as an exception that requires an explicit evidence map. If a security-policy table contains a claim that cannot be traced to vendor-approved design, implementation, configuration, or test information, the issue is not “a drafting task”; it is an unresolved technical claim.

Follow responsibility through the validation workflow

The formal process becomes easier to manage when you view it as a sequence of controlled handoffs rather than a single “submission.”

At a high level, the vendor-laboratory-CMVP sequence is iterative:

The laboratory is the formal channel for validation-package communication. The vendor is frequently essential to resolving findings, but should not treat the CMVP review as a direct, informal technical support channel.

Phase 1: Implementation Under Test

The vendor contracts with an accredited CSTL, provides controlled documentation, and delivers the module or prepares it for testing at the vendor facility. The CSTL assigns the tracking identifier used for CMVP communication and conducts testing under the applicable ISO/IEC 24759 test requirements, SP 800-140 series requirements, and applicable IG.

At this phase, a responsibility register should make the following boundaries explicit:

One subtle point from the Management Manual is especially important for consultants: ISO/IEC 19790 remains the definitive reference for whether the module meets the security requirements. A test-procedure ambiguity does not allow a team to waive the underlying security outcome. If a proposed test deviation still satisfies that outcome, it requires CMVP approval before submission.

Phase 2: submission, review, and coordination

Once the CSTL determines the module is conformant, it prepares the submission package. The CSTL must address each test-evidence item independently rather than relying on vague cross-references to another test-evidence response.

When CMVP reviewers begin their assessment, comments are sent to the CSTL. The CSTL then coordinates with the vendor as needed, but must resubmit a complete and internally coherent package. A vendor response that only patches one security-policy paragraph while leaving the test report, module specification, configuration manifest, or evidence matrix unchanged is a common coordination failure.

At this stage, use a strict split:

• Vendor: analyzes the technical issue, updates implementation or authoritative evidence, performs regression analysis, and approves content.
• CSTL: determines whether the response is sufficient, repeats applicable assessment activity, updates the report, and submits the coordinated response.
• CMVP: evaluates the resubmitted package and either issues additional comments or reaches “All OK.”

The Management Manual states that the CSTL must respond within 90 days during Coordination to avoid the review being placed on hold. For consulting planning, this means that a CMVP comment should immediately become a managed work item with a technical owner, CSTL owner, affected trace IDs, evidence dependencies, and a target delivery date well before that limit.

Phase 3: finalization and certificate issuance

Finalization confirms that changes made during coordination are correctly reflected and that vendor and module information is accurate. Once that review succeeds, the joint Validation Authorities issue a certificate number and publish the validation entry.

The vendor should not describe a module as validated before this point. A completed laboratory test campaign, an IUT listing, or a module in review is not a CMVP certificate.

Escalation: distinguish defects, interpretation questions, and authority decisions

Not every problem should travel to NIST and CCCS. Escalating a routine documentation inconsistency to CMVP wastes review capacity; failing to escalate a genuine interpretation or test-deviation issue creates a late-stage submission risk.

Use this triage model.

The CMVP FAQ summarizes the laboratory’s core obligation: it tests against applicable requirements, records results, and submits a written report when conformance is established; otherwise, it works with the vendor to resolve discrepancies before resubmission. The same division applies after validation if a credible third-party technical concern is raised.

What a good escalation package contains

Before asking the CSTL to seek CMVP guidance, prepare a bounded technical package. It should not be a message saying, “Please confirm compliance.”

Include:

• the module version, boundary, embodiment, platform, and claimed security level;
• the exact normative requirement, test requirement, SP 800-140 modification, and current IG item;
• the concrete implementation fact pattern;
• the vendor’s evidence locators, diagrams, and observed behavior;
• the CSTL’s assessment position;
• the specific question requiring an authority decision;
• the options considered and security impact of each; and
• the requested decision or clarification.

This is similar to preparing a well-bounded engineering nonconformance: the decision-maker needs the configuration, requirement, observed condition, safety or security significance, and proposed disposition. An escalation without these facts tends to return as a request for clarification rather than producing usable direction.

Worked example: approved-mode inconsistency

Consider a software cryptographic module for a satellite communications gateway. Its security policy says that approved mode blocks a legacy protocol. During laboratory testing, however, the protocol can be enabled through an undocumented runtime configuration flag.

The responsibility assignment is not ambiguous:

1. Vendor: owns the implementation defect or scope inconsistency. It must determine whether the function is to be removed, blocked in approved mode, excluded from the validated configuration, or otherwise controlled. It updates the build, configuration instructions, module specification, security policy, and regression evidence as appropriate.

2. CSTL: records the observed behavior, identifies the affected requirement and evidence items, evaluates the vendor’s correction, and retests the relevant configuration. The CSTL decides whether the corrected implementation and evidence support a conformance conclusion.

3. CMVP: does not normally need to decide a straightforward inconsistency between claimed and actual behavior. However, if the proposed solution relies on an unclear policy interpretation or on a deviation from prescribed assessment treatment, the CSTL should request CMVP guidance with the full fact pattern.

4. NIST and CCCS: act through the CMVP as joint Validation Authorities when a validation-policy decision is needed. The consultant should not frame the issue as a request for one authority to overrule the other.

Reusable work product: responsibility and escalation register

Add the following register beside your requirements-to-evidence matrix. A trace record explains why evidence is needed; this register explains who must move it forward.

A concise example entry might read:

Use the register in weekly vendor–CSTL meetings. The goal is not to burden the project with project-management language; it is to prevent three dangerous ambiguities:

• an evidence gap with no named vendor owner;
• a test finding that is “waiting on the lab” even though the vendor must correct the module; or
• a policy question that is being debated informally instead of escalated through the CSTL with a defined fact pattern.

Key takeaways

The CMVP lifecycle relies on a deliberate separation of duties:

• The vendor designs and produces the module, controls its configuration, supplies evidence, and corrects nonconformances.
• The CSTL independently tests and reviews the module, records results, prepares the submission, coordinates responses, and cannot test a module it designed or originally documented.
• The CMVP Validation Authorities, jointly managed by NIST and CCCS, review submissions, resolve authority-level questions, issue validation decisions, and publish certificates.
• Most defects are resolved through the vendor–CSTL loop. Escalate through the CSTL when an interpretation, test deviation, or CMVP decision is genuinely required.
• A responsibility and escalation register turns a static requirements trace into an executable validation plan.

Next, you will apply this ecosystem perspective to product claims: distinguishing a validated cryptographic module from a broader product that merely incorporates or uses validated cryptography.