Receiving a radio packet at a gateway does not, by itself, complete a secure metering installation. Network activation, root-key custody, session-key use, replay detection, backend transport and access privileges are distinct controls. A procurement and commissioning specification should test all of them.
A gateway is not the entire security architecture
In LoRaWAN, an end device transmits to one or more gateways, which forward radio traffic over IP to a Network Server. The gateway is not, by itself, responsible for end-device admission or application-payload decryption. Integrity and counter checks belong to the network layer, while access to decrypted application data depends on the Application Server and the chosen key architecture.
The ATLAS LR-1 is described as a collection gateway for LoRaWAN meters and sensors. Join Server, Network Server, Application Server, TLS/VPN transport and key governance must be specified separately; they should not be represented as intrinsic guarantees of LR-1 hardware.
OTAA versus ABP
Over-the-Air Activation (OTAA) derives new session keys during a join procedure and is generally the preferred production approach. Activation by Personalization (ABP) provisions a device address and session keys in advance. ABP can impose additional operational and security risks when devices reboot, migrate or are recommissioned.
LoRaWAN 1.0.x uses AppKey to derive NwkSKey for network integrity and AppSKey for application-data confidentiality. LoRaWAN 1.1 distinguishes AppKey and NwkKey roots and introduces FNwkSIntKey, SNwkSIntKey and NwkSEncKey network session keys. First verify the protocol version; do not assume that all fleets use the same key scheme.
What AES-128 protects—and what it does not
LoRaWAN uses AES-128-based cryptography for protected application payloads and MAC integrity mechanisms. This does not automatically secure every IP connection, user account, API or database downstream of the gateway. Use appropriate protected backhaul, least-privilege access, credential rotation and operational audit logs.
DevEUI and JoinEUI are identifiers rather than secrets. Root keys require secure device-specific provisioning, controlled custody and an approved revocation procedure. Avoid circulating plaintext secrets in ordinary spreadsheets or unprotected email.
How frame counters help prevent replay
Captured radio traffic may be rebroadcast. LoRaWAN frame counters such as FCntUp help receivers reject frames that have already been accepted. For example, after uplink counter 105 has been accepted, an old frame with counter 103 should not be treated as a new measurement. Counter persistence deserves particular attention during ABP device reboot, migration and backup restoration.
Protocol frame counters are not the same as a water meter’s cumulative consumption index. Independently validate meter identifiers, measurement timestamps, data ordering and register plausibility in the application layer.
Nine commissioning checks for a secure fleet
Record device protocol version, region and activation method. Verify device identity and per-device root-key issuance. Test the DevEUI/JoinEUI registration against the authorized server. Capture join failures and retry behavior. Confirm rejection of stale counters in a controlled test environment. Review protected gateway-to-backend transport and account permissions. Scope application API tokens and operator roles. Define key and access revocation for device transfer. Test timestamp/index consistency plus backup and recovery using synthetic records.
Applying the checklist to ATLAS LR-1 projects
The LR-1 product page describes LoRaWAN data collection, with connectivity variants and radio parameters subject to the quoted hardware revision. A deployment brief should separately identify the end-device models, LoRaWAN version, Network Server, Join Server, Application Server, owner of key material and incident-response responsibilities. Gateway coverage alone is not a security acceptance criterion.
Review the ATLAS LR-1 gateway and request an integration assessment covering your end-device versions, backend architecture and key-management requirements.
General LoRaWAN security principles are discussed; no specific ATLAS end-device firmware version or security certification is asserted.