IoT Threat Modeling: A Step-by-Step Guide for Hardware Manufacturers

Artem Sulyma — Wed, 15 Jul 2026 12:08:15 +0000

Written by CTO at Platanor Technologies.

Threat modeling is the process of identifying what can go wrong with your device before an attacker does it for you. For IoT and embedded hardware manufacturers, it is the single most cost-effective security activity you can run — because catching a design flaw at the blueprint stage costs a fraction of what it costs to patch devices already shipped to 50,000 customers.

According to SonicWall's 2025 Annual Cyber Threat Report, attacks on IoT devices rose 124% year-over-year in 2024. The IBM Cost of a Data Breach Report 2024 puts the average cost of a breach in the industrial sector at $5.56 million, 13% above the global average and an 18% jump from 2023.

These numbers describe companies that did not do threat modeling early enough. This guide explains how to do it right.

What Is a Threat Model and Why It Matters for Device Manufacturers
A threat model is a structured document that answers four questions: What are you building? What can go wrong? What are you going to do about it? Did you do a good enough job?
The concept comes from software security, but it applies directly to hardware and firmware. Your device has a microcontroller, a communication interface, a firmware update mechanism, and probably a cloud backend. Each of those components has attack surfaces. Threat modeling forces your engineering team to think like an attacker before the product ships.
For manufacturers, the practical outcome of a threat model is a prioritized list of security requirements. Instead of asking "what security features should we add," you start from "what can break and what does it cost if it does."

The CRA Factor: Threat Modeling Is Now a Legal Requirement

If you manufacture connected devices and sell them in the European Union, the EU Cyber Resilience Act makes threat modeling a compliance obligation, not a best practice. CRA Annex I requires manufacturers to conduct and document a cybersecurity risk assessment covering the full product lifecycle. Annex VII specifies that this documentation must be available for market surveillance authorities.
The deadline for full CRA compliance is December 11, 2027. The vulnerability reporting obligation kicks in earlier, on September 11, 2026.
Threat modeling is the foundation of that documentation. Without it, you cannot produce a credible SBOM, you cannot define your vulnerability management process, and you cannot demonstrate that your design decisions were intentional rather than accidental.

Step 1: Define the Scope and Identify Your Assets

Start by drawing a boundary around what you are modeling. The scope of your threat model should match the scope of your CRA risk assessment — the product itself, including its firmware, interfaces, cloud connectivity, and mobile companion app if there is one.
Within that boundary, list your assets. An asset is anything worth protecting. For a connected industrial sensor, the assets typically include:

Device firmware and its integrity. If an attacker can replace your firmware with their own, they own the device.
Cryptographic keys stored on the device. If they are extracted, the entire device fleet is compromised.
Telemetry data the device collects and transmits.
The firmware update channel. A compromised update mechanism can push malicious firmware to every device in your fleet simultaneously.
Provisioning credentials used during manufacturing. If reused across devices, one compromised unit exposes all units.

Step 2: Map Data Flows and Attack Surfaces

Draw a data flow diagram showing how data moves through your system. What matters is that the diagram shows every interface where external input enters the system.
For most IoT devices, the critical attack surfaces are:
Physical interfaces. UART, JTAG, and USB ports left enabled in production firmware are a known and frequently exploited attack path.
Wireless interfaces. Bluetooth, Wi-Fi, Zigbee, and cellular all present network-facing attack surfaces.
Firmware update mechanism. If your OTA update process does not verify the cryptographic signature of incoming firmware, an attacker on the same network can push arbitrary code to your device.
Cloud API. If device authentication relies on a shared secret embedded in firmware, extracting that secret from one device gives access to your entire backend.
Supply chain. A growing share of IoT incidents trace back to third-party suppliers. The manufacturing step — when cryptographic keys are generated and injected into devices — is a significant risk point.

Step 3: Apply STRIDE to Identify Threats

STRIDE maps six threat types to your system components: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.
Spoofing — Can an attacker impersonate your device to your backend, or vice versa?
Tampering — Can an attacker modify firmware, configuration, or data in transit?
Repudiation — Can an attacker perform an action and deny it happened?
Information Disclosure — Can an attacker read sensitive data? Hardcoded credentials in firmware, unencrypted telemetry, or private keys in plaintext flash all appear in real device audits regularly.
Denial of Service — Can an attacker make the device unavailable? This is a safety issue in industrial and medical applications.
Elevation of Privilege — Can an attacker gain capabilities beyond what they should have?
For each threat, write one specific sentence describing the scenario. Vague threats are not actionable.

Step 4: Rate Each Threat by Risk Level

A useful scoring approach is DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability). The point is to end up with a ranked list.
High-priority threats are easy to exploit, affect many devices, and cause significant damage. Low-priority threats require significant attacker resources and have low real-world impact.

Step 5: Define Mitigations for Each High-Priority Threat

Firmware tampering: implement cryptographic signature verification in the bootloader before any application code executes.
Device identity spoofing: provision each device with a unique certificate or key at manufacture time, stored in a hardware security element if possible.
Exposed physical debug interfaces: disable UART and JTAG in production firmware builds.
Insecure OTA updates: enforce signature verification, use TLS, implement rollback protection.

Document the mitigation decision alongside the threat. If you accept a risk rather than mitigate it, document that reasoning — this is what regulators expect to see.

Step 6: Document and Keep It Updated

A threat model is not a one-time document. Update it when your product design changes, when a new CVE affects a component you use, and at least once per year.
This document becomes part of your CRA technical documentation under Annex VII and is the starting point for penetration testing.
Common Mistakes Manufacturers Make

Doing it after the design is finalized. The point is to influence design decisions, not document them after the fact.
Modeling the happy path only. Threat modeling requires thinking about malformed inputs and active attackers.
Treating it as a security team responsibility. It works best when firmware engineers and security professionals work through it together.
Using generic threat lists without adapting to your product.

Frequently Asked Questions

When should we start threat modeling?
At the architecture design phase, before firmware development begins.
Does STRIDE work for hardware as well as software?
Yes. Physical tampering is a STRIDE Tampering threat. Side-channel attacks fall under Information Disclosure.
How long does a threat model take to produce?
For a mid-complexity connected device, an initial workshop takes two to three days. Documentation and review adds another day or two.
Is threat modeling required by the EU Cyber Resilience Act?
CRA Annex I requires a documented cybersecurity risk assessment covering threat scenarios. A formal threat model is the most defensible way to satisfy this requirement.
What tools can we use?
Microsoft Threat Modeling Tool (free, STRIDE-based), OWASP Threat Dragon (open-source), IriusRisk (IoT-specific). A structured spreadsheet works fine at early stages.

DEV Community: Artem Sulyma

IoT Threat Modeling: A Step-by-Step Guide for Hardware Manufacturers