ISO/IEC 15408 (Common Criteria):

Overview

Common Criteria, adopted as ISO/IEC 15408:2022, is the internationally recognized framework for evaluating IT product security. Vendors specify security requirements in a Security Target, often built from a published Protection Profile, and an accredited testing laboratory independently verifies the product meets those claims. Certificates issued under the Common Criteria Recognition Arrangement are mutually recognized across all signatory nations, avoiding duplicate evaluations for the same product in each market.

Cryptography-specific Protection Profiles, and the Security Functional Requirements in Common Criteria’s FCS class, commonly assume the underlying cryptographic algorithms have already been validated through NIST’s Cryptographic Algorithm Validation Program (CAVP) or CMVP. NIAP Policy Letter #5 formalizes that relationship: a Common Criteria evaluation is not a substitute for CAVP or CMVP validation, it builds on top of it.

Why it matters

Common Criteria certification is frequently a literal procurement gate for government and defense buyers worldwide, not a matter of interpretation; many national procurement rules cite it directly as a baseline requirement for categories like network devices, VPN gateways, and mobile device management platforms.

Because most Protection Profiles fold in cryptographic assurance activities that assume the underlying algorithms are already CAVP or CMVP-validated, a gap in FIPS validation status becomes a gap in Common Criteria evaluation too. This directly couples this chapter to the FIPS 140-3 chapter earlier in this guide: a product cannot cleanly pass Common Criteria evaluation while its cryptographic module sits unvalidated or has slipped onto the CMVP Historical List.

How this maps to cryptography 

ISO/IEC 15408 (Common Criteria) addresses cryptography through several interlocking control areas. The key areas with direct cryptographic implications are:

Audit readiness

Assessments and examinations, whether self-conducted, performed by a regulator, or reviewed by an independent assessor, focus on demonstrated evidence rather than policy statements alone. Key areas that examiners and assessors commonly probe:

• Security Target Cryptographic Accuracy:  Does the Security Target accurately describe the cryptographic algorithms, modes, and key sizes actually implemented in the shipping product?
• Underlying CAVP/CMVP Status:  Do the algorithms and modules referenced in the Security Target hold current, active CAVP and CMVP validation?
• Protection Profile Assurance Activity Evidence:  Is there test evidence supporting every cryptographic assurance activity specified in the applicable Protection Profile?
• Configuration Management Documentation:  Does ALC-class documentation demonstrate control over the cryptographic components inside the evaluated boundary?
• Assurance Continuity Change Tracking:  Is there a process for evaluating whether a cryptographic library update or algorithm change triggers an Assurance Continuity review or full re-evaluation?
• Patch Signing and Version Matching:  Are patches issued against a certified product signed, and does the deployed version match what the certificate covers?

TAKE THIS TO MANAGEMENT

Common Criteria certification is often the literal gate that determines whether we can sell into a government or defense account, not a nice-to-have credential. And because most Protection Profiles assume our cryptography is already CAVP or CMVP validated, a gap in our FIPS validation status doesn’t just cost us federal sales directly, it also blocks or delays the Common Criteria evaluation that gates other deals.

The quiet risk is what happens after certification: a routine library update or algorithm patch can silently invalidate the evaluated baseline if we’re not tracking it against Assurance Continuity requirements. We need to know, for every certified product, exactly which cryptographic components sit inside that boundary and whether a given change needs a review before it ships.