LoRaWAN network security: architecture, challenges, best practices and critical applications

Long Range Wide Area Networks (LoRaWAN) have become a key infrastructure for industrial IoT due to their range, low power consumption, and flexibility. However, one of the main challenges remains cybersecurity . Unlike ad hoc protocols, LoRaWAN is designed with native security, defined by the LoRa Alliance . This article provides an in-depth look at the LoRaWAN security architecture, potential threats, recommended safeguards, and implications for critical applications.

LoRaWAN Security Architecture: Double Logical Shielding

LoRaWAN security is based on a model with two independent cryptographic layers :

• 1. Network Layer Security : validated by the Network Session Key (NwkSKey) , it ensures the authenticity of messages exchanged between the object and the Network Server .
• 2. Application Layer Security : Provided via the Application Session Key (AppSKey) , it guarantees the confidentiality of data exchanged between the object and the application server. Only the owner of the object has access to it.

The protocol uses AES-128 algorithms in CCM* (Counter with CBC-MAC) mode , specified in the LoRaWAN Specification v1.0.4 , ensuring confidentiality, integrity and authentication.

OTAA vs ABP: Security Implications

Activation of a LoRaWAN object can be done in two ways, with direct consequences on security:

• ABP (Activation By Personalization) : Static key hard-coded into the terminal. High risk if captured or cloned.
• OTAA (Over-The-Air Activation) : Secure dynamic negotiation. Generates NwkSKey and AppSKey keys via a cryptographic challenge based on the AppKey.

Industrial or public deployments should ban ABP except in a perfectly isolated environment and prefer OTAA with periodic renewal of keys (rejoin).

⚠️ Risks and potential attack vectors on LoRaWAN

Despite its security mechanisms, a LoRaWAN network can be exposed to several threats:

• Replay attacks : injection of previously captured frames. Prevention: validation of frame counters.
• Impersonation : Malicious device masquerading as a legitimate node. Prevention: Unique AppKey, OTAA strong authentication.
• RF Sniffing : Passive listening to the LoRa channel. Prevention: Active end-to-end encryption (AppSKey).
• Gateway vulnerability : Outdated firmware or open interfaces (SSH, HTTP). Prevention: System hardening.
• Network manipulation : backend attacks (DNS spoofing, SQL injection). Prevention: secure infrastructure (TLS 1.3, partitioning, HIDS).

🛡️ Security Recommendations (LoRa Alliance & ENISA)

• Use a unique AppKey per device , protected in a secure component (TPM, Secure Element).
• Force a periodic rejoin to renew dynamic keys.
• Check FCnt counters for anomalies.
• Host servers in certified environments (ISO 27001, HDS, etc.)
• Tighten gateway configuration and disable unnecessary services.

Focus: industrial gateways with enhanced security

• Integrated firewall (e.g. iptables with IP whitelist).
• Native VPN support (IPsec, WireGuard...)
• SNMP, MQTT, Syslog monitoring for behavioral analysis.
• Partitioned modules with containerization (Docker, LXC).

Critical use cases

• Motorway tunnels: ventilation, CO2, fire alerts.
• Smart BTP: collapse sensors, presence, anti-intrusion.
• Smart buildings: secure LoRa access control.
• Health: Vaccination temperature, silent alarms.

Conclusion

LoRaWAN offers industry-leading security from the outset, but its robustness depends on the implementation. Unique keys, OTA, up-to-date firmware, strict encryption: every layer counts. By following the LoRa Alliance guidelines, industrial IoT projects can benefit from a high-performance , cyber-resilient communications infrastructure.