Common Criteria, EUCC & eIDAS Certification
Common Criteria, EUCC and eIDAS in depth: the evaluation model, EAL claims, Protection Profiles, and how a PQC change travels from regulation to a certified device. Start with LM-065 for the fundamentals the schemes share.
Why this matters: In Europe a product meets Common Criteria three ways at once: as an international CCRA certificate, as an EUCC certificate under EU law, and as the evaluation behind an eIDAS qualified device. Reading the claim — EAL, augmentations, Protection Profile — is what tells you whether adding PQC is a change the certificate survives.
Start here: Open Decode the certificate claim and decode a Common Criteria claim — the EAL, each named augmentation, and what it does and does not cover.
Choose your learning path
No path selected — every section and workshop step counts toward completion. Pick a path to scope the module to one audience.
Practitioner orientation — not laboratory training. Not yet reviewed by an accredited lab or certification body.
Common Criteria (CC) is a framework for writing down security claims about an IT product and having an accredited laboratory check them. The criteria are published by the Common Criteria Recognition Arrangement (CCRA) participants as CC:2022, and by ISO/IEC as ISO/IEC 15408:2022. The evaluator follows the Common Evaluation Methodology, CEM:2022 (ISO/IEC 18045:2022). A certification scheme — a national one such as France’s ANSSI or Singapore’s CSA, or in the EU the EUCC scheme — oversees the laboratory and issues the certificate. The CCRA then decides which certificates its member countries accept from one another.
The question a CC certificate answers
Does this defined Target of Evaluation (TOE) meet the security functional and assurance claims in its Security Target — possibly while conforming to a Protection Profile?
Common Criteria does not say what a product must do. The Security Target does. CC supplies the vocabulary for writing those claims and the method for checking them.
The vocabulary you need
| Term | What it means | Where it comes from |
|---|---|---|
| Assets, threats, organisational security policies (OSPs), assumptions | The security problem the product addresses, and what it assumes about its environment | Security problem definition in the ST or PP |
| Target of Evaluation (TOE) | The exact product or product portion evaluated, with its version, configuration and guidance | Defined in the ST |
| TOE Security Functionality (TSF) | The parts of the TOE that the security requirements depend on | Defined in the ST |
| Security Target (ST) | The product-specific claims: threats, objectives, requirements, and how the TOE meets them | Written by the developer; a sanitised version is published |
| Protection Profile (PP) | Implementation-independent requirements for a class of products. PP-Modules and PP-Configurations combine PPs | Written by a user group, standards body or government; certified on its own |
| Security Functional Requirements (SFRs) | What the TOE does — for example FCS_COP.1 (cryptographic operation) | CC:2022 Part 2 |
| Security Assurance Requirements (SARs) | How much evidence and evaluator work backs the claims — classes ADV, AGD, ALC, ASE, ATE, AVA | CC:2022 Part 3 |
| Packages, including the EALs | Predefined sets of requirements; EAL1–EAL7 are assurance packages | CC:2022 Part 5 |
| Evaluation methods and activities | Product-class-specific tests; collaborative PPs (cPPs) define their own | CC:2022 Part 4 |
| ITSEF, certification body (CB), ETR | The lab evaluates and writes the Evaluation Technical Report (not public); the CB reviews it and issues the certificate and a public certification report | The scheme’s rules |
Claims live in the Security Target
The ST states the threats and objectives, the SFRs the TOE meets, the SARs it was evaluated against, and a TOE summary specification saying how each SFR is implemented. The evaluator works through the CEM work units for each SAR, using the developer’s evidence and their own testing. The certificate then says one narrow thing: this TOE, in this configuration, meets this ST at this assurance.
“This certificate applies only to this specific version of the product in its evaluated configuration.”
— ANSSI certificate ANSSI-CC-2025/09 (TrustWay Proteccio HSM), translated from French
Take the anchor product, Orrin N7 (fictional), a network HSM sold as an appliance and as a multi-tenant cloud service. Its ST might define the TOE as the appliance hardware, firmware and crypto library, and leave the client SDK and the cloud tenant-management plane outside. Everything outside the TOE is a claim the certificate cannot support. The cloud service would need its own TOE definition — or would simply not be covered.
Where cryptography sits
CC has no list of approved algorithms. Cryptography appears as SFRs from class FCS — mainly FCS_CKM (key management) and FCS_COP (cryptographic operation) — iterated once per algorithm or operation. A PP can constrain them. The EN 419221-5 HSM PP, for example, requires algorithms “approved for the identified purpose” and tells the ST author to consult the relevant national body. Schemes add their own rules: ANSSI analysed TrustWay Proteccio’s mechanisms against its own cryptographic guide, and EUCC uses the ECCG Agreed Cryptographic Mechanisms.
So: is ML-KEM in the certificate?
Read the ST’s FCS_COP iterations and the certification report. An assurance level never answers that question. A product can hold a high-assurance certificate for a version with no post-quantum algorithm at all — TrustWay Proteccio’s ST lists none (as of 24 September 2026).
Conformance to a Protection Profile
An ST that claims a PP must meet it in the way the PP demands. Both PPs studied in this module require strict conformance: the ST may add to the PP’s requirements but may not weaken or omit any of them. Some PPs require exact conformance, where the ST must reproduce the PP’s requirements. CC:2022 Part 5 notes that an ST claiming exact conformance cannot augment its EAL at all.
Who does what
| Role | Does | Example from a real record |
|---|---|---|
| Developer / sponsor | Writes the ST and evidence; pays for the evaluation | Entrust, for the nShield5s HSM |
| ITSEF (evaluation laboratory) | Evaluates against the CEM; writes the ETR | SGS Brightsight; SERMA and AMOSSYS |
| Certification body | Oversees the lab, reviews the ETR, issues certificate and report | CSA (Singapore), ANSSI (France); under EUCC, commercial CBs such as TrustCB |
| CCRA participants | Authorising members issue certificates; consuming members only recognise them | Recognition covers EAL1–2 plus ALC_FLR, or collaborative PPs (next section) |
Sources (read 24 September 2026): CC:2022 Part 1, Part 2, Part 3, Part 4, Part 5, CEM:2022; EN 419221-5 PP (v0.15); ANSSI certificate and report ANSSI-CC-2025/09 and CSA report CSA_CC_23004 (links in the Decode the certificate claim workshop step).
Check off all sections and mark this reading done.
Related modules
- FIPS 140-3 CertificationSame track · Hardware Infrastructure · Same migration phase · Shares ML-KEM, ML-DSA
- PCI CertificationSame track · Hardware Infrastructure · Same migration phase · Shares ML-KEM, ML-DSA
- Cryptographic Product Certification: FundamentalsSame track · Hardware Infrastructure · Same migration phase · Shares ML-KEM, ML-DSA
- PQC Hardware AccelerationSame track · Hardware Infrastructure · Shares ML-DSA, ML-KEM
Check your understanding
6 questions on Common Criteria, EUCC & eIDAS Certification, each with its answer and the reason.
Take the quizNext step
Produce the artifact: Vendor Scorecard BuilderThis module belongs to phase 7 (Vendor & Supply Chain); Vendor Scorecard Builder produces a deliverable of that phase in the Command Center.
Learning module content can be inaccurate. Please double-check its information. Report inaccuracies in PQC Today GitHub Discussions.