← Back to articlesIoT · LoRaWAN · Part III of III

Why cybersecurity matters in LoRaWAN networks: part III

A practical scenario showing how exposed keys and poor counter management can enable data disclosure or falsification.

9 min readOriginally published: February 2022Recovered: September 2026By jotita3

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.

Normal temperature-monitoring flow through LoRaWAN
Normal flow from the sensor to the application.

If the value exceeds the defined threshold, for example 100 °C, the application alerts the responsible services.

Temperature alert transmitted through LoRaWAN
The application raises an alert when the threshold is exceeded.

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.

Diagram of AppKey protection and LoRaWAN session-key derivation

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.

Sequence of LoRaWAN messages with temperature values and frame counters
Strict counter validation helps detect replays and anomalous states.

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.

Urban devices physically exposed in a public space

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.