EU Cloud Security Certification (EUCS) 2026: What SaaS Developers and Cloud Buyers Must Know

Every time the EU adopts a new regulation — NIS2, the AI Act, DORA — it creates procurement consequences: organizations subject to the regulation must choose suppliers that help them stay compliant. Cloud infrastructure is the most consequential supplier choice a SaaS developer makes, and the EU Cybersecurity Cloud Certification Scheme (EUCS) is the framework that will determine which cloud services count as "compliant" for European regulated sectors.

EUCS has been in development since 2019. It is not yet mandatory — but it is increasingly referenced in public sector procurement rules, NIS2 implementation guidance, and sector-specific regulations. For developers building SaaS products that serve European enterprises, public authorities, or regulated industries, understanding EUCS now prevents a forced infrastructure migration later.

What EUCS Is and Where It Comes From

EUCS is the European Cybersecurity Certification Scheme for Cloud Services, developed by the European Union Agency for Cybersecurity (ENISA) under the authority of the EU Cybersecurity Act (Regulation 2019/881). The Cybersecurity Act created a framework for voluntary (and potentially mandatory) cybersecurity certification schemes across EU markets. EUCS is the first scheme developed under this framework specifically for cloud services.

The scheme sets technical and organizational security requirements that cloud service providers (CSPs) must meet to achieve certification, and defines how independent conformity assessment bodies (CABs) evaluate those requirements. Once certified, a CSP receives an EU cybersecurity certificate that government bodies, NIS2 essential entities, and procurement frameworks can rely on.

The European Commission adopted the draft EUCS scheme after years of technical work by ENISA, with significant political controversy along the way — particularly around sovereignty requirements for the "High" assurance level.

Three Assurance Levels — and What Each Means for Developers

EUCS defines three certification levels that correspond to the sensitivity of data and the risk tolerance of the use case.

Basic

Basic certification targets cloud services that handle low-sensitivity data where the consequences of a breach are limited. Requirements focus on documented security practices, vulnerability disclosure processes, and basic operational security hygiene. Self-assessment is permitted at this level with limited third-party review.

For developers: Basic is relevant for non-critical internal tooling, development environments, or public-facing services where personal data processing is minimal. Basic certification does not satisfy NIS2 essential entity procurement requirements for core infrastructure.

Substantial

Substantial certification targets services handling personal data, financial data, or information affecting business continuity where breaches would cause significant harm. Requirements include independently audited penetration testing, formal incident response plans, documented access controls, and security information and event management (SIEM) capabilities.

The majority of B2B SaaS products that serve European mid-market companies fall into "Substantial" territory. If your product is part of a customer's NIS2 compliance posture — if a breach of your service could trigger their own NIS2 incident reporting obligation — then your cloud provider being Substantial-certified matters for procurement.

For developers: When selling to companies that are themselves NIS2-important entities (a category that includes most medium-to-large organizations in health, energy, transport, digital infrastructure, and manufacturing), expect due diligence questions about whether your cloud infrastructure is EUCS Substantial-certified.

High

High certification is the most demanding level. It targets services handling sensitive personal data at scale, classified government data (up to the EU RESTRICTED classification), critical infrastructure control systems, or data whose compromise would affect public security.

High assurance requires not only rigorous technical security controls but also — and this is where the political controversy lives — assurance about sovereignty: the ability to guarantee that data stored in or processed through the service cannot be accessed by non-EU legal authorities under foreign law.

For developers: Unless you are building infrastructure for EU public authorities, critical national infrastructure, or classified data environments, High certification is probably not your immediate concern. But the sovereignty requirements for "High" have significant implications for the entire market, which is why they matter even for developers targeting Substantial-level customers.

The EU Sovereignty Controversy

The most contested aspect of EUCS has been the sovereignty requirements proposed for the "High" certification level.

ENISA's original 2022 draft proposed that High-certified cloud services must be:

1. Operated by an EU-based entity — the legal person holding the service must be established in the EU
2. Free from non-EU law jurisdiction — the operator must not be subject to laws of non-EU countries that could compel data access, including through parent companies
3. Stored and processed within the EU — data must not leave EU territory for High-assurance services

The third condition is already common (data residency). The first two conditions are the controversial ones. They would effectively exclude AWS, Microsoft Azure, and Google Cloud from High certification in their current corporate structures — not because of technical security failures, but because they are subsidiaries of US corporations subject to US law, including FISA 702 and the CLOUD Act.

This triggered an intense lobbying battle. US hyperscalers argued that the sovereignty requirements were discriminatory trade barriers unrelated to actual security. Several EU member states — particularly those with significant US tech presence — pushed back. The Commission moderated the final scheme, creating a pathway for US-parent companies to achieve High certification through structural separation: establishing EU-incorporated entities with EU-based control planes and contractual firewalls against US parent company data requests.

Hyperscalers have responded with "sovereign cloud" products — AWS European Sovereign Cloud, Microsoft Cloud for Sovereignty, Google Sovereign Cloud — that attempt to satisfy EUCS High requirements through operational separation. Whether these structures actually eliminate CLOUD Act and FISA 702 exposure is a question that legal scholars and the CJEU are still working through (see the ongoing Schrems III challenge to the Data Privacy Framework).

The EUCS controversy matters to developers because it shapes the regulatory environment they operate in. If your SaaS targets EU public sector or critical infrastructure clients, those clients will increasingly specify EUCS-certified cloud in their procurement requirements — and "certified" may mean different things depending on whether they mean Substantial or High.

NIS2 and EUCS: The Procurement Connection

NIS2 Directive (EU 2022/2555), which required transposition into national law by October 2024, does not mandate the use of EUCS-certified cloud services directly. But it creates the conditions that make EUCS procurement-relevant.

Under NIS2 Article 21, essential and important entities must take "appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems." Article 21(2)(d) specifically requires attention to supply chain security, including the security of suppliers and service providers.

When an NIS2 essential entity is choosing cloud infrastructure for services that affect their NIS2-covered operations, the question becomes: how do we demonstrate that our cloud supplier meets appropriate security standards? EUCS certification is the EU-developed answer. Procurement frameworks for EU public authorities are beginning to specify it explicitly.

Germany's BSI (Bundesamt für Sicherheit in der Informationstechnik) has incorporated EUCS-equivalent requirements into its C5 (Cloud Computing Compliance Criteria Catalogue) certification, which many German enterprises require from SaaS vendors. France's ANSSI has its own SecNumCloud certification (which has stricter sovereignty requirements than the current EUCS High draft). These national schemes are converging toward EUCS.

For SaaS developers, the path of compliance risk is:

1. You serve NIS2-regulated organizations (essential or important entities)
2. Those organizations ask about your supply chain security for NIS2 Art. 21(2)(d)
3. You need to demonstrate your cloud infrastructure meets appropriate standards
4. EUCS (or national equivalents) is increasingly the benchmark they reference

What EUCS Means for SaaS Developers: Four Practical Scenarios

Scenario 1: You Build a B2B SaaS for European Enterprises

Your customers include manufacturing companies, healthcare organizations, or financial services firms that are NIS2 important entities. These customers are beginning to receive EUCS-related questions in their own vendor assessments and will pass those questions down to you.

What to do: Check whether your cloud provider is pursuing EUCS Substantial certification. The major hyperscalers have committed to EUCS certification timelines. EU-native providers like sota.io are structured to meet EUCS sovereignty requirements by design — they are EU-incorporated, EU-operated, and not subject to US parent company jurisdiction. Ask your provider for their certification roadmap and document their security controls under NIS2 Article 21 standards.

Scenario 2: You Build Infrastructure for EU Public Authorities

Government digital services, EU institution tools, or national administration platforms typically have procurement requirements that specify security certifications. EUCS is increasingly referenced in EU public procurement notices (Official Journal tenders), and national certification requirements (BSI C5 in Germany, SecNumCloud in France) apply in specific member states.

What to do: For EU public sector work, treat EUCS High as the target even if not yet mandatory. This means your cloud provider must have EU legal establishment, must demonstrate operational independence from non-EU parent company jurisdiction, and must store and process data entirely within the EU. Consider whether existing US-cloud "sovereign" offerings actually satisfy these requirements or merely satisfy them structurally while retaining FISA 702 exposure through shared services.

Scenario 3: You Are the Cloud Provider

If your SaaS platform functions as cloud infrastructure for other developers (PaaS, hosting, managed databases), EUCS applies to you as a cloud service provider. You will need to pursue certification if your customers are regulated entities that specify EUCS in their supplier requirements.

What to do: Map your current security controls against EUCS Substantial requirements. ENISA has published the detailed technical specification. Engage a conformity assessment body early — CABs with EUCS expertise are building their capacity but demand is increasing. Plan for a 12-24 month certification timeline for a first assessment.

Scenario 4: You Are Building AI Systems Under the EU AI Act

High-risk AI systems under EU AI Act Annex III require a documented risk management system (Art. 9), quality management system (Art. 17), and data governance practices (Art. 10). The infrastructure hosting these systems is part of the overall compliance picture. If your AI system processes sensitive personal data at scale — financial data, health data, biometric data — the security of your cloud infrastructure contributes to your AI Act compliance posture.

For GPAI model providers subject to Art. 53, systemic risk requirements include cybersecurity and infrastructure protection obligations (Art. 53(1)(d)). Using EUCS-certified cloud infrastructure provides documented evidence of infrastructure security in a format that EU regulators recognize.

The EUCS Timeline: Where Things Stand in 2026

Understanding where EUCS stands requires understanding that EU certification schemes go through multiple stages:

2019: EU Cybersecurity Act enters into force, establishing the certification framework
2020-2022: ENISA drafts EUCS scheme, public consultation rounds
2022: First comprehensive EUCS draft published, sovereignty controversy begins
2023-2024: Political negotiations over sovereignty requirements for "High" level, Commission moderates requirements
2024: EUCS scheme adopted by the European Commission; certification activities begin
2025: First EUCS-certified services begin appearing; national procurement frameworks begin referencing EUCS
2026 (current): EUCS Substantial certification increasingly specified in NIS2-related procurement; EU public authority tenders incorporating EUCS requirements; High-level certification processes underway for first applicants

What this means for your planning horizon: EUCS is not yet mandatory for most use cases, but procurement pressure is real and growing. Organizations subject to NIS2, DORA, the AI Act, or public sector procurement rules are already asking cloud security questions that EUCS is designed to answer. Developers who choose EU-native cloud infrastructure now avoid a forced migration when these requirements become explicit.

National Cloud Certification Schemes and EUCS Alignment

EUCS is designed to become the single European certification standard, but several member states developed their own cloud certification requirements before EUCS finalized.

Germany — BSI C5 (Cloud Computing Compliance Criteria Catalogue): C5 is the BSI's cloud security certification, widely used in German enterprise procurement. C5 2020 edition aligns with ISO 27001 and EUCS Substantial requirements. Many SaaS vendors selling to German enterprises are already asked for C5 attestation from their cloud providers. EUCS certification at Substantial level should satisfy C5 requirements, but confirm with specific customers.

France — ANSSI SecNumCloud: SecNumCloud has stricter sovereignty requirements than even the EUCS High draft in some respects. SecNumCloud requires that the cloud provider be a French-registered entity with no non-EU controlling interest. This effectively excludes US hyperscalers even with structural separation. If you sell to French government or defense-adjacent organizations, SecNumCloud may be a harder requirement than EUCS.

Spain — ENS (Esquema Nacional de Seguridad): ENS applies to Spanish public administrations and their technology suppliers. Cloud services used in ENS contexts must meet specific security requirements. EUCS alignment with ENS is ongoing.

For developers operating across multiple EU markets, understand which national schemes your customers reference — and whether EUCS certification at the appropriate level satisfies those national requirements.

What "EU Sovereignty" Actually Requires in Practice

When a EUCS High requirement says the cloud provider must be free from non-EU law jurisdiction, what does that mean operationally?

Legal entity: The cloud service provider must be an EU-incorporated legal entity (GmbH, SAS, BV, etc.) that is the contractual counterparty for EU customers. This is not the same as having an EU data center — AWS Frankfurt is operated by Amazon Web Services EMEA SARL (Luxembourg), which is a subsidiary of Amazon.com Inc. (US). The EU subsidiary is the contracting entity, but the US parent company's data access capabilities under FISA 702 flow through the corporate structure.

Control plane: The operational management of the cloud service — the systems that control infrastructure configuration, access management, support access to customer data — must be operated by EU-based personnel not subject to non-EU jurisdiction. This is where many "sovereign cloud" offerings struggle: if the support escalation path leads to US-based teams with access to production systems, the control plane sovereignty is incomplete.

Data access: Customer data must be accessible only by EU-personnel under EU legal process, not by non-EU parent company employees or under non-EU legal orders. Structural separation through contractual provisions, technical access controls, and EU-only key management must ensure this.

Ownership: No non-EU entity may hold a controlling interest. This is the most stringent requirement and is why some analysts believe EUCS High essentially requires a European-owned cloud provider.

For SaaS developers, this analysis matters because it helps you evaluate "sovereign cloud" marketing claims from US hyperscalers against the actual EUCS High requirements. The claim "our EU data center means your data stays in Europe" addresses data residency but not the control plane, legal entity jurisdiction, or ownership requirements.

EU-native cloud providers — companies that are incorporated in the EU, controlled by EU entities, and operated exclusively by EU-based teams — satisfy sovereignty requirements by structure, not by contractual workaround.

Practical Checklist: EUCS Compliance Questions for Your Cloud Provider

Use these questions when evaluating cloud infrastructure for EUCS-relevant use cases:

Legal and Jurisdictional

• Is the cloud service provider's contracting entity incorporated in an EU member state?
• Does any non-EU parent company have data access rights under its home country law?
• Has the provider published a legal analysis of CLOUD Act and FISA 702 applicability?
• Are there contractual provisions limiting parent company access to customer data?

Technical and Operational

• Is the provider pursuing EUCS certification, and at which assurance level?
• What is their expected certification timeline and which CAB are they working with?
• Do they have equivalent certifications (BSI C5, ISO 27001) in the interim?
• Is the control plane (support access, infrastructure management) operated exclusively by EU-based personnel?

Data and Access

• Is all data storage and processing confirmed to remain within EU territory?
• Are encryption keys managed exclusively within the EU (EU-only key management)?
• What is the process for handling a non-EU law enforcement request for customer data?
• Is there a transparency report covering government data access requests?

Supply Chain

• Does the cloud provider use any non-EU sub-processors for core services?
• If so, are those sub-processors themselves EUCS-eligible?
• Is there a supplier assessment process for the provider's own infrastructure dependencies?

Connecting EUCS to Your SaaS Architecture

The most resilient response to EUCS uncertainty is to architect your SaaS so that cloud provider compliance certifications are composable rather than central.

Data isolation at the infrastructure layer: Host customer data in EU-resident infrastructure with clear data residency guarantees. This satisfies the EUCS residency requirement regardless of other sovereignty questions, and it satisfies GDPR Chapter V transfer restrictions by design.

Dependency auditing: For NIS2 Art. 21(2)(d) supply chain requirements, document every cloud service your SaaS uses, classify them by sensitivity of data they touch, and map them against EUCS or equivalent certification status. This becomes a deliverable for enterprise due diligence.

Abstracted cloud dependencies: Where possible, use infrastructure abstractions that allow migration between cloud providers without rewriting application code. This reduces switching costs if a customer requires a specific certified provider. Container-based deployment on standards-compliant PaaS is more portable than vendor-specific managed services.

Document your security controls: EUCS Substantial requirements largely overlap with what a well-run SaaS should already be doing — vulnerability management, access controls, incident response, logging. Document these controls in a format that responds to EUCS-style due diligence questions. Your security documentation is increasingly a sales asset.

The Bottom Line

EUCS is moving from a technical specification to a market reality. The timeline is measured in years, not decades: NIS2 transposition is complete across most EU member states, procurement frameworks are incorporating EUCS, and regulated enterprises are beginning to require cloud security certifications from their SaaS vendors.

The core message for SaaS developers:

1. Know your customers' NIS2 status — if they are essential or important entities, EUCS will appear in their supplier assessments
2. Know your cloud provider's certification path — ask explicitly about EUCS and equivalent national certifications
3. Understand the sovereignty distinction — data residency and EUCS sovereignty are different requirements; EU data center ≠ EUCS-compliant
4. Start your documentation now — EUCS-style security documentation is useful regardless of certification timeline

Choosing EU-native cloud infrastructure from providers that are structured for EUCS compliance by design — rather than retrofitting US cloud through sovereign wrappers — is the lowest-risk path. When EUCS becomes a requirement, not a preference, the infrastructure question is already answered.

Related guides: NIS2 Art. 21 Supply Chain Security, Why AWS European Sovereign Cloud Doesn't Solve the CLOUD Act Problem, Schrems III Warning Signs: EU-US Data Transfer Risk in 2026