Defining Trust Boundaries in an IoT Product
Most attacks happen where trust changes hands. A trust boundary is any point where data or control passes between two components that trust each other to different degrees, and those crossings are where validation gets skipped and assumptions get violated. Finding and hardening them is one of the highest-leverage things a connected product can do.
What a Trust Boundary Is
A trust boundary is the line between two parts of a system that operate at different levels of trust. The classic example is the line between your code and input from the network: inside, you trust your own data; outside, anything could arrive. Every place data crosses such a line, a decision has to be made about whether to trust it.
In a connected product these lines are everywhere, and they are where security actually lives. The cryptography, the access control, the input validation all matter precisely at boundaries. A bug deep inside a trusted component is often unreachable; a missing check at a boundary is the front door. Finding the boundaries is therefore the first step to knowing where defenses belong.
Why Boundaries Are Where Attacks Happen
Attackers look for the assumption that does not hold. Inside a trusted zone, code takes shortcuts: it assumes the data is well-formed, the caller is authorized, the value is in range. Those assumptions are reasonable within the zone and dangerous at its edge, because the thing on the other side may not honor them.
A trust boundary is exactly where one component’s assumptions meet another component’s reality. When the firmware assumes the companion app only sends valid commands, and the app is actually an attacker’s script, the boundary between them is where the product breaks. Mapping boundaries is mapping the places where an attacker’s reality collides with your code’s assumptions.
Map the Components First
Before you can find boundaries you need the components. List every part of the product that processes or stores data: the device firmware, the bootloader, any secure element, the radios, the companion mobile app, the cloud backend, and third-party services. Each is a zone that trusts its own internals to some degree.
For a typical connected device the component list spans hardware and software and several owners. The device runs your firmware; the phone runs your app on someone else’s OS; the cloud runs your backend, often on a third party’s infrastructure. Writing them all down, including the ones you do not control, is what makes the next step, drawing the lines between them, possible.
Draw the Data Flows
Connect the components with the actual flows of data and control between them. A command from the app travels over Bluetooth or the cloud to the firmware; telemetry flows the other way; firmware updates flow from the backend to the device. Each arrow is a path data takes, and a trust boundary sits wherever an arrow crosses between zones of different trust.
[ Companion App ] --BLE/cloud--> [ Device Firmware ] --SPI--> [ Secure Element ]
| | ^
| TLS | | local radio (Zigbee/BLE)
v v |
[ Cloud Backend ] <----TLS---- [ other devices / gateway ]
* trust boundaries: App<->Firmware, Firmware<->SE, Firmware<->radio peers,
Device<->Cloud, Cloud<->third-party servicesThe diagram does not need to be elaborate; even this rough sketch makes the crossings obvious. Each labeled boundary is a place to ask the boundary questions: who is on the other side, what do they send, and what happens if they are hostile. The flows turn an abstract architecture into a concrete set of edges to examine.
The Boundary Between Device and Network
The most exposed boundary is between the device and anything on the network, because that is reachable without physical access. Every command, query, and update that arrives over the air or the wire crosses it, and the firmware on the inside must treat all of it as untrusted until validated.
This boundary is where input validation, authentication, and the parser’s robustness are tested. A device that trusts a well-formed-looking packet without authenticating its source, or that parses a length field without bounds-checking it, has a weak boundary here. It is the first place I probe, because it is the first place an attacker can reach.
The Boundary Between Firmware and Secrets
Inside the device there is a boundary between the general firmware and the secrets it relies on, the keys, the secure element, the protected memory. The firmware is more trusted than the network but less trusted than the key store, and that internal line matters because a compromised application should not automatically yield the keys.
A device that stores keys in a secure element the firmware can ask to sign but cannot read has drawn this boundary well. A device that keeps keys in the same readable memory as the application has erased it, so a single firmware bug exposes everything. The strength of this internal boundary often decides how bad a firmware compromise actually is.
The Local Radio Boundary
Local wireless, Bluetooth, Zigbee, Wi-Fi, RF, creates a boundary that teams frequently mis-set, because the LAN or the local radio range feels safe. It is not. Anyone within range, or on the same network, is on the other side of this boundary, and treating local peers as automatically trusted is a recurring and serious mistake.
The right stance is that the local network is not a trust boundary you can lean on. A device that accepts privileged commands from any LAN peer, or pairs with any radio that asks, has placed its trust boundary in the wrong place. Authentication has to happen at the device, not be assumed from network position.
The Cloud and Third-Party Boundaries
The boundary between the device and your cloud backend, and between your backend and third-party services, extends the trust map beyond the device. The device trusts the cloud to send legitimate commands and updates; the cloud trusts the device’s reported identity and data. Each direction of that trust is a boundary an attacker may target.
Third-party services add boundaries you only partly control: an analytics provider, a notification service, a contract manufacturer’s provisioning system. Each one that touches sensitive data or holds a credential is a trust relationship to examine, because a compromise there crosses into your system through a boundary you may not have hardened.
Ask the Boundary Questions
At each boundary, ask a fixed set of questions: who is on the other side, are they authenticated, is the data validated as it crosses, what privilege does crossing grant, and what happens if the other side is hostile or compromised. Answering these for every boundary turns the map into a list of concrete checks.
For boundary [App -> Firmware]: - Authenticated? who proves the app is genuine and authorized? - Validated? is every field bounds-checked before use? - Privilege gained? what can a crossing command actually do? - If hostile? what is the worst a malicious sender achieves?
Working through these questions at each boundary surfaces the weak ones quickly. A boundary with no authentication, or no validation, or one where crossing grants broad privilege, is a finding. The questions are the same everywhere, which makes the analysis systematic rather than dependent on remembering to check each spot.
Validate Everything That Crosses
The core defensive principle is that data crossing into a more-trusted zone must be validated at the crossing, every time, without assuming an earlier component already did it. Length fields bounds-checked, formats verified, values range-checked, and the sender authenticated before the data is acted on.
Defense in depth means re-validating even data that supposedly passed an earlier check, because the earlier check may have been bypassed or may not have covered your case. The cost is a few checks at each boundary; the benefit is that no single skipped validation upstream becomes a compromise downstream. Boundaries are precisely where that redundancy pays off.
Minimize What Crossing Grants
Beyond validation, limit the privilege that crossing a boundary confers. A command that arrives over the network should be able to do only what that channel legitimately needs, not everything the firmware can do. Narrow interfaces at boundaries contain the damage when something hostile gets through.
This is least privilege applied to boundaries. If crossing the network boundary can, at most, change a user-facing setting, a compromise there cannot reflash firmware or read keys. The boundaries that grant the least are the ones an attacker gains the least from crossing, which is why narrowing them is as important as validating them.
Keep the Map Current
Trust boundaries shift as the product evolves. A new feature that opens a port, a new integration with a third party, a moved key, each changes the boundary map, and a boundary that was tight can loosen without anyone noticing. Revisiting the map when the architecture changes is what keeps it accurate.
A boundary map kept current is a living reference for the whole team. Engineers see which side of a boundary their code sits on and what it must validate; reviewers know where to focus; new integrations get evaluated against the existing boundaries before they ship. The map is most valuable when it reflects the product as it is now, not as it was at the first review.
From Boundaries to Defenses
The output of this analysis is a prioritized set of boundaries to harden, which feeds straight into the security requirements and the test plan. Each weak boundary becomes a requirement, authenticate this channel, validate these fields, narrow this interface, and each hardened boundary becomes a test to confirm it holds.
That hand-off is what makes the exercise actionable. The most exposed boundaries, the network and the local radio, usually top the list, and the internal boundary around the secrets usually decides how survivable a compromise is. Hardening them in priority order is among the highest-leverage security work a connected product can do.
Where This Fits
Mapping and hardening trust boundaries is core threat-modeling work and one of the first things I do in a product security assessment. If you want the trust boundaries in your connected product mapped and pressure-tested, that is the kind of work we do at Berkner Tech.