The European Union’s Cyber Resilience Act has been law since December 2024, but for most organizations it has existed as a future problem — a 2027 compliance deadline comfortably over the horizon. That changes in roughly ninety days. On September 11, 2026, the CRA’s vulnerability and incident reporting obligations take effect, and with them the most operationally demanding clock in the regulation: a 24-hour early-warning requirement for actively exploited vulnerabilities. It is the first part of the CRA to bite, it applies to the connected devices that fill modern offices, and survey data suggests most of the industry is not ready.
This is not only a manufacturer’s problem. The CRA reshapes how connected products are bought, imported, and operated across the EU, and organizations that purchase smart-office and OT hardware inherit obligations and leverage of their own. Here is what the September deadline actually requires, how the full timeline unfolds, and what buyers and operators should be doing with the time that remains.
The Clock: What September 11 Actually Requires
From September 11, 2026, manufacturers of products with digital elements placed on the EU market must report through a single channel when something goes wrong. The reporting obligation runs on two parallel tracks — one for actively exploited vulnerabilities, one for severe security incidents — and each track is a three-stage cascade.
What starts the clock. A manufacturer is considered “aware” once it has a reasonable degree of certainty that a vulnerability in its product is being actively exploited, or that a severe incident has occurred. The trigger is active exploitation, not the mere discovery of a flaw — but once that threshold is crossed, the timeline is unforgiving.
The actively-exploited-vulnerability track:
- Early warning within 24 hours of becoming aware, identifying, where applicable, the Member States in which the product has been made available.
- A fuller vulnerability notification within 72 hours, covering the nature of the vulnerability and the exploit, any corrective or mitigating measures taken, and mitigations users can apply.
- A final report within 14 days of a corrective or mitigating measure becoming available.
The severe-incident track runs on a similar cadence: a 24-hour early warning (stating at minimum whether the incident is suspected to stem from malicious acts), a 72-hour detailed notification, and a final report within one month.
Where the report goes. Reports are filed once, through ENISA’s Single Reporting Platform — a centralized system that simultaneously notifies ENISA and the relevant national CSIRT. The manufacturer selects a coordinating CSIRT at filing, and that CSIRT disseminates the information to other affected Member States. ENISA has indicated the platform will be operational by the September deadline, with registration guidance and dry-run materials published in the run-up; notably, the platform is expected to launch without an API, meaning initial reporting will be manual web-portal submission rather than automated integration. Manufacturers must also notify affected users of the vulnerability and the available mitigations.
A 24-hour early-warning obligation is a demanding operational requirement. It presumes a vendor has the monitoring to detect active exploitation, the internal escalation paths to recognize it as reportable, and the process maturity to file a regulatory report inside a single day. For organizations that have never operated under a breach-notification regime, that is a standing capability that has to be built, not a form that gets filled out after the fact.
The Full Timeline
The September reporting deadline is one milestone in a sequence. The anchors that matter:
- December 10, 2024 — the CRA entered into force as Regulation (EU) 2024/2847.
- June 11, 2026 — deadline for Member States to notify their conformity-assessment bodies (the notified bodies that will handle third-party assessment for higher-risk products).
- September 11, 2026 — vulnerability and incident reporting obligations begin; the Single Reporting Platform goes live.
- December 11, 2027 — the main event: the essential cybersecurity requirements, conformity assessment, and CE marking obligations apply in full.
Running alongside this is the standardization track. The harmonized standards that will let most manufacturers self-assess against the CRA’s requirements are being developed under standardization request M/606, accepted by CEN, CENELEC, and ETSI in April 2025 and covering roughly 41 standards. Commentary tracking that work cites target delivery dates of August 30, 2026 for the horizontal “type A” and “type B” standards and October 30, 2026 for product-specific “type C” standards. These are standardization targets rather than statutory deadlines, and they have a history of slipping — but their timing matters, because a thin or late set of harmonized standards complicates the self-assessment route ahead of the December 2027 compliance date.
Who and What Is in Scope
The CRA applies to “products with digital elements” — any hardware or software product, and associated remote data-processing solutions, with a direct or indirect logical or physical data connection to a device or network. In practice that sweeps in essentially the entire connected-office and OT estate: routers, IP and security cameras, smart speakers, building-automation devices, industrial control systems, and the software that runs on and alongside them. Separately marketed components are included in their own right.
Products are classified by risk based on their core functionality. Most fall into the default category and can be self-assessed by the manufacturer. “Important” products in Annex III split into Class I (self-assessment permitted only if harmonized standards or certification schemes are applied, otherwise third-party assessment) and Class II (third-party assessment or certification required). “Critical” products in Annex IV require third-party assessment or a European cybersecurity certification scheme. Products already governed by sector-specific EU law — certain medical devices, motor vehicles, aviation — are carved out, and products not supplied in the course of commercial activity are outside scope. Open-source software gets tailored treatment: developers can self-assess where documentation is public, and open-source stewards are exempt from the regulation’s penalties.
The Requirements That Will Actually Matter
For an audience watching the steady drumbeat of hardcoded-credential and default-password advisories, the CRA’s essential requirements read like a direct response. Products must be designed, developed, and produced to ensure an appropriate level of cybersecurity and to handle vulnerabilities throughout a defined support period. The operationally salient requirements include:
- Secure by default, with no weak default passwords. Products must ship in a secure default configuration, require the user to set a password on first use, disable unnecessary services by default, and keep high-risk functions (such as internet video streaming) off until explicitly enabled.
- Encrypted communication by default and protection of the confidentiality and integrity of data.
- Security updates for the stated support period, delivered automatically by default (with a user opt-out), and a clearly communicated support-period length.
- A documented vulnerability-handling and coordinated-disclosure process, including a contact point for receiving reports.
- A software bill of materials (SBOM) in a machine-readable, commonly used format covering at least top-level dependencies, made available to authorities on request.
- Attack-surface minimization and secure-by-design engineering throughout.
Read against the June 2026 advisories — cameras shipping with default credentials, doorbells and robots with hardcoded keys, routers writing admin passwords to a readable log — this list is a catalog of the exact failures regulators have decided to make commercially untenable.
What It Means for Buyers and Operators
The CRA is written for manufacturers, but its effects fall squarely on the organizations that buy and run connected devices, and there is genuine leverage here for those who use it.
Procurement becomes a security control with legal backing. The CRA directs Member States to ensure that, when in-scope products are procured, compliance with the essential requirements — including the manufacturer’s ability to handle vulnerabilities effectively — is taken into account in the procurement process. That gives buyers a basis to make CE marking, a committed support period, SBOM availability, and a documented vulnerability-handling process explicit, contractual selection criteria. After December 2027, CE marking will be a hard buying signal; before then, a credible vendor roadmap toward it is the screen.
You may be an “importer” or “distributor” without realizing it. An organization that places a non-EU vendor’s product on the EU market takes on importer obligations: verifying CE marking, confirming a conformity assessment was performed, ensuring technical documentation exists, and refraining from placing non-compliant products on the market. Importers must also inform the manufacturer and authorities on becoming aware of a vulnerability or risk. Distributors who make products available without altering them must likewise check for CE marking and documentation. Organizations that resell, bundle, or deploy connected hardware on behalf of others should determine which role they occupy.
Operational readiness is the practical work. Operators of smart-office and OT fleets should map which of their devices are in scope, demand SBOMs from vendors, track support-period end dates as a rising-risk indicator, and align their own incident processes with the 24/72-hour reporting cascade their vendors now run — because a vendor’s 24-hour report is only useful if the customer can act on it quickly.
The Penalties — and the Readiness Gap
The CRA’s enforcement tiers are significant. Breaching the essential cybersecurity requirements or core manufacturer obligations can draw fines of up to €15 million or 2.5% of global annual turnover, whichever is higher. Other obligation breaches carry up to €10 million or 2%, and supplying incorrect, incomplete, or misleading information to notified bodies or market-surveillance authorities up to €5 million or 1%. Authorities can additionally order products withdrawn, recalled, or banned from the market. Micro and small enterprises receive some relief on the timing of the 24-hour obligation, and open-source stewards are exempt from fines.
Against that backdrop, the readiness picture is concerning. The 2026 CRA awareness survey from OpenSSF and Linux Foundation Research found that 66% of respondents remain unfamiliar with the regulation, up from 62% a year earlier — and that more than half of European SMEs remain unaware of it entirely. With the reporting clock starting in roughly ninety days and full compliance due in eighteen months, a two-thirds unfamiliarity rate is not a comfortable position for an industry.
In Context
The Cyber Resilience Act is the regulatory answer to a decade of connected-device security failures, and September 11 is the moment it stops being theoretical. The 24-hour reporting obligation is demanding precisely because it forces manufacturers to build the detection and escalation capability that responsible vendors should already have — and it gives buyers, for the first time, a legal hook to insist on it.
For organizations running connected offices, the strategic shift is that device security is migrating from an operational afterthought into a procurement and compliance discipline with real financial consequences attached. The vendors who treat the September deadline as a forcing function — building vulnerability-handling processes, publishing SBOMs, committing to support periods, and shipping secure-by-default — will be the ones still selling into the EU market in 2028. Buyers should be sorting their suppliers into those who are moving and those who are not, and they should be doing it now, while ninety days still counts as time to prepare.
This article is provided for informational purposes only and does not constitute legal advice. Organizations should consult qualified counsel regarding their specific obligations under Regulation (EU) 2024/2847.



