EUCC Look Back: What the Scheme’s Full Maturity Means for European Security Assurance and Market Compliance

A buyer asks for an EUCC certificate. The manufacturer provides a Common Criteria evaluation report or a certificate issued under a national scheme, while its internal regulatory or compliance team refers to the Cyber Resilience Act. Everyone may be discussing legitimate security and compliance work, but they may not be discussing the same certification scheme, product boundary, or assurance claim.

That distinction matters because the European Common Criteria-based cybersecurity certification scheme, known as EUCC, is operating under Commission Implementing Regulation (EU) 2024/482. The regulation became applicable on 27 February 2025. EUCC certificates are now being issued by certification bodies (CBs), with evaluations performed by accredited and, where necessary, authorized Information Technology Security Evaluation Facilities (ITSEFs). ENISA maintains the scheme material, and national authorities (NCCAs) are developing the oversight and peer review arrangements intended to support consistent implementation across Europe.

The European Commission’s framework overview, last updated January 22, 2026, reports that 27 conformity assessment bodies had been notified and that 16 certificates had been issued during the first year of transition with national schemes. The wording matters. Those figures do not, by themselves, show that all 16 certificates were issued under EUCC after February 27, 2025. Buyers and manufacturers should check the ENISA certificate register for the current position.

What EUCC Maturity Means in Practice 

Calling EUCC “mature” requires care because the term has no formal legal definition. Here, it means the scheme has moved beyond publication into practical operation: bodies are available, certificates are being issued, technical material is maintained, and lifecycle procedures are developing.

Those foundations are in place, although availability may still vary by product category, technical domain, assurance level, and Member State. The practical questions are what a certificate covers, how to select an assurance level, and when EUCC evidence can support a CRA conformity route.

How EUCC Moved From Framework to Operating Scheme 

EUCC did not appear from nowhere. It was built on nearly three decades of Common Criteria experience in Europe and drew heavily on the SOG-IS Mutual Recognition Agreement, which had already supported high-assurance evaluations in several Member States. ENISA developed a candidate scheme with an ad hoc working group before the European Commission adopted the final implementing regulation.

 Here is how design shifted to operation:

The sequence matters. Adoption did not make every project straightforward. Manufacturers still need a body with the right technical scope, evaluators need current methodologies, buyers need to understand certificate limits, and regulators need comparable oversight.

The operating model is clear: the applicant defines the product and supplies evidence, the ITSEF evaluates it, the certification body issues the certificate, and the National Cybersecurity Certification Authority supervises or authorizes the system where required.

What an EUCC Certificate Actually Covers

 

 

ENISA points to technological components such as chips and smartcards, along with hardware and software. Depending on the product category and Security Target, a manufacturer may therefore be dealing with a secure element, network device, operating system, or specialized security software. The ENISA EUCC overview sets out the scheme’s scope and certification process.

The certificate is tied to a defined Target of Evaluation, or TOE. That target may be a complete product or a defined part of a product. It is assessed against a Security Target, which describes the security problem, intended use, security objectives, and security requirements selected for the evaluation. Under EUCC, the Security Target can be defined by the applicant or can incorporate a certified Protection Profile where the product falls within that profile’s category. A Protection Profile is useful when a product category has common security requirements, but it is not required for every EUCC certification.

For a document-level view of the process, CCLab’s Common Criteria evaluation guide and checklist is updated for the EUCC scheme and walks through the core materials and evaluation stages.

Here is where market discussions often become too broad. An EUCC certificate does not certify a company’s entire cybersecurity program. It does not automatically cover every product in a portfolio. It does not cover a cloud service, mobile application, management console, or later product version simply because they are connected to the certified product. Those elements need to be included in the certification scope, addressed through dependencies and assumptions, or assessed separately.

The certificate’s boundary is therefore as important as its assurance level. A certificate for a secure element is a meaningful result, but it is not automatically a certificate for the passport, payment terminal, identity wallet, or wider system in which that element is used. A certificate for an operating system does not automatically certify every application that runs on it.

That limitation is not a weakness in the scheme, but rather how a technical assurance claim remains testable. The problem begins when a narrowly scoped certificate is presented as though it were a statement about an entire connected system.

What Substantial and High Assurance Mean 

 

 

Under EUCC, the assurance level is determined through the scheme’s defined Common Criteria packages and vulnerability assessment requirements. A national Common Criteria certificate with an AVA_VAN result is not automatically an EUCC certificate.

Practical differences are more complex than the labels suggest. High assurance requires a different level of vulnerability analysis, evaluator competence, attack potential assessment, and oversight. Assuming simply Substantial assurance with a longer checklist is wrong. Availability also depends on the product category, technical domain, Protection Profile, and evaluation methodology that apply to the project. Manufacturers should confirm the applicable national requirements with the relevant National Cybersecurity Certification Authority before selecting a body.

For a closer look at the additional work behind the High level, our article overview of high assurance EUCC certification examines what changes beyond a traditional Common Criteria project.

Manufacturers should also avoid treating Evaluation Assurance Levels, or EALs, as a substitute for the EUCC assurance level. An EAL describes a package of evaluation requirements. AVA_VAN describes the depth of vulnerability analysis. Neither label, viewed in isolation, substitutes for reading the EUCC certificate, Security Target, assurance package, product scope, and certificate conditions. “EAL4+” on its own does not tell a buyer whether the product has an EUCC Substantial or High claim.

QIMA’s technical overview of mapping EUCC to Common Criteria goes deeper into how EALs, AVA_VAN, and evaluation requirements fit together.

The question manufacturers should ask themselves is  “Which level is proportionate to the product’s intended use, threat model, regulatory route, and customer requirement?” Selecting High when the product does not need it can add time and cost without improving the market outcome. Selecting Substantial when a procurement authority, sector rule, or risk profile requires stronger resistance creates a different problem.

How EUCC Certificates Are Maintained Over Time

An EUCC product certificate may be valid for up to five years, but the certificate period does not remove lifecycle responsibilities. Manufacturers must continue monitoring, managing, and disclosing vulnerabilities. A minor update may follow assurance-continuity procedures. A change to the TOE, security functionality, or operating environment may require additional evaluation, a scope change, or a new certificate.

The December 2025 amendment introduced rules for ICT product series certification and assurance continuity. Those rules matter to manufacturers with related products, variants, or planned releases, but they do not make a product family an unlimited certification shortcut. The manufacturer still needs to show what is shared, what differs, and whether the original assurance claim remains valid.

What EUCC Means for Market Compliance The strongest market benefit of EUCC is predictability. An EUCC certificate is designed to provide recognition across the EU within the scheme’s scope and conditions. A manufacturer selling an in-scope ICT product in several EU countries should not have to rebuild the certification case for each national market. That does not make the certificate sufficient for every buyer, regulator, or sector rule. EUCC is voluntary at the scheme level, although another EU law, national measure, procurement rule, or contract may make certification necessary. The product may also be subject to the Cyber Resilience Act (CRA), the Radio Equipment Directive (RED), medical device rules, or sector-specific security requirements. EUCC is best understood as a common assurance route, not as a universal compliance passport. For a buyer, the useful question is not whether a supplier has an EUCC logo. The buyer should check:

• certificate number and issuing body

• exact product and version

• Target of Evaluation

• evaluated configuration 

• assurance level

• certificate validity

• assumptions and guidance

• maintenance or assurance-continuity status

A product may be certified, yet the buyer may still deploy it outside the assumptions and guidance stated in the certification documentation. For a manufacturer, the commercial value depends on the same details. A certificate becomes a stronger procurement asset when sales, engineering, regulatory, and security teams describe the same scope. If one team presents it as covering the complete platform while another knows it covers only a component, it creates confusion instead of trust. There is also a geographic limit. Recognition under the Common Criteria Recognition Arrangement depends on the applicable CCRA rules and certificate conditions. It should not be described as automatic worldwide acceptance or full mutual recognition between EUCC and the CCRA. How EUCC Relates to the Cyber Resilience Act (CRA) The Cyber Resilience Act (CRA) is why EUCC is receiving attention beyond the Common Criteria community. The CRA creates mandatory cybersecurity obligations for products with digital elements, covering design, development, maintenance, vulnerability handling, technical documentation, and market access. Its reporting obligations have applied since September 11, 2026, while its main obligations apply from December 11, 2027.

CCLab’s CRA and EUCC comparison gives a practical side-by-side explanation. Use it for orientation, then verify legal effect against the Commission and ENISA sources because implementation measures continue to develop.

Under the CRA, a European cybersecurity certification scheme at least at Substantial level may support a presumption of conformity when the applicable legal conditions are satisfied. That is not automatic CRA compliance. The certificate’s scope, the product’s classification, the conformity-assessment route, and any implementing measure all matter.

For a manufacturer starting an EUCC project today, the practical approach is to preserve useful EUCC evidence while separately mapping product scope, vulnerability handling, technical documentation, support-period duties, reporting processes, and the applicable CRA conformity route.

What Manufacturers Should Do Before Starting an EUCC Project 

1. Start with the product and the legal route. Decide whether the product is an appropriate EUCC candidate, which other rules apply, and whether the requirement comes from a regulator, procurement authority, customer, or internal risk decision. Check the certificate register linked above and confirm that an appropriate certification body and ITSEF are available for the relevant product category, technical domain, and assurance level.

2. Define the certification boundary early. Define the Target of Evaluation and identify the firmware, applications, cloud functions, interfaces, hardware components, dependencies, and operating assumptions that sit inside or outside the evaluation.

3. Select the assurance level from the risk, not from the label. Relate Substantial or High to the product’s intended use, threat model, regulatory classification, and customer requirement. Confirm that an accredited and, where necessary, authorized body is available for the relevant product category and technical domain.

4. Prepare the evidence before the formal evaluation begins. The Security Target, Protection Profile analysis, design evidence, developer documentation, testing, configuration management, vulnerability handling, and update processes all influence the evaluation effort. A late scope decision usually becomes a late evidence redesign.

5. Treat updates as part of certification. Define how the organization will assess vulnerabilities, disclose relevant information, manage patches, analyze product changes, and decide whether assurance continuity or recertification is required.

6. Keep the regulatory mapping separate from the certificate claim. Use EUCC evidence where it supports CRA, RED, procurement, or other obligations, but verify each legal route and its conditions. Do not use “EUCC certified” as shorthand for every cybersecurity obligation attached to the product.

This approach also preserves the value of work that does not end in an EUCC certificate. A well-defined TOE, clear Security Target, and documented vulnerability and change processes can support other conformity assessment work when the evidence is mapped to that framework’s requirements.

How QIMA CCLab Supports EUCC Projects

QIMA CCLab supports manufacturers before and during Common Criteria and EUCC projects. The work starts with the product boundary and intended assurance claim, then moves through Protection Profile analysis, TOE definition, Security Target preparation, developer evidence, vulnerability handling, and evaluation readiness.

QIMA’s Common Criteria consultation service and Common Criteria consultancy service support preparation through Protection Profile analysis, Security Target creation, design review, documentation, configuration management, and pre-vulnerability assessment. Consultation supports readiness. It does not replace independent evaluation.

To discuss your EUCC certification scope with QIMA CCLab, contact the laboratory.

FAQ

Is EUCC mandatory?

EUCC is an EU-wide voluntary certification scheme. A customer, procurement authority, sector requirement, or another legal instrument may still make third-party certification necessary for a particular product.

What is the difference between substantial and high assurance?

Substantial maps to AVA_VAN.1 or AVA_VAN.2 and addresses attackers with limited skills and resources. High maps to AVA_VAN.3 through AVA_VAN.5 and requires stronger vulnerability analysis, authorization, and technical capability.

Does an EUCC certificate automatically prove CRA compliance?

No. An EUCC certificate may support a CRA presumption of conformity at Substantial level when the legal conditions are met. Scope, product classification, the conformity route, and implementing measures still matter. It is not a blanket CRA compliance claim.

How long is an EUCC certificate valid?

An EUCC product certificate may be valid for up to five years. During that period, monitoring, vulnerability management, disclosure, and change-management duties continue. A significant product change may require additional evaluation, a scope change, or a new certificate.