LoRaWAN Risks in Smart Street Lighting: Why Cities Are Cautious

With the vision for a smarter, safer and sustainable cities, municipalities are exploring various communication technologies to manage urban infrastructure. LoRaWAN (Long Range Wide Area Network) is one such network solution for the Smart Cities / Internet of Things (IoT) landscape.

For low-data and non-critical applications, such as reading smart meters, water meters or monitoring waste containers, LoRaWAN is one of the reasonable choices. It is cost-effective, energy-efficient, and offers long-range coverage.

However, a challenge arises when this communication network is applied to the Smart Street Lighting application. Vendors often encourage municipalities to “piggyback” smart street lights onto existing smart meter networks. While this appears efficient in theory, it ignores a fundamental reality: ‘passive monitoring’ is distinct from ‘active critical control’.

Street lights are public-critical infrastructure requiring assurance on real-time responsiveness, high security, and guaranteed reliability. Below are the six critical reasons why industry consultants and municipalities are exercising caution regarding LoRaWAN for smart street lighting.

1. The Traffic Asymmetry: “Reading” versus “Controlling”

To evaluate the risk, one must understand the direction of data flow.

• Smart Metering (the ideal use case): smart meters need an “uplink-dominant” process. Devices wake up periodically, transmit a small data packet (the meter reading) to the cloud, and return to sleep. Packet loss is acceptable, as the data can be re-sent later.

• Smart Street Lighting (the LoRaWAN limitation): this requires “downlink” reliability. The system must transmit commands (for example, “Turn ON,” “Dim to 100%”) from the cloud to the device instantly.

The Technical Bottleneck

LoRaWAN architecture is asymmetric; it is designed to receive data, not to send it.

A standard LoRaWAN gateway can receive thousands of messages from the devices, but is severely limited in the number of commands it can transmit back to devices.

When a municipality attempts to control thousands of streetlights simultaneously – for example, bringing lights to full brightness during an emergency – the network often faces severe congestion. This results in the “popcorn effect”, where lights activate sporadically over several minutes / hours, or even fail to activate entirely.

2. Latency as a Public Safety Liability

For smart meter or water meter reading, a 15-minute or an hour delay in data transmission is operationally negligible. For public lighting, a delay of even a few seconds can be a safety liability.

Modern street lights act as the backbone for public safety. Street lighting is often integrated with emergency response systems, and occassionally with adaptive motion-sensor based lighting solution. If police, ambulance or fire-brigade requires maximum brightness in an area, the response must be instantaneous.

LoRaWAN operates in unlicensed spectrum and under strict “duty cycle“ regulation (typically 1%). This legal limit on the transmission time, combined with low bandwidth, means real-time control is certainly not guaranteed. In mission-critical scenarios, this latency renders LoRaWAN significantly unsafe for public critical infrastructure.

3. Security Risks: Unlicensed Spectrum and Protocol Vulnerabilities

Deploying critical infrastructure on LoRaWAN introduces significant security challenges, as highlighted by recent cybersecurity research*.

A. Unlicensed Spectrum (Physical Layer Risks): LoRaWAN operates on unlicensed ISM bands (for example, 868 MHz or 915 MHz).

These frequencies are open to the public, sharing airwaves with consumer electronics. Consequently, the network is susceptible to signal interference, jamming, and spoofing attacks**.

B. The “Black Box” Network Server: unlike Cellular (3GPP) or RF Mesh (IEEE) communication networks, which adhere to rigorous, globally audited stringent security standards, LoRaWAN infrastructure lacks a unified governance model for its network servers.

The LoRa Network Server (LNS) implementation is often proprietary to each vendor. This creates a “black box” risk: municipalities must trust a specific vendor’s security design rather than an open, international standard. Research indicates that vulnerabilities in key management can significantly expose networks to replay attacks.

Recent security presentations, such as the BlinkenCity Research, demonstrated how easily attackers can hijack such radio-control. Using inexpensive, handheld radio tools (such as a Flipper Zero), researchers showed that unauthenticated or weakly protected radio signals can be recorded and “replayed” to seize control of city grids. This underscores the danger of using open radio frequencies for controlling critical infrastructure that does not follow IEEE, ISO or equivalent standards.

For public-critical infrastructure such as street lighting – where commands like “turn off” or “dim to 10%” directly affect public safety – these vulnerabilities and lack of open standardization are unacceptable risks.

* Giacobbe et al, 2025; Bräunlein and Melette, 2025; Dossa et al, 2025; Šabić et al, 2025; McWeeney et al, 2024 ** Basu et al., 2020; Butun et al., 2019; Dossa & Amhoud, 2025

4. The Interoperability Myth: Connectivity vs. Functionality

Municipalities often assume that “LoRaWAN certified” means “Plug-and-Play.” This is a costly misconception.

While LoRaWAN ensures that a device can connect to a gateway, it does not standardize the language the device speaks (the data payload).

• No Data Standardization: a street light controller from Vendor A transmits data in a completely different format than a controller from Vendor B.

• The Lock-in Trap: if a municipality purchases controllers from Vendor A today, they cannot simply swap them for Vendor B’s controllers in the future. The data payloads will be unreadable to the central management system without expensive, custom software integration for every new device type.

True interoperability allow operators to mix and match hardware brands seamlessly (similar to Wi-Fi devices, DALI drivers or TALQ protocol). LoRaWAN fails to deliver this standard, effectively locking the city into a single hardware vendor’s ecosystem, unless they are willing to bear the cost of continuous custom integration.

5. Maintenance and Scalability: The “Firmware” Trap

Even well-designed and secure IoT devices require periodic over-the-air (OTA) firmware updates during their operational life. Updates may be needed to comply with new cybersecurity standards, ensure compatibility with evolving ecosystems, or add enhanced functionality required by cities over time.

On high-bandwidth networks such as Cellular or RF Mesh rolling out firmware upgrades to a fleet of 10,000 streetlights is a routine and predictable operation.

On LoRaWAN, however, firmware distribution becomes a structural challenge. Low data rates, strict duty-cycle limitations, and the uplink-oriented protocol design mean that delivering firmware packages to large populations of LoRaWAN-based streetlight controllers can take weeks or even months.

This creates a long-term maintenance bottleneck: when regulations change, new security requirements emerge, or interoperability updates are needed, cities may face prolonged delays before the entire infrastructure is brought to the required state. This limitation raises concerns for municipalities seeking predictable, scalable, and future-proof smart street lighting operations.

6. Hidden Operational Costs (TCO)

While LoRaWAN is frequently marketed as a “low-cost” solution due to the absence of licensed spectrum fees, the Total Cost of Ownership (TCO) often exceeds expectations:

• Infrastructure Burden (Municipality as Operator): by choosing LoRaWAN for smart street lighting application, the municipality effectively becomes the telecom operator, responsible for the power, backhaul, and maintenance of the entire network infrastructure. Unlike cellular networks, LoRaWAN relies on a Star Topology. While theoretical range is 15 km, urban obstacles (buildings, trees) typically reduce this to 2–5 km or less.Furthermore, because each gateway can only handle a limited number of devices before performance drops, a medium-sized city requires dozens or even hundreds of gateways. This fragmented architecture significantly increases deployment complexity and maintenance costs.

• Specialized Troubleshooting & the “Evolving City” Dilemma: diagnosing connection issues in a “noisy” unlicensed band requires specialized radio engineering expertise (spatial analysis, antenna calibration), which is rarely available in-house. The need for specialized inhouse engineering skills become a critical financial risk for evolving cities.

  As new buildings are constructed over the next decade, they create new signal shadows. A network that works today may fail tomorrow due to new construction, requiring expensive re-planning and infrastructure shifts.

• Resilience Issues (Single Point-of-Failure): unlike cellular network where uptime is guaranteed by local telecom operator, or RF Mesh network – wherein devices support one another, LoRaWAN controllers rely on a star topology. If a gateway fails, an entire neighborhood of lights may go offline. And LoRa gateway recovery process is certainly not simple.

Conclusion: Aligning Technology with Application

LoRaWAN is one of the suitable choices for reading smart meters, water meters, and environmental sensors. Its low power consumption and long-range capability make it an appropriate fit for these low-bandwidth monitoring tasks.

Streetlighting is different. It is a mission-critical public safety infrastructure. It requires highly reliable, robust, and secure bi-directional control. Smart streetlights also require the ability to deliver high-throughput firmware and security updates, as well as maintain open interoperability over the lifecycle of the infrastructure.

For these reasons, forward-looking municipalities increasingly turn to communication technologies specifically engineered for critical asset management, such as RF Mesh or Cellular, which are built on globally audited, stringent security standards. These alternatives offer the low latency, high reliability, and standardized cybersecurity needed to ensure public safety, and long-term operational resilience in smart street lighting deployments.