The European Common Criteria-based cybersecurity certification scheme — EUCC — entered into force on 27 February 2025 as Commission Implementing Regulation (EU) 2024/482, the first scheme adopted under the EU Cybersecurity Act's Article 49 framework. Six weeks later, the French National Cybersecurity Agency (ANSSI) issued the scheme's first two certificates, one of them for Thales's Smart Tachograph G2 smart card. The launch is the first concrete output of nearly a decade of post-Common Criteria Recognition Arrangement work to unify Europe's hardware and complex-software assurance regime — and it has significant implications for security evaluation labs, product vendors, and the procurement teams that buy from them.
What changed in February 2025?
Until EUCC entered into force, hardware and complex-software certification in Europe was governed by the legacy Common Criteria Recognition Arrangement (CCRA) and the SOG-IS Mutual Recognition Agreement (MRA), under which a handful of national schemes — France's CSPN/CC, Germany's BSI scheme, the Netherlands' NSCIB, Spain's STIC — issued certificates that other SOG-IS participants recognised. The arrangement worked but was fragmented: each national scheme published its own protection profiles, certificate registries, and surveillance practices.
The EUCC absorbs the SOG-IS legacy into a single Union-wide scheme. Five structural changes are most consequential:
- A single EU-level certificate is issued under a Union-wide registry maintained by ENISA, replacing the patchwork of national certificate listings.
- The scheme operates under ISO/IEC 15408:2022 (Common Criteria v3.1 R5 / CC:2022) as the substantive evaluation standard, with a transitional regime allowing the older ISO/IEC 15408:2008 series until 31 December 2027.
- Conformity assessment bodies (CABs) — including IT Security Evaluation Facilities (ITSEFs) and Certification Bodies — must be accredited and notified under a Union framework, with ENISA maintaining the public list.
- Two assurance levels are defined: "substantial" (corresponding broadly to EAL2 with attack potential Basic, and EAL3 with Enhanced Basic) and "high" (EAL4 and above, with Moderate or High attack potential), aligned with Article 52 of the Cybersecurity Act.
- Patch management requirements are formalised at scheme level, including how vendors must handle vulnerability disclosure and certificate maintenance for the lifetime of the certified product.
Who is in scope and why does this matter beyond smart cards?
EUCC is voluntary in 2025-2026 and applies to any "ICT product" that a manufacturer wishes to certify — historically dominated by smart cards, hardware security modules, secure elements, qualified signature creation devices, and tachograph systems. The scheme's importance now extends well beyond these traditional categories because of two adjacent legal acts:
- Under the eIDAS 2 framework, qualified electronic signature creation devices, qualified trust service provider HSMs, and EUDI Wallet authentication devices may be required to hold an EUCC certificate at the "high" assurance level.
- Under the EU Cyber Resilience Act, the Commission can, by delegated act, make European cybersecurity certification mandatory for specific product categories. The first candidates for mandatory certification — likely industrial control systems, smart meters, and certain network equipment — are being scoped through 2025-2026, and EUCC is the most mature scheme to absorb them.
In practice, any vendor selling to the EU public sector, to qualified trust service providers, or to operators of essential services in regulated sectors should expect procurement clauses requiring EUCC by the end of the decade.
How does the certificate lifecycle work?
The lifecycle is structured by the implementing regulation's annexes and aligned with CC:2022 conventions. Five phases:
| Phase | Actor | Key artefacts | |---|---|---| | Preparation | Manufacturer | Security Target, claimed protection profile, evidence portfolio | | Evaluation | ITSEF (accredited CAB) | Evaluation Technical Report (ETR), attack-potential analysis | | Certification | Certification Body | EUCC certificate, certification report, public summary | | Maintenance | Manufacturer + CB | Patch management procedure, vulnerability disclosure, periodic review | | Surveillance / Reassessment | CB + competent authority | Renewal decisions, withdrawal where compromised |
Each EUCC certificate is published on the ENISA EUCC registry with a unique certificate identifier, the target of evaluation, the assurance level, and the link to the certification report. Withdrawals and suspensions are also public — a meaningful change from some legacy schemes, where retraction was opaque.
What about patch management?
Patch management has historically been one of Common Criteria's weakest points. A certificate would freeze the evaluated configuration; any post-certification security patch invalidated the certificate unless the vendor went through full re-evaluation. EUCC formalises a patch management procedure derived from the SOG-IS Common Criteria Patch Management requirements: a vendor can declare a patch management baseline at certification time, evaluate the procedure once, and apply patches that meet the declared baseline without invalidating the certificate.
This procedure must be documented in the Security Target, evaluated as part of the ALC (life-cycle) family, and surveilled by the certification body. The result is a meaningful gain in agility for software-heavy products — including network firewalls, secure-by-design IoT controllers, and HSMs that increasingly run general-purpose firmware.
How does it relate to the CRA?
The CRA explicitly recognises European cybersecurity certification under the Cybersecurity Act as a route to demonstrating presumption of conformity with the CRA's essential requirements (Annex I). Article 27(8) of the CRA allows manufacturers to use an EUCC certificate at the appropriate assurance level as evidence of compliance with the CRA security requirements for the certified scope.
The interplay matters because the CRA applies broadly to all products with digital elements from 11 December 2027 (with reporting obligations from September 2026), while EUCC is voluntary except where specifically mandated. Vendors of higher-risk product categories — "important" and "critical" under CRA Annex III and IV — are likely to find EUCC certification the cleanest compliance route. Vendors of lower-risk products will continue to self-assess against CRA Annex I.
CRA + EUCC interaction (manufacturer path)
+----------------+ if Annex III "important" +-----------------+
| Annex I |-----------> conformity module B/C ----->| EUCC certificate|
| essential reqs | (notified body) | (substantial+) |
+----------------+ +-----------------+
|
| Annex IV "critical"
v
+----------------+
| Mandatory EUCC | <----- Commission delegated act
| "high" |
+----------------+
What should defenders and procurement do now?
For manufacturers, four steps cover the immediate gap:
- Map your product roadmap against CRA Annexes III and IV. If any product is "important" or "critical," start engaging an accredited ITSEF now; queue times at the major French and German labs are already 9-12 months.
- Adopt CC:2022 protection profiles where available. Older PP-conformance claims (CC:2008) remain valid until 2027 but become a liability in procurement RFPs from public sector buyers.
- Operationalise patch management against the EUCC scheme template, including a vulnerability disclosure procedure consistent with ISO/IEC 29147 and 30111.
- Treat the certification report as procurement collateral. Buyers in regulated sectors increasingly require the public report and a vendor attestation that the deployed configuration matches the evaluated one.
For buyers — particularly OES under NIS2 — the EUCC registry is becoming the canonical reference. Procurement clauses should require a current EUCC certificate, a published certification report, and a structured vulnerability disclosure policy where the product is for critical infrastructure use.
How Safeguard Helps
Safeguard ingests EUCC certification reports and protection profile claims into the product registry, so procurement teams can validate that a vendor's claimed assurance level matches the product version actually deployed. SBOMs anchored to certified product baselines flag drift when a deployed binary differs from the evaluated configuration — the gap where most certificate-relevance arguments fail in practice. Griffin AI reachability analysis surfaces whether a CVE published against a certified product affects code paths that were evaluated, helping vendors decide whether a maintenance update or a re-evaluation is the right call. Policy gates enforce procurement clauses that require valid EUCC certificates for in-scope product categories, blocking purchases or deployments that lack the required certification. The compliance automation module produces the cross-walk between CRA Annex I requirements and EUCC evaluation evidence that vendors will need when they pursue Article 27(8) presumption of conformity.