EUCC Certification: Scope, Assurance Levels, and Process

EUCC is the European Union Cybersecurity Certification Scheme on Common Criteria. It gives ICT manufacturers and suppliers a shared European route for obtaining independent assurance about a defined product and its security claims. The scheme can cover hardware, software, technological components, protection profiles, and qualifying product series.

EUCC does not certify an organization’s entire cybersecurity program. It evaluates a stated target of evaluation against specified functional and assurance requirements. The resulting certificate is meaningful only when a buyer reads its product identity, version, configuration, Security Target, assurance level, validity, and maintenance status together.

This guide explains what EUCC certification covers, how it relates to Common Criteria, the difference between substantial and high assurance, the roles of applicants, laboratories and certification bodies, the evaluation process, certificate maintenance, vulnerability handling, product-series certification, and the limits buyers should preserve in procurement and risk decisions.

EUCC Is the EU Common Criteria Certification Scheme

The European Commission adopted EUCC through Commission Implementing Regulation (EU) 2024/482 under the Cybersecurity Act. The scheme became applicable on 27 February 2025, and ENISA states that EUCC certificates have been issuable since February 2025. It is the first European cybersecurity certification scheme adopted under the EU framework.

ENISA’s current EUCC overview describes a commonly understood assessment process for ICT products such as chips, smartcards, hardware, and software. The scheme reuses Common Criteria evaluation practice while establishing European roles, assurance levels, certificate publication, monitoring, vulnerability management, and scheme maintenance.

The operative text has changed since adoption. A December 2024 amendment specified applicable Common Criteria and evaluation-method versions and transition rules. A December 2025 amendment added and refined provisions for product series, major and minor changes, assurance continuity, and state-of-the-art documents. Current decisions should therefore use the consolidated EUCC regulation, not only the original 2024 text.

Scope Starts With the Target of Evaluation

Certification begins by defining exactly what is being evaluated. The target of evaluation may be a complete ICT product or a bounded part of one, together with the documentation and configuration needed to understand the security claim. Interfaces, dependencies, operational environment, excluded functions, and assumed controls affect what the evaluation result means.

The Security Target identifies the product, its security problem, objectives, functional requirements, assurance requirements, and evaluation scope. A Protection Profile can define reusable requirements for a product category. Conformance to a Protection Profile makes comparison easier, but buyers must still check the evaluated product, implementation choices, configuration, and local use.

Product names alone are weak evidence. Match the certificate reference to the exact version, model, firmware, software build, options, and certified configuration you intend to deploy. A later release, optional module, cloud service, management plane, or integration may sit outside the evaluated target.

Common Criteria Defines the Claim and Evaluation Method

EUCC uses the Common Criteria for Information Technology Security Evaluation and the Common Evaluation Methodology. Common Criteria provides a structured language for security functional requirements, security assurance requirements, Security Targets, Protection Profiles, and evaluation assurance components. The methodology tells evaluators how to examine the evidence and perform the assessment.

This structure separates required security behavior from confidence in the implementation and evaluation. A product can claim authentication, access control, cryptographic, audit, or other functions while the assurance package defines the development, testing, vulnerability-analysis, and evaluation work used to support confidence in those claims.

Do not translate an Evaluation Assurance Level or AVA_VAN component into a simple percentage of security. The evaluated requirements, threat assumptions, attack potential, product complexity, operational guidance, and excluded environment matter as much as the shorthand label.

Substantial and High Express Different Assurance Depth

EUCC certificates use the assurance levels substantial and high. Under the consolidated regulation, substantial corresponds to vulnerability-analysis components AVA_VAN.1 or AVA_VAN.2. High corresponds to AVA_VAN.3, AVA_VAN.4, or AVA_VAN.5. The higher range addresses progressively stronger attack potential and deeper analysis.

The assurance level does not state the business impact of compromise, decide whether the product fits a particular system, or guarantee that exploitation is impossible. It describes assurance under the scheme for the evaluated target and claim. Select a level from the intended use, threat capability, regulatory or procurement requirement, exposure, consequence, and availability of an appropriate evaluation path.

High-assurance certification also has stricter authorization and oversight conditions. Procurement language should name the required scheme, level, product scope, certificate status, and any relevant Protection Profile instead of requesting “EU certified” without a verifiable claim.

Applicant, Laboratory, Certification Body, and Authority Have Separate Roles

The applicant defines the product and certification claim, prepares evidence, provides access to the evaluated target, and supports vulnerability and lifecycle obligations. The evaluation facility—commonly described in EUCC material as an ITSEF—performs the technical and documentary evaluation under the applicable criteria and methodology.

An accredited certification body reviews the evaluation and issues the certificate when the requirements are satisfied. National cybersecurity certification authorities supervise the national certification system and perform authorization tasks where required. ENISA maintains scheme information and publishes certificate information through the European certification framework.

Independence and competence are part of the evidence chain. ENISA’s current notified-body directory helps applicants identify bodies notified for EUCC. An applicant should confirm the body’s scope, assurance-level authorization, technical-domain capability, laboratory relationship, capacity, and national process before planning dates or claiming eligibility.

The Certification Process Begins Before Laboratory Testing

Start with product readiness and a defensible scope. Identify the target of evaluation, intended configurations, interfaces, dependencies, operational assumptions, product lifecycle, development evidence, vulnerability-handling process, and desired assurance claim. Determine whether a recognized Protection Profile and technical-domain state-of-the-art documents apply.

Engage a suitable certification body and evaluation facility early. They can clarify scheme eligibility, required evidence, evaluation plan, interpretation questions, sampling, technical-domain requirements, and change control. The evaluator reviews documentation, design and implementation evidence, guidance, tests, vulnerability analysis, and other assurance components required by the selected package.

Findings must be resolved with traceable product or evidence changes. The certification body reviews the evaluation result and, if the scheme conditions are met, issues the certificate and associated certification report. Publication makes the claim discoverable, but the applicant still owns accurate product mapping, vulnerability response, change notification, and assurance continuity.

Evidence Quality Determines Evaluation Readiness

Evaluation cannot substitute for missing product knowledge. Maintain consistent architecture, interface, functional-specification, design, implementation, test, build, delivery, configuration-management, and operational-guidance evidence at the depth required by the assurance package. The evaluated build must be reproducible and identifiable.

Resolve contradictions before formal evaluation. A security function described differently in the Security Target, administrator guide, design evidence, test plan, and implementation will create rework and weaken the claim. Tie evidence to controlled versions and record why each change does or does not affect the target of evaluation.

Reuse should be justified, not assumed. Prior Common Criteria material, a Protection Profile, component evaluation, or earlier certificate can accelerate work only when the product, versions, dependencies, assumptions, methods, and scheme rules support that reuse.

Vulnerability Management Continues After Certification

A certificate is not a freeze on product risk. New vulnerabilities, attack methods, cryptographic guidance, dependencies, and environmental conditions can change the assurance picture after issue. EUCC therefore includes monitoring, vulnerability management and disclosure responsibilities during the certificate lifecycle.

Maintain intake, triage, technical analysis, remediation, disclosure, customer communication, and certificate-impact assessment. Connect reports to the exact certified versions and configurations. When a vulnerability affects an evaluated security function or assumption, coordinate with the certification body rather than treating an ordinary patch note as sufficient assurance evidence.

Buyers should monitor both the supplier’s advisories and certificate status. Feed relevant findings into vulnerability intelligence prioritization using deployment, exposure, exploitation, consequence, and compensating controls instead of assuming certification makes a finding low priority.

Assurance Continuity Controls Product Changes

Product maintenance creates a practical tension: users need patches and improvements, while certification evidence refers to a controlled evaluated target. The scheme’s assurance-continuity process addresses re-assessment, change impact, assessed patch-management processes where included, and lifecycle or production-process review.

The December 2025 amendment distinguishes minor changes that do not adversely affect the expressed assurance from major changes that may do so. The classification is evidence-based. A small code diff can affect a security boundary, while a larger editorial or environmental change may leave the evaluated assurance intact.

Build certificate-impact review into release governance. Record changed components, security functions, interfaces, dependencies, development environment, tests, vulnerability analysis, guidance, and operational assumptions. Do not advertise a new version as certified until the certification path and public status support that statement.

Product-Series Certification Still Requires Bounded Variation

The amended scheme defines a product series as ICT products from one applicant that share a functional basis and address the same security needs while design, hardware, firmware, or software may vary. This can support families of related products, but it does not make every variant automatically equivalent.

The certification body decides case by case whether product-series certification is appropriate. The applicant must identify common and variable elements, explain how variation affects security functions and assurance evidence, and support an evaluation strategy that covers the claimed series.

Buyers should confirm that the exact model or variant is included. Marketing references to a certified family are not enough when the certificate, report, or maintained product list does not cover the purchased configuration.

Buyers Should Verify the Claim Before Using It as Supplier Evidence

Treat EUCC certification as one strong but bounded evidence source. Verify the certificate in ENISA’s official European cybersecurity certification library, then check the issuer, assurance level, product and version, Security Target, Protection Profile, certified configuration, issue and validity information, maintenance status, and known advisories. Record where your deployment differs.

Then connect the certificate to the actual decision. A high-assurance component can still be integrated badly, exposed through an insecure management plane, operated with unsafe defaults, or surrounded by unassessed services. Conversely, a product without EUCC may have other useful assurance evidence; the correct comparison depends on the procurement and risk requirement.

Combine certification with software supply chain assurance, supplier vulnerability handling, support commitments, secure configuration, architecture review, penetration testing where authorized, logging, incident response, and exit planning. Do not convert a scoped evaluation into a blanket statement about the supplier.

EUCC Certification Readiness and Review Checklist

For applicants: define the target, users, environment, security problem, requirements, assurance level, applicable Protection Profile, technical domain, product-series boundaries, and controlled build. Select an eligible certification body and evaluation facility. Prepare consistent evidence, tests, vulnerability analysis, delivery controls, operational guidance, change governance, disclosure procedures, and post-certificate ownership.

For buyers: verify the certificate in the official source. Match product, model, version, configuration, claim, level, and status. Read the Security Target and certification report. Identify exclusions and assumptions. Check maintenance, vulnerabilities, local integration, deployment controls, and contractual response obligations.

The decision rule is simple: use EUCC as independently reviewed evidence for a defined product claim, then preserve every boundary that keeps the claim true in operation.