Why can a gap in FIPS validation block Common Criteria certification?

Common Criteria cryptographic assurance often depends on validated modules and algorithms already being in place. If the underlying cryptography is unvalidated, or if a module has slipped onto the CMVP Historical List, the evaluation inherits that weakness. In practice, the product may still exist, but the certification path becomes slower, riskier, or temporarily unavailable for the targeted Protection Profile.

Why the FIPS gap changes the certification path

common criteria does not evaluate cryptography in a vacuum. If a target protection profile expects validated cryptographic services, then the certification effort depends on a module, algorithm, or implementation path that can be trusted under the relevant assurance regime. When that foundation is missing or has been moved to the CMVP Historical List, the evaluator must treat the cryptographic claim as unresolved rather than simply assume it will be accepted later.

That is why the gap is usually procedural as much as technical. The product can still be real and functional, but the evaluation cannot safely treat the crypto layer as a settled dependency until the validation status is clear enough for the certification boundary being assessed.

What evaluators and vendors are actually waiting to see

The issue is not just whether cryptography exists, but whether the specific cryptographic path is acceptable for the claim being made. A Common Criteria evaluation may rely on validated modules to support assurance claims about secure communications, key handling, or enforcement mechanisms, and the absence of a current validation can force the lab to narrow scope, defer evidence, or ask for a different implementation path.

For vendors, that means the certification schedule is tied to crypto readiness very early in the project. If the module is unvalidated, expired, or otherwise out of step with the expected assurance story, the certification work often shifts from validation testing to dependency replacement, scope adjustment, or rework of the security target itself.

Why historical status can be as disruptive as no validation at all

A module on the CMVP Historical List is not usually a live certification asset for new claims. Even if the implementation once had a valid standing, its historical status signals that it may no longer support the present evaluation path the way the program expects. That can matter just as much as a module that was never validated, because the evaluator is looking for current, defensible assurance rather than legacy comfort.

In practice, this creates a timing problem. If the crypto dependency is central to the protection profile, the certification path can stall until the vendor swaps in a current validated component or demonstrates a different acceptable basis for the claim.

Risk and Threat Considerations

When certification depends on a cryptographic foundation that is not currently validated, the main risk is assurance drift: the product may appear ready while its compliance basis is not. The failure mode is usually not immediate compromise, but a delayed, weakened, or rejected evaluation path that can force redesign, retesting, or a narrower certification scope.

Failure mechanism: The evaluation inherits the status of the underlying cryptographic module or algorithm, so an expired, historical, or otherwise unvalidated dependency can break the assurance chain for the target Protection Profile.

Impact: Certification can be delayed or blocked, the scope of what is certifiable may shrink, and the vendor may have to replace the crypto component or restart portions of the evidence trail before the product can progress.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	SC-13 — Cryptographic Protection	FIPS status affects whether cryptographic protection can support the assurance claim.
	IA-5 — Authenticator Management	Validated crypto often underpins credential and token handling in evaluated products.
Recommendation — Use SC-13 only for cryptographic functions that must remain assured under evaluation. Manage authenticators so their crypto dependencies remain current and supportable.
ISO/IEC 27001:2022	A.8.24 — Use of cryptography	The question centers on whether cryptographic status can sustain a certification path.
Recommendation — Document cryptographic dependencies and verify their approval status before certification.
NIST CSF 2.0	PR.DS-01 — Data-at-rest is protected	Validated cryptography is often part of the protection story for sensitive data.
	GV.SC-01 — Cybersecurity supply chain risk management processes are established	Historical or unvalidated crypto is a dependency risk that can affect certification readiness.
Recommendation — Confirm the protection method is acceptable for the assurance claim being made. Track third-party cryptographic dependencies as part of assurance and certification planning.

Practitioner Guidance

What to verify: Confirm the exact cryptographic module, algorithm set, and deployment boundary that the certification claim depends on. Then verify current validation status against the intended evaluation scope, not just against a product marketing statement or an old approval record.

Decision rule: If the crypto path is material to the target Protection Profile, treat historical or expired validation as a certification risk, not a documentation issue. If the crypto is only incidental, the impact may be limited to a narrower claim set rather than a full program delay.

Practitioner takeaway: The fastest way to avoid certification surprise is to treat cryptographic validation as a dependency of the assurance case, not as a later compliance checkbox.