The Clock Is Already Running
The EU Cyber Resilience Act (CRA) is no longer a regulatory horizon — it is a countdown. On September 11, 2026, the first hard deadline of the CRA enters into force: manufacturers and developers of products with digital elements must begin reporting actively exploited vulnerabilities to ENISA and national CSIRTs. That is 77 days from today.
If your organisation builds software, sells connected hardware, or integrates third-party digital components into products you distribute in EU markets, this deadline applies to you. The CRA introduces obligations that span your development pipeline, your vendor relationships, your incident response process, and your executive reporting structure.
This guide explains what the September deadline requires, who is in scope, what penalties apply, and the practical steps to take right now — before regulators start asking the questions.
What Is the EU Cyber Resilience Act?
The CRA entered into force in December 2024 after years of legislative work triggered by a wave of incidents — SolarWinds, Log4Shell, MOVEit — that exposed the systemic risk of insecure software supply chains. Unlike the GDPR (which governs data) or NIS2 (which governs operations), the CRA targets the products themselves. It imposes mandatory cybersecurity requirements on any product with digital elements (PDE) placed on the EU market — covering the entire product lifecycle from design through end-of-life.
The CRA's central principle is security by default: products must ship secure, without requiring the customer to configure security separately. This shifts accountability upstream — to developers and manufacturers — rather than leaving it with the end user.
Key distinction: GDPR protects data. NIS2 protects operations. The CRA protects the software and hardware products themselves, from the moment they are designed to the moment they are decommissioned.
The September 11, 2026 Deadline: What Changes
The CRA is phased. September 11, 2026 activates the vulnerability reporting obligations — the most operationally urgent requirement for most organisations today. From that date, any actively exploited vulnerability affecting your product triggers a strict notification cascade.
| Window |
Obligation |
Recipient |
| 24 hours |
Early warning: notify that an actively exploited vulnerability has been identified, with initial severity assessment |
ENISA + national CSIRT |
| 72 hours |
Full technical notification: affected versions, CVE reference, severity score, initial mitigation advice |
ENISA + national CSIRT |
| 14 days after patch |
Final report: comprehensive remediation summary, root cause, patch availability, and recommendations for affected users |
ENISA + national CSIRT |
Two aspects of this timeline deserve particular attention. First, the 24-hour window starts from the moment your organisation becomes aware of active exploitation — not from when you receive a formal CVE assignment or public disclosure. This makes threat detection and internal alerting a direct compliance obligation. Detection lag is legal exposure.
Second, this applies to any actively exploited vulnerability — there is no severity threshold. A low-severity bug being exploited in the wild must be reported within 24 hours. A critical vulnerability that is not yet exploited does not trigger the clock. The trigger is exploitation, not severity.
Who Is in Scope?
The CRA's scope is intentionally broad. The following categories of organisations are directly affected.
Manufacturers
Any organisation that designs, develops, or produces products with digital elements and places them on the EU market. This includes enterprise software, consumer applications, connected hardware, industrial control systems, embedded firmware, and network equipment. If your company ships a software product or a hardware device with software components to EU customers, you are a manufacturer under the CRA.
Software-as-a-Service Providers
The CRA explicitly addresses remotely supplied digital products. SaaS providers are within scope where their services include components that qualify as products with digital elements — particularly where those components can be downloaded, installed, or updated on the customer's systems. If your SaaS offering involves a desktop agent, a mobile application, an on-premise connector, or an SDK, those components fall within the CRA framework.
Importers and Distributors
Organisations that import or distribute products with digital elements into EU markets must verify that the manufacturers they work with have satisfied CRA obligations. If a manufacturer fails to comply, distributors and importers bear residual obligations — including potential liability.
Open-Source Projects
Purely not-for-profit, open-source projects without commercial activity are generally exempt. However, if your organisation commercialises open-source software — through support contracts, hosted services, integrated products, or SaaS built on open-source components — you are not exempt. The size of your organisation does not change this.
Practical test: If your organisation generates revenue from a product that includes or is built upon digital elements, and that product is available to EU customers, the CRA applies to you.
The Supply Chain Dimension
The CRA is particularly significant for supply chain risk. Third-party involvement now accounts for 48% of all data breaches globally (IBM Cost of a Data Breach 2026), and supply chain attacks increased 75% in 2025 (Sonatype). The CRA converts third-party security risk into a regulatory compliance obligation: you must not only manage your own products' security but demonstrate due diligence in verifying the security of components you integrate from others.
The December 2027 Requirements: Planning Ahead
September 11, 2026 is the first wave. The full weight of CRA obligations arrives on December 11, 2027. Organisations that treat September 2026 as the finish line will find themselves under-prepared for what follows. The 18 months between the two deadlines should be used for the more structurally complex requirements.
Software Bill of Materials (SBOM)
Manufacturers must maintain and make available a Software Bill of Materials — a machine-readable inventory of every software component, library, dependency, and version included in a product. The SBOM must be kept current throughout the product's supported lifecycle.
Building a mature SBOM capability requires changes to your development toolchain, your CI/CD pipeline, your vendor onboarding process, and your release management workflow. Organisations that begin this work in autumn 2026 will have a realistic path to December 2027 compliance. Those who start in 2027 will not.
Security by Design
Products must be designed with the minimum necessary attack surface, secure default configurations, appropriate access controls, encryption of data in transit and at rest, and the ability to receive security updates throughout their supported lifetime. This is a development methodology requirement, not just a documentation exercise.
Vulnerability Management Programme
Manufacturers must operate a formal vulnerability management programme: policies for identifying, assessing, and remediating vulnerabilities; coordinated vulnerability disclosure processes; and records demonstrating ongoing management over the product's supported lifetime.
Conformity Assessment and Technical Documentation
Products are classified into risk tiers. Most standard software products can self-declare conformity, but must maintain comprehensive technical documentation: architecture descriptions, threat models, security test results, vulnerability management records, and evidence of design review. High-risk product categories require third-party conformity assessments.
The Penalties: What Is at Stake
The CRA's enforcement mechanisms are calibrated to be consequential. Non-compliance can attract:
- Up to €15 million or 2.5% of global annual turnover — for failure to meet essential cybersecurity requirements or vulnerability management obligations (whichever figure is higher)
- Up to €10 million or 2% of global annual turnover — for failure to report actively exploited vulnerabilities within the mandated timeframes
- Up to €5 million or 1% of global annual turnover — for providing false or misleading information to national market surveillance authorities
Beyond financial penalties, national market surveillance authorities can order the withdrawal or recall of non-compliant products from EU markets. For organisations whose revenue depends on EU market access, this is an existential business continuity risk — not merely a regulatory fine.
Governance implication: As with NIS2 and DORA, CRA violations can trigger scrutiny of executive decision-making. Boards and senior management teams should treat CRA compliance as a fiduciary matter, not a technical one.
The CRA in the Broader Regulatory Picture
The CRA does not operate in isolation. It is one of three major EU digital regulations entering active enforcement in 2026, alongside NIS2 (now issuing administrative penalties) and DORA (already applied to financial sector entities since January 17, 2025). A single incident can trigger simultaneous obligations under multiple frameworks.
The interconnections are structural, not coincidental:
- The same national CSIRTs receive both CRA vulnerability reports and NIS2 incident notifications. For organisations in scope of both frameworks — common for technology companies serving critical-sector clients — the same exploitation event could trigger parallel reporting timelines.
- DORA's ICT third-party risk management requirements create obligations on financial entities to assess their vendors' CRA compliance status. If you supply software or technology services to financial sector clients, your CRA readiness is now part of their DORA supplier due diligence.
- The EU AI Act's cybersecurity requirements for high-risk AI systems reference the CRA's essential requirements. An AI product that fails CRA conformity may also fail AI Act conformity — creating cascading regulatory exposure from a single gap.
Organisations running separate compliance workstreams for NIS2, DORA, and EU AI Act should be assessing the structural overlap with CRA obligations now — the evidence you are already gathering for one framework will often serve another.
Your 10-Step CRA Readiness Checklist
The following steps are sequenced to address the September 11, 2026 deadline first, then build toward December 2027 compliance.
-
Scope assessment. Map every product your organisation designs, develops, imports, or distributes that may qualify as a product with digital elements under the CRA. Include connected hardware, software products, embedded systems, SDKs, and any SaaS components installed on customer systems. Engage legal counsel to confirm scope determinations for edge cases.
-
Threat detection and alerting. Implement or strengthen monitoring to detect active exploitation of known vulnerabilities affecting your products. The 24-hour reporting window starts the moment you become aware of exploitation — your detection infrastructure is therefore a compliance control. Gaps in detection capability translate directly into reporting delays.
-
CSIRT registration and contacts. Identify and formally document the national CSIRT and ENISA reporting channels for each jurisdiction where your products are placed on market. In Luxembourg, the primary authority is CIRCL (Computer Incident Response Center Luxembourg). Establish tested communication protocols — do not discover the correct contact under incident pressure.
-
Incident response playbook update. Revise your incident response procedures to include CRA reporting steps. Define who initiates the 24-hour early warning, who approves the 72-hour notification, and who signs off the 14-day final report. Assign ownership and backup contacts for each role.
-
Component inventory. Begin cataloguing all software components, libraries, and dependencies in your products. This is the foundation of your SBOM. Prioritise products closest to end-of-life or those with complex dependency trees.
-
Vendor contract review. Review contracts with all software and technology vendors whose components appear in your products. Add CRA-aligned clauses requiring timely vulnerability disclosure, notification of actively exploited vulnerabilities, and commitment to patching timelines. CRA compliance status should become a vendor qualification criterion.
-
Technical documentation baseline. Begin assembling the technical documentation required by the CRA: architecture descriptions, data flow diagrams, threat models, security test results, and vulnerability management records. This documentation is needed for both self-declaration conformity and any third-party assessment.
-
Vulnerability management programme formalisation. Establish or formalise your vulnerability management policy. Define discovery processes (internal testing, bug bounty, third-party research), triage and severity classification, remediation timelines, and coordinated disclosure procedures.
-
SBOM tooling selection and piloting. Evaluate SBOM generation and management tools against your technology stack. Pilot integration into at least one product's CI/CD pipeline before year-end. Mature SBOM tooling requires months of configuration and integration — starting in autumn 2026 is the minimum viable schedule for December 2027 compliance.
-
Developer and executive training. Ensure development teams understand secure-by-design principles and their obligations under the CRA. Ensure executives and board members understand the regulatory framework, the personal accountability dimensions, and the business continuity risk of non-compliance.
The Infrastructure and IT Angle: Why This Is Not Just a Developer Problem
The CRA is often framed as a software development regulation — and it is. But its implications reach into infrastructure, procurement, and IT operations in ways that are frequently overlooked.
If your IT team procures connected devices, enterprise software, or cloud services that interact with your network, those vendors must now be CRA-compliant. Procurement checklists need to include CRA conformity documentation. Vendor qualification processes need to be updated. IT asset inventories need to capture CRA compliance status alongside version and support status.
For IT managers in Luxembourg, DORA's ICT third-party risk management requirements create a parallel obligation: financial sector entities must assess and document the ICT security of their vendors, including their CRA compliance posture. The vendor management programme you build for DORA should be extended to capture CRA status.
The 2026 threat landscape reinforces the urgency. Mandiant's M-Trends 2026 found attackers are exploiting vulnerabilities an average of seven days before public disclosure. The organisations that survive a seven-day exploitation window are those with automated vulnerability scanning, continuous monitoring, and documented response procedures — precisely the capabilities the CRA requires.
How ObsidianCorps Can Help
Our teams have been working with organisations across Luxembourg and the Greater Region on regulatory compliance programmes since NIS2 entered into force. CRA readiness is an extension of that work — and for many of our clients, the groundwork is already partially in place.
Here is where we can accelerate your programme between now and September 11:
- CRA scope assessment and gap analysis. We review your product portfolio, development practices, vendor relationships, and current security documentation against CRA requirements. You receive a prioritised readiness report identifying the gaps that must be closed before September and a roadmap for December 2027.
- Vulnerability management programme design. We help you build or formalise the policies, processes, and tooling for vulnerability detection, triage, disclosure, and reporting — including integration with CSIRT notification workflows.
- Penetration testing and security validation. Independent security testing of your products gives you both the technical evidence needed for conformity documentation and early visibility into vulnerabilities before they become a September 11 reporting event.
- SBOM implementation and DevSecOps integration. Our software development and DevSecOps teams help integrate SBOM generation into your CI/CD pipeline, selecting and configuring tools appropriate for your technology stack.
- Technical documentation preparation. We help assemble the architecture descriptions, threat models, and security records required for CRA conformity assessment — in formats aligned with the requirements of both self-declaration and third-party review.
- Developer and executive training. We offer security training programmes adapted to CRA obligations for both technical teams and leadership, including table-top exercises simulating a vulnerability disclosure scenario under the CRA's reporting timelines.
If you are unsure whether your products fall in scope, or if you have identified a gap and need to close it before September 11, we offer an initial consultation at no charge. Seventy-seven days is enough time to make meaningful progress — but not enough time to waste.
Contact ObsidianCorps to start your CRA readiness assessment.
