Key takeaways
- A LoRaWAN device can join a network one of two ways, and the choice has real security consequences.
- LoRaWAN's key architecture also changed in a way that matters for who can see what.
- This is the question worth asking before treating a LoRaWAN deployment as "secure" in the generic sense.
- Default to OTAA, not ABP, for any production deployment — reserve ABP for lab/bench testing where you control the full key lifecycle directly.
LoRaWAN secures two specific things — the join procedure that admits a device to a network, and the confidentiality/integrity of network and application traffic once joined, both via AES-128 and a frame-counter replay check — but it does not secure the radio link against jamming, and it deliberately leaves key provisioning and lifecycle management to the device maker rather than the specification. That split matters for anyone building or buying LoRaWAN-based sensors for smart metering, tank-level monitoring, leak detection or asset tracking, because "LoRaWAN has security built in" and "this specific sensor deployment is secure" are different claims, and the gap between them is exactly where device-maker implementation choices live.
What security does LoRaWAN actually build into the protocol?
LoRaWAN, the MAC-layer protocol maintained by the LoRa Alliance on top of Semtech's LoRa radio modulation, authenticates a device to the network during activation and then protects ongoing traffic with symmetric cryptography. Per the LoRa Alliance's own description of the protocol, every LoRaWAN frame carries a Message Integrity Code computed with AES-CMAC, truncated to 4 bytes, so a receiver can detect a tampered frame; application payloads are separately encrypted with AES-128 in counter mode so that only a holder of the correct session key can read the content; and a monotonically increasing frame counter, covered by that same MIC calculation, is checked by the receiver so that a previously-seen frame is rejected as a replay rather than re-processed. None of this is exotic cryptography — AES-128 and CMAC are standard, well-reviewed primitives — but the design decision to put authentication, confidentiality and replay protection into the base specification (rather than treating them as optional extensions, as many legacy industrial fieldbus protocols do) is a genuine security-by-design choice on the LoRa Alliance's part.
OTAA vs. ABP: why one join method is recommended and the other is not
A LoRaWAN device can join a network one of two ways, and the choice has real security consequences.
| OTAA (Over-The-Air Activation) | ABP (Activation By Personalization) | |
|---|---|---|
| How it joins | Device sends a Join-request, Join Server validates the MIC and returns a Join-accept; fresh session keys are derived for that join | No join procedure — device address and session keys are hard-coded at manufacturing/deployment time |
| Session keys | Freshly derived from the device's root key(s) at each join | Fixed for the device's entire operational life unless manually reflashed |
| Changing networks | Possible — device can rejoin a different network's Join Server | Not possible without physically reprovisioning the device |
| LoRa Alliance / community guidance | Recommended, more secure | Discouraged for production use; "less secure" |
| Frame-counter exhaustion risk | Lower — counters reset with each fresh join (and 1.0.4/1.1 mandate 32-bit counters) | Higher — a static session with a legacy 16-bit counter can exhaust well inside typical sensor battery life |
The Things Network's own LoRaWAN documentation states plainly that OTAA is the recommended and more secure activation method and that ABP is less secure, for exactly the reasons in the table: ABP session keys never rotate, and because the keys are static, a compromised ABP device's keys stay compromised for the device's lifetime with no re-join to refresh them. NCC Group's published LoRaWAN research quantified one concrete failure mode of this staticness: a device using a 16-bit frame counter (as allowed under the original 2015 LoRaWAN 1.0 specification) that reports every five minutes would exhaust that counter in roughly 227 days — well short of the multi-year battery life many LoRaWAN sensor vendors advertise for exactly this kind of low-duty-cycle device. Later spec revisions (1.0.4 and 1.1) address this by mandating 32-bit frame counters and explicitly forbidding counter overflow, but a device maker shipping against an older spec version, or choosing ABP for simplicity, can still inherit the weaker behavior.
The 1.0.x vs. 1.1 key model: one root key or two?
LoRaWAN's key architecture also changed in a way that matters for who can see what. In LoRaWAN 1.0.x, a device holds a single 128-bit AES root key, AppKey, and during OTAA both the Network Session Key (NwkSKey, used for frame integrity) and the Application Session Key (AppSKey, used to decrypt application payload) are derived from that one root key. LoRaWAN 1.1, published by the LoRa Alliance on 11 October 2017, splits this into two root keys — NwkKey and AppKey — each still a 128-bit AES key, with network-side session keys (FNwkSIntKey, SNwkSIntKey, NwkSEncKey) derived from NwkKey and only the application session key (AppSKey) derived from AppKey. The practical effect: under the 1.1 model, a network operator's infrastructure can be built so that only a Join Server — not the day-to-day Network Server — ever handles the key material tied to decrypting application payload, giving the application owner a cleaner separation from the network operator than the 1.0.x single-key model provides.
The caveat worth stating plainly: 1.1 adoption in deployed sensor hardware has historically lagged well behind 1.0.x. Independent security research examining the LoRaWAN ecosystem has noted stretches where essentially no commercially listed sensors supported 1.1 at all. A buyer evaluating a LoRaWAN sensor line today should ask the vendor which spec version is actually implemented in firmware rather than assuming the two-key model applies — "LoRaWAN" alone does not specify the version.
What does LoRaWAN's security model not cover?
This is the question worth asking before treating a LoRaWAN deployment as "secure" in the generic sense. Two gaps are consistently documented and worth taking seriously:
Radio-layer denial of service. LoRaWAN's cryptography operates on frames that have already arrived over the air — it has nothing to say about whether those frames arrive at all. Independent research on LoRaWAN jamming describes both broadband jamming and protocol-aware "selective" jamming, where an attacker exploits the fact that the LoRa physical-layer preamble and header are unencrypted to detect an in-progress transmission and jam it before the payload completes, producing effective denial of service that AES-128 and frame counters cannot prevent because they never get the chance to run. A gateway also generally cannot tell a jammed link apart from ordinary RF congestion, a dead battery, or a sensor moved out of range, which complicates detecting the attack rather than just tolerating the outage.
Key provisioning and lifecycle. The LoRa Alliance's own security materials and the 1.1 specification text are explicit that initializing, storing and managing the lifecycle of root keys (AppKey/NwkKey) is outside the scope of what the LoRaWAN specification itself defines — the spec recommends, without mandating, that root keys live in a secure element or hardware security module on-device. What actually happens in practice varies by manufacturer. NCC Group's published LoRaWAN field research documented real cases of root keys shipped printed inside a device's box or sent by e-mail on request — provisioning practices that make the strength of the underlying AES-128 cryptography beside the point, since an attacker who can read the key off a label or an inbox never needs to attack the cipher at all. Mapping this exposure requires looking at the device's actual firmware and provisioning flow, which is the gap SoftWSP's device firmware security analysis is built to close: unpacking the binary firmware image to build an SBOM and check for exactly this class of issue — hard-coded keys, embedded secrets and credentials left in the image — rather than taking a LoRaWAN security claim at face value.
Checklist for device makers and integrators
Default to OTAA, not ABP, for any production deployment — reserve ABP for lab/bench testing where you control the full key lifecycle directly. Confirm which LoRaWAN spec version your device firmware actually implements(1.0.x single-key vs. 1.1 two-key) before describing a security property of one version as if it applied to a device running the other. Verify frame-counter width and overflow handling in firmware, especially for long-battery-life sensors — a 16-bit counter on a frequently reporting device can exhaust well within the advertised service life. Treat root-key provisioning as a supply-chain security control, not a formality— avoid printing keys on packaging, emailing them, or leaving them recoverable from firmware without a secure element or HSM. Do not assume LoRaWAN compliance covers RF-layer resilience— for leak, tank-level or other alarm-relevant sensors, separately assess what happens operationally when a jammed or out-of-range sensor simply goes silent. Fold the LoRaWAN stack into the device's own SBOM and firmware risk picturerather than treating "runs LoRaWAN" as a security checkbox on its own — the LoRaWAN radio stack is one component among the RTOS, drivers and application code that make up the shipped firmware image, each with its own update and vulnerability history to track.
This guide draws on the LoRa Alliance's own published security materials, The Things Network's LoRaWAN documentation, NCC Group's published LoRaWAN field research, and NIST's public LPWAN work; it has not independently re-verified every clause of the full paywalled or registration-gated LoRaWAN 1.1 specification text, so treat granular key-derivation algorithm steps as general description rather than a drop-in implementation reference. This guide is general information, not a substitute for the LoRa Alliance's own current specification or a specific product's security documentation.
Sources
- LoRa Alliance: LoRaWAN Security (overview, "LoRaWAN Is Secure, but Implementation Matters")
- LoRa Alliance: LoRaWAN Security — a white paper prepared for the LoRa Alliance (PDF)
- The Things Network: End Device Activation (OTAA vs. ABP, key architecture by spec version)
- NCC Group Research: Rise of the Sensors — Securing LoRaWAN Networks
- NIST: A Demonstration of Low Power Wide Area Networking for City-Scale Monitoring Applications
Frequently asked questions
Is LoRaWAN secure enough for industrial sensor deployments like smart metering or tank-level monitoring?
The LoRa Alliance designed LoRaWAN with security built in from the start — mutual authentication at join time, AES-128 encryption of application payloads, and a frame-counter-based replay check on every message — which is a materially stronger starting point than legacy OT fieldbus protocols with no cryptographic design goals at all. But 'the protocol has security features' is not the same claim as 'this deployment is secure.' The LoRa Alliance's own specification explicitly leaves key provisioning, storage and lifecycle management out of scope, and real-world practice varies: NCC Group's LoRaWAN research documented devices shipped with root keys printed inside the box or e-mailed on request, and activation choices (OTAA vs. the weaker ABP mode, covered below) that device makers make unilaterally can undercut the protocol's own protections. Whether a specific deployment is secure depends on implementation choices the spec does not dictate.
What is the difference between OTAA and ABP, and why is ABP discouraged?
Over-The-Air Activation (OTAA) runs a join procedure each time a device joins the network: the device and a Join Server exchange a Join-request/Join-accept pair authenticated with AES-CMAC, and fresh session keys are derived from the device's root key(s) for that session. Activation By Personalization (ABP) skips the join procedure entirely — the device address and session keys are hard-coded into the device at manufacturing time and used unchanged for the device's operational life. The Things Network's own documentation describes OTAA as the recommended, more secure method and ABP as less secure, precisely because ABP session keys never rotate and a device activated by ABP cannot change networks without being physically reflashed. Frame-counter exhaustion is also a sharper problem under ABP: NCC Group calculated that a sensor using a 16-bit frame counter and reporting every five minutes would exhaust its counter in roughly 227 days — well inside the multi-year battery life many LoRaWAN sensor vendors advertise — which is one reason later spec revisions moved to mandatory 32-bit counters.
What changed between LoRaWAN 1.0.x and 1.1's key architecture?
LoRaWAN 1.0.x uses a single root key, AppKey, from which both the Network Session Key (NwkSKey) and Application Session Key (AppSKey) are derived during OTAA — which means the network operator's infrastructure necessarily has access to key material tied to payload confidentiality, not just network-layer integrity. LoRaWAN 1.1, published by the LoRa Alliance on 11 October 2017, splits this into two root keys: NwkKey (network-side) and AppKey (application-side), each a 128-bit AES key. Session keys derived from NwkKey (FNwkSIntKey, SNwkSIntKey, NwkSEncKey) now handle network-layer integrity and header encryption, while only AppSKey — derived from the application-side AppKey — can decrypt application payload, giving the application owner cleaner separation from the network operator. In 1.1 the root keys are also meant to sit with a dedicated Join Server rather than the Network Server. The tradeoff: 1.1 adoption in deployed sensor hardware has historically lagged well behind 1.0.x, so a buyer cannot assume a given commercial sensor implements the 1.1 key split without checking the specific product's declared spec version.
Does LoRaWAN's security model cover jamming or other radio-layer attacks?
No — and this is one of the most consistently documented gaps in independent LoRaWAN security research. LoRaWAN's cryptographic protections (AES-CMAC integrity checks, AES-128 payload encryption, frame-counter replay protection) operate at the network and application layers, on top of whatever radio frame actually arrives. They do nothing to stop an attacker from denying service at the physical layer: multiple independent studies on LoRaWAN jamming describe both broadband and protocol-aware selective jamming (the latter exploiting the fact that the LoRa physical layer preamble and header are not encrypted, letting an attacker detect and jam a transmission before its payload completes) producing effective denial of service that no amount of payload-layer cryptography can prevent. A gateway or network server also cannot reliably distinguish a jammed/degraded RF link from ordinary congestion or a dead battery, which complicates detecting the attack in the first place. Device makers selling into safety- or compliance-relevant uses (leak detection, tank-level alarms) should treat RF-layer denial of service as a residual risk the LoRaWAN spec does not retire, not as something the protocol has already handled.
Who is actually responsible for provisioning and protecting LoRaWAN root keys?
The device maker and network operator, by default — not the specification. The LoRa Alliance's own LoRaWAN security whitepaper and independent analyses of the spec (including the 1.1 text itself) are explicit that key initialization, secure storage and lifecycle management of root keys are out of scope for the LoRaWAN specification; the spec only recommends, without mandating, the use of a secure element or hardware security module to hold root keys on-device. NCC Group's published LoRaWAN research found real provisioning practices falling well short of that recommendation in some deployments, including root keys physically printed inside a device's packaging and keys sent over e-mail on request — practices that make the cryptography described above irrelevant if an attacker never needs to break AES-128 because the key was never protected to begin with.
In this cluster
