CRA Threat Modeling for Embedded Products
Threat modeling for embedded products under CRA Annex VII: handling physical attacks, JTAG access, and constrained environments with STRIDE.
Annex VII of the Cyber Resilience Act requires manufacturers to include a cybersecurity risk assessment in their technical documentation. In practice, this means you need a threat model — a structured analysis of how your product could be attacked and what you've done about it.
For firmware and embedded product teams, this is unfamiliar territory. Threat modeling has been a standard practice in web application and cloud security for years (OWASP, Microsoft SDL), but embedded teams have historically relied on security-by-obscurity, physical inaccessibility, or simply not thinking about it.
The CRA changes that. You need a documented threat model, it needs to cover the embedded-specific attack surface (physical access, debug interfaces, side channels, supply chain), and it needs to map to your Annex I mitigations. This post shows you how.
What Annex VII Requires
Annex VII, Section 2 requires the technical documentation to include:
- An assessment of the cybersecurity risks against which the product is designed, developed, and manufactured
- How the essential requirements in Annex I are addressed based on that assessment
- The security design and architecture of the product
In regulatory terms: the threat model is the justification for your security design decisions. It answers "why did you implement these specific security controls?" with "because our risk assessment identified these specific threats."
What it doesn't require:
- A specific threat modeling methodology (STRIDE, PASTA, LINDDUN, attack trees — any recognised approach is acceptable)
- A specific format or template
- Third-party validation (for default-category products)
What market surveillance authorities will look for:
- Evidence that the threat model was created before or during development (not retroactively slapped together for compliance)
- Coverage of the product's actual attack surface (not a generic template)
- Traceability from identified threats to implemented mitigations
- Alignment between the threat model and the Annex I requirements you claim to satisfy
Why IT Threat Models Don't Fit Embedded
Standard IT threat models (STRIDE applied to web applications, OWASP Top 10 for APIs) assume a context that doesn't match embedded products:
IT assumes network-only attackers. Embedded products have physical attack surfaces: debug ports, flash memory that can be desoldered and read, RF interfaces that can be intercepted at close range, side-channel emissions.
IT assumes patching is fast. Web applications deploy patches in hours. Firmware updates for devices in the field take days to weeks, and many devices may never update. The threat model needs to account for the window of exposure.
IT assumes abundant resources. Crypto libraries, logging infrastructure, intrusion detection — all of these consume CPU, RAM, and flash that may be severely constrained on an MCU.
IT ignores supply chain hardware attacks. For embedded products, the supply chain includes PCB fabrication, component sourcing, firmware programming during manufacturing — each is an attack surface.
An embedded threat model needs to cover:
- Network attacks (same as IT, but for constrained devices)
- Physical attacks (debug ports, flash readout, hardware tampering)
- Side-channel attacks (power analysis, EM analysis, timing attacks)
- Supply chain attacks (counterfeit components, firmware tampering during manufacturing)
- RF/wireless attacks (BLE spoofing, Wi-Fi deauth, Zigbee interception)
- Firmware-specific attacks (rollback, unsigned updates, bootloader exploits)
STRIDE Adapted for Embedded Systems
STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) is a good starting framework because it's well-documented and widely recognised by conformity assessment bodies. But it needs adaptation for embedded contexts.
Embedded STRIDE Categories
| STRIDE Category | IT Example | Embedded Example |
|---|---|---|
| Spoofing | Forged authentication token | Cloned device identity, spoofed BLE peripheral, rogue OTA server |
| Tampering | Modified HTTP request | Firmware replacement via JTAG, flash chip swap, OTA image manipulation |
| Repudiation | User denies sending a message | Device denies it was in a specific state; no audit logs on constrained device |
| Information Disclosure | SQL injection leaks database | JTAG readout of firmware and keys, side-channel key extraction, unencrypted BLE data |
| Denial of Service | HTTP flood | Network stack crash via malformed packets, radio jamming, flash wear-out |
| Elevation of Privilege | SQL injection to admin | Buffer overflow to code execution, debug port to full device access, MPU bypass |
Step-by-Step Embedded STRIDE Process
Step 1: Define the system boundary
Draw a context diagram showing:
- Your device and its internal components (MCU, flash, sensors, radio)
- External entities that interact with it (cloud services, mobile apps, other devices, users, maintenance technicians)
- Data flows between them (MQTT, BLE, UART, JTAG, OTA updates, sensor data)
- Trust boundaries (what's inside your device vs. what's external and untrusted)
Step 2: Decompose into elements
Break the system into individual components:
- Bootloader
- Application firmware
- Network stack
- Cryptographic module
- Key storage
- Configuration storage
- Debug interfaces
- Physical interfaces (USB, UART, GPIO)
- Wireless interfaces (Wi-Fi, BLE, Zigbee, LoRa)
- OTA update mechanism
- Sensor inputs
Step 3: Apply STRIDE to each element and data flow
For each component and each data flow, ask the six STRIDE questions. Not every category applies to every element, but you need to consider each one.
Step 4: Rate and prioritise
For each identified threat:
- Likelihood: How likely is this attack given your product's deployment context?
- Impact: What happens if this attack succeeds?
- Risk: Likelihood x Impact
Use a simple scale (High/Medium/Low) or CVSS-style scoring. The CRA doesn't mandate a specific risk rating system.
Step 5: Map to mitigations and Annex I requirements
For each threat rated Medium or above, document:
- The mitigation you've implemented
- Which Annex I requirement the mitigation satisfies
- Test evidence that the mitigation works
Worked Example: STM32 Sensor Node
Consider a temperature/humidity sensor node based on an STM32L4 with BLE connectivity, deployed in a commercial building.
System Context
┌──────────────────────────────────┐
│ Cloud Backend │
│ (MQTT broker, device registry) │
└──────────────┬───────────────────┘
│ TLS/MQTT
┌──────────────┴───────────────────┐
│ BLE Gateway │
│ (Raspberry Pi, nRF dongle) │
└──────────────┬───────────────────┘
│ BLE (GATT)
┌──────────────┴───────────────────┐
│ STM32L4 Sensor Node │
│ ┌─────────┐ ┌───────────────┐ │
│ │ Sensors │ │ BLE Radio │ │
│ └─────────┘ └───────────────┘ │
│ ┌─────────┐ ┌───────────────┐ │
│ │ Flash │ │ JTAG/SWD Port │ │
│ └─────────┘ └───────────────┘ │
└──────────────────────────────────┘
Threat Analysis (Selected Threats)
| # | Element | STRIDE | Threat | Likelihood | Impact | Risk |
|---|---|---|---|---|---|---|
| T1 | BLE interface | Spoofing | Attacker impersonates gateway to extract sensor data | Medium | Low | Low |
| T2 | BLE interface | Information Disclosure | Unencrypted BLE advertising leaks sensor readings | High | Low | Medium |
| T3 | JTAG/SWD port | Information Disclosure | Attacker with physical access reads firmware and keys | Medium | High | High |
| T4 | JTAG/SWD port | Tampering | Attacker installs malicious firmware via debug port | Medium | High | High |
| T5 | Flash storage | Information Disclosure | Attacker desolders flash and reads keys | Low | High | Medium |
| T6 | OTA update | Tampering | Man-in-the-middle replaces OTA image | Medium | High | High |
| T7 | OTA update | Tampering | Attacker rolls back to vulnerable firmware version | Medium | High | High |
| T8 | Bootloader | Elevation of Privilege | Attacker exploits bootloader vulnerability to execute arbitrary code | Low | High | Medium |
| T9 | Application | Denial of Service | Malformed BLE packets crash the network stack | Medium | Medium | Medium |
| T10 | Supply chain | Tampering | Counterfeit MCU with modified ROM bootloader | Low | High | Medium |
Mitigation Mapping
| Threat | Mitigation | Annex I Requirement |
|---|---|---|
| T2 — BLE data leakage | BLE LE Secure Connections with encryption enabled | Req 4 (Confidentiality), Req 10 (Secure comms) |
| T3 — JTAG key readout | RDP Level 2 set in production; JTAG permanently disabled | Req 6 (Attack surface) |
| T4 — JTAG firmware install | RDP Level 2; secure boot verifies firmware signature | Req 3 (Integrity), Req 6 (Attack surface) |
| T5 — Flash readout | Encryption keys stored in STM32 OTP, not external flash | Req 4 (Confidentiality) |
| T6 — OTA MITM | OTA images signed with ECDSA P-256; verified by bootloader | Req 3 (Integrity) |
| T7 — Firmware rollback | Anti-rollback counter in protected flash | Req 2 (No known vulns), Req 3 (Integrity) |
| T8 — Bootloader exploit | MCUboot with minimal attack surface, verified boot chain | Req 6 (Attack surface), Req 3 (Integrity) |
| T9 — BLE DoS | Input validation on BLE GATT handlers, watchdog timer | Req 9 (Availability) |
| T10 — Supply chain | Incoming inspection with firmware verification, vendor qualification | Req 1 (Appropriate cybersecurity) |
This mapping is the core deliverable: it connects your identified risks to specific engineering controls and traces those controls to Annex I requirements.
Tools for Embedded Threat Modeling
Microsoft Threat Modeling Tool
Free, GUI-based, uses data flow diagrams with STRIDE analysis. Works well for embedded systems if you create custom element types for MCU components, flash storage, and debug interfaces. The default templates are IT-focused, but custom templates are supported.
OWASP Threat Dragon
Open-source, web-based. Simpler than Microsoft's tool. Good for smaller teams. Supports STRIDE, data flow diagrams, and threat documentation. Can be self-hosted.
Attack Trees
For detailed analysis of specific attack paths (e.g., "how can an attacker extract the firmware signing key?"), attack trees provide a more granular view than STRIDE. Each leaf node is a specific attack step; the tree shows how steps combine.
Pen and Paper / Whiteboard
For small embedded teams, a whiteboard session followed by a structured document is often more practical than a specialised tool. The CRA doesn't require specific tooling — it requires a documented, structured analysis.
Annex VII Deliverable Format
Your threat model document should be part of the Annex VII technical documentation file. A practical structure:
1. System description
- Product overview and intended purpose
- System context diagram
- Component list
- Data flow diagrams
- Trust boundaries
2. Threat identification
- Methodology used (STRIDE, attack trees, etc.)
- Identified threats with description, STRIDE category, and affected component
- Likelihood and impact ratings with rationale
3. Mitigation mapping
- For each threat: mitigation implemented, Annex I requirement satisfied, evidence reference
- Residual risk assessment (risks accepted without full mitigation, with justification)
4. Test evidence references
- Links to test reports that validate mitigations
- Penetration testing results (where applicable)
5. Maintenance plan
- Triggers for threat model update (see below)
- Review schedule
Maintenance Triggers
A threat model isn't a one-time document. It must be maintained. The CRA's "appropriate to the risks" language means your security controls must stay appropriate as the risk landscape changes.
Update your threat model when:
- New hardware revision: Changed interfaces, new components, or modified PCB layout may introduce new attack surfaces
- New firmware feature: Adding a network protocol, cloud connectivity, or new peripheral interface changes the attack surface
- New CVE in a component you use: A newly published vulnerability may change the likelihood or impact ratings in your threat model
- Deployment context change: If your product moves into a new market (e.g., from commercial building to healthcare facility), the threat landscape changes
- Security incident: If your product or a similar product is attacked, the threat model should reflect the learned attack vector
- Annex III reclassification: If Annex III is updated and your product's classification changes, the assessment depth may need to increase
Recommended review cadence: At minimum, review the threat model annually and with every major firmware release. For Class I and Class II products, conformity assessment bodies and notified bodies will expect evidence of ongoing threat model maintenance.
Common Mistakes
1. Using a generic template without product-specific analysis. Market surveillance authorities will recognise a copy-pasted threat model. The threats must be specific to your product's architecture and deployment context.
2. Ignoring physical attacks. For embedded products, physical access is often the highest-impact attack vector. If your threat model doesn't cover JTAG, flash readout, and hardware tampering, it's incomplete.
3. Not mapping threats to Annex I. The threat model's purpose in the CRA context is to justify your Annex I mitigations. Without this mapping, the threat model is a standalone document that doesn't demonstrate compliance.
4. Treating it as a one-time exercise. If your threat model was written two years ago and never updated despite three major firmware releases, it won't hold up to scrutiny.
5. Overly academic scope. You don't need to model nation-state attacks on a temperature sensor. Rate threats against your actual deployment context and attacker profile. Document your assumptions about the attacker (skill level, access, motivation).
Embedded Threat Model Checklist
- System context diagram created with all external entities and data flows
- Component decomposition covers: bootloader, application, network stack, crypto, storage, debug interfaces, wireless interfaces, OTA mechanism
- STRIDE (or equivalent) applied to each component and data flow
- Physical attack surface covered (JTAG/SWD, flash readout, hardware tampering)
- Supply chain threats assessed
- Wireless-specific threats assessed (spoofing, interception, jamming)
- Each threat rated for likelihood and impact
- Each medium/high threat mapped to a specific mitigation
- Each mitigation mapped to an Annex I requirement
- Residual risks documented with acceptance rationale
- Test evidence referenced for each mitigation
- Maintenance triggers and review schedule defined
- Threat model included in Annex VII technical documentation file
The Stack Canary assessment tool includes a threat model gap assessment that identifies which attack categories you need to cover based on your product's architecture and connectivity.
Based on Regulation EU 2024/2847 Annex VII Section 2, Microsoft STRIDE methodology, OWASP Threat Modeling guidelines, and IEC 62443 (industrial cybersecurity risk assessment). This does not constitute legal advice.
Sources
Check your CRA compliance status
Answer 7 questions about your embedded product and get a personalized gap analysis — with your CRA classification, key deadlines, and specific action items.
Start free assessment →