A realistic Smart City scenario
The previous parts introduced LoRaWAN architecture, frames, OTAA and ABP modes and the keys used during a session. With that foundation, we can analyze one of the most relevant threats: impersonation of a legitimate node.
Imagine a network consisting of a temperature sensor installed in a waste container, a gateway deployed in the city, a Network Server and an application that periodically receives the temperature.
The goal is to detect possible fires. When the temperature remains within the expected range, the platform records the value without generating alerts.
If the value exceeds the defined threshold, for example 100 °C, the application alerts the responsible services.
Key exposure and data disclosure
These technologies improve visibility over urban resources, but they also raise important questions: can an attacker decrypt transmitted information or send false measurements?
In OTAA, the device uses an AppKey during the join procedure. If that key has been exposed and an attacker captures the JoinRequest/JoinAccept exchange, they may be able to derive session keys and access protected content. A weak AppKey may also be exposed through systematic guessing attempts.
Node spoofing and the frame counter
Knowing a sensor identity is not enough to impersonate it. An attacker would need the session keys and a valid packet from the original node. They would also need to manage the FCnt field correctly, as this counter is used to reject old or replayed frames.
If the last legitimate packet used counter 123 and the network then accepts a forged frame with value 124, later messages from the original device could be rejected as stale. The malicious node would then control the information observed by the application.

The impact can go beyond reading an isolated value. A forged measurement could conceal a fire, trigger a false alert or alter decisions related to lighting, traffic or waste collection.

Recommended measures
- Maintain an up-to-date inventory of all devices and their owners.
- Monitor which sensors transmit, how often they do so and from which session state.
- Alert when a device stops transmitting or its counter changes abruptly.
- Use unique, random AppKeys and protect them during provisioning.
- Rotate credentials after exposure or physical tampering.
- Periodically inspect nodes installed in streets, lights or containers.
- Correlate critical measurements with other sensors before executing sensitive actions.
Conclusion: a secure LoRaWAN network requires a combination of cryptography, sound key management, device-state control and continuous monitoring.