EUCS High Level Certification: Exact Technical Requirements and What EU Cloud Providers Must Prove

Post #2 in the sota.io EU Cloud Sovereignty Series

The first post in this series established the landscape: EUCS defines three assurance levels, and US-owned cloud providers structurally cannot reach the High Level due to CLOUD Act jurisdiction. This post goes one layer deeper — into the actual technical and legal requirements that a cloud provider must satisfy to claim High Level certification.

If you are a SaaS developer evaluating cloud infrastructure, or a procurement team assessing vendor claims, this is the specification you need to hold providers accountable against.

Why High Level Exists as a Separate Category

EUCS Basic and Substantial levels address technical security controls: access management, encryption, incident response, audit logging. Any competent cloud provider operating with modern security practices can achieve Substantial Level certification through documented controls and third-party audits.

High Level adds a requirement that no amount of technical controls can satisfy if the underlying corporate structure is wrong: legal sovereignty. Specifically:

A cloud provider at EUCS High Level must demonstrate that no non-EU legal authority can compel access to certified workloads without following EU law and the mutual legal assistance treaty (MLAT) process.

This is not a judgment about technical capability. AWS, Azure, and GCP have excellent security engineering. The disqualifying factor is organizational: they are incorporated in the United States, which means the US CLOUD Act (Clarifying Lawful Overseas Use of Data Act) applies to them globally, including their EU infrastructure.

A US federal court can issue a warrant requiring a US-incorporated company to produce data stored anywhere in the world — including Frankfurt, Amsterdam, or Dublin. The EU Cloud Scheme, at the High Level, treats this legal exposure as a certification failure regardless of where the bytes sit.

The Six Technical Control Domains

EUCS High Level certification is structured around six control domains. Each domain has specific requirements that go beyond what Substantial Level demands.

1. Cryptographic Controls and Key Sovereignty

At Substantial Level: provider-managed encryption with documented key management procedures.

At High Level:

• Hardware Security Module (HSM) requirement: All encryption keys protecting High Level workloads must be generated, stored, and used within HSMs. Software key stores are not acceptable.
• Customer-managed key option mandatory: Providers must offer HSM-backed customer-managed keys (CMK) where the customer holds the key material and the provider never has access to unencrypted workload data.
• Key import restrictions: Key derivation processes must prevent the provider's operations personnel from ever holding plaintext key material.
• HSM certification: The HSMs themselves must be certified to FIPS 140-3 Level 3 or Common Criteria EAL4+ with augmented cryptographic requirements.

This is why Hetzner's approach of offering physical hardware with customer-controlled root access is structurally better positioned for High Level compliance than shared virtualized infrastructure with provider-managed encryption by default.

2. Access Control and Identity Management

At Substantial Level: multi-factor authentication for all administrative access, privileged access management, access logs.

At High Level:

• EU-based privileged access only: Personnel with privileged access to High Level infrastructure must be EU residents and subject exclusively to EU employment law. Remote access by non-EU staff is prohibited even for emergency operations.
• Dual-person integrity (DPI): Any administrative action on production systems requires authorization from two separate EU-based staff members. No single administrator can execute privileged commands unilaterally.
• Hardware authenticators mandatory: Software TOTP or SMS MFA is insufficient. Physical hardware security keys (FIDO2/WebAuthn with EU-resident key holders) are required for all privileged access.
• Access review cycle: Formal access reviews at 90-day maximum intervals with documented revocation of unused access rights.

3. Physical Security and EU Infrastructure Residency

At Substantial Level: EU data residency is required, with standard physical security controls at data centers.

At High Level:

• EU-only data center ownership or long-term lease: The provider must demonstrate that EU law, not foreign law, governs the physical premises where High Level workloads run. This typically requires either EU-incorporated ownership or lease agreements with explicit European jurisdiction clauses.
• Physical security certification: Data centers must hold ISO/IEC 27001 certification with additional physical security controls documented to IEC 62443-2-4 standards.
• Supply chain country-of-origin restrictions: Network hardware, servers, and HSM equipment must come from countries that do not present jurisdiction risk. Hardware from US manufacturers (Cisco, Intel, etc.) is technically permissible at component level, but firmware and management software must not create backdoor access under non-EU law.
• Canary warrant prohibition documentation: The provider must demonstrate that it has mechanisms to notify customers of lawful access attempts within the scope permitted by applicable EU law, and that no standing agreements exist to provide silent access to third-party governments.

4. Incident Response and Sovereign Escalation

At Substantial Level: incident notification to competent authorities within EUCS-defined timeframes, documented incident response plan.

At High Level:

• EU-sovereign incident response team: The team handling security incidents for High Level workloads must consist of EU residents. The incident response plan must not route escalation paths through non-EU parent company security operations centers.
• ENISA notification: Major security incidents affecting High Level certified workloads require notification to ENISA in addition to relevant national CSIRT, with defined SLAs.
• Sovereign data recovery: Backup and disaster recovery processes must ensure that recovery operations cannot be blocked or compromised by actions of non-EU legal authorities — including orders to third-party backup providers.
• Legal threat response protocol: The provider must have a published, legally reviewed protocol for responding to requests for access from non-EU authorities — specifically, a commitment to contest such requests through EU legal channels before any data disclosure.

5. Audit, Certification, and Conformity Assessment

At Substantial Level: third-party security audit by an accredited certification body (CAB), with audit report made available to customers under NDA.

At High Level:

• Annual full-scope audits: Continuous monitoring plus a full-scope conformity assessment annually by an ENISA-accredited CAB.
• Penetration testing requirements: Independent red team exercises at minimum annually, with test reports reviewed by the CAB as part of the certification assessment.
• Transparency report obligations: The provider must publish an annual transparency report covering: number of legal access requests received, number contested, number complied with (to the extent permitted by law), and the outcomes.
• Certification evidence made public: Unlike lower levels where audit reports can be confidential, High Level certification requires that the certification decision and summary of material findings is publicly accessible — so customers and procurement authorities can verify claims independently.

6. Legal Entity and Ownership Structure

This is the control domain where US-owned hyperscalers fail, and no technical investment can fix it without corporate restructuring.

At High Level:

• EU legal entity requirement: The cloud provider operating High Level infrastructure must be incorporated and headquartered in an EU member state (or EEA country with equivalent legal treatment). A subsidiary or branch of a non-EU corporation is not sufficient because the parent corporation's legal obligations extend to subsidiary data.
• Beneficial ownership transparency: Ultimate beneficial ownership must be documentable to the CAB as EU-resident with no controlling interest by entities subject to non-EU compelled access laws.
• CLOUD Act non-applicability certification: The provider must obtain a legal opinion from an EU-qualified attorney confirming that no provisions of the US CLOUD Act, UK Investigatory Powers Act, or equivalent non-EU compelled access legislation apply to the provider's High Level infrastructure operations.

This requirement is what renders AWS (incorporated in Delaware), Microsoft Azure (Washington State), and GCP (California) non-compliant at the High Level, regardless of their Frankfurt, Dublin, or Amsterdam data center investments.

Who Is Currently Pursuing High Level Certification?

As of mid-2026, EUCS High Level is not yet formally adopted as a mandatory certification scheme — the European Commission is still finalizing the regulatory basis. But several EU-native providers are already building toward anticipated High Level requirements:

OVHcloud (France): Europe's largest cloud provider by revenue. EU-incorporated, no US parent. Has explicitly positioned EUCS High Level compliance as a strategic objective. Already holds SecNumCloud certification from ANSSI (France's national cybersecurity agency), which many experts consider a technical superset of anticipated EUCS High Level requirements.

Hetzner Online (Germany): Privately held, German-incorporated. All infrastructure in Germany and Finland. Does not publicly market EUCS positioning but meets the structural requirements — EU legal entity, no non-EU parent, physical infrastructure on EU soil.

IONOS Cloud (Germany): Subsidiary of United Internet AG (Frankfurt Stock Exchange listed, German parent). Pursuing cloud certification under German C5 standard (BSI), which aligns closely with anticipated EUCS High Level requirements.

Scaleway (France): Subsidiary of Iliad SA (French telecoms company). EU-incorporated parent. Explicitly positions EUCS High Level readiness in enterprise sales materials.

Deutsche Telekom Cloud (T-Systems): The sovereign cloud division of Deutsche Telekom. Pursuing full EUCS High Level certification with dedicated EU-employee operations teams and German-law-governed infrastructure contracts.

Notably absent from High Level pursuit: AWS (pursuing only Substantial), Azure (EU Data Boundary covers Substantial requirements), GCP (similar position to Azure). All three acknowledge the jurisdictional barrier and do not market High Level compliance.

What SaaS Developers Should Demand From Cloud Providers

If you are building on cloud infrastructure for EU customers in regulated sectors — healthcare, finance, defense supply chain, critical infrastructure — here is how to use EUCS High Level requirements as a procurement filter:

Question 1: What is your legal entity structure? Demand the provider's registration documents and a legal opinion confirming no non-EU parent company has controlling interest. "We have data centers in Germany" is not the same as "we are a German company not subject to the CLOUD Act."

Question 2: Who has privileged access to my workloads? High Level requires EU-resident personnel only. Ask for the provider's staffing policy for privileged operations roles. If they route support escalations through a US-based NOC, that is a disqualifying condition.

Question 3: Where are your encryption keys generated? HSM-backed customer-managed keys are the High Level standard. If the provider offers customer-managed keys only through software key stores, they are at Substantial Level at best. Ask specifically: "Are CMKs generated within HSMs certified to FIPS 140-3 Level 3?"

Question 4: How do you respond to non-EU law enforcement requests? Ask for the provider's published legal access protocol. A provider at High Level should have a documented commitment to contest non-EU legal access requests and notify customers within legally permitted bounds.

Question 5: What is your EUCS certification timeline? If a provider cannot give you a specific answer — either "we hold certification from [CAB] effective [date]" or "we are in active certification assessment, expected completion [quarter]" — treat their EUCS claims as marketing. Actual certification requires an accredited third party to sign off.

The EUCS Certification Timeline for 2026-2027

The EU Cybersecurity Act established the framework. ENISA published the EUCS candidate scheme. The European Commission must issue an implementing act to make EUCS formally binding — this step is expected in late 2026 or 2027 based on the current legislative schedule.

What does "not yet formally binding" mean in practice?

• Public sector procurement: Many EU member states are already requiring EUCS-equivalent controls in cloud tenders, referencing SecNumCloud (France), C5 (Germany), or ENS Alto (Spain) as interim equivalents. Providers who cannot demonstrate alignment with these national schemes are losing public sector deals today.
• Regulated industries: DORA, NIS2, and the AI Act all reference the EU Cybersecurity Act certification framework. Before EUCS becomes formally mandatory, regulators in banking and critical infrastructure are using it as guidance for supervisory expectations.
• Private sector early adoption: Enterprise customers in healthcare and finance are including EUCS High Level requirements in RFPs now, ahead of formal adoption, because retrofitting provider selection after mandatory adoption is operationally expensive.

The practical advice: if your SaaS product will serve EU public sector or regulated industry customers in 2027 or beyond, your cloud provider selection decision is not just a technical choice — it is a compliance upstream dependency. A provider who cannot achieve High Level certification could become a disqualifying factor in customer procurement processes within 12-24 months.

How sota.io Is Positioned

sota.io runs exclusively on Hetzner infrastructure in Germany. No US parent company. No shared operations with non-EU entities. No CLOUD Act exposure.

This is not a marketing claim we make — it is a structural fact about how the platform is built. Every compute instance, every database, and every network layer operates on infrastructure owned and operated by a German-incorporated company without US-parent jurisdiction.

For SaaS teams deploying on sota.io, this means your production workload inherits the infrastructure sovereignty of an EU-native stack from day one. You do not need to configure special regions, negotiate EU Data Boundary commitments, or audit whether your provider's NOC is routing support tickets through Virginia.

In EUCS terms, sota.io's infrastructure is built on Substantial Level-capable providers today, and aligned with anticipated High Level structural requirements — because those requirements describe how EU-native infrastructure should be built, not an exceptional standard.

Next in this series: EUCS Certification for SaaS Tenants — What Your Cloud Vendor's Certification Means for Your Compliance Obligations

Previous: EUCS Cloud Assurance Levels 2026: Why AWS, Azure, and GCP Cannot Reach the Highest EU Certification