The EU Cyber Resilience Act (CRA) has applied in part since 11 September 2026, when manufacturers became obliged to report actively exploited vulnerabilities and severe incidents within 24 hours. That's the deadline that made the news. The bigger job comes next: from 11 December 2027, every product with digital elements sold in the EU needs a documented cybersecurity risk assessment under Article 13, and that assessment has to say how the product meets each essential requirement in Annex I.
The regulation never uses the words "threat model", but what it asks for is one. This post builds that assessment for a fictional smart thermostat, from scope to a scored register: a data flow diagram, a threat-by-threat walk through Annex I, an attack tree for the worst outcome and a register you can put in the technical documentation.
The short version: Article 13 asks for a written risk assessment based on the product's intended and foreseeable use. It has to state, for each point of Annex I Part I, whether it applies and how you meet it, with a justification wherever a point doesn't apply. It goes in the technical documentation and has to stay current for the whole support period, normally at least five years. A threat model gives you all of that in one place. Draw the device, app, cloud backend and update path, because the cloud counts as part of the product when the product needs it to work. Score the threats and map each treatment to the Annex I point it covers. Then keep the model alive, because the vulnerability handling in Annex I Part II and the reporting duties in Article 14 depend on it. As of 27 October 2026 no harmonised standard is cited yet, so document your method.
Where the CRA stands on 27 October 2026
The CRA is Regulation (EU) 2024/2847. It applies to manufacturers, importers and distributors of products with digital elements: hardware and software, and their remote data processing, placed on the EU market. Some products are excluded because other rules already cover them: medical devices, vehicles, aviation, marine equipment and products made only for defence or national security. That's why our FDA premarket and ISO/SAE 21434 TARA worked examples follow different rules.
| Date | What applies |
|---|---|
| 10 Dec 2024 | Entry into force. |
| 11 Jun 2026 | Rules for conformity assessment bodies (notified bodies). |
| 11 Sep 2026 | Article 14 reporting: an early warning within 24 hours, a notification within 72 hours and a final report later, for actively exploited vulnerabilities and severe incidents. It covers products already on the market, and reports go through ENISA's Single Reporting Platform. |
| 11 Dec 2027 | Everything else, including the Article 13 risk assessment, the Annex I essential requirements, technical documentation and CE marking. |
Two other things matter as of today. The Commission published its guidance on applying the CRA on 27 July 2026. It isn't binding, but it covers scope, remote data processing, support periods and risk assessments, and market surveillance authorities will read the rules through it. Second, no harmonised standard for the CRA has been cited in the Official Journal yet. CEN, CENELEC and ETSI are drafting them, with the first horizontal standards due at the end of October 2026 after a two-month delay. Until one is cited, nothing gives you a presumption of conformity, so your assessment has to explain its own method. Fines for breaching the essential requirements go up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.
What Article 13 actually asks for
Strip out the legal phrasing and Article 13(2) to 13(4) ask for five things:
- An assessment of the product's cybersecurity risks, whose outcome is taken into account during planning, design, development, production, delivery and maintenance.
- Based on intended purpose and reasonably foreseeable use, including the operational environment, the assets to protect and how long the product is expected to be in use.
- A statement for each security requirement in Annex I Part I, point 2: whether it applies and, if so, how it's implemented, plus how you apply point 1 and the vulnerability handling requirements of Part II.
- Documented and updated as appropriate during the support period.
- Included in the technical documentation (Article 31 and Annex VII), with a justification wherever an essential requirement doesn't apply.
Points 1 and 2 describe ordinary threat modeling: what are we building, what can go wrong and what are we doing about it. Point 3 is the part teams underestimate. A list of threats isn't enough: the assessment has to come back to Annex I's thirteen lettered requirements, one by one. Points 4 and 5 mean it's a living document that an authority can ask to see, not a slide from the kickoff meeting.
The example: the Hearthly smart thermostat
Hearthly is a fictional company selling a Wi-Fi thermostat in the EU. The thermostat controls the home's boiler or heat pump. A companion phone app pairs with it over Bluetooth during setup, then controls it through Hearthly's cloud. The cloud stores accounts, schedules and temperature telemetry, and an update server delivers firmware over the air. A small support team can look up a customer's device from an internal console.
Two scope decisions come first, and both belong in the assessment:
- The cloud is part of the product. The CRA covers remote data processing designed by or for the manufacturer when the product can't perform one of its functions without it. Remote control and over-the-air updates don't work without Hearthly's cloud, so the cloud backend is in scope. The general-purpose cloud provider underneath isn't Hearthly's product. Hearthly's own services on top of it are.
- Category. A thermostat with no security functions isn't listed in Annex III or IV, which list important and critical products such as smart door locks, security cameras and alarm systems. So in our reading it's in the default category, and Hearthly can use internal control (self-assessment) for conformity. If it sold the thermostat bundled with a door lock or an alarm, that would change. Write the reasoning down either way.
Step 1: Draw the product, not just the device
A diagram of the device on its own would miss most of the risk. A CRA assessment covers the whole product, so draw everything that ships or runs on its behalf: the firmware, the app, the cloud services the product depends on, the update path and the build pipeline that signs releases. Put a trust boundary around the customer's home, Hearthly's cloud and the build environment. Show the third-party libraries as their own element, because Annex I Part II starts with knowing what's in the product.
The diagram also answers Article 13's "operational environment" question: the device sits on a home network Hearthly doesn't control, next to whatever else is on it, for ten years or more.
Step 2: Walk Annex I, point by point
Find threats the usual way first. Walk each element and flow with STRIDE, or with the checklist you already use. Then turn the result round and read it against Annex I Part I, point 2. Every point needs a line saying whether it applies and how it's met. Where a treatment belongs in the register, the last column gives its ID from Step 4.
| Annex I (2) | Requirement, in short | How Hearthly meets it | Register |
|---|---|---|---|
| (a) | No known exploitable vulnerabilities when placed on the market | Release gate: every build's SBOM is checked against known vulnerabilities, and nothing ships with a known exploitable one open. | C4 |
| (b) | Secure by default configuration, with a reset to the original state | No default password. Pairing needs a button press on the device. Debug interfaces are off in production builds. Factory reset is on the device. | C6 |
| (c) | Vulnerabilities can be fixed through security updates, automatic by default with an opt-out | Over-the-air updates install automatically by default. The user can postpone them, and the app tells them when an update is waiting. | C2 |
| (d) | Protection from unauthorised access | Each thermostat has its own certificate for the broker. Every command checks that the device belongs to the caller's account. Support staff sign in with MFA. | C1, C3 |
| (e) | Confidentiality of stored and transmitted data | TLS on every network flow. Wi-Fi credentials are kept in encrypted storage on the device. | None |
| (f) | Integrity of data, commands, programs and configuration, and reporting of corruption | Secure boot and signed firmware with rollback protection. The device reports a failed signature check to the cloud. | C2, C5 |
| (g) | Data minimisation | Telemetry is room temperature and heating state every five minutes. No location beyond the country set at signup, and no occupancy data. | None |
| (h) | Availability of essential functions, including resilience against denial of service | The thermostat runs its last schedule and a frost-protection minimum when the cloud can't be reached. | C7 |
| (i) | Minimise the negative impact on other devices and networks | No listening services on the LAN. Outbound traffic only to Hearthly's endpoints, with rate limits on the device. | C6, C7 |
| (j) | Limit attack surfaces, including external interfaces | No inbound ports. Bluetooth is on only during pairing. The support console is reachable only through the company's identity provider. | C3, C6 |
| (k) | Reduce the impact of an incident with exploitation mitigation mechanisms | Compiler and memory protections in the firmware. Each cloud service runs with its own least-privilege credentials. | C1, C5 |
| (l) | Record and monitor relevant internal activity, with an opt-out for the user | Sign-ins, commands, firmware changes and support console actions are logged. Users can switch off optional diagnostic logs on the device. | C3 |
| (m) | Users can securely and permanently remove all data and settings, and transfer data securely | Factory reset wipes Wi-Fi credentials, schedules and the account link, and the cloud unbinds the device. Transfer: not applicable. The product has no feature for moving data to other products. Justification recorded. | C8 |
Two rows have no register entry, and that's fine. Point (g) was a design decision, not a threat with a score. Point (e) is met by controls with nothing left to track. The table still has to say so, because Article 13(3) asks about every point, not only the ones with problems. The italic note under (m) is the kind of justification Article 13(4) requires when part of a requirement doesn't apply.
Step 3: An attack tree for the outcome that matters
For a connected heating product, the worst realistic outcome isn't one hacked thermostat. It's someone controlling thousands of them at once: heating switched off across a city in January, or a fleet of devices used to flood someone else's network. That's an Annex I (h) and (i) problem as much as a confidentiality one. Leaves are scored likelihood × impact on a 5×5 risk matrix.
The tree's lesson is the usual one for connected products: the cloud API is the fleet's front door. An IDOR on a device ID needs no hardware skills and reaches every home at once. Firmware threats score high on impact and lower on likelihood, as long as the signing key stays out of reach. The rollback leaf matters because a signature check alone doesn't stop an attacker reinstalling an older, genuinely signed image that has a known flaw.
Step 4: Score it and build the register
Every leaf becomes a row in the risk register, with a treatment, an owner and the Annex I points it covers. The Annex I column is what turns an ordinary register into CRA evidence: an assessor can follow any requirement from the Step 2 table to a row here, and from the row to the design.
| # | Threat | L × I | Treatment | Annex I | Owner |
|---|---|---|---|---|---|
| C1 | Another home's thermostat controlled via its device ID | 4 × 4 = 16 | Mitigate: every command and read checks on the server that the device belongs to the caller's account. Device IDs are random. Tests call every endpoint as a different account. | I(2)(d), (k) | Backend lead |
| C2 | Device accepts an older, vulnerable signed image | 3 × 5 = 15 | Mitigate: the bootloader checks a version counter kept in protected storage as well as the signature, and refuses anything older. | I(2)(c), (f) | Firmware lead |
| C3 | Support login phished, console has no MFA | 3 × 5 = 15 | Mitigate: console behind the company identity provider with phishing-resistant MFA. Staff can view a device but not command it without the customer's consent in the app. Every action logged. | I(2)(d), (j), (l) | Platform |
| C4 | Known flaw in a bundled library, never patched | 3 × 4 = 12 | Mitigate: an SBOM for every release, checked daily against new vulnerabilities, with a fix deadline set by severity and a release gate. | I(2)(a), II(1), II(2) | Firmware lead |
| C5 | Firmware signing key stolen from CI | 2 × 5 = 10 | Mitigate: the key lives in an HSM. Signing is a separate job that needs a second person's approval. Build jobs can request a signature but never read the key. | I(2)(f), (k), II(7) | Platform |
| C6 | Debug service left open on the LAN | 3 × 3 = 9 | Mitigate: debug is compiled out of production builds, and a release test fails if any port is listening. | I(2)(b), (i), (j) | Firmware lead |
| C7 | Cloud outage or attack leaves homes without heating | 2 × 4 = 8 | Mitigate: local schedule and frost protection keep running offline. Accept the remaining risk that remote control is unavailable during an outage. | I(2)(h), (i) | Product lead |
| C8 | A resold thermostat still holds the first owner's data | 3 × 2 = 6 | Mitigate: factory reset wipes the device and tells the cloud to unbind it. The app prompts users to reset before selling. | I(2)(m) | Product lead |
C7 is the honest row. Hearthly accepts that remote control stops during an outage and says why that's acceptable: the essential function, keeping the home heated, doesn't stop. Writing the residual risk down is better than claiming the product never fails, and it's exactly what an authority will want to see under point (h).
Step 5: Keep it alive for the support period
A CRA risk assessment can't be written once at launch and filed. Article 13 wants it updated during the support period. Annex I Part II wants an SBOM, prompt fixes, regular security testing and secure update distribution. And since 11 September 2026, Article 14 gives you 24 hours to send an early warning once you know a vulnerability in your product is being actively exploited. The threat model is what makes those duties manageable:
- Triage. When a CVE lands in a component on your SBOM, the diagram tells you whether that component touches an exposed flow, such as the broker connection or the update path. That's the difference between a fix in the next release and a fix this week. The SBOM says what's in the product, and the model says where it sits.
- Reporting. An early warning in 24 hours is much easier when you already know which products, versions and data flows a component reaches.
- Change. A new interface, a new cloud dependency or a new data type is a reason to re-threat model, and under the CRA it's also a reason to check whether the change counts as a substantial modification.
Keep the model next to the code it describes, version it with each release, and record the date of each review. A dated model with an owner on every row shows "updated as appropriate" better than any policy statement.
What threat modeling can't do here
- It can't make you compliant. It produces the risk assessment. Conformity also needs the rest of the technical documentation, a conformity assessment, the EU declaration of conformity, the CE marking and user information under Annex II.
- It can't settle scope or category for you. Whether your cloud counts as remote data processing, and whether your product is in Annex III, are legal readings. Record the reasoning and check it against the Commission's guidance.
- It can't replace vulnerability handling. You still need the SBOM, a coordinated vulnerability disclosure policy, a contact address, testing and a working route to ENISA's reporting platform.
- It can't anticipate the standards. When harmonised standards are cited, they may expect a particular structure or method. Expect to adjust the assessment's format, not redo the analysis.
A checklist for your CRA risk assessment
- Decide whether the product is in scope, and whether any cloud services count as its remote data processing. Write down why.
- Decide the category (default, important Class I or II, critical) with your reasoning.
- Set the support period and write down the product's expected time in use.
- Draw the device, app, cloud, update path and build pipeline, with trust boundaries and third-party components.
- Find threats across every element and flow, then read them against Annex I Part I, point 2, points (a) to (m).
- For each point, record whether it applies, how it's met and which register rows cover it. Justify anything that doesn't apply.
- Build an attack tree for fleet-wide compromise and score the leaves.
- Give every treatment an owner, and say which risks you've accepted and why.
- Link the model to your SBOM, vulnerability handling and Article 14 reporting process.
- Version the assessment with each release and review it whenever the product changes.
Sources, as of 27 October 2026: Regulation (EU) 2024/2847 (Articles 3, 13, 14 and 64, Annexes I, III and VII), the Commission's Cyber Resilience Act pages, Hunton Andrews Kurth on the 27 July 2026 guidance, McCann FitzGerald on the reporting obligations, and the CRA state-of-play tracker for the standards timeline. This post isn't legal advice. Check scope and category questions with counsel.
Frequently asked questions
Does the Cyber Resilience Act require threat modeling?
Not by name. Article 13 requires manufacturers to assess the cybersecurity risks of their product, document that assessment, use it through design, development and maintenance, and keep it updated during the support period. It must say how each Annex I requirement applies and how it's met. A threat model of the product, with a diagram, scored threats and owned treatments, is a practical way to produce that assessment and keep it current.
Does the Cyber Resilience Act apply to SaaS?
Not to standalone SaaS. The CRA covers products with digital elements: hardware and software placed on the EU market. Remote data processing is in scope only when it's designed by or for the manufacturer and the product can't perform one of its functions without it, such as the cloud backend of a smart device. A SaaS provider is more likely to fall under NIS2.
When does the Cyber Resilience Act apply?
It entered into force on 10 December 2024. The reporting obligations in Article 14 have applied since 11 September 2026, including for products placed on the market before then. The rest, including the Article 13 risk assessment and the Annex I essential requirements, applies from 11 December 2027.
Is there a harmonised standard for the CRA risk assessment?
Not yet. As of 27 October 2026, no CRA harmonised standard has been cited in the Official Journal of the EU, so none gives a presumption of conformity. CEN, CENELEC and ETSI are drafting them under the Commission's standardisation request, with the first horizontal standards due at the end of October 2026. Until one is cited, document your method and show how it covers each point of Annex I.
How often does a CRA risk assessment need updating?
Article 13 says it must be updated as appropriate during the support period, which is normally at least five years. In practice, update it when the product's architecture changes, when you add a feature or interface, when a component in your SBOM has a serious new vulnerability, and after any incident or actively exploited vulnerability you report.