LoRaWAN Security Guide: Join, Keys and Network Servers

LoRaWAN's cryptography is sound, but most real-world weaknesses sit in how root keys are generated, provisioned, stored and shared between manufacturers, network servers and join servers. LoRaWAN connects meters, sensors, trackers and actuators for utilities, smart cities, agriculture and buildings over long ranges at low power, often for ten years or more on a single battery. Every device holds 128-bit AES keys, and anyone who obtains a device's root key can impersonate it or read its data for the rest of its life. This guide explains the key hierarchy in LoRaWAN 1.0.x and 1.1, why over-the-air activation (OTAA) beats activation by personalisation (ABP), how to secure the join server, network server, application server and gateways, and how to monitor a fleet. It is for IoT architects, utility and smart city security teams, and operators of private or managed LoRaWAN networks.

Key takeaways

• Root keys are the crown jewels: AppKey (and NwkKey in 1.1) derive every session key. They must be unique per device, generated randomly, and held only on the device and in the join server.
• Use OTAA, not ABP: The Things Stack documentation states that ABP session keys are hardcoded and cannot be rotated if they leak, and that ABP frame counters must never be reset. OTAA renegotiates keys and counters at every join.
• Separate the join server: the LoRa Alliance notes that backend interfaces isolate root key storage in the join server. A separate join server lets the network operator run the network without ever holding root keys or the application session key.
• Frame counters are your replay protection: devices must keep 32-bit counters across power cycles, and networks must not "relax" counter checks to hide device bugs.
• Gateways and servers are ordinary IT: use LoRa Basics Station with TLS rather than the legacy UDP packet forwarder, protect network server APIs and API keys, and patch and monitor them like any internet-facing service.

The LoRaWAN architecture and trust boundaries

A LoRaWAN network has five kinds of component. The Things Stack documentation describes the server roles as follows, and ChirpStack and other network servers use the same split defined by the LoRa Alliance backend interfaces.

The gateway does not hold device keys, which is why a compromised gateway can drop or delay frames but cannot read payloads or forge messages that pass the network's integrity check. The real trust boundaries are the device, the join server and the people and systems that handle root keys between factory and join server.

Keys in LoRaWAN 1.0.x and 1.1

All LoRaWAN keys are 128-bit AES keys. The Things Network documentation explains that in 1.0.x the NwkSKey computes and checks the message integrity code (MIC) with AES-CMAC and the AppSKey encrypts the payload end to end between device and application server, so the network cannot read application data. LoRaWAN 1.1, which the LoRa Alliance describes as adding security enhancements alongside roaming and Class B changes, separates network keys further and adds a second root key.

The Things Stack ABP documentation confirms the session key sets: AppSKey and NwkSKey for 1.0.x, and AppSKey, FNwkSIntKey, SNwkSIntKey and NwkSEncKey for 1.1. In 1.1 and in the 1.0.4 revision, the device's join nonce handling was tightened so that a replayed join request is rejected; check that both device firmware and network server implement the revision you specify, because mixed versions are common.

• Unique keys per device: the LoRa Alliance warns that compromise can follow if keys are not randomised across devices. A fleet that shares one AppKey can be impersonated wholesale after one device is opened.
• Secure elements: the LoRa Alliance notes that secure element hardware adds physical protection against tampering, and The Things Stack documentation points to hardware secure elements that prevent exposure of keys to software, firmware, manufacturing sites and other third parties. For devices deployed in public places (meters, street furniture) they are worth the cost.
• Disable debug interfaces (JTAG, SWD) and read-out of flash in production firmware so keys cannot be dumped from a stolen device.

1.0.x or 1.1: choose 1.1 where both device and network server support it and roaming or separate network operators are likely, because the split network keys and second root key limit what any one server can do. Most installed devices are 1.0.x; for those, insist on the latest 1.0.x revision the vendor supports and on unique keys, which matter more than the version.

OTAA versus ABP

The Things Stack documentation describes ABP as hardcoding the device address and security keys, "which is insecure". If you must run ABP devices, generate unique keys per device, store them only in the network server and application server, keep 32-bit counters in non-volatile memory, and never enable options that reset or ignore frame counters.

Joins and fleet behaviour: The Things Stack best practices note that the specification warns against systematic rejoin after network failure, that devices should persist DevAddr, session keys, frame counters and nonces across power cycles, and that join retries should use jitter and backoff. This is a security point as well as a reliability one: devices that rejoin constantly churn nonces and make anomalous joins harder to spot.

Securing the join server and key handling

The join server holds every root key, so it deserves the protection you would give a certificate authority or a hardware security module.

1. Decide who runs the join server: the network operator, the device manufacturer, a third-party join server or you. ChirpStack documents that when an external join server is used, it does not derive session keys and has no need to configure the AppKey (and NwkKey for 1.1); join requests are routed by JoinEUI.
2. Get keys in without spreadsheets: the common failure is root keys sent from factory to operator as CSV files by email. Use manufacturer-provisioned join servers, device claiming, or encrypted key transfer, and destroy intermediate copies.
3. Authenticate backend connections: use mutual TLS between the network server and the join server. ChirpStack's join server configuration takes a CA certificate, client certificate and key for each join server it calls.
4. Use end-to-end encryption where the network operator is not trusted: ChirpStack's end-to-end encryption mode keeps the network server from ever seeing root keys or the application session key; the join server delivers the AppSKey encrypted under a key encryption key shared with the end application.
5. Protect key storage: encrypt root keys at rest, ideally under an HSM or cloud KMS key, restrict who can export them, and log every export.
6. Plan for compromise: know how you would revoke a device (remove it from the join server so it can no longer join) and how you would rekey if the join server itself were compromised.

Gateways and network servers

• Retire the Semtech UDP packet forwarder: The Things Stack documentation says it has many security and scalability drawbacks and recommends LoRa Basics Station. The UDP protocol carries no authentication of the gateway or the server.
• Use Basics Station with TLS: Basics Station connects to the LoRaWAN Network Server (LNS) for traffic and optionally to the Configuration and Update Server (CUPS) for remote configuration and firmware updates. The Things Stack supports TLS server authentication with a client token (a trust file and a key file) for these connections.
• Treat CUPS as privileged: CUPS can change gateway configuration and firmware, so restrict and audit who can use it.
• Harden gateway hosts: change default passwords, disable unused services such as SSH from the WAN, keep firmware updated and use a private APN or VPN for cellular backhaul.
• Protect server APIs and integrations: network server and application server APIs, MQTT brokers and webhooks expose device data and allow downlinks to actuators. Use scoped API keys, rotate them and keep them in a secrets manager.
• Multi-tenant networks: on a shared or managed network, confirm tenant isolation for devices, gateways and integrations, and who at the operator can see network session keys.

Where identity fits

A LoRaWAN deployment is a machine identity system end to end. Each device has a DevEUI and root keys, each gateway has credentials to the network server, and each integration has an API key or MQTT credential. The API keys used by applications and integrations are often the easiest way into the data: they are long-lived, broadly scoped and copied into scripts. Inventory them, scope them to the applications that need them, rotate them, and remove those belonging to retired integrations. See the Device and IoT Identity Guide and the IoT Security Guide for the wider device identity and lifecycle picture.

Detection and monitoring

• Join anomalies: repeated join requests from one DevEUI, join requests for decommissioned devices, or rejected joins due to nonce reuse.
• Frame counter errors: MIC failures and frames dropped for counter reasons can indicate replay attempts, cloned devices or device bugs. Investigate rather than relaxing counter checks.
• Location and gateway pattern changes: a fixed meter suddenly heard by distant gateways may be cloned.
• Gateway health: unknown gateways registering, gateways going silent across a district, configuration changes through CUPS.
• Server and API activity: new API keys, API key use from new addresses, bulk device exports and root key exports.
• Downlinks to actuators: commands to valves or switches outside expected schedules.

Metrics

• Percentage of devices using OTAA.
• Percentage of devices with unique root keys (target 100) and with a secure element.
• Percentage of gateways on Basics Station with TLS rather than UDP.
• Number of API keys older than the rotation policy or without an owner.
• Number of root key exports from the join server per quarter, each with an approval record.

Implementing a secure LoRaWAN deployment

1. Specify in procurement: LoRaWAN version and revision, OTAA, unique random root keys, secure element where exposure warrants it, disabled debug interfaces, persistent 32-bit counters and a key delivery method that is not plain files.
2. Design the backend: choose join server ownership and whether end-to-end encryption is required, define API key scopes and integration credentials.
3. Pilot: onboard a small batch through the full path, factory to join server to application, and test device removal, rejoin and gateway failover.
4. Roll out by area: deploy gateways on Basics Station with TLS, onboard devices in batches and monitor join and counter errors.
5. Migrate legacy: move ABP devices to OTAA at firmware update or replacement, and UDP gateways to Basics Station.
6. Rollback: keep previous gateway configurations deployable through CUPS or local access, and keep device records so you can restore a join server from encrypted backup.

Small versus large deployments: a campus or farm with a few hundred devices on a managed network mostly needs good procurement, OTAA and API key hygiene. A utility or city with hundreds of thousands of meters needs its own or a contracted join server with HSM-backed key storage, a formal key ceremony with manufacturers and SOC monitoring of joins and counters.

Framework mapping

Common failure patterns

• One AppKey for the whole fleet, often a manufacturer default, so one opened device exposes all of them.
• Root keys in spreadsheets emailed between manufacturer, integrator and operator, then stored indefinitely.
• ABP with counter checks disabled to work around devices that reset counters on reboot, which removes replay protection.
• Legacy UDP gateways on public backhaul with default passwords.
• Over-scoped API keys with rights to all applications and devices, embedded in dashboards and scripts.
• No decommissioning: removed or stolen devices stay registered and can still join.

Practitioner checklist

• Require OTAA with unique, randomly generated root keys for every new device.
• Use secure elements for devices in public or easily accessible locations.
• Keep root keys only on devices and in the join server, encrypted at rest and with logged exports.
• Use mutual TLS between network server and join server; consider end-to-end encryption on third-party networks.
• Move gateways to LoRa Basics Station with TLS and restrict CUPS access.
• Scope, vault and rotate API keys and integration credentials.
• Monitor joins, MIC failures, counter errors and gateway changes.
• Decommission devices in the join server and network server when removed.

Standards and references

• LoRa Alliance: LoRaWAN Specification v1.1
• LoRa Alliance: LoRaWAN is secure, but implementation matters
• The Things Network: LoRaWAN Security
• The Things Stack documentation: ABP vs OTAA
• The Things Stack documentation: LoRa Basics Station
• ChirpStack documentation: End-to-end encryption
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: IoT Security Guide · Device and IoT Identity Guide · Smart Grid Security Guide · Industrial IoT (IIoT) Security Guide