EU Cybersecurity Act and EUCS Guide: ENISA, Certification Schemes and Cloud Certification

The EU Cybersecurity Act is the law behind every European cybersecurity certificate, yet most security teams only meet it when a customer, regulator or tender asks for an EUCC certificate or an EUCS cloud attestation that may not exist yet. Regulation (EU) 2019/881 did two things: it gave ENISA a permanent mandate and it created a voluntary, EU-wide certification framework for ICT products, services and processes. In January 2026 the Commission proposed a replacement, the "Cybersecurity Act 2", which is still being negotiated, while the cloud scheme (EUCS) has been in draft since 2020. This guide explains what the current Act requires, which schemes exist and which are still drafts, what the 2026 proposal would change, and how product, cloud and security teams should prepare. It is written for compliance leads, product security managers, cloud architects and procurement teams in or selling into the EU.

Key takeaways

• Certification is voluntary by default. The Act creates schemes; it only becomes mandatory where another EU or national law requires a certificate, which is why NIS2, the CRA and eIDAS matter more than the Act itself for obligations.
• EUCC is the only general ICT product scheme in force. Implementing Regulation (EU) 2024/482 adopted the Common Criteria based EUCC, and it has applied since 27 February 2025.
• EUCS is still a draft. The cloud scheme has stalled over whether it should cover sovereignty and other non-technical risks; do not promise customers EUCS certification until an implementing act is published.
• Managed security services can now be certified. Regulation (EU) 2025/37 extended the framework to services such as incident response and penetration testing, and ENISA consulted on an EUMS scheme in July 2026.
• The Cybersecurity Act 2 is a proposal, not law. COM(2026) 11 would repeal Regulation 2019/881, add "cyber posture" certification and a high-risk supplier regime; Council had not agreed a position at its May 2026 progress report.

Scope: who and what is covered

The Act has two halves. Title II sets ENISA's mandate and tasks. Title III sets the European cybersecurity certification framework. Neither half imposes direct security obligations on companies in the way NIS2 or DORA do; the Act matters to organisations because of the certificates it makes possible and the laws that rely on them.

Key definitions sit in Article 2. A European cybersecurity certification scheme is a comprehensive set of rules, technical requirements, standards and procedures established at Union level (Art. 2(9)). An assurance level is a basis for confidence that a product, service or process meets the scheme's security requirements; it indicates the level of evaluation, not the level of security itself (Art. 2(21)). Conformity self-assessment is the manufacturer or provider evaluating its own product (Art. 2(22)).

Key obligations

The certification framework (Title III)

• Assurance levels: schemes may specify basic, substantial or high. Basic aims to minimise known basic risks, substantial aims to minimise known risks and attacks by actors with limited skills and resources, and high aims to minimise the risk of state-of-the-art attacks by actors with significant skills and resources (Art. 52). Evaluation depth rises with the level, from documentation review to penetration testing.
• Self-assessment: a scheme may allow conformity self-assessment only at basic level (Art. 53). The manufacturer issues an EU statement of conformity and keeps the evidence available to the NCCA.
• Voluntary unless required: certification is voluntary unless Union or Member State law says otherwise (Art. 56). ENISA's certification site states the same and notes that some laws, such as eIDAS, may require it.
• One scheme replaces national schemes: national schemes covering the same products cease to have effect from a date set in the implementing act (recital 94, Art. 57), so a European certificate is recognised in every Member State.
• Who issues certificates: accredited CABs issue certificates at basic and substantial; at high level, the NCCA issues them or delegates to a CAB under conditions in the scheme. CAB accreditation lasts up to five years (recital 97).
• Supervision: each Member State designates one or more NCCAs (Art. 58) to monitor certificates and self-declarations, authorise CABs and handle complaints. The European Cybersecurity Certification Group (ECCG) of Member State representatives advises the Commission and helps ENISA prepare schemes (Art. 62).

Schemes in force and in development

The supporting implementing acts matter for anyone hiring a CAB: Implementing Regulation (EU) 2024/3143 sets how NCCAs notify CABs, and ENISA publishes the Union rolling work programme that signals the next schemes.

EUCS in detail

ENISA published the EUCS candidate scheme for consultation in December 2020; the consultation closed in February 2021. The draft covers IaaS, PaaS, SaaS and other cloud services, defines basic, substantial and high levels, builds on existing national schemes and international standards, provides a transition path from national schemes, sets a three year certificate validity and adds transparency requirements such as where data is processed and stored. Later drafts added "sovereignty" requirements at the high level, such as EU headquarters and immunity from non-EU law, and Member States have since disagreed over whether a certification scheme should address strategic, non-technical risks at all. Industry analysis in February 2026 still described the final EUCS draft as pending.

See the Data Sovereignty and Residency Guide for the residency questions that drove the EUCS dispute, and the Cloud Security Alliance CCM and STAR Guide and ISO/IEC 27017 Cloud Security Controls Guide for the attestations customers rely on today.

ENISA's mandate (Title II)

The Act made ENISA permanent and gave it tasks in policy support, capacity building, operational cooperation (it is secretariat of the CSIRTs network), certification and standardisation, knowledge, awareness and research (Arts. 5 to 12). For certification, ENISA prepares candidate schemes, evaluates adopted schemes, takes part in NCCA peer reviews and supports the ECCG (Art. 8).

Timeline and current status

What the Cybersecurity Act 2 would change

• Repeal and replace: COM(2026) 11 would repeal Regulation 2019/881 and reorganise ENISA's mandate around supporting implementation of Union law, operational cooperation, certification and standardisation, and the Cybersecurity Skills Academy.
• New ENISA services: early alerts on threats, ransomware response support with Europol and CSIRTs, a Union vulnerability management service, operation of the EU Cybersecurity Reserve, and a single-entry point for incident reporting linked to the Digital Omnibus.
• Faster schemes: ENISA would deliver a candidate scheme within 12 months of a Commission request by default, with a maintenance mechanism for existing schemes.
• Cyber posture certification: schemes could certify an entity's overall security posture, starting with NIS2 entities, and certification could give a presumption of conformity with other Union law. Certification stays voluntary; the Commission did not choose the mandatory option.
• ICT supply chain security: a new title would let the Commission identify key ICT assets and, after coordinated risk assessments, restrict high-risk suppliers linked to third countries of concern. For mobile networks, the phase-out of high-risk components would be capped at 36 months from entry into force.

Status wording matters. As of the most recent official document read for this guide (the Council progress report of 22 May 2026), Member States had raised concerns about ENISA's expanded role, certification deadlines, the high-risk supplier mechanism and the legal basis, and no Council position had been adopted. Check the Legislative Observatory before relying on any CSA2 provision; text, numbering and timelines are likely to change.

Enforcement and penalties

The current Act has no fines set at EU level. Article 65 requires Member States to lay down rules on penalties for infringements of Title III and of European schemes, which must be effective, proportionate and dissuasive. In practice, enforcement runs through the NCCAs:

• Certificate withdrawal: NCCAs and CABs can restrict, suspend or withdraw certificates that no longer meet scheme requirements, and EUCC adds explicit vulnerability handling and disclosure duties on certificate holders.
• Complaints: anyone can complain to the NCCA about a certificate or EU statement of conformity, with a right to an effective judicial remedy.
• Peer review: NCCAs review each other so that a certificate from one Member State can be trusted in another.

Under the CSA2 proposal, Member States would still set penalties for certification infringements, and a separate penalties article would cover the ICT supply chain title.

What it means for AI agents and non-human identities

No scheme addresses AI agents or non-human identities as a subject, but certification evaluations test the controls that govern them, and evaluators will ask for evidence.

• Product certification (EUCC): a product's security target defines its security functions. Hard-coded credentials, default service accounts, embedded API keys and weak update signing keys are typical findings that block substantial or high level certification. See the NHI Authentication Guide.
• Cloud certification (EUCS draft): the draft requirements cover identity and access management, cryptography and key management, and logging for the provider's own administrative and machine identities, as well as tenant-facing controls. Workload identities, provider-side automation and key custody are in scope of any evaluation. See the Cloud Workload Identity Guide.
• Managed security services (EUMS): an MSSP holds privileged API tokens and agent credentials in many customer estates. Expect assurance questions on how those credentials are issued, scoped, rotated and revoked when a contract ends.
• Cyber posture certification (proposed): if adopted, posture schemes for NIS2 entities would likely test access control and secrets management across the estate, including machine and agent identities. See the NHI Governance Maturity Model for a way to baseline that now.
• AI components: AI models inside a certified product fall within the target of evaluation like any other component; the EU AI Act, not the Cybersecurity Act, sets AI-specific duties. See the EU AI Act Compliance Guide.

How the Act interacts with other EU laws

Compliance steps

Because certification is voluntary, "compliance" here means deciding where a certificate creates value or is required by another law, then preparing for an evaluation. A phased approach:

1. Map demand (weeks 1 to 4): list products and services sold into the EU, the customers and tenders that ask for certificates, and any law (NIS2 national transposition, CRA, eIDAS) that requires or rewards one. Record which national schemes (Common Criteria, SecNumCloud, C5, ENS) you already hold.
2. Choose the scheme and level: EUCC substantial for most commercial products with a security function; high only where customers or law demand it, because evaluation cost and time rise sharply. For cloud, keep ISO/IEC 27001, 27017 and CSA STAR current and track EUCS drafts rather than paying for "pre-certification".
3. Gap assessment: compare current controls with the scheme's requirements. For EUCC, draft the security target and check the vulnerability handling, patch and disclosure process the scheme requires of certificate holders.
4. Select a CAB: confirm it is accredited and notified for the scheme and level on ENISA's certification site, and agree the evaluation plan.
5. Pilot evaluation: run one product or service through first. Use internal penetration testing and a mock evaluation to find blockers such as hard-coded secrets before the CAB does.
6. Operate the certificate: assign an owner for vulnerability notifications, change impact analysis and surveillance audits. Decide in advance which changes trigger re-evaluation and when you would rather let a certificate lapse than misrepresent it.
7. Track CSA2: assign someone to monitor 2026/0011(COD), especially the supply chain title if you sell telecom or network equipment, and the posture scheme if you are a NIS2 entity.

Decision guidance

• Small vendors: certify only where a buyer or law requires it; a self-assessed basic level, once schemes allow it, may be enough for low-risk products.
• Large vendors with national certificates: plan migration to EUCC before national Common Criteria routes close; check transition dates in the implementing act.
• Cloud buyers: do not make EUCS a mandatory tender criterion until it exists; ask for the evidence it would cover (control set, data location, key custody) instead.
• Regulated buyers: treat a certificate as one input to supplier risk, alongside contract terms and monitoring. See the ISO/IEC 27036 Supplier Relationships Guide.

Framework mapping and measurement

CIS Controls v8.1 Control 15 (Service Provider Management) covers the buyer side. Useful metrics:

• Percentage of EU-facing products with a mapped certification decision (target 100%).
• Number of open evaluation findings, and median days to close them.
• Days from a vulnerability affecting a certified product to notification of the CAB or NCCA, against the scheme's deadline.
• Percentage of critical cloud and ICT suppliers with current third-party attestations on file.

Common failure patterns

• Treating EUCS as real: tenders and contracts that require "EUCS certification" cannot be met; write requirements against controls and existing attestations.
• Certifying the product, not the process: EUCC certificate holders must handle and disclose vulnerabilities; teams that certify once and stop monitoring risk suspension.
• Scoping too narrowly: a target of evaluation that excludes the update mechanism, management interface or cloud back end gives buyers false comfort.
• Hard-coded machine credentials: embedded keys and default service accounts are among the commonest reasons evaluations fail late and expensively.

Practitioner checklist

• Inventory EU-facing products and services and record which certificates customers and laws ask for.
• Confirm current status of each relevant scheme on ENISA's certification site before committing to a date.
• Pick EUCC level per product with a cost and time estimate from an accredited, notified CAB.
• Remove hard-coded credentials and default machine accounts before evaluation.
• Stand up a vulnerability handling and disclosure process that meets EUCC certificate holder duties.
• For cloud, keep ISO/IEC 27001, 27017 and STAR evidence current and map it to the EUCS draft control families.
• Replace "EUCS certified" in procurement templates with control and data location requirements.
• Assign an owner to track 2026/0011(COD) and the linked NIS2 amendments.
• Record certificates as evidence in NIS2, CRA and DORA compliance files, with expiry dates.

Standards and references

• EUR-Lex: Regulation (EU) 2019/881 (Cybersecurity Act)
• EUR-Lex: Commission Implementing Regulation (EU) 2024/482 adopting the EUCC scheme
• EUR-Lex: Regulation (EU) 2025/37 amending the Cybersecurity Act as regards managed security services
• Council of the EU: Proposal for a Cybersecurity Act 2, COM(2026) 11
• European Commission: The EU Cybersecurity Act
• ENISA: EU Cybersecurity Certification
• European Commission: EUCS cloud services candidate scheme
• Cullen International: Revised Cybersecurity Act (CSA2), changes to the certification framework

Related NHI Mgmt Group resources: NIS2 Directive Guide · EU Cyber Resilience Act Guide · DORA Guide · Cyber Solidarity Act Guide · Global Cybersecurity Regulatory Map. This guide summarises the EU Cybersecurity Act, its certification schemes and the 2026 revision proposal as at October 2026 and is not legal advice.