CRA Penalty Framework 2026: The €15M Fine Risk That Makes EU-Native Hosting a Strategic Imperative

Post #3 in the sota.io CRA Compliance Series

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024. Most developers know it requires security-by-design and vulnerability patching. Fewer have read the penalty framework — and almost none have calculated how their infrastructure choices affect their fine exposure.

This post breaks down the CRA penalty tiers, explains why CLOUD Act interference creates a hidden compliance multiplier, and quantifies the risk difference between US-hosted and EU-native deployments.

The CRA Penalty Tiers (Article 52)

The CRA establishes three tiers of administrative fines:

Tier 1 — €15,000,000 or 2.5% of global annual turnover (whichever is higher)

Applies to violations of the essential cybersecurity requirements set out in Annexes I and II. These cover security-by-design obligations including: no known exploitable vulnerabilities at time of market entry, secure default configuration, protection of data confidentiality and integrity, minimal attack surface, and documented software bill of materials (SBOM).

For a company with €100M global turnover, this means a maximum fine of €2.5M. For a €1B company, it's €25M.

Tier 2 — €10,000,000 or 2% of global annual turnover (whichever is higher)

Applies to violations of other obligations in the CRA — including documentation requirements, conformity assessment procedures, CE marking obligations, and cooperation with market surveillance authorities.

Tier 3 — €5,000,000 or 1% of global annual turnover (whichever is higher)

Applies to providing incorrect, incomplete, or misleading information to national market surveillance authorities or to EU-level coordination bodies.

For microenterprises and small enterprises (fewer than 50 employees, annual turnover under €10M), the regulation provides for reduced maximum fines — market surveillance authorities must take proportionality into account.

The CRA Enforcement Timeline

Understanding when these fines become applicable is critical:

The September 2026 date is the near-term cliff. Article 14 requires manufacturers to notify ENISA of actively exploited vulnerabilities within 24 hours of becoming aware. Article 15 requires follow-up notification within 72 hours with more detail. Both carry Tier 2 fine exposure.

We covered the 24-hour reporting obligation in detail in CRA Art.10 Vulnerability Reporting 2026 and the coordinated disclosure framework in CRA Art.14 CVD 2026. This post focuses on the penalty multiplier that hosting jurisdiction creates.

The Hidden CRA Fine Multiplier: CLOUD Act Interference

Here is the compliance scenario that most legal teams have not modeled:

Scenario: Active exploit discovered, 24-hour ENISA clock running

You are a German SaaS company. Your application runs on AWS (Virginia) or Vercel (Delaware). An attacker is actively exploiting a vulnerability in your product. Under CRA Art.14, you have 24 hours to notify ENISA.

During those 24 hours:

1. Your forensic access may be disrupted. A US law enforcement agency, under 18 U.S.C. §2703 (the Stored Communications Act, the technical core of CLOUD Act compulsion), can demand your cloud provider hand over data without notifying you. AWS, Microsoft Azure, and Google Cloud are all subject to this. Your incident response team may lose access to logs, container state, or configuration at the worst possible moment.

2. Your vendor's CLOUD Act response may breach confidentiality. Under 18 U.S.C. §2705(b), the government can prohibit your provider from notifying you of a demand. You may not know your forensic evidence has been accessed — or partially removed from your view — during active incident response.

3. ENISA notification accuracy suffers. The CRA requires your 24-hour notification to include information about the vulnerability, the nature of the exploit, and affected products. If your infrastructure provider's CLOUD Act response has interfered with your forensic access, your ENISA notification may be incomplete — triggering Art.52 Tier 2 fine exposure.

4. Market surveillance authority access. National market surveillance authorities (MSAs) — in Germany, the Bundesamt für Sicherheit in der Informationstechnik (BSI); in France, ANSSI — are tasked under CRA Chapter VII with auditing your compliance. If your deployment infrastructure is US-based, an MSA's request for infrastructure-level evidence may be complicated by cross-jurisdictional conflicts. Evidence you need to provide to demonstrate compliance may be subject to US export controls or attorney-client privilege claims asserted by your US cloud provider.

None of these scenarios automatically result in a CRA fine. But each one creates friction that increases your exposure: delayed notification, incomplete documentation, reduced cooperation with market surveillance authorities.

Market Surveillance: What Authorities Actually Check

The CRA's market surveillance framework assigns significant powers to national authorities:

• Access to premises and documentation. MSAs can demand access to technical documentation, source code (for high-risk product categories), test results, and deployment records.
• Product testing and audits. For products in critical categories (Annex III and IV), MSAs can require third-party conformity assessments and conduct their own technical testing.
• Corrective measures. MSAs can order product withdrawal, recall, or restriction of market access for products that do not comply with Annex I/II requirements.
• Information sharing. Under the RAPEX/ICSMS system (now integrated into the Market Surveillance Information and Communication System — ICSMS), MSAs share findings across EU member states. A finding in Germany is visible to authorities in France, the Netherlands, and all other member states.

When your deployment infrastructure is US-based, an MSA audit creates a chain of custody problem:

1. MSA requests deployment logs demonstrating your CI/CD pipeline enforces SBOM generation.
2. Your CI/CD runs on GitHub Actions (Microsoft, Delaware) or CircleCI (CircleCI Inc., Delaware).
3. GitHub's terms allow Microsoft to comply with US legal process. CircleCI's do the same.
4. The MSA, operating under EU law, may be unable to independently verify that the evidence you provide has not been modified, filtered, or withheld under a US CLOUD Act demand.

This is not a theoretical concern. The EDPB's 2022 SCCs guidance and the ECJ's Schrems II ruling already established that Standard Contractual Clauses do not override CLOUD Act obligations. The same legal reality applies in the CRA enforcement context.

CRA Risk Matrix: US-Hosted vs EU-Native

Note: Tier 1 fines apply to the security properties of your product, not your infrastructure. If your software has exploitable vulnerabilities, EU-native hosting does not reduce your Tier 1 exposure. The hosting advantage is concentrated in Tier 2 (documentation, reporting, cooperation) and the practical ability to meet Art.14's 24-hour reporting window cleanly.

The SME Calculation

For small and medium enterprises, the CRA penalty framework includes proportionality provisions. MSAs "shall take into account" the enterprise's size, economic situation, and market position when determining penalties. However, proportionality does not eliminate fine exposure — it caps the maximum for qualifying companies.

More important for SMEs is the practical burden of CRA compliance with US infrastructure:

Legal review costs. Every CLOUD Act demand disclosure situation requires legal analysis of your obligations under both US law and EU law. Dual jurisdiction = double legal costs.

Insurance premium impact. Cyber insurance underwriters are beginning to price CLOUD Act exposure into premiums for EU-based companies using US cloud infrastructure. The CRA creates a regulatory framework that makes this pricing more concrete.

Customer contract risk. Enterprise customers subject to NIS2 or sector-specific regulations (DORA for financial services, medical device regulations for health tech) are increasingly requiring that their SaaS vendors can demonstrate CRA-compliant deployments. US-hosted deployments create friction in procurement and contract negotiations.

The CRA-GDPR Compound Risk

The CRA's penalty framework operates independently of GDPR. A single security incident that involves personal data can generate fines under both:

• GDPR Art.33 (72-hour breach notification to supervisory authority): Up to €10M or 2% global turnover.
• CRA Art.14 (24-hour ENISA notification of actively exploited vulnerability): Up to €10M or 2% global turnover.

These are separate legal bases, separate enforcement authorities, and separate penalty calculations. A significant incident could generate both.

The CLOUD Act interference risk applies to both. Your ability to make a complete 72-hour GDPR notification and a complete 24-hour CRA notification depends on your forensic access during the incident window. US-hosted infrastructure creates two simultaneous points of failure in that forensic chain.

Enforcement Geography: Where Are the MSAs?

The CRA designates national market surveillance authorities in each member state. For software and digital products, the most active MSAs are expected to be:

• Germany: BSI (Bundesamt für Sicherheit in der Informationstechnik) — already active in NIS2 enforcement
• France: ANSSI (Agence nationale de la sécurité des systèmes d'information) — established enforcement track record
• Netherlands: NCSC-NL — coordinating with European partners
• Sweden: NCSC-SE and Swedish Post and Telecom Authority

The CRA includes a "home country" rule — enforcement is primarily coordinated by the MSA in the member state where the product manufacturer has its main EU establishment. However, because findings are shared via ICSMS, enforcement in one member state creates visibility across all.

For non-EU companies selling products in the EU market, the CRA requires designation of an EU-authorized representative — who bears legal liability for compliance documentation. This representative cannot easily explain away CLOUD Act interference to an MSA conducting an audit.

The December 2027 Deadline

The full CRA enforcement date is 11 December 2027 — 19 months from now. This seems distant, but the compliance timeline for Annex I/II requirements (essential cybersecurity requirements) requires:

1. Security assessment of existing products (many months)
2. SBOM generation and maintenance pipeline (3-6 months implementation)
3. Vulnerability management process aligned with ENISA's EUVDB (3-4 months)
4. Technical documentation sufficient to satisfy MSA audit (months of work)
5. Conformity assessment for Annex III/IV products (third-party audit cycles of 6-12+ months)

Companies that begin CRA compliance programs in late 2026 will struggle to meet the December 2027 deadline. Infrastructure migration — moving from US-hosted PaaS to EU-native infrastructure — is typically a 3-6 month project depending on architecture complexity.

The September 2026 vulnerability reporting deadline provides the earliest enforcement cliff. Companies not on EU-native infrastructure should treat Q3 2026 as their practical deadline for infrastructure migration, not Q4 2027.

What EU-Native PaaS Changes

Deploying on EU-native infrastructure — with no US parent company, no CLOUD Act jurisdiction, and servers in Germany or another EU member state — changes the compliance calculus in three ways:

1. Clean forensic access during incident response. Your infrastructure provider cannot receive a CLOUD Act demand because it has no US legal entity. Your 24-hour Art.14 notification window is not disrupted by a parallel US legal process.

2. Simplified market surveillance cooperation. When a national MSA requests deployment evidence, your infrastructure provider operates entirely under EU law. No cross-jurisdictional conflict. No foreign legal claims over your deployment data.

3. Single legal jurisdiction for incident documentation. Your GDPR breach notification and your CRA vulnerability notification both operate in the same legal framework. No dual-track compliance documentation.

sota.io is an EU-native managed PaaS: registered in Germany, operated on Hetzner Germany infrastructure, with no US parent company and no CLOUD Act exposure. Your deployments, your logs, and your incident forensics stay in EU jurisdiction throughout the CRA compliance lifecycle.

CRA Compliance Checklist for Platform Teams

Before December 2027 (all requirements) and September 2026 (vulnerability reporting):

• SBOM generation. Does your CI/CD pipeline generate a Software Bill of Materials for each release? Is it accessible for MSA audit?
• Vulnerability tracking. Do you have a process to identify actively exploited vulnerabilities in your product components within hours of public disclosure?
• ENISA EUVDB registration. Are you registered (or planning to register) with ENISA's European Vulnerability Database for your CVD process?
• 24-hour notification capability. Can you file a complete ENISA notification within 24 hours of discovering an actively exploited vulnerability? Does your incident response runbook assume uninterrupted infrastructure access?
• Infrastructure jurisdiction audit. Does any component of your deployment infrastructure (CI/CD, container registry, secrets management, monitoring) have a US parent company?
• Technical documentation. Do you maintain documentation sufficient to demonstrate Annex I/II compliance to a national MSA?
• EU-authorized representative. If your company is outside the EU, have you designated an EU-authorized representative with access to your compliance documentation?

Summary

The CRA penalty framework creates three tiers of fine exposure: €15M/2.5% for security failures, €10M/2% for documentation and reporting failures, and €5M/1% for misleading authorities. Tier 2 exposure — documentation and reporting — is where infrastructure choice matters most.

CLOUD Act interference during incident response, market surveillance authority audit complications, and cross-jurisdictional evidence conflicts all increase Tier 2 fine exposure for companies using US-owned infrastructure. EU-native hosting eliminates these compounding factors.

With the September 2026 vulnerability reporting deadline 16 months away and infrastructure migrations typically requiring 3-6 months, the decision window for platform teams is now.

sota.io provides EU-native managed PaaS with no US parent company and full GDPR + CRA-aligned deployment infrastructure. Deploy your first project in minutes.