What is the EU Cyber Resilience Act (CRA)?

The CRA scope is intentionally broad. Any product whose intended or reasonably foreseeable use includes data connection — direct or indirect — to a device or network falls in scope. That includes:

• Consumer IoT (smart speakers, cameras, locks, thermostats).
• Industrial control systems and IIoT.
• Network equipment (routers, switches, firewalls).
• Operating systems, middleware, libraries, browsers, productivity software, mobile apps.
• Identity/authentication products.
• Smartcards, hardware security modules, smart sensors.
• Most enterprise software products including cybersecurity tools.

Out of scope (covered by other regimes): medical devices under MDR/IVDR, motor vehicles under type-approval, aviation, products covered by Civil Aviation Authority rules, services-only offerings (covered by NIS2 instead).

Open-source nuance: non-commercial open-source contributors are not "manufacturers" under the CRA. But anyone monetising open-source — through paid support, hosted SaaS, or commercial distribution — becomes a manufacturer for the products they monetise. The "open-source steward" category in Art. 24 creates lighter obligations for foundations and similar non-profit stewards of widely-used components.

Article 7 + Annex III splits products into three risk classes that drive conformity assessment depth.

Default class — the majority of products. Self-assessment against Annex I essential requirements is sufficient; the manufacturer signs the EU Declaration of Conformity.

Important class (Class I and Class II, Annex III) — higher-risk product types. Class I includes identity management products, browsers, password managers, antivirus, VPNs, network management, SIEM/SOAR, smart-home with safety functions, video surveillance. Class II includes hypervisors and container runtimes used in industrial settings, firewalls/IDS for industrial use, tamper-resistant microprocessors. Class I and II require either harmonised-standard conformity (self-declared but standardised) or third-party conformity assessment.

Critical class (Annex IV) — at present a narrow list: hardware devices with security boxes, smart-card-like secure elements, smart-meter gateways. The Commission can move products in and out of critical via delegated acts. Critical products require mandatory third-party conformity assessment from a notified body, plus possible European cybersecurity certification scheme.

For cybersecurity vendors specifically, the Annex III(I) list is where most enterprise security tooling lands — including endpoint, network detection, vulnerability scanning, IAM, and SIEM. Conformity-assessment infrastructure for this class will not be optional from December 2027.

Annex I splits into Part 1 (security properties of the product) and Part 2 (vulnerability-handling process). Both are essential — failing either prevents CE-marking.

Part 1 — product security: - Delivered without known exploitable vulnerabilities. - Delivered with a secure-by-default configuration. - Confidentiality, integrity, authenticity, availability protected by appropriate means. - Minimised attack surface (no unnecessary external interfaces, services, accounts, debug functionality enabled by default). - Resilience against denial-of-service. - Logging of security events for the user. - Secure update mechanism, including automatic security updates where appropriate. - Data only processed as needed for the intended purpose.

Part 2 — vulnerability handling: - Identifying and documenting vulnerabilities and their components (SBOM in machine-readable format). - Addressing vulnerabilities without delay through security updates. - Public disclosure of fixed vulnerabilities once an update is available — and a published coordinated disclosure policy. - Free security updates for the declared support period. - Verification of security updates (signed, integrity-checked).

The SBOM requirement is the operational hinge most product teams underestimate. The SBOM must be machine-readable (CycloneDX or SPDX), kept current, and provided to market-surveillance authorities upon request. Manual SBOMs assembled at audit time fail the "kept current" test.

Article 14 — effective 11 September 2026, earlier than the rest of the regulation — creates two mandatory reports for manufacturers.

Actively exploited vulnerability notification (Art. 14(1)): within 24 hours of becoming aware, an early warning to the CSIRT designated as coordinator under NIS2 *and* ENISA, with name, type of vulnerability, and whether (when known) corrective or mitigating measures are available. Within 72 hours, a more detailed report. Final report no later than 14 days after a corrective measure becomes available.

Severe incident notification (Art. 14(2)): within 24 hours of awareness of a severe incident impacting the security of a product with digital elements, early warning to the same recipients. Definition of severe is significant impact on the ability to provide a key functionality, on confidentiality/integrity/availability of significant amounts of data or any function deemed of public interest.

Reporting is via the ENISA single reporting platform (under construction at time of writing; specifications in the implementing acts under preparation). This is a regulator-grade notification, not a customer comms. The clock starts at awareness — meaning detection capability is itself a CRA conformity concern.

For products planned to remain on the EU market past December 2027:

Now (2026): - Map the product portfolio against Annex III to identify Class I / Class II / Critical items. Notified-body queues will saturate through 2027. - Stand up the vulnerability-handling process (coordinated disclosure policy, SBOM tooling, update-signing infrastructure, CVE Numbering Authority registration if appropriate). - Wire the September 2026 reporting workflow — who is the CRA-incident lead, what is the 24-hour notification template, where is the ENISA channel. - Conformity assessment dry-runs against the current harmonised standards drafts (ETSI EN 303 645 for consumer IoT, ISO/IEC 27001 alignment for general processes).

Through 2027: - Engineering changes to meet Annex I Part 1 by default for new builds. - SBOM coverage of every shipped artefact, kept current build-on-build. - Update cadence and support-period declaration in product documentation and EU Declaration of Conformity.

The expensive mistake current product teams are making is treating CRA as a "documentation problem to solve in Q3 2027". The conformity-assessment infrastructure (notified bodies, harmonised standards, ENISA platform) is being built through 2026-2027 with capacity constraints; products that arrive at the queue late will not ship into the EU on 12 December 2027.

For cybersecurity tool vendors specifically — including AI-powered security platforms — the CRA stacks with the AI Act where the tool falls into Annex III categories. Producing two conformity packages from the same evidence base is dramatically easier than building each one separately; the operational implication is that the Trust Center / continuous evidence model becomes a CRA enabler, not just an audit nice-to-have.