CRA Art.13 Security by Design 2026: Why Your PaaS Jurisdiction Is Now a Compliance Requirement

Post #4 in the sota.io EU Cyber Resilience Act Series

The EU Cyber Resilience Act (CRA, Regulation 2024/2847) introduces a concept that sounds simple but has profound infrastructure implications: security by design and default. Under Article 13, every manufacturer of a "product with digital elements" must ensure that security is not an afterthought bolted on at the end of development — it must be architecturally embedded from the start.

For developers building SaaS products, developer tools, or any software sold into the EU market, this means documenting your security architecture, minimising your attack surface, and demonstrating that your product defaults to secure configuration. The CRA begins applying to most product categories on 13 September 2026.

But here is the compliance gap that almost no one is talking about: if your product runs on a US-headquartered PaaS platform, your "secure by design" architecture includes a legal backdoor that CRA compliance cannot close.

What CRA Article 13 Actually Requires

Article 13 sets out the operational security obligations for manufacturers. Combined with Annex I (the essential cybersecurity requirements), it creates a comprehensive framework for how digital products must be built and maintained.

The core requirements under Art.13 and Annex I Part I include:

1. No known exploitable vulnerabilities at the time of placing on the market — your product must ship with a clean vulnerability profile. Deploying onto infrastructure that has known CLOUD Act exposure creates a documented legal vulnerability that cannot be mitigated through software patching.

2. Secure by default configuration — products must ship in their most secure state, with all features that are not needed disabled, and with security protections active from day one. If your PaaS provider can be legally compelled to access your infrastructure without your knowledge (18 USC § 2703(f)), your "secure default" configuration is compromised by design.

3. Minimisation of attack surface — you must implement the principle of least privilege, reduce exposed network interfaces, and limit access to sensitive functions. FISA Section 702 orders issued to US cloud providers are a non-minimisable attack surface expansion — one that exists at the infrastructure layer, below your application code.

4. Logging and monitoring capabilities — Art.13(2)(f) requires that products enable recording and monitoring of relevant security events. If your infrastructure provider is under a NSL (National Security Letter) with a non-disclosure order, your logging chain has a legally enforced gap.

5. Security update mechanisms — manufacturers must provide security updates for the expected product lifetime (minimum five years for most products under Art.13(8)). Security update delivery through a US-controlled supply chain is subject to Executive Order interference and CLOUD Act demands.

The CLOUD Act Structural Gap

The US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) requires US-headquartered cloud providers to comply with lawful US government demands for data stored anywhere in the world — including in EU data centres.

This is not a theoretical risk. It is a documented legal obligation that the hosting provider cannot refuse. AWS, Microsoft Azure, Google Cloud, and every other US-domiciled PaaS platform operates under this constraint regardless of where their EU region is physically located.

For CRA Art.13 compliance, this creates three specific failure modes:

Failure Mode 1: The Undisclosed Access Problem

Under 18 USC § 2705(b), US authorities can obtain a court order preventing a cloud provider from notifying the customer that a data request has been served. This is directly incompatible with Art.13(2)(d) — the requirement that products "protect against unauthorized access to data." If the access is legally authorised under US law but constitutes unauthorized access under EU law, your security architecture has a permanent compliance gap.

Your legal team can document this risk. Your privacy policy can reference it. But your Art.13 compliance documentation cannot truthfully state that your product "protects against unauthorized access" when a class of authorized-under-US-law access exists that you cannot detect, prevent, or log.

Failure Mode 2: The Security Update Supply Chain Problem

CRA Art.13(8) requires security updates to be delivered separately from functionality updates, clearly identified, and made available for the expected product lifetime. When your update delivery mechanism runs through a US-domiciled infrastructure provider, the update supply chain is subject to CLOUD Act demands.

The concern here is not routine. In a scenario where a vulnerability in your product overlaps with a US law enforcement investigation target, a CLOUD Act demand for your deployment environment could theoretically delay or interfere with your patch delivery process during a critical incident window — precisely the period covered by Art.10's 24-hour reporting obligation and Art.14's coordinated disclosure window.

Failure Mode 3: The Documentation Integrity Problem

CRA Art.13(15) requires manufacturers to maintain technical documentation demonstrating conformity. This documentation must describe the security architecture, the threat model, and the measures taken to meet each essential requirement in Annex I.

How do you document an "essential cybersecurity requirement" being met when a legal mechanism exists that you cannot fully disclose, that bypasses your access controls, and that your infrastructure provider is legally prohibited from describing to you after the fact?

The honest answer is: you cannot document it truthfully while remaining in compliance with US law simultaneously.

The EU-Native Advantage for Art.13 Compliance

EU-domiciled PaaS providers — those incorporated and headquartered within EU member states, without US parent companies or significant US investors who could create de facto CLOUD Act exposure — do not operate under the CLOUD Act. They cannot be compelled by US authorities to produce your data. There is no legally mandated silent access mechanism.

This means:

Clean compliance documentation. Your Art.13 technical documentation can state, accurately and verifiably, that access to your infrastructure is controlled by EU law only. No US-law exception class exists. Market surveillance authorities reviewing your conformity documentation will not find a CLOUD Act footnote in your architecture.

Genuine secure-by-default configuration. Your access control architecture has no externally imposed bypass class. The attack surface minimisation you implement in your code actually reflects your deployed attack surface — not a subset of it with a US-government-accessible exception.

Audit trail integrity. Your security event logging captures all access that is legally accessible to any actor. There is no class of access — NSL-compelled, FISA-authorized, or otherwise — that your logs cannot record because the legal mechanism that would generate it does not apply to your infrastructure provider.

Supply chain clarity. Your security update delivery chain runs through entities whose legal obligations are entirely within EU law. The SBOM your Art.11 vulnerability handling process maintains does not need to account for US-law supply chain interference scenarios.

What This Means for September 2026

The CRA enters application on 13 September 2026 for most products. The conformity assessment process — whether self-assessed or third-party — requires you to demonstrate compliance with Annex I Part I before placing your product on the market.

Market surveillance authorities can request your technical documentation at any time. If your documentation describes a security architecture that includes a CLOUD Act exposure, you have two options: describe it accurately (and acknowledge the compliance gap) or describe it inaccurately (and face Art.64 penalties of up to €15M or 2.5% of global turnover for providing incorrect information to authorities).

The window for migrating infrastructure is narrowing. September 2026 is four months away. A typical production migration from a US-domiciled PaaS to an EU-native alternative takes 4-8 weeks for a mid-size application — but that assumes you have already chosen the platform, configured CI/CD, and validated performance parity. Starting that process today gives you time to complete it before the CRA deadline.

Starting it in August does not.

The CRA Series So Far

This post is part of our ongoing analysis of CRA provisions and their infrastructure implications:

• CRA Art.10: Vulnerability Reporting 2026 — The 24-hour ENISA notification requirement and why your hosting jurisdiction determines your compliance burden during an active vulnerability response.
• CRA Art.14: Coordinated Vulnerability Disclosure 2026 — The 9-month CVD window and CLOUD Act exposure of vulnerability data during the coordination period.
• CRA Penalty Framework 2026 — The tiered fine structure (€15M / 2.5% global turnover) and how US-hosted deployments compound your penalty exposure.

Practical Implementation Checklist for Art.13 Compliance

For developers building products targeting the EU market and deploying on EU-native infrastructure:

Before September 2026:

• Complete infrastructure audit: identify all US-domiciled service dependencies (PaaS, CDN, email, observability, error tracking)
• For each US-domiciled service: assess CLOUD Act exposure and document in threat model
• Evaluate EU-native alternatives for critical path infrastructure
• Begin migration for highest-impact dependencies (compute, storage, deployment pipeline)

Art.13 Documentation Requirements:

• Document your threat model including legal threat actors (government compulsion scenarios)
• For each Annex I Part I requirement: document the technical control and its jurisdiction
• If US infrastructure remains: document the CLOUD Act risk in your conformity assessment with mitigation measures (encryption, separation, fallback procedures)
• Establish security update delivery timeline SLA and verify supply chain independence

For EU-Native Deployments:

• Confirm PaaS provider's incorporation jurisdiction (not just data centre location)
• Verify no US parent company relationship that creates de facto CLOUD Act exposure
• Document jurisdiction confirmation in technical documentation for market surveillance authorities

The Architectural Truth

CRA Article 13 is ultimately about architectural honesty. Security by design means that security properties are intrinsic to the architecture — not dependent on policies, promises, or contractual limitations on provider behaviour.

A CLOUD Act exposure is an architectural property. It cannot be contracted away. It cannot be mitigated with encryption if the compulsion targets your key management service. It cannot be documented away in a privacy policy if market surveillance authorities are evaluating your conformity with Annex I.

The CRA's security-by-design mandate is, at its core, a mandate to choose infrastructure whose legal obligations are consistent with your security architecture. For products sold in the EU market, that means EU-native infrastructure.

sota.io is a EU-native PaaS platform, incorporated and operated within the EU, with no US parent company. Our infrastructure operates exclusively under EU law — no CLOUD Act, no FISA Section 702, no NSL disclosure obligations. If you're evaluating infrastructure for CRA Art.13 compliance, start your free trial or contact us to discuss your migration timeline.