Beyond Wi-Fi: Digital Twin Threat Modelling

Part 4 of 6: Attack Surface, Wireless Security and Threat Modelling.

A wireless pentest can identify an access point, BLE device, IoT sensor or wireless bridge and still miss part of the picture: what that component connects to, what depends on it and where an attacker can realistically reach it from.

This is where threat modelling fits into the testing pipeline. In the previous stages of this series, OSINT established what an attacker might learn before arriving, while social engineering and proximity assessment considered how close that attacker could realistically get. Threat modelling takes those findings and asks what becomes relevant from that position.

Wireless components may not exist in isolation. They occupy physical locations, communicate with other systems, cross trust boundaries and depend on supporting infrastructure that may not be obvious when each device is considered separately. In this article, we use a digital twin to make those relationships visible and give the threat-modelling stage the context needed to define realistic attack paths and testable hypotheses.

Digital twins can represent anything from an individual component to a wider asset, system or operational process. For this purpose, the twin only needs enough detail to represent the parts of the environment relevant to the attack path.

From component to process

A useful way to think about digital twins is as a hierarchy. At component level, the model might represent an individual Wi-Fi access point, BLE peripheral, IoT sensor or wireless bridge. At asset level, several components form a functional asset, such as a staff handheld, camera unit, ticketing terminal or access-control device. At system level, those assets interact through wireless infrastructure, authentication, monitoring and backend services. At process level, the model shows the operational activity those systems collectively support.

Digital twin hierarchy

Image 1: Four-level digital twin hierarchy showing how wireless technologies sit within the wider assets, systems and operational processes they support.

For a wireless assessment, moving through these levels adds context to the technical target. An access point may look relatively unimportant when viewed as a single component, but the wider model may show that it supports a staff device connected to an operational system. Equally, an apparently interesting wireless device may have little meaningful connectivity or operational significance once its wider role is understood. The aim is not to model everything, but to understand enough of the surrounding environment to identify which technical paths deserve testing.

A fictional UK crossing

The relationship becomes particularly easy to see in environments where public access and operational infrastructure occupy the same physical space. Across the UK, ferry crossings, ports, transport terminals and similar sites can place members of the public within close proximity of systems supporting day-to-day operations.

Consider a deliberately simplified and fictional UK vehicle crossing, using Cornwall as the setting. Vehicles queue, pass through check or payment, cross a controlled-access boundary, enter a managed holding area and eventually board for the crossing. Supporting that process may be operational Wi-Fi, BLE-enabled staff devices, IoT sensors and cameras, wireless bridges, backend services and monitoring, together with shared dependencies such as power, UPS, backhaul and maintenance interfaces.

Digital twin of a fictional UK crossing

Image 2: Digital twin showing how the physical access boundary separates public and controlled areas, while wireless coverage may extend across both.

Where the boundaries actually sit

This is where the earlier proximity work begins to influence the pentest scope. A person sitting in the public vehicle queue has not necessarily bypassed any physical control; they may simply be occupying a location where members of the public are expected to wait. The question is what parts of the wireless environment become reachable from that legitimate position, and what trusted systems sit behind them.

Several boundaries can exist along the same attack path. The physical access boundary marks where public access ends. The RF trust boundary surrounds the radio-facing assets that can potentially be discovered or interacted with over Wi-Fi, BLE or other wireless technologies. Beyond those assets, authentication and access controls create a logical trust boundary before traffic enters the operational network, while backend or monitoring systems may introduce a further trust boundary of their own.

These boundaries do not necessarily align. A barrier may prevent a vehicle from moving beyond the public area, while RF coverage from multiple operational wireless assets could extend across that physical boundary. The wireless path can therefore become relevant before the attacker enters the controlled part of the site.

That matters because an assessment that begins with “assume the tester is already in range” has already removed part of the attack path from consideration. Threat modelling makes that path explicit: where can the attacker realistically position themselves, what becomes reachable from there, where does trust change, and what sits behind those boundaries?

Wireless threat model of the crossing

Image 3: Wireless threat model showing how realistic attacker position, RF and logical trust boundaries, data flows and adversary context shape the attack path before a pentest hypothesis is defined.

The same model can then be interrogated using established threat-modelling techniques. In the example, STRIDE is kept in its standard S–T–R–I–D–E order, with spoofing, tampering, information disclosure and denial of service highlighted as the primary concerns for this particular wireless path. Repudiation and elevation of privilege remain visible but are not treated as the main focus of the scenario.

The Diamond Model provides the wider context. The adversary is an unauthorised actor with legitimate public proximity; the infrastructure includes the public queue and RF-accessible environment; the capability is wireless discovery and interaction; and the victim is the connected operational asset or system. It is the same model applied at a broader wireless/RF level, now brought down to the scale of a single site and attack path — the same model, at a different altitude.

Turning the model into pentest hypotheses

The model does not establish that a vulnerability exists. Its value is in identifying which relationships are important enough to examine technically.

If operational Wi-Fi extends into the public queue, the relevant question is no longer only whether the network is securely configured. The pentest can examine what an unauthorised person can observe or interact with from that realistic location, what is exposed before authentication is established, whether public and operational services are adequately separated, and whether trusted infrastructure or clients can be impersonated.

BLE and IoT introduce a different path. A sensor, camera or short-range peripheral may appear relatively low value at component level, but the system model may show that it communicates through a gateway, management platform or staff device into a more trusted environment. The useful hypothesis then becomes whether interaction with the edge device exposes information, control or a path towards something more significant.

A wireless bridge may look like little more than another radio link when considered in isolation, while the system twin shows that it joins two network segments treated as internal infrastructure. That can make its RF exposure, management interfaces and the trust carried across the link more important than the radio component itself.

The model can also expose relationships just outside a narrowly defined wireless scope. For example, USB is not wireless, but a physically accessible maintenance interface on a wireless-connected asset may still form part of a relevant attack path. This does not automatically bring USB testing or other adjacent interfaces into scope, but it gives the organisation and tester the context to decide whether they should be included.

Availability can be treated in the same way. Wireless links can degrade because of weak signal, obstruction, equipment failure, interference or power loss. Deliberate RF interference or jamming is another possible threat, although any validation would require explicitly authorised and controlled testing. At the threat-modelling stage, the question is whether loss or degradation of that wireless dependency creates a meaningful test hypothesis.

Monitoring is part of the same path. A device experiencing weak RF, a failed component, loss of power or hostile interference may initially look very similar from the operational side: it simply disappears. If monitoring depends on the same wireless path, loss of connectivity may remove both the service and some of the visibility required to understand what happened.

Power and backhaul can reveal similar dependencies. Several wireless components may appear independent while relying on a common UPS, switch, network path or monitoring service. Those dependencies are not separate topics added to make the wireless pentest larger; they matter only where the threat model shows that they change the attack path, the likely impact or the assumptions worth validating.

Example pentest hypothesis sheet

Image 4: Threat-model output mapping realistic attacker positions and reachable paths to testable hypotheses for pentest validation.

DFDs and STRIDE underneath the twin

The digital twin provides the physical and operational context, while conventional threat-modelling techniques provide the structure for examining specific attack paths.

A data flow diagram (DFD) can isolate the communications relevant to a scenario: a staff handheld communicating with an AP and backend service, a BLE device exchanging data with a terminal, an IoT sensor reporting through a gateway, or a wireless bridge linking two network segments. Each flow can then be examined where it crosses a trust boundary.

This is preferable to producing one enormous diagram for the entire estate. Different wireless scenarios have different trust boundaries and failure points, so the useful model is built around the specific path being examined.

The selected STRIDE categories shown in Image 3 can then be applied to those flows, while the Diamond Model keeps the scenario tied to a plausible adversary, infrastructure, capability and victim. Together, they help turn each path into a testable pentest hypothesis rather than a generic checklist.

From threat modelling to the pentest

At the end of the threat-modelling stage, the useful output is not another architecture diagram. It is a short set of prioritised attack paths and hypotheses that the pentest can validate.

That is the role of threat modelling in the pipeline. OSINT establishes what an attacker can learn before arriving. Social engineering and proximity establish where they could realistically position themselves and what access opportunities may exist. Threat modelling then connects that position to reachable wireless components, the assets and systems behind them, and the trust boundaries they cross. From there, the pentest can validate the most relevant hypotheses before the results are considered in terms of wider infrastructure impact.

Five-stage wireless pentest pipeline

Image 5: Five-stage wireless pentest pipeline showing how reconnaissance and realistic proximity are converted through threat modelling into prioritised hypotheses for the pentest to validate.

Why this matters

A technically competent wireless pentest can still begin with incomplete assumptions if the attacker position, trust boundaries and wider system relationships are predefined before testing begins.

The digital twin gives the threat-modelling stage a practical way to connect those pieces. The DFD shows the relevant flows, trust boundaries identify where assumptions change, STRIDE helps interrogate the path, and the Diamond Model keeps the scenario tied to a plausible adversary and victim.

The result is a more specific instruction than simply “test the Wi-Fi.”

Instead, the pentester begins with defined questions about where the attacker can realistically operate, what wireless assets become reachable from that position, what those assets connect to and which of those relationships are important enough to prove or disprove.

Next week, we take those hypotheses into the pentest itself and look at how freely available wireless testing tools can be used to validate what the model predicted.

Want to know whether your wireless assessment is testing the right attack paths?

Speak to IntSpired®

IntSpired® | Offensive Cyber & Wireless Security | UK

We test your defences the way adversaries would, under formal authorisation, to uncover what is actually exploitable.

intspired.co.uk