Data Security in IoT Networks: What Utility Providers Need to Know

What to Protect: Readings, Access, and Metering Continuity

Smart meter data security involves three objectives: maintaining confidentiality, preventing undetected changes to information, and ensuring its availability. In remote metering, these objectives are closely connected. A data leak exposes consumption information, tampering leads to incorrect calculations, and prolonged gaps in readings make it harder to reconcile resource supply and consumption.

Utility network protection needs to cover more than total consumption. The device identifier, measurement time, customer account association, pulse conversion factor, and change log also matter. For example, a system may transmit readings accurately but assign them to the wrong apartment because the meter was linked incorrectly during installation.

Detailed consumption profiles, particularly electricity profiles, may allow inferences about household activity and when residents are at home. Whether such conclusions are possible depends on the resource being measured, the measurement frequency, and the availability of additional data. The level of detail, authorised users, and retention periods should therefore reflect the metering requirements.

Encryption protects the message in transit, but it does not, by itself, confirm that a measurement or meter configuration is correct. Reliable metering requires technical safeguards to ensure secure data transmission, validation of source data, and a controlled process for making changes.

Why Choosing a Secure Protocol Is Not Enough

An attacker does not necessarily need to intercept a radio signal. A contractor’s account, an unpatched server, or a data exchange interface with excessive permissions can provide an entry point. Assessing security and data privacy in smart metering solely through the specifications of LoRaWAN or NB-IoT therefore leaves a substantial part of the system unexamined.

Broader statistics illustrate the significance of these risks. The Verizon DBIR 2026 identifies vulnerability exploitation as the initial access method in 31% of the data breaches examined. The share of breaches involving third parties reached 48%. The latter figure covers various dependencies on suppliers and partners, rather than contractor access to a system alone.

For organisations procuring remote metering systems, these findings highlight the importance of unauthorised access prevention through timely updates, software supplier assessment, and IoT access control for service providers. However, cross-industry statistics cannot establish the likelihood of a particular meter or network being compromised.

^{Data Security: Risks Beyond the Radio Link}

LoRaWAN and NB-IoT: Where Protection Begins and Ends

LoRaWAN provides message authentication, integrity checks, and protection against the replay of previously intercepted packets. It uses 128-bit AES keys for cryptographic protection. The application payload is encrypted between the end device and the application server.

However, end-to-end data encryption in secure IoT networks should not be equated with end-to-end integrity protection. The LoRaWAN 1.1 specification provides integrity protection on individual segments and treats the network server as a trusted component. Its security and the communications between server components therefore require separate assessment.

The LoRaWAN security architecture allows network management to be separated from access to the contents of meter readings. With the appropriate allocation of keys, a network operator can deliver messages without being able to read the payload. Each project using secure LoRaWAN communication needs to establish who holds the keys, who manages the servers, and where decryption takes place.

Practical security also depends on encryption key management. Using a shared secret key for an entire batch of devices or sending it in an unprotected spreadsheet creates additional risks. Session keys are generated following a successful OTAA join. This doesn’t mean they are automatically rotated on a schedule: the rejoin procedure depends on the system implementation.

NB-IoT uses cellular network security mechanisms, including SIM-based authentication and communications protection. But having a SIM card does not automatically secure the entire path to the metering software. Communications between the device and the application server require separate assessment.

TLS, DTLS, or other mechanisms supported by the architecture can be used to protect this exchange. Support, configuration, and server authentication must be confirmed for the selected device. Using a SIM as secure storage for application keys requires a compatible solution, such as IoT SAFE, and is not a default feature of every SIM card.

Choosing between LoRaWAN and NB-IoT network protection solely on the basis of “which is more secure” is therefore not a sound approach. What matters is the project architecture, allocation of responsibilities, key management, and backend security. A private network offers more control but also requires resources for ongoing maintenance.

How to Protect Data After Transmission

Once decrypted, readings enter a database, appear in a user portal, and are passed to other software. At this stage, the platform’s own security mechanisms apply. The customer needs a clear picture of which organisations process the information, where it’s stored, and who can read, modify, or export it.

User permissions should be assigned according to job responsibilities. An installer may need access to connect devices at a particular site, an accountant may need readings for billing, and an administrator may need access to settings. A shared account for an entire department makes it difficult to identify who performed a particular action and complicates access revocation.

Administrative and remote access should use multifactor device authentication protocols. Contractor access should be limited to the agreed scope and the time required. The same principle applies to application programming interfaces, or APIs: an integration that only retrieves readings does not need permission to change device settings.

When a developer hands a building over to a property management company or homeowners association, control of the metering system must also be transferred. This includes administrative permissions, documentation, an equipment inventory, and maintenance procedures. Previous contractor access should be reviewed rather than left active by default.

^{What to protect on each device}

What Happens if Connectivity Is Lost or Tampering Occurs?

Encryption does not prevent a gateway power outage, antenna damage, or radio interference. Remote meter reading security therefore includes the ability to withstand a communications outage and recover data. Before purchasing, establish whether the device stores readings locally, how much history its archive retains, and how the system retrieves missing records.

The cumulative total and a detailed consumption history are different types of data. If the device continued measuring and storing results, the system may retrieve the current total or archived records once connectivity is restored. However, the availability of a cumulative total does not guarantee that hourly detail has been preserved.

Loss of connectivity must also be distinguished from a failure to record readings. For example, an external pulse radio module that loses power may stop counting pulses even though the meter itself continues measuring consumption. In this case, missing data will not be recovered automatically and reconciliation with the meter’s readings may be necessary. Recovery capabilities must be verified for the specific model.

The maximum acceptable interruption in data delivery and the acceptable loss of historical data should be defined in advance. Server backups also need practical testing: can the database, device associations, and settings be restored, how long does it take, and who performs the recovery?

Physical events require separate attention: module removal, enclosure opening, or exposure to a magnetic field, where the selected model can detect them. An alert is a reason to investigate, not automatic proof of theft. Its usefulness in terms of data integrity monitoring  depends on the timestamp, successful message delivery, and a clear response procedure.

Updates and Support Throughout the Service Life

Long battery life does not guarantee an equally long period of software support. When selecting equipment, compare its expected service life with the periods during which patches will be provided for radio modules, gateways, and server software. GSMA guidance addresses IoT security throughout the solution’s lifecycle.

Ask the supplier how update authenticity is verified, who authorises installation, and what happens if the process is interrupted. Not all devices support remote updates. Where this capability is unavailable, there must be a realistic procedure for addressing vulnerabilities, such as on-site servicing, restricting functionality, or replacing equipment.

A change of maintenance provider is equally important to plan for. The customer should agree in advance on historical data exports, the transfer of necessary settings, device disconnection, and access revocation. The ability to continue metering should not depend on a single employee or a contractor’s account.

How Jooby RDC Helps Monitor System Status

Jooby RDC combines meter reading collection with information about device status. The Jooby RDC Dashboard description includes alerts for unauthorised removal, magnetic interference, and low battery levels. The availability of specific events depends on the selected equipment model. This information helps identify which metering points require inspection.

During deployment, requirements for access, data storage, integrations, and event response should be documented in the project. This connects hardware and software capabilities with the operating procedures of the utility provider or property management company.

What to Check Before Purchasing at Scale

A security assessment should conclude with a pilot at a real site. The pilot requires the selected production devices, an operational network, and the planned integration method. Demonstrating that a single reading arrives confirms connectivity but does not show how the system handles a failure or changes in user access.

The acceptance test plan should include several checks:

• Access restrictions: confirm that users assigned to one site cannot see another site’s data and that disabled accounts lose access.
• Change traceability: verify that the system records who changed a device’s account association, pulse conversion factor, or other significant settings, when the change was made, and what was changed.
• Metering recovery: establish which records are available after a communications outage, which are missing, and whether duplicates appear.
• Backup restoration: verify that the database and necessary settings can be restored to operation within the agreed time.
• Event response: confirm that the responsible employee receives the alert and that the inspection outcome is recorded.

These tests should be carried out in an agreed test area. Results should be documented against measurable criteria, including acceptable recovery time, the extent of available historical data, log completeness, and the actions permitted for each role. This turns utility infrastructure security requirements into verifiable acceptance criteria.

A secure IoT system makes it possible to establish the origin of readings, restrict access to them, and restore metering after a failure within the equipment’s verified capabilities. 

LoRaWAN and NB-IoT provide communications security mechanisms, while the overall result depends on their implementation, platform configuration, and the work of service providers. 

A solution for remote device management security should be selected based on the capabilities of the entire system, from key and permission management to pilot results and support terms.