The Netherlands' Cyberbeveiligingswet — the Dutch NIS2 implementation — took effect on 15 August. Three and a half weeks later, on 11 September 2026, a completely different EU law reaches its own first hard deadline: Article 14 of the Cyber Resilience Act (CRA) makes vulnerability and incident reporting mandatory. Close together in time, close in subject matter, easy to mentally merge into "the EU cybersecurity thing that started in August/September." They are not the same law, they don't regulate the same organizations, and conflating them is the fastest way to tell a client "you're covered" when you aren't.
What actually becomes mandatory on 11 September
The CRA itself entered into force back on 10 December 2024, and its full product-compliance regime — CE marking, conformity assessment, the whole apparatus — doesn't apply until 11 December 2027. What lands on 11 September 2026 is narrower and more operational: Article 14's reporting obligations, and they're demanding on a short clock. Per the detailed breakdown from Crowell & Moring's client alert, manufacturers face two parallel tracks:
- Actively exploited vulnerabilities — notify ENISA and the relevant national CSIRT within 24 hours of becoming aware, a follow-up assessment within 72 hours, and a final report within 14 days of a fix becoming available.
- Severe security incidents — same 24-hour initial notification to ENISA, a detailed report within 72 hours, and a final report within one month of that 72-hour report.
Both tracks route through the ENISA Single Reporting Platform, a single portal meant to notify ENISA and the coordinating national CSIRT simultaneously. As of the Crowell & Moring alert, the platform was scheduled to be operational by 11 September but hadn't been formally stood up yet, submissions are manual with no API, and manufacturers are expected to have trained staff ready to file on short notice from day one. That's worth sitting with: the compliance deadline and the tooling to comply with it are arriving at essentially the same moment.
Who this actually applies to — and the SaaS carve-out that matters
This is the part that gets lost when CRA and NIS2 blur together. NIS2 — the Cyberbeveiligingswet, in the Dutch case — regulates operators of essential and important services: hospitals, energy providers, government bodies, digital infrastructure operators, reporting incidents in their own operations. The CRA regulates manufacturers of "products with digital elements" — hardware and software sold, licensed, or made available on the EU market, full stop, regardless of what sector buys them.
The scope is genuinely broad: network equipment, routers, firewalls, VPNs, operating systems, virtualization software, industrial control systems, IoT devices, password managers — anything that connects to a network or another device, built by an EU or non-EU manufacturer, sold into the EU. But there's a specific, deliberate carve-out that matters a great deal to a cloud-focused audience: standalone SaaS is out of scope. The Commission's March 2026 draft guidance confirms it explicitly. Cloud only gets pulled in when it qualifies as a remote data processing solution (RDPS) — data processing at a distance that a specific product cannot function without, designed by or under the responsibility of that product's own manufacturer. A smart device that phones home to a vendor-run cloud service to perform a core function brings that cloud service into CRA scope alongside the device. A general-purpose SaaS platform, consumed independently, does not.
Where this actually touches the sovereignty and Azure Local world
Read that RDPS boundary again with an Arc or Azure Local lens on, and the relevance sharpens fast. Azure itself, as a general-purpose cloud service, sits mostly outside CRA scope. But the moment you're an OEM shipping a validated Azure Local appliance, or an ISV building an Arc-enabled industrial gateway, or a systems integrator packaging an on-prem sovereign appliance around Azure IoT Operations and AKS Arc — you are very plausibly a "manufacturer of a product with digital elements" under this law, and any Azure-hosted service your product can't function without is your RDPS. On-prem and hybrid delivery, which is most of what "sovereign private cloud" and "disconnected operations" actually mean in practice, sits closer to CRA's core scope than cloud-native SaaS ever does.
Microsoft has clearly read the room here: the company is positioning Azure Arc and AKS as part of a reference architecture for CRA compliance, offering partners a "CRA Readiness Assessment" and pre-integrated components aimed at manufacturers building connected products on Azure infrastructure. That's a tell. If Microsoft is building a go-to-market motion around helping OEMs hit this deadline, the deadline is real enough to be worth productizing — and worth checking your own supply chain against before a customer asks you to prove you have.
What's not answered yet
- The reporting platform's own readiness. The ENISA Single Reporting Platform was still not formally operational as of the most recent alert I could verify, with the 11 September date treated as a target, not a confirmed go-live. Worth checking the Commission's CRA reporting page directly before assuming the tooling will simply be there.
- The classified/defense carve-out's edges. Products developed exclusively for national security or classified-information processing sit outside the CRA and fall to national requirements instead — but dual-use products remain in scope. For anyone in the defense-adjacent sovereignty space, that line needs a case-by-case legal read, not an assumption.
- Where exactly the RDPS line falls for hybrid Azure Local products. "The absence of which would prevent the product from performing one of its functions" is a fact-specific test. I haven't found a Microsoft- or Commission-published worked example for an Azure Local or Arc-connected appliance specifically — that's a real gap for anyone trying to self-assess right now.
- Whether "awareness" triggers get missed in practice. The Commission's guidance ties the 24-hour clock to "a reasonable degree of certainty," reached after an initial assessment — but an open-ended investigation is explicitly not a valid excuse for missing the window. That's a tight operational bar for teams that haven't built the monitoring and escalation path yet.
Who should care
Anyone building or reselling hardware or on-prem/hybrid software with an Azure or Azure Local component — OEM partners, systems integrators, ISVs shipping Arc-enabled appliances — should treat 11 September as a real compliance date, not background EU policy noise. Pure SaaS vendors get more breathing room, but should still document why they believe they sit outside the RDPS definition rather than assume it. And anyone advising clients across both NIS2 and CRA should be explicit, in writing, about which law applies to which entity in the relationship: the operator running the infrastructure, or the manufacturer who built what's running on it.
Two EU cybersecurity deadlines landed three and a half weeks apart, and they regulate almost opposite things: one covers what you run, the other covers what you built. Getting that distinction wrong in a client conversation is the kind of mistake that only surfaces during an actual incident.
I'm mapping where the Azure Local / Arc appliance supply chain actually lands on the manufacturer-vs-RDPS line — that's worth a proper lab once the ENISA platform is live and I can see the reporting workflow directly instead of reading about it. If you want that when it's ready, or you're working through your own CRA scoping right now, subscribe to Sovereign Cloud Watch or find me on LinkedIn.
This article summarizes publicly available guidance on the EU Cyber Resilience Act for informational purposes. It isn't legal advice — CRA scoping is fact-specific, and organizations should confirm their obligations with qualified counsel.