Common Criteria (CC) is the international standard for security evaluation of information technology products. It was adopted as ISO/IEC 15408 in 1999 and has been revised through several editions, with the current version being CC:2022 published as ISO/IEC 15408-1 through 15408-5 (2022). When governments procure cryptographic products that handle sensitive but not classified information, they often require a CC certificate at a specified Evaluation Assurance Level (EAL) or against a specified Protection Profile.
As the post quantum transition has accelerated, Common Criteria evaluation schemes around the world have started accepting and in some cases requiring ML-KEM, ML-DSA, and the rest of the NIST PQC algorithm catalog. This article explains where PQC fits in CC evaluation, how the EAL ladder relates to algorithm validation, and how the international Common Criteria Recognition Arrangement (CCRA) handles cross border recognition of PQC capable products.
What Common Criteria Is
Common Criteria is a framework for stating security requirements (in Protection Profiles or Security Targets), evaluating that a product meets those requirements, and certifying the result. The framework distinguishes between the security functional requirements (SFRs), which describe what the product does, and the security assurance requirements (SARs), which describe how thoroughly the developer and evaluator demonstrate that the product does it.
A complete CC evaluation produces a Security Target document, an evaluation technical report from a licensed lab, and a certificate from a national scheme operator. The certificate identifies the product, the version, the Security Target, and the assurance package (typically an EAL number or a Protection Profile claim).
EAL Ladder and What It Means
EAL numbers run from EAL 1 (functionally tested) through EAL 7 (formally verified design and tested). The middle tier most commonly seen in commercial product certification is EAL 4 augmented (often written EAL 4+) which requires methodically designed, tested, and reviewed assurance components.
For most cryptographic products in 2026, the relevant target is not a raw EAL number but a Protection Profile claim. The CCRA limits mutual recognition to evaluations at EAL 2 or claims against a recognized Protection Profile, so vendors targeting global sales typically choose Protection Profile based evaluation rather than chasing high EAL numbers.
EAL is not directly a cryptographic strength measure. A product can hold EAL 4 with weak cryptography or with strong cryptography. The cryptographic algorithms are stated in the SFR text inside the Protection Profile or Security Target, not in the EAL number.
Where PQC Algorithms Show Up in CC Evaluation
PQC algorithms appear in the FCS (Cryptographic Support) family of SFRs. The relevant SFR clauses include:
- FCS_COP.1 (Cryptographic Operation) for performing encryption, decryption, signing, verification, and hashing
- FCS_CKM.1 (Cryptographic Key Generation) for generating keys
- FCS_CKM.2 (Cryptographic Key Distribution) for getting keys from where they were generated to where they are used
- FCS_CKM.4 (Cryptographic Key Destruction) for zeroizing keys when no longer needed
- FCS_RBG_EXT.1 (Random Bit Generation) for the underlying RNG
For ML-KEM, the SFR text typically reads "the TOE shall perform key encapsulation in accordance with FIPS 203 with security parameter ML-KEM-768 or ML-KEM-1024". For ML-DSA, the analogous text references FIPS 204 with parameter ML-DSA-65 or ML-DSA-87. For SLH-DSA, the reference is FIPS 205.
The Protection Profile or Security Target then lists the specific test cases the evaluator will run. For ML-KEM, the test cases include the NIST CAVP known answer tests, decapsulation correctness checks across thousands of random ciphertexts, and seed determinism verification when seeds are reused. For ML-DSA, tests cover signature determinism with a fixed seed, signature verification correctness, and rejection sampling correctness.
ISO/IEC 15408:2022 Updates
The 2022 revision of ISO/IEC 15408 split the standard across five parts (introduction, evaluation methodology, security functional components, security assurance components, and pre defined packages). The structural revision did not directly touch cryptography, but it created a cleaner home for new algorithm specifications to land.
Working groups under ISO/IEC JTC 1/SC 27 are coordinating updates to align CC SFR language with NIST FIPS 203, 204, and 205. The updates include cross references to ISO/IEC 18033-3 and 18033-4 (encryption algorithms) and ISO/IEC 14888-3 (digital signatures) where appropriate.
CCRA and Mutual Recognition
The Common Criteria Recognition Arrangement is a multilateral agreement among more than thirty countries. Under the CCRA, certificates issued by an authorizing nation are recognized by consuming nations up to a defined ceiling, currently EAL 2 augmented or claims against a CCRA recognized Protection Profile (a "collaborative Protection Profile" or cPP).
For PQC capable products, the recognition path runs through cPPs maintained by the CCRA's international Technical Communities (iTCs). The Network Devices iTC, Application Software iTC, and Mobile Devices iTC are most relevant. Each iTC has been updating its cPP and supporting documents to incorporate ML-KEM and ML-DSA.
National schemes that can issue CCRA recognized certificates include NIAP (United States), BSI (Germany), ANSSI (France), CCN (Spain), CSEC (Sweden), JISEC (Japan), and several others. We covered the United States NIAP path in detail in our NIAP and PQC article.
German BSI and ANSSI Approaches
BSI (Federal Office for Information Security in Germany) maintains a national cryptographic catalog called Technische Richtlinie BSI TR-02102, which has been updated to recommend Kyber (ML-KEM) and Dilithium (ML-DSA) for new German federal systems. BSI runs CC evaluations through its CC scheme and has published guidance on incorporating PQC into Security Targets.
ANSSI (French national agency) maintains the Référentiel Général de Sécurité (RGS) and the Premier visa de sécurité framework. ANSSI has published guidance recommending hybrid PQC (combining a classical algorithm with a post quantum algorithm) for the migration period. France's preferred approach is hybrid by default, more strongly than the United States CNSA 2.0 which permits but does not require hybrid.
Hybrid Key Exchange in CC Evaluation
Hybrid constructions are now appearing in cPPs. The TLS supporting documents reference the IETF draft draft-ietf-tls-hybrid-design and the named groups X25519MLKEM768 and SecP256r1MLKEM768. The cPP language is structured so a product can claim either pure classical TLS, pure PQC TLS, hybrid TLS, or all three. The evaluator runs wire format checks against the relevant draft or RFC version.
The choice of hybrid versus pure PQC is left to the product, with national schemes expressing preferences in their non binding guidance. France prefers hybrid. Germany and the United States permit either. Smaller schemes generally follow one of the major schemes' lead.
Random Number Generation
Random number generation is a frequent fail point in CC evaluation. ML-KEM-1024 requires fairly long seeds (about 64 bytes) and the SFR text demands a NIST SP 800-90A compliant deterministic random bit generator (DRBG) seeded from an SP 800-90B compliant entropy source.
CC evaluators will check the entropy source against published characterization tests, examine the DRBG instantiation, and run statistical tests on output. Where a product uses an operating system supplied RNG, the evaluator may rely on the OS's separately certified RNG, but the product must document the dependency in its Security Target.
Cryptographic Module Validation as a Sub Component
A common pattern is that the cryptographic operations within a CC evaluated product are performed by a separately validated cryptographic module under FIPS 140-3 / ISO/IEC 19790. The CC evaluation then relies on the module's CMVP certificate for the algorithm correctness claim, and the CC evaluator focuses on integration, key management, and configuration.
This pattern is efficient for vendors because it lets them swap cryptographic modules without re evaluating the whole product, as long as the new module has equivalent CMVP certification. We discuss CMVP and FIPS 140-3 in detail in our CMVP article.
Documentation Burden
CC evaluation is documentation heavy. The Security Target, Functional Specification, TOE Design, and operational guidance documents are all reviewed by the evaluator. Adding PQC algorithms increases documentation by roughly twenty to thirty percent because the algorithms are new, the wire formats are different, the test vectors are unfamiliar, and the operational guidance has to walk through new key management procedures.
Vendors planning their first PQC capable CC evaluation should expect this overhead and budget accordingly. Reusing existing documentation patterns from previous evaluations reduces effort, and the international iTCs are publishing template Security Target language that vendors can adapt.
Side Channel Resistance
CC evaluations at EAL 4 augmented and above often include side channel attack resistance components from the AVA family (vulnerability assessment). Lattice based PQC algorithms have specific side channel concerns. ML-KEM decapsulation timing can leak information about the secret key if not carefully implemented in constant time. ML-DSA rejection sampling can leak through power analysis if rejection rates depend on secret material.
Modern implementations (including reference code from NIST and the formally verified implementations from teams like Cryspen and HACL) address these concerns at the software level. Hardware accelerators add another layer of side channel hardening. CC evaluators check that the product's implementation either runs on a side channel hardened module or includes documented mitigations.
Cost and Schedule for a PQC Capable CC Evaluation
A first time CC evaluation at EAL 2 augmented or against a cPP typically costs between fifty thousand and two hundred thousand US dollars depending on product complexity, plus the lab and certification fees. PQC adds roughly ten to twenty percent on top of a baseline classical only evaluation. Schedule wise, twelve to eighteen months from kickoff to certificate is typical, with longer timelines if the product targets multiple Protection Profiles or higher EAL levels.
Subsequent evaluations of new versions are cheaper because the documentation foundation exists. Vendors that plan ongoing CC certification typically budget twenty to thirty percent of the initial cost for each major version refresh.
What This Means for Buyers
Procurement officers buying CC evaluated products should look for:
- A current CC certificate from a CCRA member nation
- Coverage of the relevant Protection Profile or cPP at the version that includes PQC selections
- Specific PQC algorithm selections in the Security Target
- An assurance package at EAL 2 or above for CCRA recognition
Buyers should be cautious of vendors who advertise "PQC support" but cannot point to PQC SFR claims in their Security Target. Marketing language is not a substitute for evaluated functionality.
FAQ
Q: What is the difference between Common Criteria and FIPS 140-3? A: FIPS 140-3 evaluates cryptographic modules in isolation. Common Criteria evaluates products in their operational context, including the cryptographic module, the application logic, the configuration interfaces, and the key management. CC and FIPS 140-3 complement each other.
Q: Do I need both CC and FIPS 140-3 to sell to the United States government? A: It depends on the buying agency. NSS programs typically require both. Federal civilian programs often require FIPS 140-3 plus a NIAP certificate against a relevant Protection Profile.
Q: Are PQC algorithms required by Common Criteria today? A: They are permitted and increasingly preferred, but not yet universally required. Some Protection Profiles allow either classical or PQC. The trend is toward requiring PQC by 2027 or 2030 in most active Protection Profiles.
Q: Can a product claim hybrid PQC and classical encryption simultaneously? A: Yes. The Security Target lists the supported algorithm combinations, and the evaluator tests each one.
Q: How does CCRA mutual recognition handle PQC? A: PQC capable products evaluated against a CCRA recognized cPP at EAL 2 augmented or below are mutually recognized across CCRA member nations. National specific evaluations above the CCRA ceiling require separate national certifications.
Sources
- ISO/IEC 15408-1:2022, Information Security, Cybersecurity and Privacy Protection — Evaluation Criteria for IT Security. https://www.iso.org/standard/72891.html
- Common Criteria Recognition Arrangement. https://www.commoncriteriaportal.org
- NIST FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA). https://csrc.nist.gov/projects/post-quantum-cryptography
- BSI TR-02102, Cryptographic Mechanisms. https://www.bsi.bund.de/EN/Topics/Industry_CI/standards-and-certification/cryptographic-mechanisms/
- ANSSI Référentiel Général de Sécurité (RGS). https://cyber.gouv.fr/
- NIAP CCEVS, https://www.niap-ccevs.org
Related Articles
- NIAP and PQC
- CMVP and FIPS 140-3
- NIST FIPS Guide
- Hybrid Encryption Explained
- PQC for Government and Defense
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.