Cyber Resilience Act: What German Tech Startups Must Do Before 11 September 2026

If you ship software, firmware, or a connected device into the European market, your compliance clock is running. The Cyber Resilience Act entered into force on 10 December 2024. It starts biting in two distinct phases: the reporting obligation in Article 14 from 11 September 2026, and the substantive cybersecurity obligations with CE marking from 11 December 2027.

Most of my CRA conversations split cleanly. Hardware and firmware teams want to understand Annex I and the conformity assessment. B2B SaaS teams want to know why every third compliance newsletter tells them the CRA applies. The honest answer is that pure cloud-hosted SaaS without any client-side binary usually stays outside the CRA. Ship a downloadable agent, a mobile app, firmware, or a connected device, and you are a manufacturer under Article 3 with the full obligation set.

Scope

Article 3 defines a product with digital elements as a software or hardware product, plus its remote data processing solutions, that is placed on the market with an intended purpose or reasonably foreseeable use involving a direct or indirect data connection to a device or network. That definition pulls in most startup products: IoT hardware with firmware, any downloadable software, mobile apps, desktop clients, device drivers, and companion cloud services bundled with a product.

Two exclusions matter for startups. First, non-commercial open-source developers are outside the scope, though the CRA introduces a new role called open-source software steward with a lighter set of duties. Second, products governed by sector-specific Union cybersecurity law (for example medical devices under the MDR, or aviation under Regulation 2018/1139) are partially carved out where the CRA would otherwise double-regulate.

The essential requirements (Annex I)

Annex I has two parts. Part I sets out product properties: delivered with a secure-by-default configuration, protected against unauthorized access, data integrity and confidentiality protection, minimization of attack surface, resilience against denial-of-service, and logging of relevant security events. Part II sets out manufacturer vulnerability-handling processes: documenting and addressing vulnerabilities, security updates (separated from feature updates where possible), a public disclosure policy, coordinated vulnerability disclosure, and a Software Bill of Materials.

Before placing a product on the market, Article 13 requires a cybersecurity risk assessment that informs the design. Manufacturers must draw up technical documentation, run the conformity assessment procedure that matches their product class, draw up the EU Declaration of Conformity, and affix the CE mark. For most products this is a self-assessment.

Classification sits in three tiers. Important products in Annex III Class I (password managers, standalone antivirus, VPN clients, network-management systems, boot managers) can use self-assessment where a harmonized standard covers all essential requirements. Annex III Class II (hypervisors, firewalls and intrusion detection systems, tamper-resistant microprocessors) follows the same logic but is more likely to need a notified body. Critical products in Annex IV (hardware devices with security boxes, smart meter gateways within smart metering systems, smart cards with secure elements) always require a notified-body assessment.

The 24/72-hour reporting cascade

From 11 September 2026, Article 14 creates a two-step reporting flow for actively exploited vulnerabilities and severe incidents impacting product security. The manufacturer submits an early warning to the coordinating national CSIRT and ENISA via the Single Reporting Platform within 24 hours of becoming aware. A full vulnerability notification follows within 72 hours. For actively exploited vulnerabilities, a final report is due without undue delay, and in any event within 14 days, once a corrective or mitigating measure is available. For severe incidents, a one-month final report applies.

Two things founders keep underestimating. First, actively exploited is the trigger — narrower than the GDPR breach concept in Article 33 GDPR, but with a tighter 24-hour window. A single exploited CVE in your firmware starts the clock, even if no user data leaves the device. Second, the reporting goes via a single EU-wide platform that becomes operational on 11 September 2026, not to each national regulator separately. In Germany, the coordinating CSIRT function sits with the BSI.

Penalties

Article 64 splits fines into three tiers by which obligation you missed.

The higher of the EUR figure and the percentage applies. In Germany, CRA market surveillance is coordinated through the BSI, which also runs the national CSIRT function for Article 14 reporting. Microenterprises and small enterprises under Recommendation 2003/361/EC receive extended reporting timeframes under Article 14(8). The substantive Annex I obligations and the penalty exposure remain in place.

Key dates

What to do in the next six months

Overlap with NIS2 and the AI Act

Three EU cybersecurity regimes now apply to German tech startups, each on a different basis. NIS2 regulates you as an entity that operates essential or important services once you cross the medium-enterprise size cap in a covered sector (broadly 50 employees or EUR 10 million turnover, with size-cap exceptions for DNS, TLD, trust services and sole providers). The CRA regulates you as a manufacturer of a product regardless of headcount. The AI Act adds cybersecurity obligations specifically for high-risk AI systems in Article 15. A connected-device startup can be in all three regimes at once. The technical measures overlap heavily; the reporting channels do not. Build one internal security program, but keep the reporting matrix explicit.

Bottom line

The CRA reporting clock starts on 11 September 2026. The CE marking and Annex I clock runs out on 11 December 2027. If you ship a product with any client-side code or connected hardware into the EU, you are in scope, and the early part of the plan (risk assessment, SBOM, vulnerability handling, reporting workflow) needs to be ready by September. The founders I see moving on this in April and May have clean technical files at the Series A. The ones who wait for December 2027 will be redoing product documentation under deal-stage time pressure while their VPN vendor is also asking them for a CRA conformity attestation as part of a procurement review.

For the related compliance track on data processing security, see GDPR basics for B2B SaaS. For how the AI Act layers on top for machine-learning products, see AI Act: what German startups need to know.