LoRaWAN Explained: Network Architecture, Join Procedure, Keys and Security

LoRaWAN is the open, LoRa Alliance maintained MAC and network protocol that carries small, infrequent messages from battery powered sensors over kilometres of unlicensed sub-GHz spectrum to a central network server. LoRa is only the radio modulation underneath it. A LoRaWAN deployment is secure when every device joins over the air with its own AES-128 root keys, frame counters never repeat, and the gateway backhaul, network server and join server are each locked down.

This post sits next to our other one protocol per post explainers for connected devices and operational technology: MQTT 5, CoAP, BACnet and Modbus. Here we stay on LoRaWAN: what the radio layer and the MAC layer each do, how a network is built from end devices to application servers, what device classes and regional parameters mean in practice under EU and US rules, how Over-the-Air Activation and Activation by Personalization differ byte by byte, every key in LoRaWAN 1.0.x and 1.1 and what 1.1 fixed, the weaknesses that show up in real deployments, and a step by step lab with the open source ChirpStack network server.

Key takeaways

• LoRa is a chirp spread spectrum radio modulation. LoRaWAN is the MAC layer and network architecture on top of it, specified by the LoRa Alliance in its L2 specification (TS001), its Regional Parameters (RP002) and its Backend Interfaces (TS002).
• A LoRaWAN network is a star of stars. End devices transmit single hop radio frames, any gateway in range forwards them over IP, and a network server deduplicates them, checks integrity and routes them to a join server and application servers. Gateways never hold session keys.
• Every device implements Class A: one uplink followed by two short receive windows. Class B adds beacon synchronised receive slots (the beacon period is 128 seconds), and Class C keeps the receiver open almost all the time.
• Regional Parameters turn radio rules into channel plans. EU868 has three default 125 kHz channels at 868.1, 868.3 and 868.5 MHz with a duty cycle under 1 percent; US915 has 64 uplink channels at 125 kHz, 8 at 500 kHz, no duty cycle limit and a 400 ms dwell time, following FCC Part 15.247.
• Over-the-Air Activation (OTAA) derives fresh session keys at every join from long term root keys. Activation by Personalization (ABP) burns the session keys and device address into the device for life, cannot rekey, and must never reset its frame counters. The 1.1 specification itself recommends OTAA for higher security applications.
• LoRaWAN 1.0.x uses one root key (AppKey) and two session keys. LoRaWAN 1.1 splits the root into NwkKey and AppKey and the network session into three keys (FNwkSIntKey, SNwkSIntKey, NwkSEncKey), encrypts MAC commands carried in FOpts, makes DevNonce and JoinNonce monotonic counters, and splits the downlink counter so the network operator no longer needs the key that decrypts application data.
• The weaknesses that bite are operational: frame counter resets on ABP devices, the same root key across a fleet, root keys stored in the clear, an unencrypted gateway backhaul, and a network server trusted to keep application payloads intact even though it can alter them.
• An open source network server can be stood up in minutes; its lab defaults are exactly what you change before any real device joins.

LoRa vs LoRaWAN: the radio and the protocol

People use the two words interchangeably, and that causes real confusion in security reviews, because the radio and the protocol fail in different ways.

LoRa is a physical layer: a chirp spread spectrum modulation that trades data rate for range and sensitivity. Its main knob is the spreading factor. A higher spreading factor stretches each symbol in time, which makes the signal decodable at lower signal to noise ratios but makes every frame take longer on air. LoRa on its own has no addressing, no encryption, no integrity protection and no idea what a network server is. Two devices can exchange raw LoRa frames point to point with no LoRaWAN involved, and many hobby and industrial links do exactly that.

LoRaWAN is the MAC and network protocol layered on LoRa (and, in some regions, on an FSK alternative). The LoRa Alliance describes it as a low power wide area "end-to-end system architecture designed to wirelessly connect battery operated things to the internet in regional, national or global networks". It defines the frame formats, device addresses, the join procedure, the keys, frame counters, MAC commands for adaptive data rate and channel management, device classes, and how network servers talk to join servers and to each other when roaming. RFC 8376, the IETF's LPWAN overview, summarises the design goals as single battery operation for 10 years or more, extended coverage through a 155 dB maximum coupling loss, and efficient file download for firmware updates.

The split matters because the radio layer carries no security. Anyone in range with a software defined radio can receive every LoRaWAN frame, read the device address, frame counter and port, and transmit frames of their own. Everything that makes LoRaWAN trustworthy lives in the MAC layer cryptography and the servers behind the gateways, and jamming, a radio problem, is outside what the protocol can prevent.

How a LoRaWAN network is built

RFC 8376 describes LoRaWAN networks as "typically organized in a star-of-stars topology in which Gateways relay messages between end devices and a central network server". The roles are worth taking one at a time, because each one holds different secrets and needs different protection.

End devices

An end device (sometimes called a mote) is the sensor or actuator: a water meter, a parking sensor, a soil probe, a pallet tracker, a door contact. It holds its identifiers (DevEUI, an IEEE EUI-64), its root keys if it uses OTAA, or its session keys if it uses ABP, plus its frame counters and nonces. It talks single hop to whatever gateways can hear it. It never talks IP.

Gateways

A gateway (also called a concentrator or base station) is a multi channel radio receiver attached to an IP connection: Ethernet, cellular or Wi-Fi. It demodulates every LoRa frame it hears on its channels, wraps it with metadata (timestamp, frequency, signal strength, signal to noise ratio) and forwards it to the network server. For downlinks it receives a frame and a transmit time from the network server and puts it on air. RFC 8376 is explicit that "Gateways are not expected to be provided with the AppSKey or NwkSKey, all of the infrastructure-side cryptography happens in (or behind) the network server." A gateway is therefore a packet forwarder, not a trust anchor, and an uplink can be heard by several gateways at once.

Gateways reach the network server through one of several backhaul protocols. The ChirpStack architecture page shows three: a UDP packet forwarder talking to a gateway bridge, a WebSocket based protocol known as Basics Station, and an MQTT forwarder connecting straight to an MQTT broker. Which one you pick decides whether the backhaul is encrypted and whether the gateway is authenticated, which we cover below.

Network server

The network server (NS) "terminates the LoRaWAN Medium Access Control (MAC) layer for the end devices connected to the network", in RFC 8376's words. It deduplicates copies of each uplink, verifies the message integrity code (MIC), checks the frame counter, runs adaptive data rate, picks a gateway for each downlink and forwards payloads to the right application server.

In LoRaWAN 1.1 the network role can be split further for roaming. A serving network server holds the MAC state for a device, a forwarding network server is the one whose gateways actually heard the frame, and a home network server is where the device's join server relationship lives. The 1.1 specification splits the uplink MIC in two precisely so that a forwarding network server can verify half of it without holding the serving key.

Join server

The join server (JS) "processes join requests from an end devices" (RFC 8376) and holds the long term root keys. In many 1.0.x deployments it is a function inside the network server. LoRaWAN 1.1 and the Backend Interfaces specification make it a separate role, so root keys can sit in a different system run by a different party, and so the network server receives only network session keys while the application server receives only the application session key.

Application server

The application server (AS) holds the application session key, decrypts and decodes payloads and pushes them to your applications through integrations such as HTTP webhooks or MQTT topics. Many open source stacks ship it in the same binary as the network server.

Frames, ports and payload sizes

Every LoRaWAN data frame carries a MAC header, a frame header (device address, frame control, the low 16 bits of the frame counter, optional MAC commands in FOpts), an optional port (FPort), an encrypted payload and a 4 byte MIC. Port 0 is reserved for MAC commands. Ports 1 to 223 carry application data. RFC 9011, which profiles the IETF's SCHC header compression for LoRaWAN, uses that port byte as the 8 bit SCHC Rule ID, which is how IPv6 and CoAP traffic can ride over LoRaWAN at all.

Payloads are small. RFC 8376 lists EU868 frame sizes from 59 octets at the slowest data rate to 250 octets at the fastest, and US915 frames from 19 to 250 octets. At the 19 octet minimum, 8 octets go to MAC headers and only 11 remain for payload including MAC options. That size budget is why you will not find TLS or DTLS on a LoRaWAN link, and why the security design leans on symmetric keys provisioned in advance.

Device classes, duty cycle and regional parameters

Class A, B and C

The 1.1 specification defines three device classes, and "All LoRaWAN end-devices MUST implement Class A features."

• Class A devices transmit when they want to, in an ALOHA style, and each uplink is followed by two short receive windows. RFC 8376 lists the default delays as 1 second for the first window and 2 seconds for the second, and 5 and 6 seconds for the join accept windows. A server that wants to reach a Class A device has to wait for its next uplink. This is the lowest power mode and the one most battery sensors use.
• Class B devices add scheduled receive slots ("ping slots") synchronised to a beacon broadcast by gateways. The specification sets the beacon period at 128 seconds. Class B suits actuators that need downlinks within a bounded delay without listening all the time.
• Class C devices keep the receiver open nearly continuously, closing it only while they transmit. They draw the most power and give the lowest downlink latency, so they are typically mains powered: street light controllers, valves, meters with a power supply.

Class B and Class C also support multicast: a group of devices sharing a multicast address and keys can receive the same downlink, which is how firmware updates over the air are distributed to many devices at once. Multicast keys are shared by design, so treat a multicast group as one trust unit.

Regional parameters

The radio layer has to follow local spectrum law, and the LoRa Alliance keeps those details out of the core protocol in a separate document. Its developer page explains that the Regional Parameters document "contains the approved frequency channel plans for various global regions, and follows the established regulatory constraints in those regions", covering preamble format, channel frequencies, data rates, transmit power, dwell time and power control. The current revision on the LoRa Alliance resource hub is RP002-1.0.5, published 8 October 2025.

EU868. RP002 says its EU863-870 section "applies to any region where the radio spectrum use is defined by the ETSI [EN300.220-2] standard." Every EU868 device must implement three default 125 kHz channels at 868.10, 868.30 and 868.50 MHz using data rates DR0 to DR5 (0.3 to 5 kbps), with a duty cycle under 1 percent, and must be able to store at least 24 channels. RP002 notes that ETSI allows either a duty cycle limit or listen before talk with adaptive frequency agility, and that "the current LoRaWAN specification exclusively uses duty-cycled limited transmissions to comply with the ETSI regulations." ETSI publishes EN 300 220-2 in its public deliver archive, which lists versions up to V3.3.1; the per band limits that apply to your product are in the edition your conformity assessment uses, so check it rather than relying on a channel plan summary.

US915. In the United States the band is 902 to 928 MHz, governed by FCC Part 15.247. RP002's summary table gives 64 uplink channels at 125 kHz (902.3 to 914.9 MHz in 200 kHz steps) plus 8 uplink channels at 500 kHz (903.0 to 914.2 MHz in 1.6 MHz steps), 8 downlink channels at 500 kHz (923.3 to 927.5 MHz in 600 kHz steps), no duty cycle limit, and a 400 ms dwell time limit. That 400 ms comes straight from the FCC rule: for frequency hopping systems in 902 to 928 MHz with a hopping channel narrower than 250 kHz, the system "shall use at least 50 hopping frequencies and the average time of occupancy on any frequency shall not be greater than 0.4 seconds within a 20 second period." The 500 kHz channels fit a different paragraph of the same rule, which lets digitally modulated systems with a 6 dB bandwidth of at least 500 kHz operate in the band, subject to a power spectral density cap of 8 dBm in any 3 kHz band. Peak conducted output for hopping systems with at least 50 channels is capped at 1 watt.

Because most US915 gateways listen on only 8 or 16 of the 72 uplink channels, a network operator picks a sub-band. The ChirpStack architecture page shows this with an MQTT topic prefix of us915_0, "indicating that this region uses the first 8 channels of the US915 region".

Worked example: what 1 percent duty cycle really allows

Duty cycle is the fraction of time a transmitter may be on air in a given sub-band, measured over an hour. One percent of 3,600 seconds is 36 seconds of airtime per hour.

1. Suppose a sensor at a slow spreading factor needs 1.2 seconds of airtime for each uplink. At 1 percent it must then stay silent on that sub-band for 1.2 / 0.01 minus 1.2, which is 118.8 seconds. The most it can send is 36 / 1.2 = 30 uplinks per hour.
2. The same sensor moved closer to a gateway, where adaptive data rate drops it to a fast spreading factor needing 0.06 seconds per uplink, could send up to 36 / 0.06 = 600 uplinks per hour. The radio rules are the same; the difference is how long each frame occupies the channel.
3. Downlinks count against the gateway's own duty cycle, so a network that confirms every uplink runs out of downlink airtime first. That becomes a security problem when an attacker can trigger many downlinks.

Worked example: US915 dwell time

Under the 400 ms rule, a single US915 uplink on a 125 kHz channel must fit in 400 ms of airtime. That is why US915 uplinks at the slowest data rates carry the smallest payloads, and why RFC 8376 gives a 19 octet minimum frame for US915 against 59 octets for EU868. Longer messages must be split across frames that hop channels, so no channel exceeds 0.4 seconds of average occupancy in any 20 second window.

How Over-the-Air Activation works

OTAA is the join procedure. The device starts with long term secrets and identifiers, proves knowledge of its root key, and receives a device address and the parameters it needs to derive fresh session keys. The LoRaWAN 1.1 text summarises it: "an end-device has to go through a new join procedure every time it has lost the session context information."

What the device holds before it joins

Step 1: Join-request

The device sends a Join-request containing JoinEUI (8 bytes), DevEUI (8 bytes) and DevNonce (2 bytes). With the 1 byte MAC header and the 4 byte MIC that makes the 23 byte frame RFC 8376 mentions. The frame is integrity protected but not encrypted:

Join-request MIC (LoRaWAN 1.1, TS001 section 6.2.2)
cmac = aes128_cmac(NwkKey, MHDR | JoinEUI | DevEUI | DevNonce)
MIC  = cmac[0..3]

Anyone listening can therefore read a device's DevEUI and JoinEUI. Treat both as public identifiers, never as secrets.

In 1.1, "DevNonce is a counter starting at 0 when the device is initially powered up and incremented with every Join-request. A DevNonce value SHALL NEVER be reused for a given JoinEUI value." The network server keeps the last DevNonce for each device and ignores join requests that do not increase it. The specification states the reason in a note: this "prevents replay attacks by sending previously recorded join-request messages with the intention of disconnecting the respective end-device from the network."

Step 2: The network server and join server decide

The gateway forwards the frame, the network server looks up which join server is responsible for that JoinEUI, and the join server checks the MIC with the device's root key and the DevNonce against its record. ChirpStack's docs describe the same split from an implementer's side: if a join request arrives with a JoinEUI configured for an external join server, ChirpStack forwards it there; otherwise it uses root keys stored in ChirpStack, "or raise an error if no keys have been configured." If the request is rejected, the device simply hears nothing.

Step 3: Join-accept

If the device may join, the network sends a Join-accept in the dedicated join receive windows. It carries a 3 byte JoinNonce, a 3 byte Home_NetID, a 4 byte DevAddr, a DLSettings byte, an RxDelay byte and an optional 16 byte CFList with regional channel information. The JoinNonce "is a device specific counter value (that never repeats itself) provided by the Join Server". The device "SHALL accept the Join-accept only if the MIC field is correct and the JoinNonce is strictly greater than the recorded one."

Bit 7 of DLSettings is OptNeg. If the network sets it, the device and network speak 1.1 and derive four session keys from two root keys. If it is clear, the device falls back to 1.0 behaviour with one root key. The join accept is encrypted with an AES decrypt operation in ECB mode, an unusual choice RFC 8376 explains: it means the device only ever needs the AES encrypt primitive, because counter mode payload decryption also uses AES encrypt.

Step 4: Session key derivation

With OptNeg set, the 1.1 specification derives:

LoRaWAN 1.1 session keys (TS001 section 6.2.3)
AppSKey     = aes128_encrypt(AppKey, 0x02 | JoinNonce | JoinEUI | DevNonce | pad16)
FNwkSIntKey = aes128_encrypt(NwkKey, 0x01 | JoinNonce | JoinEUI | DevNonce | pad16)
SNwkSIntKey = aes128_encrypt(NwkKey, 0x03 | JoinNonce | JoinEUI | DevNonce | pad16)
NwkSEncKey  = aes128_encrypt(NwkKey, 0x04 | JoinNonce | JoinEUI | DevNonce | pad16)

With OptNeg clear (a 1.0 network), both session keys come from the single root key and the NetID:

LoRaWAN 1.0 compatible derivation (OptNeg unset)
AppSKey     = aes128_encrypt(NwkKey, 0x02 | JoinNonce | NetID | DevNonce | pad16)
FNwkSIntKey = aes128_encrypt(NwkKey, 0x01 | JoinNonce | NetID | DevNonce | pad16)
SNwkSIntKey = NwkSEncKey = FNwkSIntKey

Two things follow. First, every join produces new session keys, because DevNonce and JoinNonce both change. Second, in the 1.0 derivation whoever holds the single root key can compute both the network and the application session keys, so in a 1.0.x deployment the party running the join function can read application payloads.

Step 5: Confirming the new session

A 1.1 device then sends RekeyInd in its uplinks until it receives RekeyConf. The network keeps both the old and new security contexts until that first uplink with RekeyInd arrives, then discards the old one. If no RekeyConf comes back within ADR_ACK_LIMIT uplinks, the device returns to the join state. Frame counters on both sides reset to 0 at a successful join.

Rejoin

LoRaWAN 1.1 adds Rejoin-request messages so the network can refresh keys or move a device without a full cold join. Type 0 and type 2 rejoins carry a MIC computed with SNwkSIntKey; type 1 uses JSIntKey, a lifetime key derived from NwkKey. The network can ask a device to rejoin immediately with ForceRejoinReq, or periodically with RejoinParamSetupReq, which lets an operator set an upper bound on how long any one session lives.

Worked example: how long does a 16 bit DevNonce last?

DevNonce is 2 bytes, so there are 65,536 values for each JoinEUI over the device's whole life.

1. A well behaved device that joins once at installation and then rejoins once a month uses 12 values a year. It would take over 5,000 years to run out.
2. A device with a firmware bug that loses its session and rejoins every 5 minutes uses 288 values a day. It exhausts the space in 65,536 / 288, which is about 228 days, after which the network will ignore every join request it sends unless the JoinEUI changes.
3. A device that stores DevNonce in RAM instead of non-volatile memory restarts at 0 after every battery change. The specification is blunt: "Resetting DevNonce without changing JoinEUI will cause the Network Server to discard the Join-requests of the device." The fix is persistent storage, not relaxing the server's check.

How Activation by Personalization works, and why it is discouraged

ABP "directly ties an end-device to a specific network by-passing the Join-request - Join-accept procedure," according to the 1.1 specification. The device address and all session keys are written into the device at manufacture or installation, and the network server is configured with the same values. ChirpStack's device docs show the operator side: for an ABP device you enter or generate the device address, network session key and application session key, and for 1.1 devices the network key is replaced by the three network session keys.

ABP is tempting because there is no join to fail and a device can transmit the moment it powers on. The specification lists the costs:

• No rekeying. "ABP devices use the same session keys throughout their lifetime (i.e., no rekeying is possible). Therefore, it is recommended that OTAA devices are used for higher security applications."
• Counters must persist forever. "Re-initialization of an ABP end-device frame counters is forbidden. ABP devices MUST use a non-volatile memory to store the frame counters." Elsewhere: "In ABP devices the frame counters MUST NEVER be reset during the device's life time."
• Keys must be unique and unguessable. "Each device SHALL have a unique set of F/SNwkSIntKey, NwkSEncKey and AppSKey," and the keys "cannot be derived in any way from publicly available information (like the node address or the end-device's devEUI for example)."
• Network lock in. ABP ties a device to one network's address space. Moving it means visiting it.

In 1.1, an ABP device that restarts must send ResetInd in every uplink until the network answers with ResetConf, and must fall back to its original configuration. That helps the network notice a reboot, but it does not make a counter reset safe.

Which keys exist in LoRaWAN 1.0.x and 1.1, and what 1.1 fixed

The LoRaWAN 1.1 specification is dated 11 October 2017. LoRaWAN 1.0.4, published as TS001-1.0.4, remains the 1.0 line that the LoRa Alliance marks as required for certification on its resource hub and is the version RFC 9011 cites. Most devices in the field today run a 1.0.x stack, and ChirpStack's docs list support for 1.0.0 through 1.0.4 and 1.1.0. Here is what each line uses.

The fixes group into five themes.

1. Separation of duties. The 1.1 note on root keys says it plainly: "the application session key is derived only from the AppKey, therefore the NwkKey may be surrendered to the network operator to manage the JOIN procedure without enabling the operator to eavesdrop on the application payload data." In 1.0.x the network operator either runs your join server (and can derive AppSKey) or you run one yourself.
2. Confidential MAC commands. RFC 8376 notes that in 1.0.x "MAC commands piggybacked as frame options (FOpts) are sent in clear" and are "visible to a passive attacker", although the MIC stops them being altered. 1.1 encrypts FOpts with NwkSEncKey, so an eavesdropper no longer learns battery level, link margins or channel changes from MAC traffic.
3. Roaming friendly integrity. The uplink MIC uses two keys "in order to allow a forwarding Network Server in a roaming setup to be able to verify only half of the MIC field." A partner network can filter garbage without holding the key that controls your devices.
4. Monotonic nonces. DevNonce and JoinNonce became counters with persistence requirements, which turns replay of old join requests and old join accepts into a simple comparison on each side.
5. Split downlink counters. Separate network and application downlink counters stop one party's counter state from constraining the other's and support a network server and application server run by different organisations.

LoRaWAN 1.1 is backwards compatible by design: when a 1.1 device joins a 1.0 network, OptNeg is clear and it falls back to one root key and one network session key. That compatibility is also a limit. A 1.1 device on a 1.0 network gets 1.0 security.

The cryptography in one paragraph

All LoRaWAN cryptography is AES-128. Integrity uses AES-CMAC (RFC 4493) truncated to 4 bytes. Payload encryption uses AES in a counter mode derived from IEEE 802.15.4, keyed by the session key and seeded with the device address, direction and frame counter. Key derivation is a single AES encrypt of a padded block. RFC 8376 observes that the design lets a device implement only the AES encrypt primitive. The 4 byte MIC means a random forgery has a 1 in 4,294,967,296 chance of passing, and every attempt costs airtime the attacker must also spend within the same radio rules.

Worked example: frame counters on the wire

Frame counters are 32 bits wide, but only the low 16 bits travel in each frame header. The receiver reconstructs the upper 16 bits.

1. A sensor sending every 10 minutes sends 144 uplinks a day. The 16 bit field on the wire wraps after 65,536 uplinks, which is about 455 days. The network server must notice the wrap and add 65,536 to its internal counter. A stack that compares only the 16 bit field would start rejecting the device after 15 months.
2. The full 32 bit counter has 4,294,967,296 values. At 144 uplinks a day that is roughly 81,700 years, so counter exhaustion is not a real limit; the 1.1 text still requires OTAA devices to establish a new session "well before saturation of a frame counter."
3. Because the counter seeds the encryption keystream, sending two different payloads with the same session key and the same counter value reuses the keystream. Anyone who captures both frames can XOR them and recover the XOR of the two plaintexts. With short, structured sensor payloads that is often enough to recover both readings. The 1.1 text says frame counter values "SHALL only be used once in all invocations of a same key".

Known weaknesses and their mitigations

None of the weaknesses below need exotic cryptanalysis. They come from how devices are built and how networks are run. We describe them conceptually with the fix for each.

Frame counter resets

What happens. An ABP device without non-volatile counter storage loses power, restarts its uplink counter at 0, and starts sending frames with counters the network has already seen. A strict network server drops them all, so the device goes silent. A network server configured to accept counter resets (some stacks offer a relaxed counter option for exactly this kind of broken device) now accepts replays of old frames, and every restarted frame reuses keystream.

Mitigation. Use OTAA so a reboot triggers a rejoin with new keys. If you must keep ABP devices, require persistent counters in the procurement specification, test a battery pull before deployment, and never switch on any relaxed counter checking in production. Alert on devices whose counters go backwards rather than silently accepting them.

Root key reuse and weak key generation

What happens. A manufacturer or integrator programs the same AppKey into a whole batch, or derives keys from the DevEUI with a simple formula, or prints keys on a label inside the enclosure. Extracting the key from one device, or reading one label, compromises the fleet. The 1.1 specification's footnote explains why per device keys matter: extracting keys from one device "only compromises this one end-device" when every device has unique keys.

Mitigation. Generate each root key from a cryptographically secure random source (the lab below uses openssl rand -hex 16), store keys in a secure element on the device where possible, and deliver them to the join server over an authenticated channel, not in a spreadsheet emailed to an installer. The specification itself points at secure elements and hardware security modules for root key storage.

Replay of uplinks, downlinks and joins

What happens. An attacker records frames and transmits them again later. Frame counters stop data replays as long as counters persist and the network server enforces them. In 1.1, monotonic DevNonce stops replayed join requests from forcing a device off the network, and monotonic JoinNonce stops a replayed join accept from rolling a device back to an old session.

Mitigation. Keep counter and nonce checks strict, make sure devices store DevNonce and JoinNonce in non-volatile memory, prefer 1.1 capable devices and servers for new deployments, and for confirmed downlinks that trigger physical actions (unlock, open valve), add an application layer timestamp or sequence number and reject stale commands.

Hop by hop integrity on application data

What happens. The 1.1 specification is candid: application payloads "are end-to-end encrypted between the end-device and the application server, but they are integrity protected only in a hop-by-hop fashion". A malicious network server "may be able to alter the content of the data messages in transit," and could even learn something from how endpoints react to altered data.

Mitigation. If you do not run the network server yourself, treat it as a trusted third party in your threat model. For commands where an altered payload would cause harm, add an application layer MAC with a separate key, which the specification explicitly allows as an additional end to end solution.

Gateway backhaul exposure

What happens. Gateways do not hold session keys, so a compromised gateway or backhaul cannot decrypt payloads. It can still see every device address, frame counter, signal metric and timing, which is enough for traffic analysis and location inference. It can drop or delay frames, and it can impersonate a gateway to the network server if the backhaul is not authenticated. The UDP packet forwarder backhaul, which ChirpStack's docker setup listens for on port 1700, has no transport encryption of its own.

Mitigation. Prefer a backhaul with TLS and per gateway credentials. ChirpStack documents MQTT with TLS where its own certificate authority signs client certificates for each gateway and for application integrations, and a WebSocket based Basics Station backend. If you must use UDP, restrict port 1700 to known gateway addresses or carry it inside a VPN. Treat each gateway as a Linux device with its own firmware, services and update cycle, because that is what it is.

Join server and network server compromise

What happens. The join server holds the root keys for every device it serves. Whoever controls it can derive the session keys of every future join. In a 1.0.x deployment the network server often is the join server.

Mitigation. Separate the join server from the network server where your stack allows it, back root keys with a hardware security module for large fleets, restrict and log access, and rotate the credentials the network server uses to talk to it. The LoRa Alliance Backend Interfaces specification (TS002-1.1.0, published 19 October 2019 on the resource hub) defines the message flows for OTAA and roaming between these roles.

Join floods and synchronised retransmission

What happens. After a power cut or outage, thousands of devices may rejoin at once. The 1.1 specification warns this "can trigger a catastrophic, self-persisting, radio network overload situation" and defines back off rules.

Mitigation. Make sure firmware implements the specified back off, randomise start up delays, and test a fleet wide power cycle in a lab.

Radio jamming

What happens. Jamming is a physical layer attack. LoRaWAN cannot prevent it, only make it visible.

Mitigation. Monitor per gateway noise and per device silence, design devices to fail safe when they lose the network, and do not use LoRaWAN for life safety functions that need guaranteed delivery.

Step by step: run an open source network server, join a device with OTAA, and review security

This lab uses ChirpStack, an open source LoRaWAN network server whose docs describe it as usable "to setup private or public LoRaWAN networks", with a web interface, integrations and a gRPC API. It supports Class A, Class B and Class C devices and the EU868 and US915 regions among others. You need a machine with Docker and Compose, a LoRaWAN gateway you control, and a test device whose keys you can set.

Step 1: Start ChirpStack with Docker Compose

The ChirpStack quickstart uses an example Compose repository:

git clone https://github.com/chirpstack/chirpstack-docker.git
cd chirpstack-docker
docker compose up

The docs note that "by default the EU868 region is configured but this can be changed to any supported region." For a US lab, follow the repository README to switch the gateway bridge and the ChirpStack region configuration to US915 and to the sub-band your gateway uses. Expect some errors on the very first start while the database initialises.

Step 2: Change the default login immediately

The web interface listens on port 8080, and the docs say to log in "with admin / admin". Change that password before you do anything else, and do not expose port 8080 to the internet. Put the interface behind a reverse proxy with TLS if anyone will reach it from outside the host.

Step 3: Connect the gateway

The Compose environment runs a gateway bridge listening for UDP packet forwarder traffic on port 1700 and a Basics Station backend on port 3001. Configure your gateway with the host address and the matching port, then register the gateway in the web interface by its gateway ID. Watch the gateway page until it shows as online.

For anything beyond a bench test, move to an authenticated backhaul. The ChirpStack Mosquitto TLS guide walks through creating a certificate authority, issuing a broker server certificate, and configuring ChirpStack with the CA so it can issue client certificates for gateways and for application integrations from the web interface. The same idea with openssl looks like this:

# Create a private CA for the broker and gateway client certificates
openssl req -x509 -newkey rsa:4096 -sha256 -days 365 -nodes \
  -keyout ca-key.pem -out ca.pem -subj "/CN=LoRaWAN Lab CA"

# Broker server certificate for the hostname gateways will connect to
openssl req -newkey rsa:4096 -nodes -keyout mqtt-server-key.pem \
  -out mqtt-server.csr -subj "/CN=lns.example.internal"
openssl x509 -req -in mqtt-server.csr -CA ca.pem -CAkey ca-key.pem \
  -CAcreateserial -out mqtt-server.pem -days 365 -sha256

Keep ca-key.pem off shared drives. It can mint credentials for every gateway on your network.

Step 4: Create a device profile

A device profile tells the network server what the device can do. ChirpStack's docs list the general settings as name, description, MAC version, region and regional parameters revision, and note that profiles can be imported from a shared repository with make import-device-profiles or created per tenant. Set:

• MAC version to exactly what the device firmware implements (for example LoRaWAN 1.0.4 or 1.1.0). A mismatch here is a common cause of join failures and of 1.1 devices silently running with 1.0 security.
• Region and regional parameters revision to match the device firmware.
• Supports OTAA on. Leave ABP off unless you have no choice.
• Class B or Class C only if the device really needs them.
• A payload codec if you want decoded readings in integrations.

Step 5: Generate unique root keys

Generate a fresh 128 bit key for each device. Never reuse a key from a vendor example or a previous device.

# One AppKey (and, for LoRaWAN 1.1, one NwkKey) per device
openssl rand -hex 16   # AppKey
openssl rand -hex 16   # NwkKey, 1.1 devices only

Program the same values into the device with its configuration tool, along with its DevEUI and the JoinEUI you will use.

Step 6: Create an application and the device

Create an application, then add a device with its DevEUI, JoinEUI and the device profile from step 4. ChirpStack's docs say that for OTAA devices "you can manage the application-key (and network-key for LoRaWAN 1.1 devices) under the Keys (OTAA) tab." Enter the keys you generated.

Step 7: Watch the join

Power the device. In the device's LoRaWAN frames view you should see a Join-request, then a Join-accept, then the first uplinks. Check:

• The DevNonce in successive join requests increases.
• The frame counter starts at 0 after the join and increases on every uplink.
• For a 1.1 device, the first uplinks carry RekeyInd and the server answers with RekeyConf.

If the join fails, check the keys, the JoinEUI, the region, and whether the server has already seen that DevNonce from an earlier test. Fix a reused DevNonce on the device, not by clearing the server's history.

Step 8: Review the security settings

Before any real device joins, go through this list:

If the host is directly on a network, a minimal firewall helps:

# Allow the gateway UDP backhaul only from known gateway addresses
sudo ufw default deny incoming
sudo ufw allow from 203.0.113.10 to any port 1700 proto udp
sudo ufw allow from 203.0.113.11 to any port 1700 proto udp
# MQTT over TLS for gateways using a forwarder
sudo ufw allow 8883/tcp
# Admin UI only from the management subnet
sudo ufw allow from 192.0.2.0/24 to any port 8080 proto tcp
sudo ufw enable

Replace the documentation addresses with your own. Check sudo ufw status numbered afterwards and confirm your own SSH access rule is present before enabling the firewall on a remote host.

LoRaWAN vs NB-IoT vs LTE-M vs ultra narrowband vs Wi-Fi HaLow

LoRaWAN is one of several ways to connect a battery sensor over distance. They differ most in who runs the network and how devices authenticate.

A few practical points follow from the table:

• Licensed vs unlicensed. NB-IoT and LTE-M ride on mobile network operators' licensed spectrum and core networks, with authentication rooted in the SIM. RFC 8376 dates the first NB-IoT standard to 3GPP Release 13 in June 2016. You do not run the radio infrastructure.
• Private networks. LoRaWAN and Wi-Fi HaLow can be run entirely by you. That gives control over keys and data, and makes you responsible for the network server, gateways and their updates.
• IP or not. Wi-Fi HaLow and cellular IoT carry IP natively. LoRaWAN needs SCHC compression (RFC 8724, profiled for LoRaWAN by RFC 9011) to carry IPv6 at all, and most deployments never do.

How the IETF fits in: LPWAN and SCHC

The IETF's LPWAN working group studied whether IP can run over networks like LoRaWAN. RFC 8376 (May 2018) is its overview and gap analysis. It lays out a common vocabulary in which a LoRaWAN end device, gateway, network server, join server and application server line up with an NB-IoT user equipment, base station, packet gateway, home subscriber server and application server.

RFC 8724 defines Static Context Header Compression and fragmentation (SCHC), which compresses IPv6 and UDP headers against a context both ends already share, and fragments packets larger than a radio frame. RFC 9011 (April 2021) profiles SCHC for LoRaWAN. It encodes the 8 bit Rule ID in the LoRaWAN FPort, reserves Rule ID 20 for uplink fragmentation, 21 for downlink fragmentation and 22 for packets SCHC could not compress, and requires the uplink and downlink fragmentation ports to differ. Its security section says it adds no new security issues beyond SCHC itself, because "SCHC data (LoRaWAN payload) are protected at the LoRaWAN level by an AES-128 encryption with a session key shared by the device and the SCHC gateway", and those keys are renewed at every join or rejoin. In other words, if you run IPv6 or CoAP over LoRaWAN, the LoRaWAN session keys are still the link security, so everything in the sections above still applies.

Timeline of LoRaWAN specifications and related standards

What baseline guidance says about LoRaWAN devices

LoRaWAN is a protocol, not a product security baseline. NIST IR 8425 (September 2022) documents the consumer profile of NIST's IoT core baseline. Its capability areas map cleanly onto a LoRaWAN device: a unique device identity (DevEUI plus unique root keys), protection of data at rest (keys and counters in a secure element or protected flash), protection of data in transit (OTAA session keys, an encrypted backhaul), and a way to update software. Our NIST IR 8425 explainer covers the baseline in depth, and the IoT secure update design checklist covers update design, which matters for LoRaWAN devices that receive firmware fragments over multicast. For the broader device picture, see IoT device security fundamentals and how a different radio family handles onboarding in Zigbee, Thread and Matter explained.

Common mistakes

• Treating DevEUI and JoinEUI as secrets. Both travel in the clear in every join request. Only the root keys are secret.
• One AppKey for a whole batch. Extracting it from one device opens every device. Generate keys per device.
• Choosing ABP to avoid join problems. ABP trades a visible join failure for an invisible security failure: no rekeying and fragile counters.
• Storing DevNonce or frame counters in RAM. A battery change then either locks the device out or invites replay.
• Relaxing frame counter checks to fix a flaky device. That turns a device bug into a network wide replay window.
• Setting the wrong MAC version in the device profile. A 1.1 device registered as 1.0.x, or the reverse, causes join failures or silently drops to 1.0 security.
• Leaving the lab backhaul in production. Plain UDP on port 1700 from anywhere on the internet, an anonymous MQTT broker, and an admin/admin web login are fine for an afternoon on a bench and nowhere else.
• Assuming the network server cannot alter data. Payloads are encrypted end to end but integrity protected hop by hop. Add an application layer check for commands that move things.
• Forgetting the gateway is a computer. It runs a Linux distribution, a packet forwarder and often a remote management agent. Patch it and inventory it like any other host.

FAQ

What is the difference between LoRa and LoRaWAN?

LoRa is the radio modulation: how bits become chirps on air. LoRaWAN is the MAC and network protocol on top of it, defining addresses, joins, keys, frame counters, device classes and the network server architecture. LoRa alone has no security; LoRaWAN adds AES-128 encryption and integrity.

Is LoRaWAN encrypted?

Yes. Application payloads are encrypted with AES-128 in counter mode using the application session key, and every frame carries a 4 byte AES-CMAC integrity code. Headers, device addresses and frame counters are not encrypted, and in LoRaWAN 1.0.x MAC commands sent in the FOpts field are visible in the clear.

Is OTAA more secure than ABP?

Yes. OTAA derives new session keys at every join from per device root keys, and frame counters reset safely because the keys change too. ABP fixes the session keys for the life of the device and depends on counters never resetting. The LoRaWAN 1.1 specification recommends OTAA for higher security applications.

What is the AppKey in LoRaWAN?

The AppKey is a 128 bit AES root key unique to each device. In LoRaWAN 1.0.x it is the only root key and derives both session keys. In LoRaWAN 1.1 it derives only the application session key, while a second root key, NwkKey, derives the network session keys.

What changed between LoRaWAN 1.0.4 and 1.1?

LoRaWAN 1.1 adds a second root key, splits the network session key into three keys, encrypts MAC commands in FOpts, makes DevNonce and JoinNonce monotonic counters, splits the downlink frame counter into network and application counters, and adds rejoin requests and rekey confirmation. Many devices and networks still run 1.0.x, so check what both sides support.

Can someone read LoRaWAN traffic with a software defined radio?

They can receive every frame and read the unencrypted headers: device address, frame counter, port and, in 1.0.x, MAC commands in FOpts. They cannot read the encrypted payload without the session keys, and they cannot alter frames without failing the integrity check.

Does the LoRaWAN gateway see my data?

No. Gateways forward encrypted frames and hold no session keys. They do see metadata such as device addresses, signal strength and timing, which is why the backhaul from gateway to network server should still be encrypted and authenticated.

What is the LoRaWAN duty cycle limit in Europe?

The LoRaWAN Regional Parameters for EU868 set the three default channels at a duty cycle under 1 percent, following ETSI EN 300 220-2. One percent means about 36 seconds of airtime per hour on a sub-band, so a frame that takes 1 second on air must be followed by about 99 seconds of silence on that sub-band.

Where Safeguard fits

Safeguard does not monitor LoRa radio traffic, manage LoRaWAN root or session keys, run join servers, configure gateways or scan device or gateway firmware. Nothing in the join, key or backhaul guidance above depends on it. The honest connection is the software around the radio network: a self hosted network server stack is a set of container images (in the ChirpStack Compose example, the network server, a gateway bridge, an MQTT broker, a database and a cache), plus the integration services, payload decoders and dashboards your team writes, usually with open source libraries pulled from npm, PyPI, Go modules or Maven.

For that software, Safeguard's software composition analysis builds a dependency inventory of your own code, container scanning shows which images carry which package versions (safeguard scan --image <name>), and SBOM generation and analysis records the result in SPDX or CycloneDX. The platform shows which projects contain a given component and version, vulnerability matching and reachability analysis help you decide what to fix first, and policies and gates can stop a build that pulls in a known vulnerable version. When an advisory lands for a broker, a database image or a LoRaWAN library, the question "which of our services still ship it" has a quick answer. See using SBOMs to find affected products fast.

Gateway and device firmware is a different matter: when the vulnerable code sits inside a vendor's gateway image or a sensor's radio stack, the fix has to come from that vendor's release. Still, the network server, the integrations and the decoders that turn LoRaWAN frames into business data are built from open source components like any other service, and rebuilding them on fixed versions is the part of a LoRaWAN deployment that sits squarely in your own pipeline.

Supply chain hygiene still matters for a LoRaWAN deployment even though the radio layer has nothing to do with package managers: the network server, the gateway software, the MQTT broker and every decoder and integration you run are built from open source components that need the same patch discipline as any web service. The steps below apply to the software you build and ship around the network, not to the radios, the keys or vendor firmware, and the fork and patch option they mention is early access today.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, SBOM and remediation workflows, not LoRaWAN radio monitoring or key management. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at the container images in a self hosted network server stack, or at an integration service your team builds, the same scan lists the packages and versions inside and their known vulnerabilities, so you know which images to rebuild after an advisory.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: ask it to fix the lodash CVE in a repository and watch it read the finding and the advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with your approval, and push nothing. The same approve each step flow applies when you bump a vulnerable dependency in a Node.js or Python service that consumes LoRaWAN uplinks from your network server's MQTT integration.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects or images ship a given package version, such as a specific MQTT client library used by your uplink decoders, and get the answer from your own scan data rather than from memory.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• LoRa Alliance: LoRaWAN for Developers (standards and Regional Parameters overview)
• LoRa Alliance: LoRaWAN Specification v1.1 resource page
• LoRa Alliance: LoRaWAN 1.1 Specification (PDF, 11 October 2017)
• LoRa Alliance: TS001-1.0.4 LoRaWAN L2 1.0.4 Specification
• LoRa Alliance: RP002-1.0.5 LoRaWAN Regional Parameters (8 October 2025)
• LoRa Alliance: TS002-1.1.0 LoRaWAN Backend Interfaces
• LoRa Alliance: TS011-1.0.1 Relay
• LoRa Alliance: Technical specifications index
• RFC 8376: Low-Power Wide Area Network (LPWAN) Overview
• RFC 8724: SCHC, a Generic Framework for Static Context Header Compression and Fragmentation
• RFC 9011: Static Context Header Compression and Fragmentation (SCHC) over LoRaWAN
• eCFR: 47 CFR 15.247, Operation within the bands 902-928 MHz, 2400-2483.5 MHz, and 5725-5850 MHz
• ETSI: EN 300 220-2 published versions (deliver archive)
• ChirpStack documentation: overview, supported regions, classes and LoRaWAN versions
• ChirpStack documentation: Architecture
• ChirpStack documentation: Quickstart Docker Compose
• ChirpStack documentation: Device activation
• ChirpStack documentation: Devices
• ChirpStack documentation: Device profiles
• ChirpStack documentation: Mosquitto TLS configuration
• ChirpStack documentation: Configuration
• NIST IR 8425: Profile of the IoT Core Baseline for Consumer IoT Products (September 2022)
• Wi-Fi Alliance: Wi-Fi CERTIFIED HaLow
• 3GPP: NB-IoT

Last reviewed: 23 October 2026. LoRa Alliance specifications, Regional Parameters revisions and network server releases change over time; check the pages above for the versions your devices and servers actually implement.