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.

PRE-DESIGN

Lay the legal and planning groundwork

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
• Evidence of implemented security controls (e.g., secure boot, encryption, access control)
• 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 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
• Exact service versions and CVEs
• Physical ports (UART, SD card, JTAG)
• Cryptographic strength (TLS version, cipher suites)
• 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.