A compliance deadline that arrives before the rules are finished
The European Union's Cyber Resilience Act reaches its first hard deadline on September 11, 2026, when reporting obligations for actively exploited vulnerabilities and severe incidents formally begin. That date sits more than a year ahead of the main compliance deadline of December 11, 2027, which covers the fuller set of product security requirements. The gap between the two dates is the entire story here: enterprises must start reporting against a regulation whose detailed technical standards are still in draft form.
ETSI's harmonized standards, the EN 304 xxx series, are the mechanism meant to give manufacturers a 'presumption of conformity,' a straightforward way to demonstrate compliance without litigating the CRA's requirements line by line with regulators. Seventeen of these standards have been released in draft, but their approval process runs from mid-September through mid-November 2026, meaning several will still be moving through review after the reporting obligations they are meant to support are already legally active.
Why the sequencing matters more than the deadline itself
A regulation phased in this way puts affected organizations in an uncomfortable position: legally required to report incidents and vulnerabilities starting in September, without a finished technical standard to measure conformity against. That compliance gap is a designed feature of the phase-in schedule, and it means security and legal teams cannot treat CRA readiness as a project with a single finish line. The obligations start accruing before the rulebook is complete, and organizations that wait for the final ETSI standards before starting will already be behind on day one, scrambling to backfill a reporting process under active regulatory scrutiny.
For enterprise software buyers specifically, this sequencing has a direct commercial consequence. Products and components with digital elements sold into the EU now carry a compliance timeline that started before most procurement teams have finished mapping which of their vendors and products the CRA actually touches, which is a wider net than many assume once embedded software and connected accessories are counted, down to firmware in devices nobody thought to classify as regulated.
The higher-risk categories deserve first attention
The draft standards give heightened scrutiny to specific product categories: password managers, smart home assistants, and wearables. These categories were singled out because they combine broad consumer and enterprise deployment with meaningful attack surface, credential stores, always-on microphones and sensors, and persistent network connectivity that makes a compromised device valuable to an attacker well beyond its own function, often as a pivot point into a broader corporate network.
Enterprises with any of these product types in their own portfolio, or embedded in vendor products they procure at scale, should treat them as the priority list for CRA readiness work rather than spreading assessment effort evenly across every connected product in the estate. A triaged approach, starting with the highest-risk categories ETSI has already flagged, produces defensible progress faster than a comprehensive inventory effort that takes months to even scope properly, let alone execute against a moving regulatory target, and it gives security leadership a concrete story to tell the board about where remediation dollars are going first.
What CIOs and CISOs should stand up before September 11
ENISA's single reporting platform is meant to be operational by the September deadline, and organizations subject to CRA reporting obligations need a defined internal process feeding into it, who identifies a reportable vulnerability, who signs off, and on what timeline, before the obligation becomes real rather than theoretical. Building that process against a still-drafting standard is uncomfortable but unavoidable given the calendar, and it is considerably easier to adjust an existing process once standards finalize than to build one from nothing after the reporting clock has already started running against a live deadline.
This is also a vendor-management exercise, not purely an internal security one. CIOs should be asking every vendor supplying connected products or embedded software into their environment what their own CRA reporting posture looks like heading into September, since a vendor's gap becomes the buying enterprise's exposure the moment a vulnerability surfaces in a product they have deployed at scale, regardless of whose engineering team actually wrote the flawed code.
The procurement filter this creates going forward
Once the CRA is fully in force, vendor CRA readiness will function as a real procurement filter rather than a compliance checkbox buried in a contract appendix, and enterprises that build that evaluation criterion into RFPs now will have a real head start over competitors who treat it as a 2027 problem. A vendor able to demonstrate a working reporting process ahead of the deadline, rather than promising one closer to the main compliance date, is a lower-risk vendor by any reasonable measure procurement teams should be applying today.
For CIOs at PE-backed and larger enterprises with EU exposure, the honest read is that CRA compliance functions as an ongoing operating capability that needs to exist starting this September and evolve as ETSI's standards finalize over the following year, rather than a single project with a defined end state in 2027. Budgeting and staffing for a one-time compliance push will underserve an obligation that is structurally ongoing from the very first reporting date, well before the main deadline arrives.
