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 show what it costs to discover security flaws after devices have shipped. This guide explains how to catch them at the design stage instead.

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." That distinction changes the conversation with your engineering team entirely.

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. Article 13 requires manufacturers to conduct and document a cybersecurity risk assessment covering the full product lifecycle, addressing the essential requirements of Annex I. That assessment becomes part of the Annex VII technical documentation, which must be kept at the disposal of market surveillance authorities.

The deadline for full CRA compliance is December 11, 2027. The vulnerability reporting obligation kicks in earlier, on September 11, 2026.

This means that if you are reading this in mid-2026, you have about 18 months to get your security documentation in order. Threat modeling is the foundation of that documentation. Without it, you cannot define your vulnerability management process, and you cannot demonstrate that your design decisions were intentional rather than accidental.

Companies that treat threat modeling as a checkbox exercise will produce thin documents that satisfy no one. Companies that do it properly will have a living artifact that actually helps their engineering team make better decisions throughout the product's life.

Step 1: Define the Scope and Identify Your Assets

Start by drawing a boundary around what you are modeling. This sounds obvious but it is where most manufacturers get confused. 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:

The 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. These protect the communication channel and the device identity. If keys are unique per device, extraction compromises only that unit — but if the same key (or a small set of keys) is shared across the fleet, extracting it from a single device compromises every device that shares it.

The telemetry data the device collects and transmits. Depending on the application, this data may be commercially sensitive or personally identifiable.

The firmware update channel. The mechanism you use to push OTA updates is itself an attack surface. A compromised update mechanism can be used to push malicious firmware to every device in your fleet simultaneously.

The provisioning credentials used during manufacturing. If these are reused across devices, one compromised unit exposes every device sharing that credential. If they are unique per device but stored insecurely, an attacker can clone or spoof that individual device — a risk that only becomes fleet-wide if the same insecure process was used to provision every unit.

Write these down. Give each asset a short description and a rough value — how bad is it if this asset is compromised?

Step 2: Map Data Flows and Attack Surfaces

Draw a data flow diagram showing how data moves through your system. It does not need to be elegant. A whiteboard photo is fine at this stage. 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 that are left enabled in production firmware are a known and frequently exploited attack path. An attacker with physical access to a device can dump firmware, extract keys, or inject commands through these interfaces. Many manufacturers enable them for convenience during development and forget to disable them before mass production.

Wireless interfaces. Bluetooth, Wi-Fi, Zigbee, and cellular all present network-facing attack surfaces. Protocol implementation bugs are common. Authentication weaknesses at the pairing or connection stage are common.

Firmware update mechanism. If your OTA update process does not verify the cryptographic signature of incoming firmware, anyone who can reach the update channel — an on-path attacker if the connection is unauthenticated, or anyone who compromises your update server — can push arbitrary code to your device.

Cloud API. The API endpoint your device uses to communicate with your backend is accessible from the internet. If device authentication to this API relies on a shared secret embedded in firmware, extracting that secret from one device lets an attacker impersonate every device in your fleet.

Supply chain. A growing share of IoT incidents in 2025 trace back to third-party suppliers rather than the device manufacturer directly. The manufacturing step — when cryptographic keys are generated and injected into devices — is a significant risk point if your contract manufacturer handles it without proper controls.

Put each of these on your data flow diagram as a trust boundary crossing. Every crossing is a potential threat entry point.

Step 3: Apply STRIDE to Identify Threats

STRIDE is a threat categorization framework developed at Microsoft that maps six threat types to your system components. It stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.

Go through each trust boundary crossing and each asset, and ask what each STRIDE category looks like in that specific context.

Spoofing — Can an attacker impersonate your device to your backend, or impersonate your backend to your device? If your device does not cryptographically authenticate the server it connects to, a man-in-the-middle attack becomes trivial.

Tampering — Can an attacker modify firmware, configuration, or data in transit? An unsigned firmware image can be modified before delivery. Configuration stored in unprotected flash memory can be altered by someone with physical access.

Repudiation — Can an attacker perform an action and deny it happened? If your device logging does not include tamper-evident records, forensic investigation after an incident becomes unreliable.

Information Disclosure — Can an attacker read sensitive data? Hardcoded credentials in firmware, unencrypted telemetry, or private keys in plaintext flash are all information disclosure risks that appear in real device audits with regularity.

Denial of Service — Can an attacker make the device unavailable? This matters more than manufacturers usually expect. A device that stops working under a network flood attack, or that can be crashed by a malformed Bluetooth packet, is a safety issue in industrial and medical applications.

Elevation of Privilege — Can an attacker gain capabilities beyond what they should have? A guest-level API caller accessing device configuration endpoints, or a local firmware vulnerability that escalates from user mode to kernel mode, are examples in this category.

For each threat you identify, write one sentence describing the specific scenario. Vague threats like "an attacker could compromise the firmware" are not useful. "An attacker with access to the firmware update channel can send an unsigned firmware image that the device will accept and execute because the bootloader does not verify the image signature" is a threat you can act on.

Step 4: Rate Each Threat by Risk Level

Not all threats deserve equal attention. Rating each threat by likelihood and impact lets you prioritize the engineering work.

The most common approach today is a simple likelihood × impact matrix: rate each threat on both axes and let the combination set its risk level. This is the same model used in ISO 27005 and IEC 62443 risk assessments, so it maps cleanly onto the documentation CRA auditors expect to see. Any consistent method works — the point is to end up with a ranked list.

High-priority threats are those that are easy to exploit, affect many devices, and cause significant damage if triggered. The firmware signature bypass example above is typically high priority because it is reproducible, well-documented in published CVEs, and affects your entire deployed fleet.

Low-priority threats are those that require significant attacker resources, affect limited functionality, and have low real-world impact. A physical attack requiring specialized lab equipment on a device that stores no sensitive data might fall here.

Be honest about exploitability. "The attacker would need physical access" is a legitimate risk reduction factor for many deployments. For devices shipped to consumer homes or installed in public spaces, it is not.

Step 5: Define Mitigations for Each High-Priority Threat

For each threat above your acceptable risk threshold, define a concrete mitigation. The mitigation should name the specific control and where it sits in your architecture.

Good mitigations for the most common IoT threats look like this:

For firmware tampering: implement cryptographic signature verification in the bootloader. The device should only boot a firmware image signed by a key you hold. The verification should happen before any application code executes.

For device identity spoofing: provision each device with a unique certificate or key at manufacture time, stored in a hardware security element if possible. Mutual TLS between device and backend ensures both sides authenticate each other.

For exposed physical debug interfaces: disable UART and JTAG in production firmware builds. If debug access is needed post-deployment, gate it behind a cryptographic challenge rather than leaving the port open.

For insecure OTA updates: enforce signature verification, use a secure channel (TLS), implement rollback protection so older vulnerable firmware cannot be reinstalled, and maintain a manifest of authorized firmware versions.

Document the mitigation decision alongside the threat. If you decide to accept a risk rather than mitigate it, document that decision and the reasoning. This is what regulators and certification bodies expect to see.

Step 6: Document and Keep It Updated

A threat model is not a one-time document. It should be updated when your product design changes, when a new CVE is published that affects a component you use, and at least once per year as a scheduled review.

The output document should include your scope definition, asset list, data flow diagrams, the complete threat list with STRIDE categorization and risk ratings, mitigation decisions, and a record of who approved the document and when.

This document becomes part of your CRA technical documentation under Annex VII. It is also the starting point for penetration testing — a good tester will work through your threat model to verify that the mitigations you documented actually work in practice.

Common Mistakes Manufacturers Make in Threat Modeling

Doing it after the design is finalized. The point of threat modeling is to influence design decisions. If you run it after the hardware is taped out and the firmware architecture is locked, your options for fixing structural issues are limited and expensive.

Modeling the happy path only. Engineers naturally think about how the system works when everything goes right. Threat modeling requires deliberately thinking about how the system behaves when inputs are malformed, components fail, or an attacker is actively trying to break it.

Treating it as a security team responsibility. Threat modeling works best when product designers, firmware engineers, and security professionals work through it together. Security engineers can identify threats that a firmware developer might miss. Firmware engineers can identify implementation constraints that would make a proposed mitigation unworkable.

Using generic threat lists without adapting to your product. A threat model copied from a generic IoT template and not adapted to your specific device, protocols, and deployment context produces a document that looks complete but misses your actual risks.

Frequently Asked Questions

When should we start threat modeling? At the architecture design phase, before firmware development begins. Ideally, threat modeling runs in parallel with hardware design so security requirements can inform component selection.

Does STRIDE work for hardware as well as software? Yes. STRIDE was designed for software but the threat categories map directly to hardware attack surfaces. Physical tampering is a STRIDE Tampering threat. Side-channel attacks on cryptographic key extraction fall under Information Disclosure.

How long does a threat model take to produce? For a mid-complexity connected device, an initial threat modeling workshop takes two to three days of focused engineering time. The documentation and review cycle adds another day or two. Subsequent updates are faster because you are working from an existing baseline.

Is threat modeling required by the EU Cyber Resilience Act? The CRA (Article 13) requires a documented cybersecurity risk assessment covering threat scenarios. A formal threat model is the most defensible way to satisfy this requirement. Manufacturers without documented threat modeling will struggle to produce the Annex VII technical documentation required for CE marking under the CRA.

What tools can we use? Microsoft Threat Modeling Tool is free and STRIDE-based. OWASP Threat Dragon is an open-source alternative. IriusRisk has purpose-built IoT threat libraries. For many embedded teams, a structured spreadsheet works perfectly well at the early stages.

Start Before It Is Urgent

The manufacturers who handle CRA compliance without major disruption to their roadmap are the ones who started their security documentation work 18 to 24 months before the deadline, not 6. The threat model is the document you build everything else from — your security requirements, your vulnerability management policy, your secure development lifecycle documentation.

If you are building connected devices that will be sold in the EU and you do not yet have a threat model for your product, that is the right place to start.

The Platanor team works with hardware manufacturers at the architecture stage to build threat models, define security requirements, and produce the technical documentation needed for CRA compliance. If you want a second set of eyes on your current design, reach out at info@platanor.com or run our free CRA Readiness Check to see where you stand today.