Threat modeling for the CRA
Threat modeling and threat analysis: a CRA risk assessment for every product
With your developers we build the threat model for each product from source code, deployment configuration and documentation, and turn it into the documented risk assessment for the technical documentation. The model lives as code in your repository and runs again on a changed release.
What the CRA requires of the risk assessment
Manufacturers assess the cybersecurity risks of their product and take the outcome into account from planning through to maintenance (Art. 13(2)). It is based on the intended purpose and reasonably foreseeable use, and indicates whether and how the security requirements in Annex I Part I(2) apply to the product and how they are implemented. It is documented and updated as appropriate during the support period (Art. 13(3)).
The assessment goes into the technical documentation (Art. 13(4), Annex VII(3)). Where an essential requirement does not apply, a clear justification belongs there too. Annex I Part I(2) opens with "On the basis of the cybersecurity risk assessment": access control, integrity and attack surface reduction follow from that assessment.
Service modules
We start with one reference product and then carry the model and the process over to the others.
Model and threat analysis
Architecture, data flows and trust boundaries from code, configuration and documentation, kept as a model in the repository; threats enumerated using STRIDE per element.
Link to the SBOM chain
Known vulnerabilities in the components you use feed into the assessment from the software bill of materials. If there is no SBOM chain yet, we build it with you.
SBOM and vulnerability managementMapping to Annex I
For each requirement in Annex I Part I(2): applicable or not, how it is implemented, and a clear justification where it does not apply.
Into the technical documentation
The risk assessment structured for Annex VII(3) and aligned with the rest of the file.
Technical documentationWhat you end up with
A document for the file and a model that keeps running.
01
Risk assessment per product
Documented and structured for the technical documentation under Annex VII(3).
02
Threat model as code
In your repository, versioned with the product and readable by your team.
03
Re-runnable model
A changed release produces an updated list of threats, and your developers check whether the rating changes. That keeps the assessment up to date as Article 13(3) requires.
What an extract of the risk assessment looks like
Schematic, for a connected device with a web interface and a cloud connection: threat on the model, Annex I requirement, justification.
| Element in the model | Threat (STRIDE) | Annex I Part I(2) | Risk | Measure and justification |
|---|---|---|---|---|
| Maintenance access via the web interface | Spoofing: login under someone else's identity | point (d) | high | Per-device authentication, no shared default password, reporting of failed logins |
| Update channel to the device | Tampering: manipulated firmware | points (c) and (f) | high | Signature check before installation, abort on invalid signature |
| Telemetry to the cloud service | Information disclosure: eavesdropping on the network | point (e) | medium | Encrypted transmission; residual risk documented |
Fictitious example for illustration, not a client product. You set the rating and the measures for your product with your developers.
How we work
From source code to an assessment an assessor can follow.
1
Free initial call
Products, architecture, existing security documentation. You then receive a proposal with a clearly defined scope.
2
Access and documents
Read access to code, configuration and architecture documentation of the reference product.
3
Derive the model
Set up the model in the repository, enumerate threats automatically.
4
Rate
Working session with your developers: real threats, risk, measures, justification.
5
Document and roll out
Risk assessment for the technical documentation, then transfer to further products.
What the tooling does and what you decide with us
The threat model sits as a machine-readable model in your repository. Threat enumeration then runs automatically and reproducibly against it, using STRIDE per element and per data flow. Known vulnerabilities in your components come from the SBOM chain where one exists; otherwise we build it with you.
The tooling does not decide which trust boundaries matter in your deployment, which enumerated threats are real where your product runs, how the risk is rated, or the reasoning an assessor reads. We work these out with your developers, and that is what turns a list of threats into a risk assessment.
What we need from you
A contact per product
A named person from development who knows the product.
Read access
To source code, deployment configuration, architecture and existing security documentation.
Developer time
For the working sessions in which threats are rated and justified.
What we do not do
So that expectations are right:
- Penetration tests are not part of our services. The threat model describes possible attacks; it does not carry any out.
- No legal services: we give a technical assessment and flag questions that need a legal decision for review by your legal department or counsel.
- We are neither a notified body nor a certification body and issue no certificates of any kind.
- Your developers implement code changes in your products unless agreed otherwise.
The obligations under the CRA remain with your company. We help you meet them and document the evidence.
Frequently asked questions
Is threat modeling mandatory under the CRA?+
The CRA does not prescribe a particular method. It requires a documented cybersecurity risk assessment for each product (Art. 13(2) to (4)). Threat modeling is an established way to produce that assessment in a structured and traceable form.
How does threat analysis differ from the risk assessment?+
Threat analysis identifies what can be attacked in the product. The CRA risk assessment rates those threats for the intended use and derives how the Annex I requirements are implemented, or why they do not apply.
Do we need our own threat modeling tool?+
No. We bring the method and the tooling; afterwards the model sits as code in your repository and your team can keep using it. No licence purchase is needed on your side.
What happens with a new release?+
The model runs again. Changed components show up via the SBOM chain, architecture changes once they have been reflected in the model. Your developers then check whether the rating changes. That keeps the risk assessment up to date during the support period (Art. 13(3)).
What does threat modeling for a product cost?+
It depends on the architecture, the number of products and the documentation already in place. After a free initial call you receive a proposal with a clearly defined scope.
Further reading
- CRA risk assessment and threat modeling: STRIDE, attack trees, DFD
- Technical documentation under the CRA
- CRA checklist, step 4
- IEC 62443 and the CRA
- CRA consulting: all services
This content provides general technical and organizational information on the Cyber Resilience Act (Regulation (EU) 2024/2847) and does not constitute legal advice (no legal services within the meaning of the German RDG).
Last updated: 2026-10-09
Kontakt aufnehmen
Threat modeling for your products
Tell us which product to start with and outline its architecture. The initial call is free and without obligation.