The Cyber Resilience Act landscape continues to move quickly and after the summer break, there is quite a lot to catch up on.
Our CRACoWi partner and CRA expert Michael Beine from Bureau Veritas has put together a practical overview of some of the latest developments, from the European Commission’s CRA Guidance and ENISA’s SME maturity assessment tool to the Single Reporting Platform, Notified Bodies and ongoing standardisation work.
If you lost track of some of the developments over the summer, this is a good place to catch up. Michael’s overview provides a quick read, together with links for those who want to explore individual topics in more detail.
CRA Guidance
The European Commission released the official CRA Guidance at the end of July.
This is a must-read for organisations preparing for CRA implementation. After the legal text itself, the Guidance provides an important source for interpreting the Regulation and brings additional clarity to many, although not all, questions surrounding CRA implementation.
ENISA has published a guided self-assessment for CRA readiness, particularly intended to support small and medium-sized enterprises (SMEs).
The SME Cyber Resilience Maturity Assessment Model can help organisations assess their current level of preparedness and identify areas requiring further attention.
ENISA continues to update its FAQs and guidance related to the Single Reporting Platform.
Among the relevant information currently available are the required datasets for the different types of reports.
To avoid unnecessary overload, the current recommendation is not to register in advance, but only when a report needs to be submitted.
Another small but practically relevant detail has recently been updated: up to 21 representatives can now be registered for one manufacturer, compared with two previously.
The nomination process for CRA Notified Bodies has started in several EU Member States through the relevant national authorities.
Bureau Veritas has submitted its application and is currently participating in the nomination process.
Relevant information on national processes is available from authorities including BSI, DAkkS and ANSSI, as well as through the available information on CRA notifying authorities.
Significant progress has also been made in the development of horizontal standards, including EN 40000-1-1, EN 40000-1-2 and EN 40000-1-3, with final versions becoming available.
Seventeen vertical standards developed by ETSI (i.e. EN 304 xxx) have reached the necessary maturity to enter Enquiry Phase.
Work is also continuing on the broad vertical standards (EN IEC 62443 prAA), with the relevant working group convening in Oslo.
Together, these developments show just how quickly the wider CRA implementation ecosystem is progressing and why keeping track of guidance, reporting mechanisms, conformity assessment and standardisation is becoming increasingly important for organisations preparing for compliance.
The EU Cyber Resilience Act (CRA) reshapes how manufacturers, importers, and distributors must approach cybersecurity. At the centre of this shift is threat modelling – the structured practice of discovering weaknesses before attackers do. Rather than being a checklist activity, threat modelling is the CRA’s foundational requirement for demonstrating secure-by-design thinking from concept through retirement.
This article distils the threat-modelling workflow presented in the CRACoWi project’s first educational session and turns it into a practical, repeatable blueprint for teams preparing for CRA compliance.
Why the CRA Makes Threat Modelling Mandatory
According to Annex I, manufacturers must perform and document a risk assessment for each Target of Evaluation (TOE). Threat modelling provides the structured inputs, such as attack surfaces, weak points, exposure paths, that this assessment depends on.
The CRA’s emphasis on secure-by-design means organisations must consider security before implementation begins. Threat modelling supports this by:
Revealing blind spots early,
Helping teams prioritise the most harmful attack paths,
Guiding secure configuration and update design, and
Supporting long-term maintenance as the product evolves.
Because the threat model is meant to live throughout the lifecycle, it must be structured, revisited after changes, and backed by evidence. It is important to note that the CRA does not mandate any specific threat-modelling methodology or tools, and the approaches described here represent one practical way to fulfil the CRA’s risk-assessment obligations. Manufacturers are free to adopt any structured method that allows them to identify threats, evaluate risks, and demonstrate secure by design decision-making. The key requirement is the outcome, not the choice of tooling.
Threat Modelling as a Multi-Level System Analysis
A key strength of the approach presented is the three-level zoom. Each layer exposes different threat categories and prevents tunnel vision.
Level 0: The Black-Box System Context
At this stage, we avoid internals and examine the device as an object inside an ecosystem.
Questions include:
What systems does it communicate with?
Which protocols does it use?
What paths allow interaction from users or attackers?
What is exposed on the local network or wider internet?
Communication matrices; like those generated via Bunkai; help enumerate real network traffic and supporting infrastructure (DNS, NTP, cloud endpoints). Even ancillary flows must be kept, as seemingly harmless protocols can become attack vectors (e.g., NTP spoofing, DNS poisoning).
Level 0 reveals the external threat surface: open ports, exposed interfaces, unencrypted services, remotely reachable management ports, or impersonable systems (e.g. a backend used without validating its identity). At this stage, the physical interfaces of the device are not taken into consideration.
Level 1: Trust Boundaries and Internal Architecture
Now we look inside:
What components exist?
Which services run on the device?
Where are trust boundaries?
Who controls each component (manufacturer, device user, cloud provider)?
By correlating communication data with an SBOM (CycloneDX or SPDX) produced by OneKey, we match network flows to specific software components. This allows you to distinguish between services that are truly active on the device and libraries that appear in the SBOM only because they were compiled into the firmware but are not exposed or reachable during operation.
At this point, we:
Define trust zones (edge, internal, user-controlled, attacker-accessible),
Mark boundaries where authentication or encryption is required, and
Extend the communication matrix with service purpose, encryption state, and boundary crossings.
This level ties the environment to the architecture and signals where attackers are most likely to focus.
Level 2: Detailed Processes, Software Versions, and Physical Interfaces
This is the deepest zoom level. At this stage, the device is dissected to reveal:
Runtime processes
Interactions between the web server, application logic, storage, and the operating system
Hard-coded credentials or misconfigurations found in firmware scans
A port scan (via Bunkai) helps validate which SBOM components are truly active. This avoids inflating risk with dormant libraries that attackers cannot reach.
Once all flows – external and internal – are labelled, each becomes a candidate for STRIDE analysis.
Identifying Threats with STRIDE
STRIDE is used at each level, but the detail increases dramatically as we descend:
S — Spoofing
Impersonation of users, devices, or services (e.g., someone pretending to be the SCADA).
T — Tampering
Changing configs, logs, firmware, or traffic; injecting malicious code.
R — Repudiation
Gaps in logging or auditability, including the absence of non-repudiation mechanisms such as secure logging or validated audit records.
I — Information Disclosure
Exposure via unencrypted HTTP, verbose errors, insecure storage.
D — Denial of Service
Overloading services or distracting operators.
E — Elevation of Privilege
Jumping from user to admin, exploiting weak isolation, or leveraging known CVEs.
Each STRIDE category may generate dozens of possible threats; depth is more important than balancing categories. Attackers only need one unprotected path.
Mapping Threats to Real-World Attacks Using MITRE
To turn abstract threats into concrete attack techniques, MITRE frameworks are used:
MITRE ATT&CK
A comprehensive, technical map of adversarial behaviour (reconnaissance, persistence, exploitation, command and control, etc.).
MITRE EMB3D
A simplified version tailored to IoT/ICS devices. Teams select components (e.g., microprocessor, radio module, web server) and receive a CSV of relevant attack patterns.
Each STRIDE threat is translated into keywords (“cleartext HTTP”, “network sniffing”, “device impersonation”, etc.), which are then matched to ATT&CK techniques. MITRE provides mitigation guidance linked to each technique, which teams can use to inform design decisions and later risk prioritisation.
Moving From Threat Modelling to Risk Assessment
Threat modelling generates an enormous list of issues, often hundreds for modern IoT/ICS systems. The next phase—required by the CRA—is prioritisation.
The CVSS calculator helps break threats down into:
Likelihood (Is the attacker remote? Is privilege required? Is user interaction needed?)
Impact (Does it compromise confidentiality, integrity, or availability?)
From these values, teams derive a severity score, and high-severity threats are addressed first to guide engineering effort efficiently. Evidence gathered earlier (SBOM entries, firmware issues, network captures) strengthens confidence ratings. Peer review is recommended to validate assumptions and catch blind spots.
CVSS scoring can be used to evaluate specific vulnerabilities or well-defined threats, but it is not required by the CRA. Organisations may use CVSS or follow their own risk assessment method, provided it produces clear likelihood, impact, and severity evaluations that meet CRA expectations.
Integrating Threat Modelling into the Device Lifecycle
CRA compliance is not about a one-time paperwork exercise. Threat modelling must be:
Updated whenever the product changes,
Kept synchronised with new firmware releases,
Re-evaluated when new CVEs are published,
Documented in a way importers, authorities, and notified bodies can trust.
This ongoing evaluation also supports compliance with the CRA’s RA 2 vulnerability-handling requirements, which oblige manufacturers to continually monitor, assess, and address newly identified issues throughout the product’s lifecycle. When done properly, the threat model becomes the backbone of CRA documentation and a long-term quality asset—not just an audit requirement.
And to conclude
Threat modelling under the Cyber Resilience Act is a structured, multi-layered process that gives manufacturers the insight needed to produce truly secure-by-design products. By combining environmental analysis, architectural inspection, firmware analysis, STRIDE classification, and MITRE mapping, teams can uncover weak points early and track them across the device’s entire lifetime.
This approach ensures not only CRA compliance but also a fundamentally more secure and resilient product line—something that benefits manufacturers, regulators, and end users alike.
Last week the European Commission has published a practical guidance to help manufacturers, developers, and businesses of all sizes meet their obligations under the Cyber Resilience Act – timely news for everyone in our community preparing for compliance.
The guidance clarifies some of the questions manufacturers ask us most often, including:
When products fall in scope – including remote data processing solutions and free and open source software
What counts as a “substantial modification”
How to interpret support periods
Reporting obligations and risk assessment requirements
Good news for SMEs in particular: the guidance includes 67 practical examples, use cases, flowcharts, and graphs to make the path to compliance clearer and more proportionate.
Good to keep in mind:
Reporting obligations already apply from 11 September 2026
Main CRA obligations apply from 11 December 2027
This is exactly the kind of regulatory clarity CRACoWi is built to help manufacturers translate into action.
The EU cybersecurity regulatory landscape is evolving fast – and organisations across every sector are being asked to keep pace. Building Cyber Resilience in the Digital Era is a high-impact workshop organised by the EU-funded projects CRACoWi, DETANGLE, and INCIDENTRON, bringing together policy, practice, and peer projects for a single day of focused, practical exchange.
The event centres on three interconnected themes shaping the future of digital resilience in Europe:
NIS2 compliance – what implementation really looks like in practice
Cyber Resilience Act (CRA) enforcement – what to expect as the regulation takes hold
Collaborative, cross-border cybersecurity incident response – how sectors and countries can work together more effectively when it matters most
This is not a theoretical policy briefing. It’s a working session designed to give attendees concrete tools, honest insights from the field, and direct access to the people building solutions to help organisations comply and stay resilient.
What You Will Gain
The workshop will provide practical guidance, real-world insights, and interactive discussions to help organisations strengthen resilience and meet evolving EU cybersecurity obligations. It moves beyond theory to deliver actionable guidance for organisations navigating the new EU cybersecurity regulatory landscape – whatever stage of the compliance journey they’re at.
What to Expect
Presentations from peer EU-funded projects See the tools and services being developed across Europe’s cybersecurity project landscape, and learn how relevant stakeholders can put them to use to strengthen readiness and achieve compliance.
Expert-led discussions A special focus on the practical challenges of NIS2 implementation, expectations around CRA enforcement, and strategies for effective cross-sector, cross-border collaboration in incident management.
Active participant engagement Ask questions, engage with experts and peers, and take part in an open survey and discussion to share your concerns, priorities, and interest in testing the projects’ solutions.
Networking lunch A valuable opportunity to continue the conversation and build lasting connections within the cybersecurity community.
Who Should Attend
This event is open to a broad audience, including:
SMEs, startups, and enterprises
Business leaders and decision-makers
Cybersecurity professionals
Legal and compliance experts
Regardless of sector, any organisation seeking to better understand and prepare for EU cybersecurity regulations will benefit from participating.
Whether you’re leading compliance efforts, shaping strategy, or working on the ground to strengthen your organisation’s cyber resilience, this is a chance to learn directly from the projects building Europe’s cybersecurity toolkit – and to help shape what comes next.
📅 Friday, 2 October 2026 🕘 09:00 – 16:00 📍 Electra Palace Athens – 18-20 N. Nikodimou str, 10557 Athens, Greece 🌐 Language: English
Understanding the Cyber Resilience Act (CRA) starts with understanding its language and that language isn’t always easy to navigate. Legal terminology, technical acronyms, and compliance concepts are scattered across the regulation and its supporting standards, often without a clear, accessible explanation in one place.
To close that gap, CRACoWi partners have developed the CRA Compliance Glossary, now available as a new resource on the CRAcademy hub. Built as part of CRAcademy’s mission to provide clear and practical information about the CRA (through FAQs, blogs, expert insights, and more) the glossary is designed to be your quick reference whenever CRA terminology gets in the way of getting things done.
The Glossary
The glossary brings together plain-language definitions of the terms, acronyms, and concepts that come up throughout the CRA compliance journey — from foundational security properties like confidentiality, integrity, and availability, to CRA-specific mechanisms such as the Declaration of Conformity, CE marking, and conformity assessment routes. It also covers the technical vocabulary manufacturers and product teams encounter in practice: SBOMs, SAST/DAST testing, threat modelling frameworks like STRIDE, vulnerability disclosure policies, and more.
Each entry is written to be understood without a legal or cybersecurity background, while staying precise enough to be useful for teams already deep in their compliance work.
The Cyber Resilience Act establishes uniform cybersecurity criteria for digital products placed on the EU market, covering the entire product lifecycle from design through decommissioning. For manufacturers, importers, and distributors (particularly SMEs without dedicated legal or cybersecurity teams) getting familiar with this vocabulary is often the first practical step toward compliance, well before documentation or technical measures come into play.
For those who prefer to save, print, or share the glossary offline, a PDF version of the CRA Compliance Glossary has also been published as an open-access download on Zenodo, ensuring the resource remains freely and permanently available to the wider CRA compliance community.
The glossary joins the CRAcademy webinar series and other capacity-building resources already available on the platform, reinforcing CRACoWi’s broader goal: helping SMEs, manufacturers, distributors, and importers meet new cybersecurity standards throughout the product lifecycle.
The implementation landscape around the Cyber Resilience Act (CRA) is evolving rapidly. While the regulation itself entered into force in 2024, the ecosystem surrounding it – including guidance documents, harmonised standards, certification schemes, and conformity assessment procedures – is now taking shape at a remarkable pace.
For companies working with products containing digital elements, 2026 has become a crucial year for understanding how CRA requirements will be interpreted and applied in practice. From draft guidance published by the European Commission to major developments in standardisation and certification, several important milestones have already been reached.
This overview is prepared based on insights and analysis provided by Michael Beine (Bureau Veritas), contributor to the CRACoWi project activities related to certification, standardisation, and CRA implementation developments.
1. Draft CRA Guidance Published by the European Commission
In March 2026, the European Commission published the draft guidance on the Cyber Resilience Act, with the commenting period ending in April 2026. The final version is expected towards the end of 2026 or beginning of 2027:
It provides interpretations of CRA legal text from official source of truth.
A must-read for everybody seeking clarity and interpretation of CRA.
In some cases, the additional level of detail creates follow-up questions, which will hopefully be addressed in the final revision
This draft guidance is particularly important because it provides interpretations of the CRA legal text directly from the official source. For many stakeholders, it is currently one of the most valuable documents available for understanding how certain provisions of the regulation may be interpreted in practice.
The document also demonstrates the complexity of implementing the CRA. While the guidance clarifies several topics, the additional level of detail has, in some areas, also created follow-up questions from industry and standardisation groups. Many stakeholders are now expecting that some of these open points will be addressed in the final revision.
2. RED-DA Cybersecurity Requirements will be Repealed – It is Official
Another major development became official in 2026. To avoid overlapping regulatory requirements, the cybersecurity-related provisions under Article 3.3 d/e/f of the Radio Equipment Directive (RED-DA) will be deactivated on the date the CRA becomes fully applicable: 11 December 2027.
This confirms an important signal from the legislator: there is currently no indication that the CRA timeline will be delayed. The transition towards CRA remains firmly on track.
3. Standardisation is Moving Forward Rapidly – prEN 40000-1-2 Drafting is Completed
Standardisation activities around the CRA are accelerating significantly.
The drafting of the first horizontal CRA standard, prEN 40000-1-2 “Cybersecurity requirements for products with digital elements – Part 1-2: Principles for cyber resilience”, has been completed and entered final review. If the formal vote is positive, publication could follow by the end of October 2026.
This is an important milestone because horizontal standards are expected to play a key role in supporting harmonised approaches to CRA compliance across industries.
At the same time, discussions around sector-specific standards continue intensely.
4. Debate Around “Broad Verticals” and IEC 62443 – “Broad verticals will not be cited in the OJEU“
One statement made by the European Commission during the ENISA Conference in March 2026 created significant discussion within standardisation working groups and the OT industry.
According to comments shared publicly after the event, the Commission stated that “broad verticals will not be cited in the Official Journal of the European Union (OJEU).”
This has raised concerns among stakeholders working on adapting IEC 62443 standards for CRA presumption of conformity, particularly in industrial and operational technology environments.
The standards EN IEC 62443-4-1 and EN IEC 62443-4-2 remained in public consultation (Enquiry phase) until the end of April 2026. However, discussions around how these standards may ultimately be referenced under the CRA framework are still ongoing.
At this stage, it is clear that the final approach to sector-specific harmonisation is still evolving.
The last word is probably not yet said about this.
5. CSA2 draft regulation proposes new Certification Schemes for CRA
The proposed update of the Cybersecurity Act (commonly referred to as CSA2) also represents an important step in aligning the EU cybersecurity certification framework with the CRA.
The proposal aims to facilitate the creation and adaptation of certification schemes supporting CRA requirements. This is particularly relevant for products that may require third-party conformity assessment procedures.
The proposal for the revised EU Cybersecurity Act has been published under the European Commission’s “Shaping Europe’s Digital Future” initiative.
CSA2 aims to boost the creation and adaptation of Certification Schemes for the CRA.
The European Commission has also indicated plans for an implementing act approving the EU Common Criteria (EUCC) scheme for CRA purposes. This would support conformity assessment procedures for critical products with digital elements, including categories such as payment terminals, smart cards, and smart meter gateways.
While no publicly available implementing act reference has yet been identified, this would represent another major step towards operationalising CRA conformity assessment mechanisms.
7. „fast track“ procedure for NoBo under RED-DA
Another important discussion currently taking place involves a potential “fast-track” procedure for the nomination of Notified Bodies (NoBos) under the CRA.
According to publicly shared information from discussions between the European Commission and ADCO CRA, the proposal would simplify nomination procedures for organisations already designated under RED-DA.
The objective appears straightforward: ensuring that a sufficient number of Notified Bodies are available before the CRA becomes fully applicable at the end of 2027.
As the Cyber Resilience Act (CRA) moves closer to full implementation, many SMEs are still trying to understand what the regulation means in practice and how to prepare for compliance. The good news is that support is already taking shape across Europe.
Several EU-funded initiatives, including CRACoWi and other projects within the CRA Cluster, are actively developing practical tools, guidance materials, and training resources designed to help organisations navigate the new cybersecurity requirements.
Within CRACoWi, the first support resources are already becoming available. This includes tools such as the CRA Scope Assesment, helping organisations better understand whether and how the CRA applies to their products, as well as the CRAcademy initiative, offering webinars, workshops, and educational materials focused on CRA implementation and cybersecurity compliance.
And this is only the beginning. Additional tools, guidance documents, training materials, and practical support mechanisms are currently under development and will continue to evolve over the coming months.
If you want to stay informed about the latest developments, upcoming training sessions, and new CRA support resources, make sure to follow the CRACoWi project and subscribe to the newsletter.
You can also explore the broader ecosystem of initiatives by visiting the CRA Cluster projects working towards practical CRA implementation across Europe: CRA Cluster
A Regulatory Ecosystem Taking Shape
What becomes increasingly clear is that the CRA is no longer only a legal text. The broader implementation ecosystem (guidance documents, harmonised standards, certification schemes, conformity assessment procedures, and institutional coordination) is now actively developing.
For companies across Europe, especially SMEs, staying informed about these developments will be essential over the coming months. The pace of change is high, and many practical aspects of compliance are still being refined in parallel with the regulation’s rollout.
Projects such as CRACoWi are therefore becoming increasingly relevant, not only because they raise awareness about the CRA, but because they help organisations translate evolving regulatory requirements into practical implementation steps.
About the Author Michael Beine is a cybersecurity and regulatory compliance expert at Bureau Veritas Consumer Product Services Germany, with more than 20 years of experience in the testing, inspection, and certification industry. His work focuses on cybersecurity requirements for connected products, IoT security, industrial automation, and European regulatory frameworks, including the Cyber Resilience Act (CRA) and RED Delegated Act. Within the CRACoWi project, he contributes to activities related to certification schemes, standardisation, and practical implementation of cybersecurity compliance requirements.
I am writing this article as the founder and owner of a small to medium-sized software company. At erminas, we develop software for industrial digitalisation. Our solutions are used by customers in productive environments – and that means responsibility. Responsibility for functioning systems, for security and for trust.
We are not a large corporation with our own security department. And that applies to many SMEs. Nevertheless, we bear the same responsibility as the big players – towards our customers, our employees and our society.
What cybersecurity looks like in everyday life
In many medium-sized companies, security is not a separate team. Security issues arise in the midst of everyday life – between deadlines, customer requests and ongoing operations. Mostly inconspicuously, until something happens.
Then comes the headline. A critical security breach. Everyone asks themselves:
Are we affected?
Does this affect our customers?
Do we have this under control?
And suddenly everything is urgent.
Stress arises when structures are lacking
Patching is not the problem – it’s the process of getting there.
Which software component do we use?
Which versions are affected?
Where exactly?
Which customers are affected?
Is the fix already in place?
Has it been delivered?
Without clear structures, every security breach becomes a stress test. Instead of reacting calmly, you find yourself having to explain yourself – both internally and externally. This leads to uncertainty, avoidable stress and sometimes even a loss of trust.
The Cyber Resilience Act: not an adversary, but a help
The Cyber Resilience Act (CRA) provides a legal framework that demands transparency and responsibility. For us, this is not a threat scenario, but an opportunity:
Clear processes instead of ad hoc reactions
Transparent information for customers
Well-founded decisions instead of gut feelings
The CRA does not force anyone to be perfect. But it does demand traceability – and that can be achieved with good teamwork and smart tools.
In practice, this often means combining a few well-established approaches rather than building a heavy security organization. Many teams rely on Security Champions to embed security awareness into day-to-day work and act as local points of contact. Regular security awareness training helps ensure that risks and responsibilities are understood across the organization. On a structural level, frameworks such as the NIST Cybersecurity Framework provide a common language for documenting decisions, processes, and responsibilities – which is exactly what traceability under the CRA is about.
What this means for our work – A realistic scenario from our everyday life
Let’s imagine that a critical security vulnerability is discovered in a widely used open source library that is also used in our products. In the past, this would have triggered a chain reaction: Who uses what? Where? Which version? Has it been fixed yet? Who needs to be informed?
Today, the process is more structured – thanks to clear processes and a shared understanding of responsibility.
Step 1: Overview via the SBOM
Our software contains a Software Bill of Materials (SBOM) for each release. This allows us to see immediately:
Whether the affected library is used at all
In which version
In which products
And: Which customer installations are specifically affected
This reduces the potential circle from ‘all’ to ‘these five installations’. This creates focus – and saves valuable time.
Step 2: Check patch status
The next question: Is there already a patch? If so:
Have we already integrated it?
Is it part of a release?
Has this release already been delivered to the affected customers?
This can also be tracked – not always automatically, but transparently documented. And if no patch exists yet, we at least know where we need to prioritise.
Step 3: Include the threat model
Not every vulnerability is automatically critical in real-world use. That’s why we also evaluate:
Is the affected function even used by us?
Is the system exposed to the outside world?
Could external access to the vulnerability even take place?
This threat model helps to avoid panic and set priorities correctly. There is a difference between something being theoretically vulnerable and practically vulnerable.
Step 4: Communicate with the customer
On this basis, we can communicate confidently – not evasively, but clearly:
‘Your system uses the library, but not the affected version – no action is required.’
‘Yes, the vulnerability affects you. We have tested the patched version internally and will deliver it tomorrow.’
Or: ‘No fix is currently available, but your specific usage scenario is not vulnerable. We are monitoring the situation closely and will keep you informed.’
These conversations are very different from before: instead of uncertainty, we show clarity. Instead of technical explanations, we convey security. This strengthens trust – especially in critical moments.
That’s a difference. And it shows in customer relationships: trust grows when we take responsibility and act in a transparent manner.
Responding better together – in the CRACoWi project
In the EU project CRACoWi, we are developing pragmatic approaches for precisely this purpose. Not with the expectation that SMEs will do everything perfectly right away, but with the goal of enabling them to take action in the first place.
Sharing responsibility instead of passing it on
Learning together
Using tools that work in everyday life
This is in line with our attitude: we want to grow together, work fairly and remain human – even in stressful situations.
Conclusion: cyber security is teamwork
Secure software is not a luxury, but part of our responsibility. The CRA can help us to work in a more organised, calm and transparent manner – without any glossy strategies.
The Cyber Resilience Act (CRA) is a European Law aiming to enhance cybersecurity standards for products with digital components, ensuring that they remain secure throughout their lifecycle.
In particular, the products of interest are the ones connected directly or indirectly to another device or network, except for the ones that are already covered by similar regulations, such as medical devices, aviation and cars. Since these domains are the ones that bear the most dangers when it comes to safety, it is easy to neglect the risks that poor cybersecurity standards result in when it comes to seemingly less critical digital products, like IoT devices. These devices though, like smart home appliances, interact with the physical world through sensors and actuators and are also vulnerable to cyberattacks.
The CRA was signed in law on October 10, 2024, and was set into force on December 10, 2024. By 2027, there will be mandatory compliance for all software and hardware digital projects sold within the EU. To be confirmed that the products comply with the CRA requirements, they will bear the CE marking, which is part of the EU’s harmonisation legislation and declares that products sold within the EEA have been assessed to complete a satisfactory level of safety.
It is important to note that CRA complements other legislation in this area, specifically the NIS2 Directive, which together form a consistent model. While NIS2 ensures secure operations like policy, detection, incident reporting and supplier assurance, CRA ensures secure products by design integrity, vulnerability handling and updates.
The CRA strategy is that products must initially comply only with essential, high-level requirements in terms of health and safety, which are subsequently specified in detail through technical harmonised Standards drafted by European Standardisation Organisations.
Why should you care?
The significant difference between CRA and previous regulations is that CRA proposes horizontal legislation. Until now, the European Commission has followed a sector-by-sector approach in cybersecurity, which, although effective to some extent, also creates challenges such as overlapping or conflicting rules for similar types of products, duplicate requirements for companies that make products across different sectors, and an overall fragmentation of the market, due to inconsistency in cybersecurity obligations.
CRA aspires to establish a unified and concise cybersecurity framework that is accessible to all relevant stakeholders, without the need for sector-specific regulations. Such harmonisation also facilitates consumer choice, enabling individuals to more easily identify the products with the right cybersecurity features, as all products will be evaluated against the same coherent requirements.
The CRA acts as a proactive protection mechanism against security issues such as data breaches, operational disruptions, and safety risks. By enforcing minimum security requirements that are broadly applicable across the EU market, it reduces the likelihood of such incidents as well as the heavy fines associated with non-compliance. From an economic perspective, beyond regulatory penalties, stronger cybersecurity standards help organisations avoid the massive financial damages that cyberattacks cause every year.
Finally, the new requirements introduced by the CRA must be implemented across all stages of the value chain of digital products, beginning from the planning and design phase and extending to their development, deployment and maintenance. This lifecycle-wide approach ensures not only security, but also reliability and privacy, as products are built on robust cybersecurity principles from the very beginning.
The CRACoWi project stands at the spotlight of these regulatory demands, supporting SMEs in understanding and applying he CRA. By developing practical tools and methodologies and facilitating knowledge-sharing activities, CRACoWi empowers stakeholders to achieve compliance more effectively and strengthen their overall cyber resilience.
The importance of cybersecurity has never been greater, especially in light of the evolving digital landscape and escalating cyber risks. Two major EU regulatory frameworks – the Cyber Resilience Act (CRA) and the NIS2 (Network and Information Security) Directive – epitomize the growing commitment to securing the digital ecosystem, both by setting rigorous cybersecurity standards and by fostering cooperation among member states.
The Cybersecurity Landscape
According to the Global Cybersecurity Outlook 2025, cyber threats continue to escalate worldwide. Around 72% of organizations surveyed have reported a rise in cyber risks, largely fueled by ransomware, AI-powered tools, and increasingly sophisticated attacks. Examining how organizations measure up, it was found:
Amongst large corporations the average cybersecurity maturity level stands at 54%, showing a slight yearly improvement but indicating a need for growth. A 56% average protection rate against ransomware attack vectors among large companies indicates that without improved defences, major breaches can still occur. Small and mid-sized businesses also lag behind, with 36% considered in a critical cybersecurity state, despite an 18% improvement from 2024. (Source)
The financial sector leads with a 62.5% maturity score, motivated by regulatory pressure and investments. (Source)
Information security spending is rising, now at 9% of IT budgets in the EU, reflecting increasing investment but also recruitment challenges, as cybersecurity staffing ratios have declined despite the rising demand. 90% of organizations expect a surge in cyberattacks next year, emphasizing the urgency for preparedness. (Source)
Why the Cyber Resilience Act is Crucial for Digital Products
The Cyber Resilience Act (CRA) addresses the challenges of managing vulnerabilities and preventing cyber incidents by establishing uniform cybersecurity criteria for digital products available on the EU market. Around two-thirds of incidents reported under the Network and Information Security (NIS) framework result from exploited vulnerabilities, showing that managing hardware and software security throughout the entire product lifecycle – from design, to development, and through to decommissioning – is essential. (Source)
The CRA focuses on:
Cybersecurity rules and essential requirements for connected products with digital elements, including hard- and software, in both consumer and OT contexts.
Obligations spanning the entire supply chain, to be addressed by manufacturers, importers and distributors.
Lifecycle security, market surveillance, and enforcement to ensure ongoing compliance.
Notably, the CRA excludes cloud-based services or SaaS products, which fall under the scope of the NIS2 Directive, and other special categories such as medical or automotive devices, which are already covered by existing legislation.
The Role of NIS2 in Strengthening Cyber Resilience
The revised NIS2 Directive builds on its predecessor by addressing fragmented resilience across member states and sectors. It promotes:
A high level of cybersecurity across the EU, with mandatory measures such as incident handling, supply chain security and vulnerability management.
Enhanced cooperative structures, including a dedicated Cooperation Group to facilitate sharing of cyber threat intelligence and best practices, as well as a network of national Computer Security Incident Response Teams (CSIRTs) to coordinate operational response efforts.
The NIS2 directive raises the bar on cybersecurity governance, risk management, and compliance especially amongst the sectors newly included within its scope. Despite ongoing efforts, many organizations currently fail to fully comply with NIS2 standards, with significant gaps remaining in areas such as third-party risk evaluation and asset management.
Furthermore, while cybersecurity budgets and manpower have generally risen due to NIS2, many entities (particularly SMEs) face difficulties in securing adequate resources to meet these demands.
What These Developments Mean
The CRA and NIS2 together set EU-wide stringent cybersecurity standards that impact businesses operating in the EU, and also help to elevate security practices globally due to the market’s size and influence. The regulations encourage adoption of secure-by-design principles and robust risk management processes across digital product and service lifecycles.
These regulations incentivize greater investment in cybersecurity technologies and human capital, though persistent workforce shortages pose ongoing challenges. With cyberattacks growing in frequency and complexity, compliance with CRA and NIS2 provisions is critical to mitigating breaches, protecting sensitive data, and maintaining confidence in digital applications and products.
The emphasis on cross-border cooperation also strengthens the EU’s collective capabilities in incident detection, response, and recovery, thereby enhancing the overall resilience of the union against cyber threats.
While this overview only scratches the surface of the Cyber Resilience Act and NIS2 Directive, it is clear that cybersecurity remains a foundational element for the safety and reliability of digital products and services. The EU’s evolving regulatory landscape continues to make decisive progress in enforcing security from the earliest stages of product development, and unifying efforts to counteract rising cyber threats. To navigate the complex cyber risk landscape effectively, organizations must commit to compliance and allocate appropriate resources toward cybersecurity initiatives.
