LoRa & LoRaWAN · Study deck
LoRaWAN Security and Joining
A farm meter loses power after sending several readings.
Radio Remi is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: Counter repair, key replacement, and ADR retuning may happen in the same incident window, but they should have separate evidence and owners so a radio optimization is not mistaken for a security fix.
- Explain: The review starts by naming the activation method, the credential owner, the join boundary, the network-server boundary, the application boundary, and the evidence that proves each boundary behaved as expected.
- Explain: The installer sees a successful join, but the security owner needs more: proof of which unit joined, which owner approved it, and what happened to the old secret state.
Major section
Start Simple
An encrypted reading alone does not prove safe entry, replacement, or retirement.
- A farm meter is replaced after a storm.
- The new unit must enter the right service, while the damaged unit must never return as a trusted member.
- The release record should answer simple questions.
- A join light is useful only when it points to that evidence.
Major section
Start Simple (continued)
The installer sees a successful join, but the security owner needs more: proof of which unit joined, which owner approved it, and what happened to the old secret state.
- The deeper sections name the activation choices, key roles, server boundaries, replay checks, recovery evidence, and reasons an exception needs stronger review.
- Security review starts before the first payload.
- OTAA and ABP are not just setup choices.
Major section
Overview: Security Review Starts at the Boundary
LoRaWAN security is not approved by writing "encrypted" beside a device fleet.
- The review starts by naming the activation method, the credential owner, the join boundary, the network-server boundary, the application boundary, and the evidence that proves each boundary behaved as expected.
- When the record names session material, keep the labels precise.
Major section
Overview: Security Review Starts at the Boundary (continued)
Application-side material protects application payload meaning for the application owner.
- Gateways forward what they hear; they are not the security owner for the whole system.
- DevAddr is the short device address used inside the network.
- The network session key, often written NwkSKey, supports network validation and integrity checks.
Major section
Overview: Security Review Starts at the Boundary (continued)
The application session key, often written AppSKey, protects application payload meaning for the application owner.
- OTAA derives this state during a join; ABP loads it before use and therefore needs stronger reset, replay, and retirement evidence.
- The same boundary record helps during audits.
- This keeps audit evidence reproducible after staff changes.
Major section
Overview: Security Review Starts at the Boundary (continued)
If a field technician can replace a device, the record should also say how the old device is retired and how the new device receives its own material.
- A reviewer can ask for the device identity, activation event, session-state evidence, frame-counter behavior, application route, and decommissioning owner without guessing which team keeps each artifact.
- A vague platform label is not enough for incident recovery.
- Replay protection is part of the security evidence.
Major section
Practitioner: Write the Activation Evidence Record
A useful release record separates the normal OTAA path from any ABP exception.
- OTAA gives the reviewer join evidence and fresh session state.
- ABP provisions session state directly, so it removes the join proof and shifts more burden onto counter persistence, recovery procedure, and owner approval.
- The device can rejoin or follow the approved rejoin procedure.
Major section
Practitioner: Write the Activation Evidence Record (continued)
Session state is provisioned before use and the reason for bypassing join is written down.
- OTAA's join evidence is not free, and a release record should say so.
- Counters and recovery behavior are tested across reset before release.
- Credential custody, join owner, network owner, and application owner are named.
Major section
Practitioner: Write the Activation Evidence Record (continued)
That cost is why the record should track restart frequency alongside the usual join, counter, and recovery evidence, not treat "uses OTAA" as a cost-free default.
- Provisioning owner, recovery owner, and decommissioning owner are named.
- Verification uplink reaches the expected application boundary after join.
- Provisioning, counters, recovery, and expiry or migration trigger are approved.
- Worked Review: New Sensor Fleet A new sensor fleet uses OTAA with unique activation material.
Major section
Under the Hood: Recovery Cannot Bypass Replay Protection
Frame counters are not bookkeeping trivia.
- They help the receiving side reject stale or repeated traffic.
- A device that works once but fails after reset is not release-ready.
- The network side can validate network behavior without owning application payload meaning.
- The application side can process payload meaning without owning gateway forwarding.
Major section
Under the Hood: Recovery Cannot Bypass Replay Protection (continued)
Security and ADR Incident Review Security recovery can look like radio trouble if the team reads symptoms too quickly.
- Incident playbooks should send each symptom to the boundary that can actually provide evidence.
- The review should also keep timing clear.
- A reset, rejoin, profile change, or credential repair can change recent link evidence.
Major section
Under the Hood: Recovery Cannot Bypass Replay Protection (continued)
If operations asks to "reset counters" so a troubled device comes back quickly, the release owner should treat that as a security decision, not a support shortcut.
- Counter repair, key replacement, and ADR retuning may happen in the same incident window, but they should have separate evidence and owners so a radio optimization is not mistaken for a security fix.
- ADR separation Keep ADR decisions separate from stale, mobile, mixed, or recovery-period link evidence.
- Decommissioning Name how retired, replaced, or compromised devices lose access without weakening replay protection for the rest of the fleet.
Major section
Restore a Meter without Reusing Yesterday's Session
The counter has moved backward by 5, so those values cannot be treated as fresh progress in the same session.
- An integrity check on the packet does not erase this replay concern.
- The server and device must preserve valid state or establish a fresh session through the activation procedure appropriate to their version.
Major section
Restore a Meter without Reusing Yesterday's Session (continued)
The server can keep the two reception records while delivering one application event.
- That deduplication case is not permission for the device to reuse old counters after a reset.
- It may create two devices with the same trusted identity if the old unit returns.
- The security lesson reaches beyond the join light.
Major section
Restore a Meter without Reusing Yesterday's Session (continued)
The roles differ: checking a valid frame does not require the gateway to interpret a temperature, while decrypting application content does not settle every network replay rule.
- Replacement needs its own approved identity and a retirement action for the removed unit.
- The server-side lifecycle test should demonstrate that yesterday's accepted ownership does not silently reopen access.
- In an illustrative recovery trace, joining starts at 2 s and the application accepts the test reading at 14 s, an end-to-end interval of 12 s.
Deck summary
Key takeaways
An encrypted reading alone does not prove safe entry, replacement, or retirement.
- The installer sees a successful join, but the security owner needs more: proof of which unit joined, which owner approved it, and what happened to the old secret state.
- LoRaWAN security is not approved by writing "encrypted" beside a device fleet.
- Application-side material protects application payload meaning for the application owner.
- The application session key, often written AppSKey, protects application payload meaning for the application owner.
Retrieval practice
Recall check 1 of 3
Radio Remi says: answer from memory, then check your reasoning.
Q1A LoRaWAN team says the deployment is secure because the radio traffic is encrypted. What should the review ask for first?
Show answer
Answer: B Security claims need observable evidence at each LoRaWAN security boundary.
Retrieval practice
Recall check 2 of 3
Radio Remi says: answer from memory, then check your reasoning.
Q2A team wants to use ABP because it avoids the join procedure. What should the reviewer require before approval?
Show answer
Answer: C ABP removes join evidence, so the release must prove the controls that make the exception bounded.
Retrieval practice
Recall check 3 of 3
Radio Remi says: answer from memory, then check your reasoning.
Q3A reset device starts producing rejected uplinks after a previously successful LoRaWAN release. What is the best first review action?
Show answer
Answer: D LoRaWAN reset and recovery issues must preserve replay protection while routing each symptom to the correct owner.
Print reference
Answers
Answer key.
- B · Security claims need observable evidence at each LoRaWAN security boundary.
- C · ABP removes join evidence, so the release must prove the controls that make the exception bounded.
- D · LoRaWAN reset and recovery issues must preserve replay protection while routing each symptom to the correct owner.