The CRA brings with it a whole lot of documentation requirements. While many details are still being finalised, we already know the core compliance artifacts you’ll need. Echoing the principle of security-by-design, the paper trail should begin at the design stage and continue well past decommissioning.
Regulations aside, documenting early and thoroughly is just good development hygiene. The CRA gives a solid nudge toward these practices and might even save you a scramble later.
Too often, documentation is an afterthought, gathered shortly before release. Security is bolted on, instead of built into the product. In the worst-case scenario, all issues are discovered in a penetration test days before the go-live date. The CRA flips that script: it demands security and traceability across the entire life cycle of a device.
This guide walks through the key compliance artifacts – when to create them, how to keep them useful, and how to streamline the process as part of real-world development.
Before design even starts, you will have a broad concept of what the product should be and what it should be able to do. As you plan timelines for the development of the product, plan documentation as part of that timeline. Versioning plans should be defined early. This is also the time to look at the CRA classification information and determine which category your product fits into. You can use the CRACoWi Scope Check for this This has a big impact on the path to compliance, as some devices can be self-assessed, others require a notified body to attest to your conformity. At this stage, you’re laying the legal and operational foundation for compliance – especially by identifying your CRA category and outlining what level of scrutiny your product will face.
This early classification also shapes how much documentation effort you’ll need to plan for. A product that falls into the default category may only require a lightweight internal documentation approach. But if you’re developing something that is likely to be considered a critical product – for example, a device that handles sensitive data or plays a role in infrastructure – the expectations will be significantly higher. Formal documentation processes, traceable decision-making, and structured risk assessments will all need to be in place from the beginning, because they will be reviewed during the final conformity assessment.
Start documenting early – the final assessment will rely on evidence youâve built throughout the process.
DESIGN
Security as a design constraint
During the design phase, the CRA should be thought of as a design requirement. Both secure-by-design and secure-by-default are fundamental principles embedded in Annex I of the regulation and should be applied from the very beginning.
Secure-by-design means that security is not added as an afterthought – it’s embedded into the architecture and functionality of the product from the outset. Threat modelling, risk analysis, and defensive design choices should influence system structure, interfaces, and component selection.
Secure-by-default ensures that when the product is first activated, it is configured in a way that minimises exposure and risk – without requiring the user to make changes. This includes things like disabling unnecessary services, enforcing strong authentication out of the box, and avoiding insecure default settings.
Itâs also at this stage that you should clarify who is responsible for maintaining documentation – including architecture decisions, threat assessments, and security design justifications – so that responsibility is clear from the start.
Taking security seriously at this point doesnât just reduce risk – it improves the product itself. Security controls that are built into the design are more effective, better integrated, and far less costly than those retrofitted later. This shift-left approach not only reduces the time, complexity, and cost of CRA compliance, but leads to a more robust, maintainable, and trustworthy product overall.
Risk Assessment
Take a first pass at the risk assessment as soon as the concept and initial architecture are established. An ideal way to do this would be to hold a workshop with engineers and security. The functionality and connectivity of the device should be considered at this stage, but also distribution and delivery risks should be considered, such as secure elements, signed firmware, secure on boarding and upgrade procedures, key management schemes, and packaging and supply chain contracts. Once the design is finalised, a second pass can be made. We can already establish the risk register at this point.
SBOM
It is a little early to create the SBOM, but some important things can be put into place. Decide on tooling, pipeline integration, and format. Establish an update process and determine the scope for the SBOM. Does it need to cover firmware, the operating system, third-party libraries and cloud elements? When looking at tooling, select the ones that have the best support for your technology stack, as there are big differences in the coverage.
Technical documentation
Technical documentation under the CRA is more than just paperwork – itâs the formal, structured evidence that your product complies with the regulation. It brings together all the security-relevant artifacts described throughout this guide – such as the SBOM, risk assessment, vulnerability management process, and testing results – into one comprehensive package. This documentation must cover the entire product life cycle and should include:
Documented risk assessment and mitigation plan
Up-to-date SBOM
Defined vulnerability handling processes
Your productâs security architecture and design decisions
Testing and assessment results (e.g., code reviews, scans, penetration tests)
Version history, change logs, and alignment with user documentation
The CRA (Article 23 + Annex II) requires this technical documentation to be maintained and updated throughout the productâs life and kept for ten years after it is withdrawn from the market. Start early. Set up the structure for your technical documentation during the design phase. Decide:
What to include
Who owns each section
What tools and repositories will be used
Choose systems your team will maintain. Treat technical documentation as a continuous, integrated part of development – not a separate compliance silo thatâs only filled in at the end.
User Documentation
Begin outlining your user documentation early. The CRA requires that security-relevant information is clear, accessible, and available at delivery – so plan what youâll need to explain: update instructions, supported life cycle, security features, and contact for vulnerability reporting.
Vulnerability Management
Determine a strategy, process and handling. Design this process so that it hooks into the SBOM and risk assessment. Set up vulnerability reporting mechanisms and a process for evaluating discovered vulnerabilities. Define how often the status will be reviewed, i.e. monthly, quarterly. Design the product with secure and fast patching in mind, and maintainability for the entire support period.
Testing
Formal testing doesnât start here, but design-level reviews matter. Use threat modelling and architecture reviews to validate your security assumptions early. Even lightweight STRIDE analysis or data flow mapping can uncover risks that are easier to fix before implementation.
DEVELOPMENT
Build, test, document as you go
In the development phase, the documentation starts to take a more concrete form. As you approach release, prepare for conformity assessment.
Risk Assessment
As third-party libraries and frameworks are added, the attack surface grows. The risk assessment starts to intersect with engineering work. You can link the previously identified risks to specific security controls that are implemented. Threat modelling and light STRIDE analysis can be built into code reviews.
SBOM
Start to generate the SBOM. If possible, this process should be automated. Regenerate the SBOM every time dependencies change and use versioning. For traceability, an SBOM can be created for each build or release.
Vulnerability Management
Integrate vulnerability scanning into the build pipelines. Run scans on every build or release. Record scanning configurations, triage decisions, and patch timelines in the technical documentation. Make sure to setup a process and the tools to include all triage and patch records between releases. This will prevent frustration and rework. If you donât already have them, this is the time to set up vulnerability disclosure and response processes.
Technical Documentation
Begin populating your technical documentation with real evidence: implemented controls, SBOM versions, risk decisions, and early test results. Keep change logs and link mitigations to risks.
User Documentation
Start drafting user documentation in parallel with feature development. Keep it aligned with actual functionality – especially around configuration, security features, and update processes. Youâll need to finalise this before market placement, so avoid leaving it all until the end.
Testing
Testing during development is where secure-by-design meets real-world implementation. Integrate SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing) tools into your CI/CD pipeline to catch vulnerabilities as early as possible. Use SBOM-based scanners to monitor dependencies for known issues and ensure that every update triggers a fresh scan. Embed security in your code review process – reviewers should check not just for bugs, but for missing access controls, exposed secrets, or poor cryptographic practices. You donât need a full threat modelling session for every change, but applying lightweight STRIDE analysis or data flow reviews during development is a powerful way to catch architectural issues early. The results of all these tests feed into your technical documentation and form the backbone of your eventual conformity assessment.
What about Penetration Testing?
The CRA doesn’t explicitly require penetration testing, and formal guidance is still evolving. However, manufacturers are expected to demonstrate that their products meet the essential security requirements in Annex I – and security testing is how you build that evidence. This might include static and dynamic testing, security audits, and – where appropriate – penetration tests. While not mandatory by name, penetration testing is strongly recommended for Class II or high-risk products. As CRA implementation matures and harmonised standards are adopted, the expectations for security testing will likely become clearer. For now, document your test plans, coverage, and results carefully, and treat testing as a key pillar of your technical documentation and conformity assessment preparation. If you’re looking for structured support, tools like CRACoWi can help guide and streamline the testing process – especially for teams working toward CRA alignment for the first time.
PRE-MARKET & DELIVERY
Lock it down and prep for CE marking
At this stage documentation should be well established, and you should be ready for compliance. Ensure that the product matches the secure design. Any supply chain or manufacturing changes must maintain CRA conformity.
The CE marking is the manufacturerâs declaration that the product complies with all applicable EU legislation – including the CRA, once it applies. It’s a visible sign of conformity that allows the product to be legally placed on the EU market. For CRA-covered products, the CE mark confirms that the essential cybersecurity requirements have been met, either through self-assessment or third-party certification, depending on the product’s classification.
Risk Assessment
Production and distribution processes can differ from what is modelled during design and development, and component substitutions, third-party manufacturing, secure handling procedures, and late design tweaks can also introduce new risks. Verify that the planned mechanisms are in place and check for last-minute changes.
SBOM
Lock down the final version and audit it against the production. SBOM generation tools should remain in place, to monitor components for changes and advisories post-release. The final SBOM should be the basis for vulnerability monitoring. Remember that you need to disclose any open-source libraries used, including licence and version.
Vulnerability Management
Review and document the full vulnerability flow, checking it is aligned with CRA obligations. Test that the security disclosure process works and ensure reporting information is included in the user documentation.
Technical Documentation
Finalise your documentation for conformity. This includes test reports, vulnerability handling workflows, finalised risk assessment, and your internal compliance checklist. Prepare your Declaration of Conformity and link to user docs. If you want a more guided approach, CRACoWi can help streamline this phase – aligning your outputs with CRA expectations and reducing last-minute gaps.
Testing
Wrap up your security testing at this stage. This might include a full SBOM scan, targeted penetration tests, or an external security audit. Document the scope, results, and remediation actions – this evidence feeds directly into your conformity assessment. The CRACoWi wizard support you to understand which tests you may need and complete them directly.
Authorised Rep & Importers
If you are outside the EU, appoint an authorised representative. Ensure importers/distributors meet CRA obligations.
Compliance Assessment & CE Marking
Based on your productâs classification, you’ll either self-assess (Default or Class I) or undergo third-party review (Class II or Critical). This assessment confirms that your product meets the essential requirements in Annex I. The result is a signed EU Declaration of Conformity – and permission to affix the CE marking.
Support/Maintenance
Stay compliant after release
After release, threat-monitoring, incident response, and vulnerability disclosure processes continue throughout the support period. Automatic security updates should be applied where required, and vulnerabilities must be patched promptly.
Under the CRA, timelines are tight: exploited vulnerabilities or actively exploited incidents must be reported within 24 hours to the EU-wide vulnerability database, and within 72 hours to national authorities where required. Ongoing compliance means staying responsive – and being able to prove it through maintained records and coordinated disclosure procedures.
Risk Assessment
This should be periodically updated. Consider changes to the environment and threat landscape, brought about by increased connection and new attack techniques. Use the risk assessment to prioritise vulnerabilities and decide on mitigations. Feed this information through to patching and documentation. Inform users and authorities, when required.
SBOM
Use the SBOM to actively monitor for vulnerabilities. Update the document with every security update, firmware release, or component change.
Vulnerability Management
Continually monitor internal sources for bugs, external sources for CVEs, and SBOM components. Assess each discovered vulnerability, log triage decisions, and patch with minimal delay. Maintain the vulnerability reporting channel.
Technical Documentation
Keep your technical documentation alive during the support period. Every security update, patch, or vulnerability response should be recorded. If you issue new firmware, update the SBOM and testing evidence. CRA compliance includes traceability – so every change should be reflected in the documentation set.
Testing
Repeat security testing after major updates. Keep scanning active during patching.
Decommissioning
CRA doesnât end at EOL
The CRA requires that end-of-life policies are clearly defined. Products should be securely decommissioned, or upgrade paths offered to supported versions. Documentation must be kept for ten years after the last product is placed on the market. Decommissioning isnât the end of compliance – the CRA expects long-term accountability, even after your product is off the market.
Risk Assessment
Identify residual risks at end of life. Inform users and archive the documentation.
SBOM
Finalise and archive the final EOL version. This final version should reflect the actual product state at the end of support. Retain it for traceability and use it to flag any known but unpatched components.
Vulnerability Management
Establish an overview of the residual risk the product carries into post-support life. Release any final patches or mitigations.
Technical Documentation
Archive a complete, final version of all technical documentation – including EOL risk analysis and final SBOM. Ensure it is retained securely for the required ten years.
The CRA isnât just a regulatory burden – itâs an opportunity to build better, more secure products. By treating documentation as a living part of your development workflow, and embedding security from day one, youâre not just checking boxes – youâre reinforcing the integrity of your product. Done right, CRA compliance protects not just your product – but your users, your team, and your reputation. It gives consumers confidence in devices that are secure by default, transparently supported, and built to last. By raising the baseline for digital security, youâre not just checking a box – youâre helping to strengthen the entire ecosystem. CRA compliance isnât just a task list – itâs a mindset. If you build security and documentation in early, the regulation becomes a by-product of good engineering.
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.
