Securing oil & gas IoT wireless (LoRaWAN, LTE, NB-IoT, Zigbee, Wi‑Fi, BLE): a threat model + control map by layer

Standard

Contrarian take: choosing the “most secure” wireless standard won’t save you.

Most breaches aren’t about the radio name. They’re about weak identity, mismanaged keys, and poor segmentation across device, network, and cloud.

If you’re deploying LoRaWAN, LTE/NB‑IoT, Zigbee, Wi‑Fi, or BLE in oil & gas, a faster way to make decisions is to map:
1) Typical attack paths per wireless option
2) Minimum viable controls per layer

Control map by layer (works across all of the above):

Device layer
– Unique device identity (no shared credentials)
– Secure boot + signed firmware; locked debug ports
– Key storage in secure element/TPM where possible
– OTA updates with rollback and provenance

Radio / link layer
– Strong join/onboarding; ban default keys and weak pairing modes
– Replay protection and message integrity enabled
– Rotate keys; define key ownership (vendor vs operator) and lifecycle

Network layer
– Segment OT/IoT from enterprise and from each other (zone/asset based)
– Private APN/VPN for cellular; gateways isolated and hardened
– Least-privilege routing; deny-by-default; egress controls

Cloud / platform layer
– Per-device authN/authZ; short-lived tokens; mutual TLS where feasible
– Secrets management, KMS/HSM, and audit logging
– Tight IAM, data minimization, and secure API gateways

Operations
– Asset inventory and certificate/key rotation schedule
– Detection for rogue gateways/devices, unusual join rates, and data exfil
– Incident playbooks that include field swap, rekey, and revocation

Procurement should ask less “Which wireless is most secure?” and more:
Who provisions identity? How are keys rotated/revoked? How is segmentation enforced end-to-end?

If you want, I can share a one-page threat model + control checklist by radio type and layer.