Wireless telemetry can be a powerful addition to industrial environments, but only when it is introduced with the right boundaries. In production facilities, LoRaWAN offers a secure way to collect data from sensors and devices without opening the door to critical control systems. This article looks at where LoRaWAN fits in industrial networks, what protects it by design, and why proper segmentation is essential for keeping production environments safe.
Does LoRaWAN create a risk for the production network?
A LoRaWAN deployment in a production facility naturally raises one key question: can this wireless network become a path into the production line?
The answer is: not if it is properly designed.
A properly segmented LoRaWAN network, used as an Internet of Things IoT telemetry layer, does not create a direct access path to PLCs, SCADA systems, safety systems, robots, drives, or process controllers. The real security risks come from poor implementation: weak segmentation, insecure key management, exposed gateways, or unsafe backend integration.
In short: LoRaWAN provides strong protocol-level security mechanisms, but the overall security of a production deployment depends on architecture, implementation, key management, and operational controls.
LoRaWAN is not Wi-Fi for the production line
A LoRaWAN gateway is not a Wi-Fi access point. It does not give end devices general access to the plant network, and it does not allow sensors to browse internal systems or connect directly to OT assets.
Although LoRaWAN end devices do not receive general IP access, gateways are IP-connected infrastructure and must be treated as managed network assets.
A typical LoRaWAN architecture looks like on Figure 1 below:
Fig. 1 The LoRaWAN network architecture (source).
In this architecture:
- the end device collects data from its sensors and transmits it to the gateway
- the gateway forwards LoRaWAN packets,
- the Network Server manages LoRaWAN network operations,
- the Application Server processes application data,
- data transmitted from the Application Server can be sent to other systems via MQTT over TLS, HTTPS, or another approved secure channel.
For Over-the-Air Activation, or OTAA, a Join Server also supports the join procedure, root key protection, and session key derivation.
The important point is simple: LoRaWAN should be treated as a separate industrial telemetry network, not as part of the production control network.
What LoRaWAN should do in production
In production facilities, LoRaWAN technology is best suited for monitoring and sensing. It is useful across various industries, including smart cities, utilities, logistics, agriculture, critical infrastructure, and industrial IoT networks.
Typical use cases include:
- temperature and humidity monitoring,
- vibration and condition monitoring,
- energy and utility metering,
- tank or fluid-level monitoring,
- leakage detection,
- asset tracking,
- equipment-status reporting,
- maintenance alerts.
These use cases provide visibility. They do not require LoRaWAN to control the production process.
A sensor that reports a temperature value is not the same as a system that changes a PLC setpoint, opens a valve, or stops a conveyor. For most production environments, LoRaWAN should be treated primarily as monitoring and telemetry technology. Any use for actuation or process influence should be assessed as an OT control use case, not as standard telemetry.
LoRaWAN security architecture
LoRaWAN is wireless communication, so radio traffic can be observed, but application payloads and message integrity are protected by LoRaWAN security mechanisms. LoRaWAN’s security architecture includes robust security measures and cryptographic mechanisms designed to protect data, authenticate devices, and preserve data integrity.
Key security properties include:
- device authentication,
- Advanced Encryption Standard AES-128 encryption,
- end-to-end encryption of application payloads between the end device and the Application Server,
- integrity protection,
- replay protection,
- secure session keys,
- separation of network and application security,
- protection against unauthorized devices.
LoRaWAN uses AES-128 for encryption and integrity protection. Application payload encryption is based on AES in counter mode, or AES-CTR, helping ensure that sensitive data remains confidential. For message integrity verification, LoRaWAN uses CMAC-based mechanisms and a Message Integrity Code, or MIC, which helps prevent intentional tampering with transmitted data.
This means unauthorized parties listening to radio traffic should not be able to read application data, modify valid messages, or impersonate authorized devices without the required cryptographic material.
Read more on Industrial IoT:
OEE: A basic KPI for optimizing manufacturing processes
Industrial Internet of Things (IoT) trends for 2026
Industrial data acquisition for energy management—how we do it at Fabrity
Internet of Things (IoT) security: A challenge for 2026
The LoRaWAN technology for industrial settings: Four practical use cases for 2026
Network Session Key and Application Session Key
LoRaWAN separates network security from application security through session keys.
At a simplified level, LoRaWAN uses two session keys:
- the Network Session Key, used for network-level integrity protection between the end device and the Network Server,
- the Application Session Key, used for end-to-end encryption of the application payload between the end device and the intended Application Server.
In LoRaWAN 1.1, the network-side security model is further split into several network session keys, such as FNwkSIntKey, SNwkSIntKey, and NwkSEncKey, while the AppSKey remains responsible for application payload encryption.
This separation is central to LoRaWAN’s security architecture. The Network Server manages the LoRaWAN network session and network operations, while the Application Server handles application data. Both the network and application layer have distinct roles, and application data remains confidential for the intended Application Server.
OTAA, ABP, and secure key management
LoRaWAN uses two activation methods:
- Over-the-Air Activation, or OTAA
- Activation by Personalization, or ABP
ABP is a static activation method with pre-configured session parameters. It can be useful in some cases, but it is generally less secure because session keys are static.
OTAA is recommended for secure settings. During the OTAA process, the device joins the network through a join request and receives a join accept message. The Join Server and Network Server support the join procedure, during which session keys are dynamically derived. This makes OTAA more secure than ABP for production-grade deployments.
Each LoRaWAN device has unique root-key material. In LoRaWAN 1.0.x, the AppKey is the root key used during OTAA to derive session keys. In LoRaWAN 1.1, root-key handling is more granular. In both cases, the principle is the same: root keys and secret keys must be unique, protected, and never reused across devices.
Strong key management is of critical importance. Key compromise can undermine device authentication, data confidentiality, and data integrity. Secure storage should be used for device keys, and hardware security modules should be considered for backend cryptographic key storage. Key rotation procedures should be defined where supported and operationally appropriate.
Protection against wireless security risks
LoRaWAN includes security mechanisms against common wireless threats:
- Eavesdropping: application payloads are encrypted, so sensitive information remains protected.
- Message tampering: CMAC and the Message Integrity Code support integrity protection.
- Replay attacks: frame counters and strict sequence tracking help detect reused or out-of-order messages.
- Unauthorized devices: device authentication during the join procedure helps ensure that only authorized devices can join.
- Malicious nodes: monitoring and access controls help reduce disruption to LoRaWAN network operations.
In LoRaWAN 1.1, the security model provides stronger separation of network and application trust domains.
RF interference and jamming
LoRaWAN operates on unlicensed radio frequencies. This makes it flexible and cost-effective, but it also means LoRaWAN can be susceptible to RF interference and RF attacks such as jamming.
These are real risks, but they are mainly availability risks for the LoRaWAN telemetry network. Interference or jamming may delay or block sensor messages. They do not, by themselves, give an attacker access to PLCs, SCADA systems, safety systems, or the production control network.
However, loss of telemetry may still affect monitoring, alerting, maintenance decisions, or any downstream process that relies on sensor data.
For critical infrastructure or production-critical use cases, availability requirements should be assessed carefully. LoRaWAN can be a strong fit for many monitoring scenarios, but safety-critical control should not depend on unlicensed-band wireless communication without a separate OT and safety assessment.
Segmentation is the decisive control
The most important security measure is segmentation.
LoRaWAN infrastructure should be deployed in a dedicated environment, such as:
- a separate IoT VLAN,
- an isolated subnet,
- an industrial DMZ,
- a private APN,
- a separate backhaul network.
The rule should be simple:
No direct route from the LoRaWAN network to production-control assets by default.
Gateways, Network Servers, Application Servers, Join Servers, and management tools should not be able to initiate uncontrolled connections to PLCs, SCADA engineering workstations, drives, robots, safety systems, or process controllers.
If integration is required, it should be:
- explicitly approved,
- firewall-controlled,
- logged,
- monitored,
- limited to the minimum required scope,
- preferably read-only.
This is why a properly segmented LoRaWAN deployment does not create a direct path into the production network.
Figure 2 below highlights the five key layers that make a LoRaWAN deployment secure in industrial environments.
Fig. 2 Five layers of secure LoRaWAN deployment
Backend and operational security still matter
LoRaWAN protocol security protects LoRaWAN frames and application payloads, but backend systems must also be secured.
That includes:
- gateway management interfaces,
- IP backhaul,
- Network Server,
- Join Server,
- Application Server,
- APIs,
- MQTT or HTTPS endpoints,
- user accounts,
- monitoring tools.
Secure backend data transit is typically achieved using MQTT over TLS, HTTPS, or equivalent secure transport. Network operators should also apply least-privilege access, certificate management, logging, monitoring, patching, and secure configuration.
Regular security audits should be conducted to identify vulnerabilities such as exposed gateway interfaces, weak keys, outdated firmware, excessive firewall permissions, misconfigured MQTT endpoints, unmanaged devices, insecure OT integrations, insecure device provisioning, shared keys, lack of secure firmware update process, and insufficient physical protection of gateways or end devices.
Security must also evolve over time. Configuration drift, undocumented changes, new devices, and evolving threats can weaken an initially secure deployment.
Telemetry is low-risk; control requires separate assessment
LoRaWAN is safest when used for telemetry:
- “The tank level is 72%.”
- “The motor vibration has exceeded a threshold.”
- “A leak sensor has detected moisture.”
These messages inform decisions. They do not directly execute control actions.
However, LoRaWAN supports bi-directional communication. If downlink messages are used to actuate devices, open valves, stop machines, trigger relays, or influence control logic, the deployment becomes part of an OT control path.
That requires a separate cybersecurity and safety assessment.
Final conclusion
LoRaWAN provides strong protocol-level security mechanisms, but the security of a production deployment depends on architecture, implementation, key management, and operational controls.
A properly segmented LoRaWAN network does not create a direct access path to the production network because:
- gateways act as packet-forwarding infrastructure,
- end devices do not receive general IP access,
- application data is protected with end-to-end encryption between the end device and the Application Server,
- message integrity is verified with MIC and CMAC mechanisms,
- replay protection uses frame counters and sequence tracking,
- OTAA supports dynamic session keys,
- backend systems can be secured with MQTT over TLS, HTTPS, secure storage, and hardware security modules,
- production systems remain separated by network segmentation.
The presence of LoRaWAN in a production facility should not be considered a security threat to production processes, provided that it is properly segmented, securely implemented, regularly audited, and not connected as an uncontrolled bridge into the production control network.
Any residual risk should be treated as an implementation, integration, or availability risk — not as an inherent weakness of LoRaWAN.
