Back to DashboardHardware InfrastructurePhase 7 · Vendor & Supply Chainadvanced35–76 min, depending on your path

Common Criteria, EUCC & eIDAS Certification

Common Criteria, EUCC and eIDAS in depth, with distinct roles: CC supplies evaluation criteria; EUCC is an EU scheme using CC; eIDAS supplies separate legal requirements for applicable trust services and devices. Choose the CC, EUCC or eIDAS path below.

Why this matters: In Europe, a Common Criteria evaluation may support an EUCC certificate and, for applicable qualified electronic-signature or seal devices, form part of an eIDAS conformity chain. CCRA recognition is separate and depends on the certificate, scheme, assurance claim and recognition rules. Reading the exact claim 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.

Practice in the Simulation

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. Reviewed and signed off by the PQC Today owner on 1 November 2026. Not yet reviewed by an accredited laboratory or certification body.

General security practitioner route

Focus on what each certificate can support, where its boundary stops, and which claims need confirmation. Exact component and submission details remain available as cited reference material.

FIPS 140-3, Common Criteria and EUCC are not interchangeable

FIPS 140-3 — cryptographic module requirements
CMVP validates a defined cryptographic module against FIPS 140-3. When adding PQC, check the module’s approved services, algorithm validations and applicable CMVP change requirements.
Common Criteria — evaluation criteria
CC provides criteria for evaluating a defined product (the TOE) against its Security Target and any claimed Protection Profile. When adding PQC, check which security claims, requirements and evaluation evidence change. Identify the certification scheme separately.
EUCC — an EU certification scheme using Common Criteria
For an EUCC evaluation, apply CC together with EUCC’s scheme-specific rules and applicable cryptographic guidance. EUCC rules are not automatically requirements for every CC evaluation. eIDAS is a separate legal context, relevant only where its requirements apply.

eIDAS — device and trust-service requirements (optional)

A passing algorithm test does not establish module validation or product certification. Evidence accepted in one context does not automatically satisfy another.

Sources: NIST FIPS 140-3; CC:2022 Part 1; ENISA EUCC overview.

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 — for example France’s ANSSI or Singapore’s CSA — oversees the laboratory and issues the certificate. The CCRA then decides which certificates its member countries accept from one another.

Under EUCC: in the EU, certificates are issued under the EUCC scheme, which adds its own rules on top of Common Criteria (see the EUCC path).

Use CC:2022 R1 with its mandatory errata

A current evaluation baseline is not the five CC:2022 R1 documents alone. The Common Criteria portal marks the applicable CC:2022 and CEM errata and interpretations as mandatory; this module was checked against the portal's v1.2 package on 16 October 2026. Record that errata version in the evaluation baseline and re-check it before starting or changing an evaluation.

Common Criteria publications and mandatory errata

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

  • Assets, threats, organisational security policies (OSPs), assumptions
    What it means
    The security problem the product addresses, and what it assumes about its environment
    Where it comes from
    Security problem definition in the ST or PP
  • Target of Evaluation (TOE)
    What it means
    The exact product or product portion evaluated, with its version, configuration and guidance
    Where it comes from
    Defined in the ST
  • TOE Security Functionality (TSF)
    What it means
    The parts of the TOE that the security requirements depend on
    Where it comes from
    Defined in the ST
  • Security Target (ST)
    What it means
    The product-specific claims: threats, objectives, requirements, and how the TOE meets them
    Where it comes from
    Written by the developer; a sanitised version is published
  • Protection Profile (PP)
    What it means
    Implementation-independent requirements for a class of products. PP-Modules and PP-Configurations combine PPs
    Where it comes from
    Written by a user group, standards body or government; certified on its own
  • Security Functional Requirements (SFRs)
    What it means
    What the TOE does — for example FCS_COP.1 (cryptographic operation)
    Where it comes from
    CC:2022 Part 2
  • Security Assurance Requirements (SARs)
    What it means
    How much evidence and evaluator work backs the claims — classes ADV, AGD, ALC, ASE, ATE, AVA
    Where it comes from
    CC:2022 Part 3
  • Packages, including the EALs
    What it means
    Predefined sets of requirements; EAL1–EAL7 are assurance packages
    Where it comes from
    CC:2022 Part 5
  • Evaluation methods and activities
    What it means
    Product-class-specific tests; collaborative PPs (cPPs) define their own
    Where it comes from
    CC:2022 Part 4
  • ITSEF, certification body (CB), ETR
    What it means
    The lab evaluates and writes the Evaluation Technical Report (not public); the CB reviews it and issues the certificate and a public certification report
    Where it comes from
    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, for example, analysed TrustWay Proteccio’s mechanisms against its own cryptographic guide. Under EUCC: the ECCG Agreed Cryptographic Mechanisms play this role (see the EUCC path).

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).

For a worked example of how three post-quantum requirements could be written in a Security Target, see the section “PQC under EUCC today (ACM v2)” on the EUCC path.

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

  • Developer / sponsor
    Does
    Writes the ST and evidence; pays for the evaluation
    Example from a real record
    Entrust, for the nShield5s HSM
  • ITSEF (evaluation laboratory)
    Does
    Evaluates against the CEM; writes the ETR
    Example from a real record
    SGS Brightsight; SERMA and AMOSSYS
  • Certification body
    Does
    Oversees the lab, reviews the ETR, issues certificate and report
    Example from a real record
    CSA (Singapore), ANSSI (France)
  • CCRA participants
    Does
    Authorising members issue certificates; consuming members only recognise them
    Example from a real record
    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; Common Criteria portal mandatory CC:2022/CEM errata and interpretations v1.2; 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

In the Industry Landscape

Check your understanding

6 questions on Common Criteria, EUCC & eIDAS Certification, each with its answer and the reason.

Take the quiz

Next step

Produce the artifact: Vendor Scorecard Builder

This 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.