Note 14
Threat models for things that radiate.
STRIDE is not the problem. Diagrams that omit the collision domain are the problem.
Teams that build radios often treat threat modeling as a web exercise that was later photocopied onto a hardware program. Spoofing becomes “TLS.” Tampering becomes “signed firmware.” Information disclosure becomes “we encrypt the payload.” Those controls can be real and still leave the product undefended at the moment it announces itself to a room.
Put spectrum on the data-flow diagram
A radiating product has at least one extra data store: the air. Beacons, probe responses, advertising packets, and paging records are writes to that store. Anyone in range is a reader. Some of them are writers. If that node is missing from the diagram, STRIDE will produce a tidy list about the API gateway and silence about the thing customers actually carry.
Translate the mnemonics
Spoofing includes forged beacons and cloned accessories. Tampering includes OTA trains and debug interfaces that never left production. Repudiation includes devices that cannot tell which peer they just took an order from. Information disclosure includes identifiers that persist across MAC randomization. Denial of service includes the spectrum itself. Elevation includes “now I am the paired watch.”
LINDDUN translates just as cleanly. Detectability of a device in a building is a privacy threat. Linkability of a “random” advertiser across days is another. The practice does not need a new religion. It needs the old questions asked of the real system.
If the adversary can sit in the collision domain, they are already inside one of your trust boundaries.
How NIIS 9 uses this
Modeling workshops for radio products start with emitters, not with user stories. User stories come second, once the diagram can survive contact with a hallway. The test charter is generated from that diagram so that laboratory time is spent on hypotheses worth falsifying.