Under Attack?
Cyber Resilience Act Services
The EU-wide regulation on the cybersecurity of products with digital elements. Reporting obligations have applied since 11 September 2026.
The Cyber Resilience Act (Regulation (EU) 2024/2847) introduces mandatory cybersecurity requirements for products with digital elements placed on the EU market. It covers hardware and software, and certain remote data processing solutions developed by or under the responsibility of the manufacturer that a product depends on to perform its functions. Manufacturers, importers and distributors all carry obligations.
Reporting obligations took effect on 11 September 2026, requiring manufacturers to notify actively exploited vulnerabilities and severe incidents within defined timeframes. These obligations extend to products already placed on the EU market. The remaining requirements, covering security by design, vulnerability handling, technical documentation, conformity assessment and CE marking, apply from 11 December 2027.
The CRA also has operational consequences for organisations that manufacture nothing at all. From September 2026, manufacturers must inform affected users of actively exploited vulnerabilities in their products. Those organisations are not themselves regulated as manufacturers under the CRA, but they will begin receiving security notifications from third parties, frequently from parties they hold no contract with, and will need a defined route for handling them.
Penalties for non-compliance with the essential requirements and core manufacturer obligations reach €15 million or 2.5% of total worldwide annual turnover, whichever is higher.
Where organisations get caught
Three issues recur, and none of them is resolved by documentation alone.
Scope is decided informally.
Few organisations describe themselves as manufacturers. The regulation does not ask for a self-description. It considers what is placed on the EU market and under whose name. Own-brand hardware, embedded and bundled software, rebranded products and connected devices sold under a company’s own logo can bring an organisation within scope.
Nobody owns the notification.
Manufacturer advisories typically arrive with an account manager, in procurement, or in a shared mailbox reviewed during business hours. They are rarely routed into incident triage by design.
Awareness is undefined.
The initial Article 14 reporting deadlines run from the point of awareness. The European Commission has published guidance on when a manufacturer is regarded as aware. No external guidance can determine who, inside a given organisation, is capable of becoming aware on its behalf.
Cyber Resilience Act Requirements
-
Determining whether products placed on the market fall within scope, and their classification
-
Reporting actively exploited vulnerabilities and severe incidents to the coordinating CSIRT and ENISA
-
Notifying affected users of vulnerabilities and available corrective measures
-
Maintaining a coordinated vulnerability disclosure policy and a monitored reporting contact address
-
Producing a software bill of materials covering top-level dependencies
-
Security by design, secure default configuration and a defined support period
-
Technical documentation, conformity assessment and CE marking
-
Providing free security updates for the duration of the support period
Why Integrity360 for the Cyber Resilience Act
A policy stating that vulnerabilities will be reported within 24 hours is not the same as being able to do it. Advice and operational capability usually come from different suppliers. Here they do not.
The obligation runs as a loop, and we cover all of it.
Detect.
The 24- and 72-hour Article 14 clocks start on awareness, and awareness arrives from several directions: product telemetry, a researcher, a customer, a third-party notification. An organisation with no detection of its own depends entirely on somebody else raising the alarm. Where product telemetry falls within monitoring scope, our 24/7 Security Operations Centres, Managed Detection and Response and Managed SIEM services shorten that dependency. Advisory work defines the obligation. The same group operates the capability that feeds it.
Assess.
The CRA regulates products, which means embedded software, connected devices, IoT and OT. Through Holiseum, our OT and IoT practice, we assess the product itself rather than the documentation describing it. Classification, SBOM composition and scope decisions are made by engineers who can open the device.
Report.
Article 14 readiness: awareness criteria defined in writing, escalation authority named including out-of-hours deputies, coordinating CSIRT identified, notification content prepared, and the evidence trail that establishes when you knew.
Remediate.
Penetration testing, application security testing, configuration build review and vulnerability management. The CRA requires that vulnerabilities are handled, not only disclosed.
Prove.
Technical documentation, conformity assessment route and audit-ready evidence, assessed against the harmonised standards as they publish.
Our consultants work across NIS2, DORA, ISO 27001 and PCI DSS daily. CRA obligations are therefore assessed against the regimes an organisation is already subject to, rather than in isolation, which is where duplicated programmes and contradictory reporting positions come from.
We operate from Dublin, London, Brussels, Stockholm, Sofia, Ludwigsburg, Madrid, Rome and Vilnius. The coordinating CSIRT depends on a manufacturer’s CRA main establishment, primarily the place where decisions relating to the cybersecurity of its products are predominantly taken, which is rarely obvious for a multinational group.
Our position
Our position on this regulation is that it has arrived ahead of its own infrastructure. The Single Reporting Platform was required to be operational by the same date the reporting obligation began. The harmonised standards framework is still maturing, and no CRA harmonised standard has yet completed the process needed to provide presumption of conformity. And the duty to publish a disclosure channel, through which manufacturers may first learn that a product is being exploited, does not apply until December 2027.
This is now the pattern rather than the exception. NIS2 followed it. The AI Act followed it. Obligations are staged and brought into force ahead of the supporting ecosystem, on the reasoning that waiting for complete tooling would delay risk reduction by years.
The practical consequence for a GRC function is structural. Compliance programmes increasingly have to operate in the interval between an obligation taking effect and the ecosystem around it maturing. Advice written on the assumption that regulation arrives fully formed will not survive contact with an actual incident.
We build CRA readiness to be operated, not filed.
Gartner Recognised
We are thrilled to share that Integrity360 has been recognised as a Gartner Representative Vendor in 6 of their Market Guides, including: Managed Security Services, Managed Detection and Response, Gartner's Market Guide for Co-Managed Security Monitoring Services and Managed SIEM Services.
Gartner has included a range of providers within its market guide for managed services to ensure clear coverage from a geographical, vertical and capabilities perspective. Those included in the Gartner market guide display clarity in the vision for an end-user outcome-focused offering distinct from a pure technology-driven offering.
Speak to an expert
Find out how we can help your organisation prepare for the Cyber Resilience Act - talk to an advisor about which solution could be right for you.
Call us
London: +44 20 3397 3414
Sofia: +359 2 491 0110
Cape Town: +27 08 606 25673
Johannesburg: +27 08 606 25673
Email us
CRA FAQs
What is the Cyber Resilience Act?
The EU regulation setting cybersecurity requirements for products with digital elements sold in the European Union. It covers the full product lifecycle, from secure design and development through to vulnerability handling and support after a product reaches the market.
Who does the CRA apply to?
Manufacturers of products with digital elements placed on the EU market, and importers and distributors of those products. Organisations do not need to describe themselves as manufacturers to fall within scope. The regulation considers what is placed on the market and under whose name or trademark, which can bring own-brand hardware, embedded and bundled software, rebranded products and connected devices sold under a company’s own logo within scope.
When does the CRA take effect?
In force since 10 December 2024. Reporting obligations under Article 14 apply from 11 September 2026 and extend to products already on the market. The remaining obligations apply from 11 December 2027.
What are the key CRA reporting requirements?
A manufacturer that becomes aware of an actively exploited vulnerability or severe incident affecting the security of its product must submit an early warning within 24 hours, a fuller notification within 72 hours, and a final report thereafter. Reports go through the Single Reporting Platform operated by ENISA, addressed to the CSIRT designated as coordinator for the manufacturer’s main establishment. For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, it is due within one month of the 72-hour notification. This is not a requirement to report every vulnerability.
Does the CRA affect organisations that do not manufacture products?
Operationally, yes, although such organisations are not themselves regulated as manufacturers under the CRA. Manufacturers must inform affected users of actively exploited vulnerabilities and severe incidents in their products, along with any corrective measures available. Where a manufacturer does not do so, the coordinating national CSIRT may inform users directly. Organisations will need a named recipient for those notifications, a defined route into incident triage, and clarity on whether a given notification engages their own obligations under NIS2 or DORA.
Does a manufacturer notification trigger NIS2 or DORA reporting?
Not automatically. A manufacturer’s advisory initiates assessment rather than reporting. Whether it becomes reportable depends on whether the organisation’s own services are materially affected and on the thresholds set by each regime. Where those thresholds are met, the organisation will be expected to evidence when it became aware.
Does the CRA apply to UK-based organisations?
In many cases, yes. The CRA applies to products placed on the EU market regardless of where the manufacturer is established. UK organisations selling products with digital elements into the EU, or supplying components to manufacturers that do, need to assess their obligations. Integrity360 supports UK organisations in determining scope and implementing the necessary controls.
How can Integrity360 help with CRA compliance?
End-to-end support across applicability and scope assessment, product classification, Article 14 reporting readiness, coordinated vulnerability disclosure, supplier notification routing, product security testing, technical documentation and conformity assessment preparation, and integration of CRA obligations into existing NIS2 and DORA programmes.
What should organisations do now to prepare?
Establish whether the regulation applies, to which products, and in which class. Identify the national CSIRT designated as coordinator for your main establishment. Define in writing what constitutes awareness and who is authorised to escalate outside business hours. Organisations that are not manufacturers should name the individual receiving manufacturer security notifications and route that channel into incident triage.
What makes Integrity360’s CRA service different?
Two capabilities shape our approach. First, the same group that advises on the obligation also operates the detection and response capability that feeds it, through our 24/7 Security Operations Centres and Managed Detection and Response services. Awareness is what starts the initial reporting clocks, and advisory work alone cannot influence it. Second, through Holiseum we assess the product itself, including embedded, IoT and OT systems, rather than the documentation describing it. Scope and classification decisions are made by engineers who can examine the device.
