MITRE EMB3D Embedded Device Threat Model Guide: Threat Modelling Embedded and OT Devices

Product security teams building PLCs, gateways, medical devices and routers have lacked a shared threat model that starts from what the device actually contains. MITRE EMB3D is a public knowledge base of cyber threats to embedded devices, with mitigations, that maps a device's properties (bootloader, debug ports, update mechanism, network services) to the threats that apply to it. Version 2.0.2, released on 1 June 2026, is current at the time of writing, and since version 2.0 the model has been published as a machine-readable STIX dataset. This guide explains how EMB3D is structured, how vendors and asset owners use it, how it relates to ATT&CK, CWE, CVE and IEC 62443, and the mistakes to avoid. It is written for product security engineers, PSIRT teams, OT and IoT security architects and procurement leads. Facts were checked on emb3d.mitre.org on 27 October 2026.

Key takeaways

• Properties drive the model. You describe the device with property IDs (PIDs), and EMB3D returns candidate threats (TIDs) and mitigations (MIDs) for exactly that design.
• Four threat categories cover the stack. Hardware (TID-1xx), System Software (TID-2xx), Application Software (TID-3xx) and Networking (TID-4xx); the four category pages list 81 threats in total.
• Mitigations come in three tiers. Foundational, Intermediate and Leading, so a vendor can set a baseline and a roadmap rather than an all-or-nothing target.
• Evidence makes it defensible. Each threat records its maturity (observed or proof of concept), CVEs and CWEs, and since 2.0 every threat maps to a CWE.
• It is data, not just a website. The STIX files, including IEC 62443 mappings on mitigations, let teams load EMB3D into threat modelling, requirements and procurement tools.

What EMB3D is and how it differs from ATT&CK

MITRE describes EMB3D as aligning with and expanding on ATT&CK, CWE and CVE, with a specific focus on embedded devices. Its threats include those observed in the field and those shown through proofs of concept or theoretical research. It is a living community resource: anyone can propose additions and revisions. Red Balloon Security co-hosted a public webinar on the model with MITRE.

In practice the models complement each other. ATT&CK for ICS tells an asset owner how adversaries have behaved against industrial environments; EMB3D tells the device engineer which design features make that behaviour possible. See the MITRE ATT&CK for ICS Guide and, for general embedded controls, the Embedded Device Security Guide.

The three building blocks: properties, threats, mitigations

Device properties (PIDs)

Properties are grouped as PID-1x Hardware, PID-2x System Software, PID-3x Application Software and PID-4x Networking, with sub-properties beneath them. Examples from the Properties List:

• PID-15: device includes a hardware access port (for example UART, JTAG).
• PID-21: device includes a bootloader; PID-23: device includes an OS or kernel.
• PID-27: device includes support for firmware or software updates.
• PID-28: device stores logs of system events (added in 2.0, with PID-34 for application event logs).
• PID-41: device exposes remote network services; PID-42: device forwards or routes network messages.

Threats (TIDs)

Numbering has gaps (for example TID-402, TID-403 and TID-409 are not listed), so do not infer counts from ranges. Each threat page records its maturity and evidence. TID-211, for instance, lists observed use, citing ATT&CK's account of Sandworm Team overwriting serial-to-Ethernet gateway firmware in the 2015 Ukraine Electric Power Attack (C0028), a proof of concept against an ATM, CWE-306 Missing Authentication for Critical Function and CVE-2015-6492.

Mitigations (MIDs)

Mitigations are numbered MID-001 to MID-089 and sorted into three tiers. Each entry carries references to guidance, limitations and deployment challenges.

The site does not define the tiers in prose, so treat them as MITRE's ordering of maturity and cost, and decide your own required tier per product line.

Version history and the STIX dataset

• 2.0 (22 April 2025): added a STIX 2.1 dataset; new properties PID-28 and PID-34; new threats TID-225 and TID-226 on log manipulation and log leakage; every threat mapped to a CWE; CVE links normalised to cve.org; new mitigations MID-084 to MID-089 covering log restrictions, log export, hardware memory enforcement and formal verification.
• 2.0.1 (29 April 2025): corrected the name of TID-213.
• 2.0.2 (1 June 2026): usability and documentation; the Properties Mapper keeps its state in a shareable URL with a single id parameter (for example ?id=11,12). Threat, property and mitigation content is unchanged.

The Data page offers emb3d-stix-2.0.1.json and emb3d-stix-2.0.json, generated with the OASIS CTI TC's Python stix2 library. Threats are STIX vulnerability objects, mitigations are course-of-action objects and properties are custom x-mitre-emb3d-property objects, joined by relates-to, mitigates and a custom subproperty-of relationship. Threats carry CWE, CVE and evidence fields; mitigations carry references and x_mitre_emb3d_mitigation_IEC_62443_mappings. Evidence is stored as Markdown text rather than STIX external references, so parsers need to handle that. The file names follow the EMB3D version, not the STIX specification version; the site describes the format as STIX 2.1.

How to use EMB3D: a step-by-step workflow

MITRE's Getting Started page sets out three steps. The list below expands them into a programme a product security team can run.

1. Enumerate properties: from design documents, select every applicable PID in the Properties Mapper. Vendors can usually enumerate all properties; asset owners and researchers may need documentation review or initial testing. Save the shareable Mapper URL with the design record.
2. Generate and triage candidate threats: review each TID for relevance and risk using its maturity, evidence, CVEs and CWEs. Record a decision per threat: applicable, not applicable (with reason) or accepted.
3. Select mitigations by tier: for each applicable threat, check whether existing mechanisms meet the Foundational tier, and plan Intermediate or Leading mitigations where the product's risk or lifetime justifies it.
4. Turn mitigations into requirements: write each chosen MID as a testable requirement, and use the IEC 62443 mapping fields to trace it to component requirements. See the IEC 62443-4-1 and 4-2 Secure Product Development Guide.
5. Verify: plan tests per threat: debug port checks for TID-119, update signature and rollback tests for TID-211 and TID-216, credential tests for TID-311 and TID-328.
6. Maintain: rerun the Mapper when hardware or firmware changes, and when EMB3D publishes a new version; diff the STIX files to see what changed.

Pilot first: run the workflow on one product line with an engineering lead and a PSIRT analyst before mandating it; a typical first pass reveals undocumented properties, such as a forgotten UART header, that change the threat list.

Worked example: a serial-to-Ethernet protocol gateway

Consider a small gateway that bridges serial field devices to an Ethernet control network. Its design review selects PID-15 (a UART header left on the board), PID-21 (bootloader), PID-23 (embedded Linux), PID-27 (field firmware updates), PID-41 (a web management interface and a Telnet-style service) and PID-42 (it forwards messages between networks). The threat triage that follows typically keeps:

TID-211 is not hypothetical for this device class: its evidence includes the Sandworm Team firmware overwrite of serial-to-Ethernet gateways in Ukraine in 2015. Each chosen MID becomes a release-gating requirement with a named test.

Using EMB3D as an asset owner and in procurement

MITRE notes that asset owners can use EMB3D output to inform acquisitions, assess the risk of devices already deployed and choose environmental mitigations for residual risk. A practical approach:

• Ask for the property map: request the vendor's EMB3D property selection and threat decisions as part of tender responses.
• Set tier expectations: require Foundational mitigations as pass or fail (for example MID-026 Secure Firmware Update, MID-043 Manage Default Login Credentials, MID-057 Disable Physical Development and Debugging Ports), and score Intermediate and Leading ones.
• Compensate for gaps: where a deployed device has TID-210 Device Vulnerabilities Unpatchable or TID-406 exposure, apply segmentation and allowlisting. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
• Link to regulation: EMB3D evidence supports the security-by-design and vulnerability handling documentation that product laws increasingly expect. See the EU Cyber Resilience Act Guide and the Product Security Laws Map.

Small vendors can use the web Mapper and a spreadsheet of decisions. Large vendors and operators should load the STIX dataset into their threat modelling or requirements tool so decisions are versioned and reportable across product lines.

Where identity fits

A large share of EMB3D's application software threats are about device credentials and keys: TID-311 Default Credentials, TID-312 Credential Change Mechanism Can Be Abused, TID-314 brute-force guessing, TID-317 Predictable Cryptographic Key, TID-328 Hardcoded Credentials and TID-329 Improper Password Storage, with TID-214 covering secrets extracted from the device root of trust. These are non-human identity problems: unique per-device credentials, protected key storage and certificate-based device identity are the durable fixes. See the IoT Device Identity with TPM and DICE Guide and the Device and IoT Identity Guide.

Detection and measurement

EMB3D is a design-time model, but two of its 2.0 additions, TID-225 (logs can be manipulated) and TID-226 (device leaks security information in logs), with mitigations MID-084 and MID-085, push vendors to make devices observable. Asset owners should check that devices can export security logs off the device to a collector, and monitor for firmware changes, new administrative sessions and configuration changes.

• Coverage: percentage of in-scope products with a current EMB3D property map and threat decision record.
• Foundational compliance: percentage of applicable threats on each product with at least one Foundational mitigation in place.
• Verification: percentage of applicable threats with a passing test in the last release cycle.
• Procurement uptake: share of new device tenders that required and scored EMB3D evidence.
• Freshness: days since the last re-map after an EMB3D release or hardware revision.

Framework mapping

Common failure patterns

• Mapping from the datasheet: marketing documents omit debug headers, diagnostic services and undocumented protocol features (TID-401); map from schematics and firmware analysis.
• Treating candidate threats as findings: the Mapper lists threats a device may be exposed to; without a relevance decision per threat the output is noise.
• Stopping at the threat list: the value comes from turning MIDs into requirements and tests, not from the diagram.
• Stale cross-references: EMB3D evidence cites ATT&CK entries that can change. TID-211 cites the ICS System Firmware technique under an older ID that ATT&CK v20 has revoked in favour of T1693.001; check IDs against the current release before reusing them.
• Ignoring credentials on the device: weakly protected stored passwords are a recurring path in real intrusions; in the Salt Typhoon telecom intrusions, stolen device configurations contained SNMP community strings and weakly protected local passwords, the pattern behind TID-329 Improper Password Storage.
• No end-of-life plan: TID-210 and MID-025 End-of-Life Management Features exist because devices outlive their support; plan decommissioning and secure wipe at design time.

Practitioner checklist

• Map each product line's properties in the Properties Mapper and store the shareable URL.
• Record an applicability decision for every candidate threat.
• Meet the Foundational tier for all applicable threats before release.
• Convert chosen mitigations into testable requirements traced to IEC 62443.
• Add EMB3D-driven tests for debug ports, update signing, rollback and credentials.
• Load the STIX dataset into your threat modelling or requirements tooling.
• Require EMB3D evidence in device procurement and score tiers.
• Ensure devices can export security logs off the device.
• Re-map after each EMB3D release and each hardware or firmware revision.

Standards and references

• MITRE: EMB3D Threat Model
• MITRE EMB3D: Getting Started
• MITRE EMB3D: Version History
• MITRE EMB3D: Data (STIX)
• MITRE EMB3D: Device Properties List
• MITRE EMB3D: TID-211 Device Allows Unauthenticated Firmware Installation
• MITRE ATT&CK for ICS: System Firmware (T1693.001)
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Embedded Device Security Guide · Firmware and Boot Security Guide · Threat Modelling Guide · IoT Security Guide · MITRE ATT&CK for ICS Guide