CRA Compliance Complete Guide 2026 — Every Article, Every Deadline, EU-Native PaaS Advantage

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

The EU Cyber Resilience Act is now law. After years of drafting, debate, and technical annexes, the CRA entered into force on 10 December 2024. Developers, product managers, and CTOs across Europe — and any non-EU company shipping connected products to EU customers — have two hard deadlines:

• 11 September 2026: Vulnerability reporting to ENISA becomes mandatory (Article 14 + Article 11 24-hour notification)
• 11 December 2027: Full CRA compliance required — all security requirements, documentation, CE marking, conformity assessment

With 14 months left until the first deadline and 30 months until full enforcement, the question for most engineering teams is no longer "does the CRA apply to us?" It almost certainly does. The question is: what exactly do you need to do, and why does your cloud provider's jurisdiction affect whether you can actually do it?

This post is the complete guide. We've covered every major CRA article in this series over the last several weeks. This finale collects all 17 posts, explains how they interconnect, and shows why EU-native infrastructure is not a "nice to have" for CRA compliance — it's a structural prerequisite for several of the most critical obligations.

Who the CRA Applies To

The CRA applies to any manufacturer, importer, or distributor of products with digital elements placed on the EU market. The definition is intentionally broad:

• Hardware with embedded software: routers, IoT devices, industrial controllers, medical devices
• Software products: standalone applications, SaaS products, operating systems, development tools
• Remote data processing: cloud services that are integral to the product's function

The critical test is whether your product has "direct or indirect logical or physical data connection to a device or network." For most SaaS products and APIs, the answer is yes.

Free and open source software is largely excluded if it's developed outside a commercial context — but the moment your OSS project is commercialised (monetised, offered as a managed service, included in a commercial product), the CRA applies to the commercial use. Article 24 creates specific obligations for open source stewards who maintain components used in CRA-covered products.

The Two Deadlines in Detail

September 2026: Vulnerability Reporting Begins

From 11 September 2026, manufacturers must notify ENISA within:

• 24 hours of becoming aware of an actively exploited vulnerability (Article 11)
• 72 hours of becoming aware of a security incident (Article 14)
• 14 days for a detailed follow-up report

This is the deadline that catches most teams off guard because it doesn't require full CE marking — it's just the reporting obligation. But the infrastructure implications are significant. Your logging, alerting, and incident response systems must be capable of detecting and confirming a vulnerability within 24 hours of active exploitation, then transmitting a compliant notification to ENISA.

If your infrastructure runs on a US-headquartered cloud provider, there's a structural problem: US National Security Letters can compel your provider to silently withhold information about security incidents from you. CLOUD Act authority means US government agencies can access your infrastructure data without your knowledge. During the exact window where you need complete, unobstructed visibility to meet a 24-hour ENISA notification, your cloud provider may legally be unable to tell you something is wrong.

December 2027: Full Compliance Required

From 11 December 2027, all covered products placed on the EU market must:

• Meet all essential security requirements (Annex I)
• Have complete technical documentation (Article 27 + Annex V)
• Have a software bill of materials (SBOM) for all third-party components
• Have undergone conformity assessment (Article 32) — self-assessment for most Class I products, third-party audit for Class II
• Bear the CE marking
• Have a coordinated vulnerability disclosure (CVD) policy (Article 14)
• Have a post-market monitoring system (Article 9)

Article-by-Article: The Complete CRA Series

Foundational Classification

CRA Art.6: Product Classification — Class I, Class II, Annex III/IV

Before you can design a compliance program, you need to know which category your product falls into. Article 6 defines the risk-based classification:

• Default (unclassified): Self-assessment conformity. Most software products. Still full Annex I requirements.
• Class I (important products): Stricter documentation, option of third-party audit. Includes browsers, password managers, VPNs, firewalls, operating systems.
• Class II (critical products): Mandatory third-party audit. Includes hardware security modules, smart meter gateways, microcontrollers for security functions.
• Annex III/IV (highly critical): Additional sector-specific requirements. HSMs, smart cards, industrial control systems, medical devices.

The classification determines your conformity assessment path and influences how much documentation you need. But it doesn't change the core Annex I security requirements — those apply to every covered product.

Core Security Requirements

CRA Annex I: Essential Security Requirements Checklist

Annex I is the technical heart of the CRA. It lists 11 essential security requirements that every covered product must meet:

1. Products must be delivered without known exploitable vulnerabilities
2. Products must have secure default configurations
3. Products must protect against unauthorised access
4. Products must protect the confidentiality and integrity of stored/transmitted data
5. Products must minimise attack surfaces
6. Products must minimise the impact of incidents
7. Products must log security-relevant events
8. Products must enable users to update software securely
9. Products must not negatively affect network security
10. Products must be designed to limit data collection (data minimisation)
11. Products must offer protection mechanisms against physical tampering (hardware)

For SaaS and software-as-a-product developers, requirements 1-8 and 10-11 are directly applicable. Requirements 4 (data confidentiality) and 7 (logging) have direct implications for cloud provider jurisdiction: if your provider can be compelled by US law to decrypt your data or suppress audit logs, you cannot guarantee these requirements are met.

CRA Art.13: Security by Design

Article 13 operationalises Annex I. It requires manufacturers to apply security engineering throughout the product lifecycle — not as an afterthought. Key obligations:

• Secure development lifecycle with security testing at every stage
• Vulnerability scanning before each release
• Cryptographic protection for data in transit and at rest
• Documented threat model for the product

The threat model requirement is where jurisdiction becomes structurally relevant: if your threat model doesn't include "US government covert access via CLOUD Act" as a threat vector for EU customer data, it's incomplete.

Vulnerability Management

CRA Art.10: Vulnerability Reporting to ENISA 2026

Article 10 establishes the basic duty: manufacturers must report vulnerabilities to ENISA. It connects to Article 11 (actively exploited) and Article 14 (CVD). The key question for cloud-hosted products is who owns the obligation when the vulnerability is in the cloud platform rather than the product itself. The answer is nuanced: platform vulnerabilities that affect your product's security posture may trigger your Article 10 obligations even if you didn't cause them.

CRA Art.11: Actively Exploited Vulnerabilities — 24-Hour ENISA Notification

The 24-hour rule is the deadline most likely to cause enforcement incidents in 2026. Article 11 requires:

• Notification to ENISA within 24 hours of becoming aware an actively exploited vulnerability affects your product
• The notification must include severity, affected versions, remediation status, and affected users (count, not identity)

The operational challenge: "becoming aware" is when the clock starts. Your monitoring systems must detect active exploitation within hours, your incident response must confirm it, and your legal/compliance team must format and transmit the ENISA notification — all within a single business day. For teams on US-hosted cloud, CLOUD Act interactions during this window could delay or prevent complete visibility of the incident.

CRA Art.7: Vulnerability Handling Requirements

Article 7 creates the ongoing vulnerability management obligations that sit between incidents: maintaining a public vulnerability disclosure policy, triaging reported vulnerabilities within defined timeframes, and coordinating remediation with downstream users. This is the operational framework that makes Articles 10, 11, and 14 work day-to-day.

CRA Art.14: Coordinated Vulnerability Disclosure (CVD)

Article 14 mandates a formal CVD policy — a structured process for receiving, triaging, and publishing vulnerability information from external researchers. Key requirements:

• A publicly accessible way for researchers to report vulnerabilities
• Acknowledgment within 5 days
• Regular status updates to reporters
• Publication of vulnerability information (CVE or equivalent) after remediation
• Coordination with ENISA and national CSIRTs for significant vulnerabilities

The CVD policy must be published. For EU-facing products, this means committing to a disclosure timeline and sticking to it — with all the infrastructure implications that follow.

Documentation and Transparency

CRA SBOM: Software Bill of Materials Requirements

The SBOM requirement is one of the most operationally complex CRA obligations. Every covered product must have a machine-readable list of all components — open source, commercial, third-party — with version numbers, license information, and known vulnerabilities at time of release.

For products deployed on cloud infrastructure, this includes your cloud SDK versions, infrastructure-as-code dependencies, and third-party services. If those third-party services are hosted by US-parent companies, the SBOM must reflect that — and the conformity assessor may ask how you manage the CLOUD Act risk for components in your supply chain.

CRA Art.27: Technical Documentation & SBOM — NSL Compliance Gap

Article 27 specifies what must be in the technical documentation package: product description, design and development documents, risk assessment, SBOM, test reports, and conformity declaration. This documentation must be kept for 10 years after the product is placed on the market.

The NSL (National Security Letter) compliance gap: if your technical documentation is stored on US-hosted infrastructure, a gag-order-accompanied NSL could prevent you from accessing, updating, or disclosing your own documentation during exactly the period when conformity assessors or market surveillance authorities are reviewing it.

CRA Annex II: User Documentation — 14 Mandatory Security Disclosures

Annex II lists what the manufacturer must tell users — in plain language, with the product:

1. Product name, type, batch/version number
2. Manufacturer contact information
3. Intended purpose and operating environment
4. Known vulnerabilities at time of sale
5. Security-relevant properties
6. Instructions for secure configuration
7. Instructions for secure disposal
8. Minimum support period (duration of security updates)
9. Update mechanism description
10. End-of-life policy
11. Contact for security reporting
12. Contact for regulatory reporting
13. CE marking and declaration of conformity reference
14. Information on whether user has ability to reset to factory defaults

The "minimum support period" disclosure is consequential: if your SaaS uses a dependency that US-parent has announced end-of-life, your Annex II documentation must reflect this — including the security implications for users.

Post-Market and Ongoing Obligations

CRA Art.9: Post-Market Monitoring

The CRA doesn't end at launch. Article 9 requires manufacturers to maintain a post-market monitoring system for the entire supported life of the product. Obligations include:

• Systematic collection of vulnerability information from security researchers, users, and threat intelligence feeds
• Active monitoring for newly discovered vulnerabilities in your components
• Regular security testing of deployed versions
• Documentation of all post-market security activities

This is essentially a permanent security operations obligation. For teams running on cloud infrastructure, the logging and monitoring systems that power post-market monitoring must be under your control — not subject to third-party gag orders that could suppress incident data.

CRA Art.12: User Notification — Security Incidents and End-of-Life

Article 12 (working with Article 13 and GDPR Article 34) creates a user-facing notification cascade:

• Users must be notified of security incidents that affect them — separate from and often before the ENISA notification
• End-of-life notice must be given at least 14 months before the product leaves active security support
• Notifications must be timely, accurate, and actionable

Supply Chain

CRA Art.16: Importer Obligations — Supply Chain Liability

Article 16 is the supply chain article that most EU software companies miss. If you place a product on the EU market that was manufactured outside the EU, you — as the importer — take on significant compliance obligations. You must verify the manufacturer has done the conformity assessment, you must keep a copy of the technical documentation, and you must act if you believe the product is not compliant.

For EU companies using US-hosted SaaS components in their products, Article 16 creates a due diligence obligation: you must assess whether those US-hosted components meet CRA requirements. If they don't, and your product relies on them, you may bear importer liability.

CRA Art.24: Open Source Steward Obligations

Article 24 recognises that open source is foundational to EU digital infrastructure and creates a distinct category: the open source steward. Stewards — organisations that develop and maintain OSS used in commercial products — must:

• Implement a CVD policy (Article 14-style)
• Cooperate with market surveillance authorities
• Notify ENISA of actively exploited vulnerabilities in their projects

For projects hosted on GitHub (Microsoft, Delaware C-Corp), CLOUD Act jurisdiction applies to the repository, the issue tracker, and the CI/CD pipelines where vulnerability information flows. This creates a structural tension with coordinated vulnerability disclosure: the coordination infrastructure is subject to potential gag orders.

Penalties

CRA Penalty Framework 2026 — Fines, Market Withdrawal, and Enforcement

The CRA enforcement regime is significantly stricter than GDPR:

• €35 million or 1.5% global annual turnover (whichever is higher) for violations of essential security requirements or vulnerability reporting obligations
• €15 million or 1% global annual turnover for other violations
• €5 million or 0.5% global annual turnover for providing false information to authorities
• Market surveillance authorities can require immediate product withdrawal from the EU market
• Member state MSAs (Market Surveillance Authorities) have powers to conduct unannounced audits

The 1.5% cap sounds modest until you compare it to GDPR's 4% cap — the CRA imposes lower percentage fines but has a lower threshold for triggering them (security requirements, not personal data processing). And market withdrawal is an existential threat to any product company.

Timeline and Implementation

CRA Implementation Timeline 2026-2027 — Month-by-Month Developer Checklist

With 14 months to September 2026 and 30 months to December 2027, a structured month-by-month plan is essential. Our timeline post breaks the compliance journey into six phases:

1. Now–August 2026: Establish ENISA reporting infrastructure, CVD policy, and 24-hour notification capability
2. September 2026: Vulnerability reporting mandatory — be ready
3. September 2026–March 2027: Complete Annex I gap analysis, SBOM generation, technical documentation
4. March–September 2027: Conformity assessment (self or third-party depending on Class)
5. September–November 2027: CE marking, declaration of conformity, final documentation
6. December 2027: Full compliance, ongoing post-market monitoring

CRA September 2026: 120-Day Countdown — ENISA Vulnerability Reporting

A focused look at the first deadline: what exactly changes on 11 September 2026, what infrastructure you need in place, and how to test your 24-hour response capability before the deadline arrives.

The Jurisdiction Problem: Why Cloud Provider Matters for CRA

Reading through 17 articles, one pattern emerges repeatedly: CRA compliance requires complete, unobstructed visibility into your product's security posture, continuous access to your own documentation, and the ability to notify regulators truthfully and timely.

US-hosted cloud infrastructure introduces three structural gaps:

Gap 1: CLOUD Act Access Without Notification

The Clarifying Lawful Overseas Use of Data Act (CLOUD Act) allows US government agencies to compel US-headquartered companies to produce data stored anywhere in the world — including EU-region servers — without notifying the data owner. This means:

• Your AWS/Azure/GCP/Vercel/Railway/Render instances can be accessed without your knowledge
• Your application logs, infrastructure metrics, and vulnerability data can be disclosed to US agencies
• You may be legally prohibited (via gag order) from telling your EU customers this has happened

For CRA Article 12 (user notification of security incidents): if you don't know an incident occurred because your cloud provider is under a gag order, you cannot notify users. You are in violation of Article 12 through no action of your own.

Gap 2: NSL Gag Orders During the Reporting Window

National Security Letters — an FBI-specific US legal mechanism — can compel telecommunications and technology companies to produce records and maintain silence about the production, sometimes indefinitely. US courts have found NSLs constitutional with modifications; the secrecy requirement survives challenge in most cases.

If your infrastructure provider receives an NSL during the 24-hour ENISA notification window (Article 11), or during the 72-hour incident reporting window (Article 14), they cannot tell you. Your monitoring systems may show anomalous access that you cannot attribute because your provider is legally forbidden from confirming what's happening.

Gap 3: Technical Documentation Availability

Article 27 requires 10-year retention of technical documentation. Market surveillance authorities must be able to access this documentation for audit. If your documentation is stored on US-hosted infrastructure and that infrastructure is under CLOUD Act access at the time of audit, you may have no way to guarantee the documentation's integrity — you cannot certify that it hasn't been reviewed, modified, or redacted by a third party acting under legal compulsion.

The EU-Native PaaS Structural Advantage

EU-native infrastructure solves all three gaps structurally, not contractually:

On CLOUD Act: A cloud provider incorporated in the EU with no US parent company is outside CLOUD Act jurisdiction entirely. There is no US entity that can be compelled. GDPR Chapter V governs any international data transfer, and EU-incorporated providers cannot comply with CLOUD Act demands without violating EU law — which creates legal cover that contractual "EU data processing" agreements on US-parent services cannot provide.

On NSLs: NSLs are a US-specific legal instrument. They apply to persons and companies subject to US law. An EU-incorporated cloud provider with no US operations, no US employees, and no US parent is outside NSL jurisdiction. Full stop.

On documentation integrity: Technical documentation stored on EU-native infrastructure, with no US-parent access paths, cannot be subject to foreign covert access. You can certify to market surveillance authorities that your documentation is complete and unaltered.

sota.io is built on Hetzner Germany — an EU-incorporated company with no US parent, no CLOUD Act jurisdiction, and full GDPR Chapter V compliance as the baseline. When you deploy on sota.io, your application, logs, and infrastructure operate entirely outside US law enforcement reach.

CRA Compliance Checklist (All 17 Areas)

Use this as a quick-reference audit tool against the full series:

What to Do Now

If you're reading this in mid-2026, the September deadline is close. Here's the priority order:

Immediate (next 30 days):

1. Determine your product classification (Art.6)
2. Audit your Annex I compliance — 11 security requirements, identify gaps
3. Draft your CVD policy (Art.14) and publish it
4. Instrument your monitoring for active exploitation detection <24h (Art.11)

Next 90 days: 5. Complete your SBOM for all current versions 6. Generate your Article 27 technical documentation 7. Audit your user documentation against Annex II's 14 items 8. Evaluate your cloud provider jurisdiction — is CLOUD Act a structural gap in your compliance?

If you're on US-hosted infrastructure: The jurisdiction gap isn't insurmountable, but it requires explicit risk acceptance and documentation. Your conformity assessor will ask. Your technical documentation must address it. And if an incident occurs during the 24-hour notification window with a cloud provider under foreign legal compulsion, you bear the Article 11 violation even if you didn't know.

Moving to EU-native infrastructure before September 2026 is not "nice to have" for high-risk products — it's how you close the structural CLOUD Act gap without adding contractual complexity that market surveillance authorities may not accept.

sota.io offers EU-native managed PaaS — deploy any language on Hetzner Germany, no US parent, no CLOUD Act jurisdiction, from €9/month. If CRA compliance is a business requirement, the infrastructure decision is part of the compliance decision.

About This Series

This post is the 18th and final entry in sota.io's CRA Compliance Series. Every article in the series is linked above. The series began with Article 10 (vulnerability reporting) and worked systematically through the CRA's full compliance architecture.

The CRA is complex, but it's not opaque. Every obligation has a clear purpose — security by design, transparency, and accountability. The jurisdiction question is the thread that runs through all of them.

If you have questions about specific CRA articles or how EU-native infrastructure addresses your compliance architecture, reach out to the sota.io team.