Cyber Resilience Act: Why the 11 September 2026 Reporting Deadline Is the Real Inflection Point for Manufacturers and Buyers

On 11 September 2026 the Cyber Resilience Act (CRA) becomes operationally binding for manufacturers across Europe. That date is when the reporting obligations kick in: 24-hour early warning, 72-hour full notification, 14-day final report. Not 2027, when full conformity obligations apply. 2026 — and for many DACH-based companies, considerably earlier than their internal processes are ready for.

The common assumption that the CRA is a "December 2027 topic" is wrong. Between the two dates lies a 15-month window in which a manufacturer must report actively exploited vulnerabilities and severe incidents — before the underlying conformity requirements even have to be fully implemented. It is a period in which operational reporting discipline is demanded while the substance is still being built.

For manufacturers of connected products, software vendors and institutional buyers running current M&A processes, 11 September 2026 is therefore not a compliance milestone. It is a stress test for governance, incident response capability and internal reporting lines.

What the CRA actually requires — and why reporting comes first

Regulation (EU) 2024/2847 entered into force on 10 December 2024. For the first time, it introduces binding cybersecurity requirements for all "products with digital elements" placed on the Union market — hardware, software, IoT, industrial control components, operating systems, firmware, separately marketed digital components.

The CRA's core timeline:

| Date | What applies | |---|---| | 10 Dec 2024 | CRA enters into force | | 11 Sep 2026 | Reporting obligations for actively exploited vulnerabilities and severe incidents | | 11 Dec 2027 | Full applicability — only CRA-compliant products with CE mark may be placed on the market |

The reporting cadence is deliberately tight (Article 14 CRA):

• Within 24 hours of awareness: initial early warning to the competent national Computer Security Incident Response Team (CSIRT) and to ENISA
• Within 72 hours: full notification with available details
• Within 14 days after a corrective measure is available (or one month for severe incidents): final report

These reports flow through the ENISA-operated Single Reporting Platform (SRP) — a single Union-wide entry point. Report once; automatic routing to the responsible CSIRT.

The critical point for management: reporting obligations apply to products already on the market before 11 December 2027. There is no grandfathering. A vendor that placed connected products on the market years ago and still ships them in 2026 is in-scope for reporting from 11 September onward — regardless of whether full CRA conformity is in place.

Germany: The BSI becomes the digital TÜV

Alongside the European regulation, the German Bundestag held first reading of the CRA Implementation Act on 11 June 2026; the Bundesrat approved it without objection on 12 June 2026 (Bundestag Drs. 21/6134). The act sets the national enforcement framework for the CRA in Germany — and the responsibility structure is clear.

The Federal Office for Information Security (BSI) is designated as the central market surveillance authority for the CRA (§ 65 BSIG-E). It examines product conformity, orders measures, and simultaneously acts as notifying authority for the conformity assessment bodies (§ 66 BSIG-E) that will conduct formal assessments for the most critical product categories.

The draft act also establishes a Cyber Resilience Real Laboratory with a €7.5 million budget (§ 67 BSIG-E) — a structure in which manufacturers can test products in a regulator-accompanied environment before market placement.

Heise summarises it plainly: BSI becomes digital TÜV for networked products. What that means for manufacturers: an agency that historically issued recommendations becomes, in 2026, an enforcement authority.

Who is really in scope — and where the grey zones sit

The CRA's scope is broader than many recognise. Covered: all products with digital elements — not just classic IoT devices, but also:

• Operating systems and application software (including B2B)
• Firmware and middleware
• Network equipment, industrial control systems (ICS/OT)
• Separately marketed digital components and libraries

Out of scope — per Commission Draft Guidance of March 2026 — is pure SaaS. That had been contested for a long time; the Commission drew the line in a March 2026 draft: standalone SaaS is out. The important caveat: as soon as a SaaS service satisfies the three-part "Remote Data Processing Services" (RDPS) test — i.e. it is essential to the core function of a product with digital elements — it falls back into CRA scope.

For DACH-based software vendors, this creates a legally complex baseline:

1. Pure SaaS business — presumably not CRA-obligated, but the RDPS assessment must be documented.
2. Hybrid offerings (on-prem component + cloud back-end) — the on-prem component is clearly in scope; the back-end is treated as a component and folded into supply-chain diligence.
3. Software libraries, SDKs, npm packages with commercial intent — squarely in the CRA lens, especially in the context of the ongoing supply-chain attack wave against npm, Ruby Gems and SAP packages.

The Open Source Software Steward — a new contractual actor

One of the CRA's structural innovations is the Open Source Software Steward category: a legal entity that systematically and sustainably supports the development of open-source software, without itself being a manufacturer in the classical sense.

Stewards are subject to a deliberately lighter regime than manufacturers — at core, three obligations: a documented cybersecurity policy, the duty to report actively exploited vulnerabilities, and active communication with the user community. No full conformity assessment, no CE mark, no full technical documentation.

The Open Source Business Alliance (OSBA) has, in its comments on the implementation act, explicitly flagged that stewards typically have very limited personnel and financial resources and will need active BSI support. Whether that support materialises as the legislator envisages will become clear between September 2026 and late 2027.

For companies, the steward category matters in two ways: first, an internal check on whether existing open-source activities trigger the steward role. Second, for critical open-source dependencies in the company's own product architecture: identify which entity is designated as steward — and how robust its reporting chain actually is.

The 2026 standards bottleneck

The 41 harmonised standards that will operationalise the CRA's technical requirements are currently in active development but not yet final. In April 2025, CEN, CENELEC and ETSI accepted Standardisation Request M/606 and are working towards Q3 2026 as the target date. Public enquiry on the drafts is scheduled for mid-July to mid-November 2026.

Delays are priced in. The standardisation bodies committed to delivering at least one year ahead of full CRA applicability — but the window is tight. That means: manufacturers who wait for final standards will burn 2026 as their operational preparation window.

A pragmatic path — already recommended by leading legal counsel — is alignment with the already-published EN 18031 series (from the RED Delegated Act implementation), on which the horizontal CRA standards build. Roughly two-thirds of the planned CRA standard requirements overlap with EN 18031. Manufacturers who have implemented EN 18031 have a meaningful head start.

What the CRA means for M&A and vendor diligence

The point still under-recognised in public CRA discussion — and one that should already be shaping decisions for institutional DACH buyers — concerns the transfer of reporting obligations in corporate transactions.

Whoever acquires a software vendor, an IoT provider or an industrial company with connected products in 2026 or 2027 inherits the full CRA history: previously reported vulnerabilities, open reporting obligations, technical documentation gaps, incomplete CE markings. A target that missed the 24-hour early warning in September 2026 carries the associated sanction exposure — and the buyer inherits it at closing.

Concretely, CRA-relevant questions belong in every M&A cyber due diligence of a software or hardware manufacturer:

• Scope: Which of the target's products fall under the CRA? Is the RDPS assessment documented?
• Reporting history: Were actively exploited vulnerabilities reported between 11 September 2026 and closing? If not — why not?
• Incident response capability: Is the 24/72-hour reporting chain operationally viable, or does it exist only on paper?
• Standards conformity: Is the EN 18031 baseline in place? Which horizontal CRA standards are already addressed?
• Supply-chain diligence: What software-component and SBOM processes are established? How robust is the evidence chain for critical open-source dependencies?
• Conformity path: Is the route to CE marking by 11 December 2027 defined and resourced?

These questions are not abstract. From autumn 2026 onward they will be the subject of hard price negotiations. The purchase-price leverage of properly executed cyber due diligence shifts structurally upward in deals with CRA exposure.

The interplay with NIS2, DORA and the SBOM regime

The CRA does not stand alone. It fits into a tightening European regulatory mesh that, for DACH-based companies, now consists of at least four interlocking legal acts:

• NIS2 (in German implementation since October 2024) — governance obligations for "essential" and "important" entities, personal liability for management, reporting obligations for operators.
• CRA — product security obligations for manufacturers.
• DORA — sector-specific digital operational resilience for financial services.
• Product Liability Directive (revised) — civil product liability, explicitly extended to software and digital elements.

For a manufacturer that is simultaneously an NIS2 "important entity" and places a CRA-obligated product on the market, the reporting obligations overlap: NIS2 notification to the BSI as CSIRT authority plus CRA notification through the Single Reporting Platform. A unified, documented reporting process is, from September 2026, no longer optional. It is the operational precondition for keeping both regimes from working against each other.

Three measures that move the needle — before September 2026

1. Clarify and document the CRA scope

Not every product falls under the CRA; not every alleged "SaaS" is outside. A documented scope assessment — including the RDPS test for SaaS components — is the starting point of any CRA preparation and the first question a market surveillance authority will ask after an incident.

2. Build the reporting chain up to board level

The 24-hour early warning is not an IT task. It is a governance task. In practice, reports fail not from missing vulnerability detection but from unclear escalation paths between the security team, legal and management. A documented incident playbook with hard timing (T+2h internal escalation, T+8h legal review, T+18h ENISA notification) is the operational basis on which the 24/72/14 cadence becomes achievable at all.

A structured vCISO mandate establishes exactly this chain — with board-level reporting, clear role assignments and a live reporting process that does not have to be improvised when the call comes.

3. Pull supply-chain evidence into every M&A transaction

For buyers addressing software or hardware manufacturers in 2026/2027, a CRA-specific diligence layer belongs inside the due-diligence architecture — as its own dimension, not an add-on to classical IT diligence. Questions on SBOM, RDPS, reporting history and standards conformity are, by now, standard content of M&A Cyber Due Diligence; the CRA extension becomes, from autumn 2026, the precondition for cleanly quantifying post-closing sanction risk.

For portfolio companies that are themselves in scope, a structured Compliance Sprint consolidates scope assessment, reporting process and standards baseline into a documented form.

Why Woodlands

Woodlands Advisory specialises in regulation-driven cyber advisory for the institutional capital market. The founder currently holds the Global Security Advisory Lead role at SAP and led the post-acquisition cyber integration of Signavio following the SAP acquisition — a role in which regulatory meshes like NIS2, CRA and the emerging AI regime meet actual deal reality.

Delivery is carried out by a curated team of senior practitioners with cloud, identity, AppSec and compliance specialisation — no outsourcing, no junior substitution. The partner stack for tooling (Vanta, Kertos, Aikido) and the law-firm partners for contractual and regulatory questions are structurally embedded, not improvised ad hoc.

For PE houses, family offices and M&A advisors in the DACH region, Woodlands delivers CRA-relevant assessments in a form that is defensible in investment committees and SPA negotiations: as risk quantification with purchase-price linkage, not as framework citation.

---

If you want to size your own CRA exposure, your portfolio's, or that of a current target, let us talk — confidentially.

Book a 20-minute strategy call →

---

Sources (Tier 1 & Tier 2):

1. European Commission — Cyber Resilience Act Policy Page & CRA Reporting Obligations & CRA Standardisation
2. ENISA — Single Reporting Platform (SRP)
3. Deutscher Bundestag — Drucksache 21/6134 (26.05.2026) — draft act implementing the Cyber Resilience Regulation
4. BMI — Legislative procedure Cyber Resilience Regulation
5. BSI — Cyber Resilience Act — topic page
6. DLA Piper — Cyber Resilience Act: The Fine Line Between SaaS and Digital Products (Feb 2026)
7. Open Source Business Alliance — Statement on the CRA Implementation Act
8. Crowell & Moring LLP — EU CRA: September 11, 2026 Reporting Deadline
9. Heise Online — BSI becomes digital TÜV for networked products