EUCC is the first EU-wide cybersecurity certification scheme adopted under the Cybersecurity Act, and it replaced patchwork national Common Criteria arrangements with one set of rules, one label and ongoing vulnerability duties for every certificate holder. The scheme is set out in Commission Implementing Regulation (EU) 2024/482, amended by Implementing Regulation (EU) 2024/3144 and a further amendment adopted on 8 December 2025. This guide explains who EUCC is for, how an evaluation works, what evidence and partners a vendor needs, how to prepare, what ongoing obligations follow certification, and where EUCC sits beside the Cyber Resilience Act and other schemes. It is written for product security leads and PSIRTs at hardware and software vendors, and for buyers who specify certified products. It goes deeper than the EU Cybersecurity Act and EUCS Guide on this one scheme. Status line: checked on 27 October 2026 against ENISA's EUCC scheme page and the EUCC vulnerability management guidelines v1.1. This guide is not legal advice.
Key takeaways
- Voluntary, product-level and Common Criteria based: ENISA describes EUCC as a voluntary scheme for ICT products such as chips, smartcards, hardware and software, built on the SOG-IS Common Criteria evaluation framework already used in 17 Member States.
- Two assurance levels: the Cybersecurity Act levels substantial and high, with vulnerability assessment depth expressed through the Common Criteria AVA_VAN components (AVA_VAN.1 to AVA_VAN.5).
- Three parties do the work: an accredited IT Security Evaluation Facility (ITSEF) evaluates, an accredited certification body (CB) certifies, and the National Cybersecurity Certification Authority (NCCA) supervises and authorises.
- Certification is not the end: Articles 33 to 37 of the EUCC regulation require holders to run vulnerability intake, impact analysis and remediation proposals, with CB review and possible withdrawal.
- State-of-the-art documents matter: ENISA publishes binding "final" and endorsed "draft" documents on accreditation, smartcards, hardware security boxes, cryptography and assurance continuity.
Who the certification is for
| Audience | Why EUCC matters |
|---|---|
| Vendors of secure elements, smartcards, HSMs and security boxes | The scheme's state-of-the-art documents cover these product types in detail, and they were core users of national Common Criteria schemes |
| Software and network product vendors | A single EU certificate and label recognised across Member States |
| Public and regulated buyers | A comparable assurance statement for procurement, and an EU certificate list to check |
| Evaluation labs and certification bodies | Accreditation and NCCA authorisation requirements specific to EUCC |
| PSIRT teams | Vulnerability handling becomes a certification obligation with deadlines |
Identity relevance is direct: smartcards, secure elements and HSMs anchor keys for PIV-style authentication, FIDO authenticators, code signing and machine identity. See the Smart Card and PIV/CAC Authentication Guide.
Evaluation format and assurance levels
An EUCC evaluation is a Common Criteria evaluation run under EU rules. The vendor defines a security target (often claiming conformance to a protection profile), the ITSEF evaluates it, and the CB issues the certificate.
| Element | What it means in EUCC | Source |
|---|---|---|
| Assurance level substantial | The lower of the two Cybersecurity Act levels used by EUCC | EUCC guidelines, Table 1 |
| Assurance level high | The higher level, for products whose intended use carries higher risk | EUCC guidelines, Table 1; ENISA scheme page |
| AVA_VAN.1 to AVA_VAN.5 | Common Criteria vulnerability analysis components referenced across both levels; vulnerability handling timeframes depend on whether the analysed component is met or failed at the certified level | EUCC guidelines, Table 1 |
| AVA_VAN.4 and 5 | Highest vulnerability analysis depth, referenced by ENISA for certified protection profiles | ENISA scheme page |
| Protection profiles | Certified and recommended profiles listed in the SOG-IS register | ENISA scheme page |
| Attack potential bands | 0 to 9 critical, 10 to 13 high, 14 to 19 medium, 20 to 24 low, 25 or more beyond high, used to rate vulnerabilities | EUCC vulnerability guidelines |
The precise mapping of AVA_VAN levels to substantial and high is in the implementing regulation; confirm it against the current consolidated text before scoping a target.
Prerequisites and evidence
- Accredited partners: choose an ITSEF accredited under ENISA's ITSEF accreditation document (v1.6c) and a CB accredited under the CB document (v1.6b). For high assurance, the CB also needs NCCA authorisation; ENISA publishes authorisation guidelines (v0.7) and a conformity assessment body finder.
- Development evidence: security target, design documentation, lifecycle and configuration management evidence, and guidance documents, as Common Criteria requires.
- Site security: for smartcards and hardware with security boxes, the Minimum Site Security Requirements (V2, final, December 2025) apply to development and production sites.
- Cryptography: the EUCC cryptography guidelines (v2) set agreed mechanisms and add post-quantum recommendations.
- A working PSIRT: Article 33(2) requires holders to maintain and publish methods for receiving vulnerability information. See the PSIRT Guide.
Preparation plan
- Decide the assurance level from buyer demand and the risk of intended use; ENISA says the level should follow the risk of the intended use.
- Pick a protection profile where one exists, to reduce scoping effort and improve buyer comparability.
- Engage an ITSEF and CB early to agree scope, evaluation plan and any state-of-the-art documents that apply (for example the Star Methodology or Application of Attack Potential to Smartcards).
- Gap-assess development evidence against the Common Criteria assurance components for your target.
- Stand up vulnerability handling that meets Articles 33 to 37 before the certificate is issued, not after.
- Plan product series and changes: ENISA's guidelines on evaluation methodology for product series and on assurance continuity for changes to certified products set out how to avoid a full re-evaluation for every release.
- Prepare labelling: the European Commission's EUCC brand book governs certification marks and labels.
Cost, validity and maintenance
Neither the ENISA scheme page nor the guidelines publish evaluation fees; costs are set commercially by ITSEFs and CBs and depend on assurance level, product complexity and site audits. Budget for the ongoing obligations below, which continue for the life of the certificate.
| Obligation | Article | What the holder does |
|---|---|---|
| Intake channel | Art. 33(2) | Maintain and publish methods for receiving vulnerability information |
| Record and analyse | Art. 33(3) | Record each potential vulnerability and carry out a vulnerability impact analysis |
| Composite products | Art. 33(4) | Inform holders of dependent EUCC certificates |
| Cooperate with the CB | Art. 33(5) | Share relevant information on the CB's reasonable request |
| Remediation | Art. 36 | Submit a proposal for appropriate remedial action; the CB reviews the certificate under Article 13 |
| Withdrawal | Art. 35(6), Art. 14 | If a vulnerability cannot be remediated, the certificate is withdrawn |
| Disclosure | Art. 37, Art. 38 | CB discloses confirmed vulnerability information to the NCCA, without exploit details; NCCA shares with ENISA |
The ENISA guidelines set maximum durations for impact analysis of 60 or 90 calendar days depending on the case, or a period agreed with the CB (defaulting to 90 days without agreement, and recommended to stay within 180 days). The NCCA may approve a further 60 or 90 day extension, and actively exploited, publicly known vulnerabilities must be reported to the CB without undue delay with analysis time cut to the minimum. Patching takes priority over recertification. Retain analyses showing no vulnerability for at least five years. Follow ISO/IEC 29147 for disclosure, and on withdrawal register remediated publicly known vulnerabilities in the European vulnerability database or another listed repository.
Certificate validity periods are set in the implementing regulation; confirm the current maximum in the consolidated text.
Where it fits on the certification landscape
| Scheme or law | Relationship to EUCC |
|---|---|
| EU Cybersecurity Act (Regulation (EU) 2019/881) | Legal basis; EUCC is a scheme under it |
| SOG-IS Common Criteria arrangements | The evaluation framework EUCC builds on; protection profile register still referenced |
| EU Cyber Resilience Act | ENISA says the vulnerability guidelines will be updated to align with the CRA; see the EU CRA Product Classes Guide |
| EUCS (cloud services scheme) | A separate candidate scheme for services rather than products |
| FIPS 140-3 (US) | Cryptographic module validation; often run in parallel for HSMs |
Decision guidance
- Substantial vs high: choose high where buyers face capable attackers or regulations reference high assurance (secure elements, HSMs). Substantial suits general network or software products where buyers want comparability more than resistance to expert attackers.
- Small vendors: start with a protection profile and a product-series strategy to keep re-evaluation costs down.
- Buyers: check the certificate in ENISA's certificate list, the target of evaluation scope, and whether the holder's vulnerability obligations are being met, not just the label.
Mapping and metrics
| EUCC element | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Evaluated products in procurement | SA-4 | GV.SC-05 |
| Holder vulnerability handling | RA-5, SI-2 | ID.RA-08 |
| Developer security testing | SA-11 | ID.IM-02 |
- Median days from vulnerability report to completed impact analysis, against the 60 or 90 day limits.
- Certified products with an assurance continuity plan.
- Open remediation proposals awaiting CB review.
- Share of security-relevant suppliers (composite components) with their own EUCC certificate.
Common failure patterns
- Treating the certificate as a one-off project: the evaluation team disbands after issue, and nobody owns the Article 33 intake and impact analysis duties, so the first reported vulnerability misses the 60 or 90 day window.
- PSIRT and certification teams not talking: a fix ships through the normal release train without the remediation proposal the CB expects under Article 36.
- Composite blind spots: a vendor building on a certified chip or platform is not told about vulnerabilities in the underlying component, although Article 33(4) expects the base holder to inform dependent certificate holders. Agree the channel in the supply contract.
- Scope surprise for buyers: procurement accepts the EUCC label without reading the target of evaluation, then deploys the product in a configuration that was never evaluated.
- Re-evaluating every release: ignoring the product series and assurance continuity guidelines and paying for full evaluations that a change scenario would have covered.
- Weak key custody around certified hardware: an evaluated HSM or secure element does not protect machine identities whose keys are exported, shared or unrotated. See the Secrets Management Guide.
Practitioner checklist
- Confirm whether customers or regulations expect EUCC, and at which assurance level.
- Identify an applicable protection profile and the state-of-the-art documents for your product type.
- Shortlist accredited ITSEFs and CBs; for high assurance, confirm CB authorisation by the NCCA.
- Publish a vulnerability intake channel and PSIRT contact before certification.
- Write a procedure for impact analysis within the guideline timeframes and NCCA extension requests.
- Plan product series and assurance continuity to avoid full re-evaluation.
- Track amendments to Implementing Regulation (EU) 2024/482, including the December 2025 change.
- Buyers: verify certificates on the ENISA list and read the target of evaluation scope.
Standards and references
- EUR-Lex: Commission Implementing Regulation (EU) 2024/482 (EUCC)
- ENISA: EUCC certification scheme
- ENISA: EUCC Guidelines on Vulnerability Management and Disclosure and ECCG opinion
- ENISA: EUCC Guidelines on Vulnerability Management and Disclosure v1.1 (PDF)
- ENISA: Accreditation of ITSEFs for the EUCC
- ENISA: Accreditation of CBs for the EUCC
- ENISA: EUCC Guidelines on Cryptography
Related NHI Mgmt Group resources: EU Cybersecurity Act and EUCS Guide · EU Cyber Resilience Act Guide · PSIRT Guide · Vulnerability Disclosure Maturity Model. This guide summarises the EUCC scheme under Implementing Regulation (EU) 2024/482 and is not legal advice.