The EU Cyber Resilience Act (CRA) is already changing product security requirements. Since 11 September 2026, manufacturers have faced mandatory reporting obligations for certain actively exploited vulnerabilities and severe security incidents. The main product cybersecurity requirements apply from 11 December 2027. For manufacturers selling into the EU, preparation cannot wait.
Whether we’re talking about industrial controllers, IoT devices, embedded systems or commercial software, the reality is that many of these products have been developed with functionality, performance and cost taking priority over security.
The European Union’s Cyber Resilience Act (CRA) is changing that.
And for manufacturers selling products into the European market, this isn’t something that can simply be left to the compliance team to deal with.
It’s going to require a fundamental change in how products are designed, developed, tested and maintained.
What Is the EU Cyber Resilience Act (CRA)?
The Cyber Resilience Act is a European regulation designed to introduce mandatory cybersecurity requirements for products containing digital elements.
In simple terms, if you’re manufacturing hardware or software that is sold within the European Union, there’s a good chance the CRA will apply to you.
This includes products such as:
- Industrial control systems and embedded devices
- IoT and connected technologies
- Network equipment, routers and firewalls
- Commercial software applications
- Smart sensors and monitoring equipment
- Industrial automation and operational technology (OT) devices
There are exclusions for certain products already covered by specific EU legislation, so manufacturers need to establish whether their products fall within scope.
One important point for UK manufacturers is that being based outside the EU doesn’t necessarily remove your obligations.
If you’re placing products on the European market, the CRA could still apply.
Cyber Resilience Act Deadlines: September 2026 and December 2027
Although the CRA’s main requirements become applicable on 11 December 2027, some important obligations have already taken effect.
Since 11 September 2026, manufacturers have been required to report certain actively exploited vulnerabilities and severe security incidents affecting their products.
The reporting requirements include:
- An initial early warning within 24 hours of becoming aware.
- A more detailed notification within 72 hours.
- A final report within 14 days after a corrective or mitigating measure is available for an actively exploited vulnerability, or within one month of the 72-hour notification for a severe incident.
Notifications are submitted through the EU’s Single Reporting Platform.
Think about what this means operationally.
If a manufacturer discovers that one of its products contains a vulnerability being actively exploited, it needs the ability to identify the issue, understand its impact and initiate the appropriate reporting process extremely quickly.
For organisations that don’t already have mature vulnerability management processes, that’s going to be a challenge.
For official guidance on reporting timelines, see the European Commission CRA reporting guidance.
How Penetration Testing Supports Cyber Resilience Act Readiness
One of the areas I find particularly interesting is how the CRA will influence security testing.
The regulation doesn’t simply say that every product must undergo an annual penetration test. Instead, it introduces risk-based cybersecurity requirements that manufacturers must demonstrate they have addressed.
In practice, independent security testing can play an important role in providing evidence that a product has been appropriately assessed.
At Rootshell, we approach security testing from an attacker’s perspective.
A product might function perfectly well in its intended environment, but what happens when someone deliberately attempts to manipulate its communications, bypass authentication or exploit weaknesses in its firmware?
For embedded devices and industrial equipment, testing might involve:
- Analysing firmware for known vulnerabilities and insecure components.
- Assessing network services and exposed interfaces.
- Testing authentication and access controls.
- Reviewing industrial communication protocols such as Modbus TCP, PROFINET and other OT protocols.
- Identifying insecure configurations and unnecessary services.
- Assessing update mechanisms and the integrity of firmware.
- Testing whether vulnerabilities could allow unauthorised access or manipulation of device functionality.
Importantly, testing needs to be appropriate for the technology involved.
You can’t necessarily approach an industrial controller in the same way you would a conventional web application. Safety, availability and the potential operational consequences of testing need to be carefully considered.
The objective isn’t simply to produce a penetration testing report. It’s to identify weaknesses before those weaknesses become exploitable problems for customers.
Why Continuous Vulnerability Management Matters Under the CRA
Another significant aspect of the CRA is the requirement for manufacturers to manage vulnerabilities throughout the supported lifecycle of their products.
Historically, some manufacturers have treated security as something that gets addressed during development, with limited attention given to what happens after the product has been sold.
That approach is becoming increasingly difficult to justify.
Imagine a manufacturer producing an industrial controller that contains a third-party operating system, an embedded web server and several open-source software libraries.
The product might be secure when it leaves the factory.
However, six months later, a critical vulnerability could be discovered in one of those underlying components.
How does the manufacturer know whether its products are affected?
How quickly can it identify which versions contain the vulnerable component?
And perhaps most importantly, how does it determine whether that vulnerability is actually being exploited?
These are exactly the types of challenges that manufacturers need to start addressing.
Vulnerability Intelligence: Understanding What’s Actually Dangerous
This is an area where I believe vulnerability intelligence becomes particularly valuable.
At Rootshell, we’ve invested heavily in developing our own vulnerability management and threat intelligence capabilities through our platform and Velma AI (Vulnerability Enhanced Learning Machine).
One of the challenges with traditional vulnerability management is the sheer volume of information organisations receive.
Vulnerabilities are published, but not all of them represent the same level of risk.
A vulnerability with a critical CVSS score doesn’t automatically mean that it’s being actively exploited, or that it’s relevant to a particular product.
Equally, a vulnerability with a lower severity score might present a significant threat if exploitation is occurring in the wild.
Our approach with Velma is to bring together multiple sources of vulnerability and exploitation intelligence to help organisations understand which issues deserve attention.
For manufacturers preparing for the CRA, this type of capability can support several important activities:
- Monitoring newly disclosed vulnerabilities.
- Identifying evidence of active exploitation.
- Prioritising vulnerabilities based on actual threat intelligence.
- Supporting remediation decisions.
- Providing visibility of emerging security threats.
- Showing auditors evidence
Of course, vulnerability intelligence is only part of the solution. Manufacturers also need an accurate understanding of the software and components incorporated into their products.
This is where maintaining a Software Bill of Materials (SBOM) becomes particularly useful.
By combining component visibility with relevant vulnerability intelligence, manufacturers are in a much stronger position to understand their exposure and respond appropriately.
What About Operational Technology and Industrial Equipment?
I suspect one of the biggest challenges will be within the operational technology sector.
Many industrial manufacturers have traditionally operated in environments where equipment remains deployed for 10, 15 or even 20 years.
Unlike conventional IT systems, industrial equipment isn’t always straightforward to patch or upgrade.
Firmware updates may require production downtime, specialist engineering support or extensive testing before they can be safely deployed.
Some devices also use proprietary communication protocols or have limited processing capabilities, making conventional security controls difficult to implement.
The CRA introduces an additional consideration for manufacturers developing these products.
Security needs to be considered from the initial design stage, rather than something added once the product is ready to ship.
This includes understanding how the product communicates, what interfaces are exposed, how authentication is implemented and how vulnerabilities will be addressed throughout its supported lifetime.
For manufacturers of industrial and embedded equipment, security by design needs to become part of the engineering process.
What Should Manufacturers Be Doing Now?
With the main CRA requirements applying from December 2027, manufacturers still have time to prepare, but I wouldn’t recommend leaving it until the last minute.
There are several practical steps organisations should already be considering.
1. Understand which products fall within scope
Review your hardware and software portfolio and identify products that could be subject to the CRA.
2. Carry out a cybersecurity gap assessment
Understand your current security posture against the relevant CRA requirements, including secure development, vulnerability handling and product documentation.
3. Introduce appropriate security testing
Consider penetration testing, firmware assessments and embedded device security testing as part of your product development lifecycle.
4. Establish vulnerability management processes
Ensure you have the ability to identify, assess, prioritise and remediate vulnerabilities affecting your products and their components.
5. Review your incident and vulnerability reporting capabilities
With the reporting obligations already in effect, manufacturers need processes that allow them to respond within the required timescales.
6. Build security into product development
Security shouldn’t be something that gets considered a few weeks before a product is released. It needs to be incorporated into the design, development and maintenance process.
How Rootshell Security Can Help
At Rootshell Security, our focus has always been on helping organisations understand and manage real cybersecurity risks.
For manufacturers preparing for the Cyber Resilience Act, we can support the technical security activities that form part of a broader compliance programme.
This includes:
Embedded Device and OT Security Testing (subject to technical scope confirmation)
Assessing industrial equipment, embedded systems and connected devices to identify vulnerabilities within firmware, network communications and exposed interfaces.
Providing independent security assessments to identify exploitable weaknesses in applications, infrastructure and connected products.
Using the Rootshell Platform to help organizations manage identified vulnerabilities, track remediation and maintain visibility of their security posture.
Threat Intelligence Through Velma AI
Providing intelligence on emerging vulnerabilities, exploitation activity and potential threats to help manufacturers make more informed security decisions.
It’s important to recognise that penetration testing alone doesn’t demonstrate full CRA compliance. Manufacturers will also need to address the applicable documentation, conformity assessment, product security and lifecycle requirements.
However, independent technical testing and effective vulnerability management can provide valuable evidence and support for that process.
CRA Readiness Starts With Product Security, Not Paperwork
Personally, I think the Cyber Resilience Act is a positive development because it brings enforceable expectations for product security.
For too long, we’ve seen products introduced into the market with security weaknesses that could have been identified during development.
The challenge has often been that manufacturers haven’t necessarily had a regulatory or commercial incentive to invest in security beyond basic functionality.
The CRA changes that conversation.
It places greater responsibility on manufacturers to understand the security of their products, address vulnerabilities and provide ongoing support.
For some organisations, this will require significant changes to their existing processes.
But I also think there’s an opportunity here.
Manufacturers that take product security seriously will be better positioned to demonstrate the security and resilience of their products to customers.
Ultimately, the CRA shouldn’t just be viewed as another compliance requirement. It should be seen as an opportunity to build better, more secure products.
And that’s something the entire cybersecurity industry should be supporting.
If your organisation manufactures embedded devices, industrial equipment or software products destined for the European market, Rootshell Security can help you understand the technical security challenges associated with the Cyber Resilience Act.
Talk to Rootshell about product security testing and continuous vulnerability management.
FAQs
Does the EU Cyber Resilience Act apply to UK manufacturers?
Yes, potentially. The CRA applies to products with digital elements made available on the EU market, including products supplied by manufacturers based outside the EU. Manufacturers should assess their specific products, roles and applicable exclusions.
When do the Cyber Resilience Act requirements take effect?
The CRA’s main requirements apply from 11 December 2027. Mandatory reporting of certain actively exploited vulnerabilities and severe security incidents began on 11 September 2026.
Does the Cyber Resilience Act require penetration testing?
The CRA sets risk-based product cybersecurity and vulnerability-handling requirements; it does not mandate an annual penetration test for every product. Appropriate security testing can support risk assessments and technical evidence, but testing alone does not establish compliance.
What must manufacturers report under the CRA?
Manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of their products when the CRA reporting criteria are met. An early warning is required within 24 hours and a fuller notification within 72 hours, followed by the applicable final report.
How can manufacturers prepare for CRA compliance?
Start by assessing product scope, identifying software and hardware components, reviewing secure development and vulnerability-handling processes, planning risk-appropriate testing, and ensuring reporting processes can meet the deadlines. A software bill of materials (SBOM) can support component visibility.
For more on scope and obligations, see the European Commission CRA summary.
