OTAA vs ABP in LoRaWAN: Why You Should Probably Use OTAA

When you’re setting up a LoRaWAN device, one of the first decisions you’ll face is: OTAA or ABP? It sounds like a minor detail, but it has real implications for security and device management. Let’s break it down.

The Two Activation Methods

OTAA (Over-The-Air Activation): Your device joins the network by performing a handshake with the network server. Think of it like connecting to WiFi – you authenticate, exchange keys, and then you’re in.

ABP (Activation By Personalization): You hardcode the session keys directly into your device. No join procedure, no handshake – your device just starts transmitting and assumes it’s already part of the network.

On the surface, ABP looks simpler. And it is – which is exactly why it’s tempting for quick prototypes or demos. But simple isn’t always better.

How OTAA Works

With OTAA, your device stores three permanent credentials:

DevEUI: Device identifier (like a MAC address)
AppEUI/JoinEUI: Application identifier
AppKey: Root encryption key (128-bit AES)

When the device wants to join the network, it sends a join request containing the DevEUI and AppEUI, encrypted with the AppKey. The network server verifies this, and if everything checks out, it responds with:

DevAddr: Dynamic device address for this session
NwkSKey: Network session key
AppSKey: Application session key

These session keys are derived from the AppKey and a random nonce, so they’re unique for every join. And here’s the kicker: they’re temporary.

How ABP Works

With ABP, you skip the join procedure entirely. You manually configure:

DevAddr: Fixed device address
NwkSKey: Network session key (hardcoded)
AppSKey: Application session key (hardcoded)

Your device boots up and immediately starts sending data using these static keys. No join request, no key derivation, no rotation.

Sounds convenient, right? It is – until it isn’t.

Why OTAA is More Secure

Here’s the thing: ABP uses the same session keys forever (or until you manually reflash the device). This creates several problems:

1. No Forward Secrecy

If someone captures your traffic and later obtains your keys, they can decrypt all of your past transmissions. With OTAA, compromised session keys only affect the current session – previous sessions used different keys.

2. Frame Counter Issues

LoRaWAN uses frame counters to prevent replay attacks. With ABP, if your device loses power and reboots, the frame counter resets to zero. The network server sees this as a potential replay attack and might reject your messages.

Some people “solve” this by disabling frame counter checks on the network server. Don’t do this. You’re basically turning off one of your main defenses against replay attacks.

With OTAA, every join creates a new session with a fresh frame counter. Reboots aren’t a problem.

3. Key Management at Scale

Imagine you have 1000 devices. With ABP, you need to generate and track 2000 unique session keys (NwkSKey + AppSKey for each device). If you ever need to rotate keys – say, because one device was compromised – you need to physically access and reflash it.

With OTAA, you only manage one AppKey per device. Session keys are derived automatically and can be refreshed by forcing a rejoin.

4. DevAddr Conflicts

With ABP, you manually assign a DevAddr to each device. In large deployments, managing this becomes a nightmare. You need to ensure no conflicts across your entire network.

With OTAA, the network server dynamically assigns DevAddrs from its pool. No manual tracking required.

When You Might Use ABP Anyway

Okay, ABP isn’t always wrong. There are a few legitimate use cases:

Class C devices that need instant communication: If your device needs to receive downlinks immediately after booting (without waiting for a join to complete), ABP might make sense.

Extremely constrained environments: If you’re working with ultra-low-power devices where even the overhead of a join request matters, ABP saves a bit of battery. But we’re talking edge cases here.

Rapid prototyping: If you’re just testing on a bench and don’t care about security, ABP gets you up faster. Just don’t deploy it to production.

The Join Process Isn’t That Expensive

One argument against OTAA is that the join procedure adds overhead. And yes, it does – but it’s minimal:

Join request: ~20 bytes
Join accept: ~33 bytes
Total airtime (SF12, BW125): ~5-6 seconds

Even with EU868’s 1% duty cycle, that’s trivial. And you only do it once per boot (or whenever you force a rejoin).

Real-World Recommendation

Unless you have a very specific reason to use ABP, just use OTAA. It’s more secure, easier to manage at scale, and handles device reboots gracefully.

Set up your devices with OTAA, store the AppKey securely, and let the network server handle session key management. Your future self (and your security team) will thank you.