A 24-hour reporting deadline. Including for products you
shipped years ago.
Since 11 September 2026 manufacturers must report actively exploited vulnerabilities within 24 hours. You can only report what you detect. We build the technical side: product pentests, vulnerability detection, SBOM review and a reporting process that holds up under pressure.
The reporting duty applies. The detection usually doesn't exist.
The Cyber Resilience Act has an uncomfortable property: the duty to report bites earlier than the duty to search systematically. Since 11 September 2026 an actively exploited vulnerability starts a 24-hour clock — from the moment you become aware. The full vulnerability-handling requirements, by contrast, only become binding on 11 December 2027. For manufacturers that means you are already liable for incidents whose detection you are still allowed to build later. Close that gap now, or you will report too late in the real case — or not at all, because nobody noticed.
Regulation (EU) 2024/2847
The Cyber Resilience Act — what applies when
Two dates decide: one has passed, one is coming.
- Reporting obligations since
11 September 2026 — binding
Actively exploited vulnerabilities and severe security incidents are reportable. This duty also covers products already on the market — not just new ones.
- Reporting deadlines
24 hours early warning · 72 hours report · final report
Early warning to the relevant CSIRT and ENISA via the European reporting platform. For actively exploited vulnerabilities the final report follows no later than 14 days after a fix is made available; for severe incidents, generally one month after the 72-hour report.
- Full application from
11 December 2027
From then the essential cybersecurity requirements of Annex I, the vulnerability handling requirements, technical documentation, conformity assessment and CE marking all apply.
- Products in scope
Products with digital elements
Hardware and software that can be connected directly or indirectly to a device or network — from a connected machine to an IoT device to a software component you sell. Exemptions and special regimes apply to certain categories.
- Vulnerability handling
Detect, document, remediate, disclose — across the whole support period
Annex I Part II requires, among other things, an SBOM in a machine-readable format, regular testing and review of product security, a coordinated vulnerability disclosure policy and a contact point for vulnerability reports.
- Support period
As a rule at least five years
Security updates must be provided across the defined period — longer where the expected product lifetime is longer.
- Fines
Up to €15m or 2.5% of global annual turnover
For breaches of the essential requirements and of the manufacturer and reporting obligations. Lower ranges apply to other breaches.
This page describes the technical implementation of Cyber Resilience Act requirements and is not legal advice. Whether your product falls within scope, how it is classified and which conformity procedure applies are questions for your legal counsel.
Who this matters to now
If you sell something that can connect, you are a manufacturer under the regulation
IoT and device manufacturers
Firmware, mobile app, cloud backend — three attack surfaces, one product. The reporting duty does not recognise that split: you are liable for the product as a whole.
Software vendors and SaaS with a product component
Sold software components, on-premise installations, SDKs and libraries. Shipping only a module still means shipping a product with digital elements.
Suppliers and component manufacturers
Your customers need information from you for their own conformity — SBOM, support period, vulnerability contact, update commitments. Those requests are already arriving, long before 2027.
Anyone who considers 2027 far away
Conformity assessment, technical documentation and a workable vulnerability process do not appear within a quarter. And the reporting duty, as noted, already applies today.
Annex I Part II in practice
Which duty we cover technically
The CRA requires a working approach to vulnerabilities across the entire support period. That is a process, not a document.
CRA requirement
What we deliver
Identify and document components and vulnerabilities, including an SBOM in a machine-readable format
Annex I Part II
SBOM and dependency review: we check whether your bill of materials is complete, whether it is generated automatically and whether known vulnerabilities in the included components would be noticed at all.
Apply effective and regular tests and reviews of the security of the product
Annex I Part II
Product penetration test — firmware, device, API, backend and update mechanism. Repeatable per major release instead of once before launch.
Address vulnerabilities without delay through security updates
Annex I Part II
Prioritised findings with concrete fix guidance, implementation by our development team on request, then a re-test. The update distribution mechanism itself is tested too.
Operate a coordinated vulnerability disclosure (CVD) policy
Annex I Part II
We set up the reporting path technically: security.txt, contact point, triage flow, severity scheme and escalation up to the 24-hour report. Including a dry run.
Provide a contact point for vulnerability reports
Annex I Part II
Setting up and monitoring the reporting channel — plus attack surface monitoring so you do not depend solely on somebody choosing to tell you.
Report actively exploited vulnerabilities within 24 hours
Article 14
You write the report — we make sure you have something to report: detection through monitoring, leak and exploit observation, and a defined flow of who decides what within which hour.
Ensure security across the entire support period
Article 13
Security Cycle retainer: continuous monitoring, an annual test, re-tests after remediation — documented and dated, and therefore presentable to a market surveillance authority.
The path to a vulnerability process that holds
From where you are today to a flow that survives the 24-hour deadline
Intro call (30 minutes, free)
Which products, which software base, which support period, which reporting paths exist today? Afterwards you know where you stand.
CRA readiness check (2 days)
Technical inventory: SBOM maturity, update mechanism, reporting paths, testing practice, the product's exposed attack surface. Output: gap list and action plan for €2,900.
SBOM and dependency review
Is the bill of materials complete, current and machine-readable? Which known vulnerabilities sit in your components today — and who would notice?
Product penetration test
Firmware, device, API, backend, update path. We test the product the way an attacker gets hold of it after purchase.
Reporting process and CVD policy
Contact point, security.txt, triage, severity assessment, escalation up to the early warning. Rehearsed once as a dry run so nobody improvises in the real case.
Continuous detection
Attack surface and leak monitoring plus observation of your components. Without detection, every reporting deadline is theoretical.
Repeat per release
Security across the support period means testing again when the product changes. Planned as a retainer instead of renegotiated every time.
What we do — and what we don't
We cover the technical side of CRA conformity. For the formal part you need other partners.
We take this on
- Technical CRA readiness check for your product
- Product, firmware, API and backend penetration testing
- SBOM and dependency review including the toolchain
- Building the CVD policy, reporting channel and triage flow
- Attack surface and component monitoring as the detection basis
- Secure SDLC review and developer workshop
- Recurring per-release testing under a retainer
We do not take this on
- Legal classification of your product under CRA categories
- Conformity assessment and CE marking — we are not a notified body
- Producing the full technical documentation in the legal sense
- Reporting to CSIRT or ENISA on your behalf
- Product liability and contract advice
- 24/7 standby for your reporting deadlines
The 24-hour deadline remains your obligation — we make sure you see the trigger in time and know what to do. For conformity assessment and legal questions we refer you to specialist partners.
Pricing for CRA security work
Available individually — as a cycle considerably closer to what the CRA actually asks for
CRA readiness check
Inventory for one product
- SBOM and dependency maturity
- Update and distribution mechanism
- Reporting and triage paths
- The product's exposed attack surface
- Prioritised action plan
Product penetration test
Regular testing in the CRA sense
- Firmware, device, API and backend
- Testing of the update mechanism
- CVSS-prioritised findings
- Report for engineering and management
- Re-test after remediation included
- Repeatable per major release
Security Cycle retainer
Security across the support period
- Continuous monitoring as the detection basis
- One product test per year
- Two consulting days per year
- Re-tests after remediation
- Maintained evidence documentation
- Support in a reporting case subject to availability
Frequently asked questions on the Cyber Resilience Act
Technical context — not legal advice
The reporting obligations. Manufacturers must report actively exploited vulnerabilities in their products and severe security incidents: an early warning within 24 hours to the relevant CSIRT and ENISA, a more detailed report within 72 hours and a final report. The remaining requirements — essential cybersecurity requirements, vulnerability handling, technical documentation, CE marking — take full effect on 11 December 2027.
Build the detection before you need the report
A 30-minute intro call: we look at one product, name the technical gaps between where you are and being able to report, and tell you what has to be in place before December 2027.