Device Security

Authentication means verifying that the device is authentic, the server is legitimate, and verifying the data has not been tampered with.

We have implemented comprehensive security protocols on our devices and software to protect against attacks on the integrity and confidentiality of your telematics data.


Authentication means verifying that the device is authentic, the server is legitimate, and verifying the data has not been tampered with. This protects against ‘spoofing’ attacks, or when malicious parties attempt to impersonate devices to steal data, spread malware, or bypass access controls.


Confidentiality involves ensuring data is transmitted securely. Data is encrypted prior to transit, such that even if it were to be intercepted by a 3rd party, it cannot be deciphered.

Authentication and Encryption

Our devices operate in AES256CCM – CCM Mode using AES for block encryption with a 256-bit key.

The Advanced Encryption Standard (AES) was established by the US National Institute of Standards and Technology in 2001 and adopted by the US Government. Today its adoption is widespread and this, along with the scheme, provides several benefits:

Widespread adoption means the standard has been thoroughly field-tested, and it has proven itself as secure.
The algorithm does not require huge amounts of computational power and is quick to implement, so performance does not suffer. We use a 256-bit encryption key as part of the scheme.
The number of operations required to brute force such a cipher is 3.31 x 10^56 – which is roughly equal to the number of atoms in the universe. So, with current computing power, AES-256 can’t be cracked.

Put simply, AES works by jumbling up the device data (a lot!) using a key. It can only then be ‘unjumbled’ by using the key at the other end. Unjumbling without knowledge of the key is so impractical (it would take so long as above) that it is regarded as impossible.

AES-256 is regarded as ‘military’ spec encryption, as it is used by the US military. If it is good enough for them, we think that it must be pretty impenetrable. A key is stored on the device, and securely on the OEM Server. Each key is randomly different for every device, so if a device was to be compromised somehow then the key cannot be used to decrypt data from other devices. A rolling code forms part of the cipher, meaning it changes on each connection – making the system even more secure.

AES256CCM also fulfills the requirement for authentication. As part of the process, a Message Authentication Code (MAC) is generated and appended to the message. Then the entire message is encrypted. The MAC provides the benefit that it can be used on the server-side to identify whether the message is authentic and if any data in the message has been altered either intentionally or via errors in transmission.

On top of this, the microcontrollers we use in our products are programmed entirely by us – including the bootloader and main firmware. This means we are not relying on any other code that could be malicious or vulnerable to known exploits.

Third-Party Integration

The security discussed above covers the critical step of the transmission of data from the device to the OEM Server, our device management layer. In order to transmit data to a 3rd party server, we can send this data over HTTPS, providing a full end to end data security.


LoRaWAN® networks use AES-128 Encryption. Each LoRaWAN® device is personalized with a unique 128 bit AES key (called AppKey) and a globally unique identifier (EUI-64-based DevEUI), both of which are used during the device authentication process. Allocation of EUI-64 identifiers requires the assignor to have an Organizationally Unique Identifier (OUI) from the IEEE Registration Authority. Similarly, LoRaWAN® networks are identified by a 24-bit globally unique identifier assigned by the LoRa Alliance®.

LoRaWAN® application payloads are always encrypted end-to-end between the end-device and the application server. Integrity protection is provided in a hop-by-hop nature: one hop over the air through the integrity protection provided by LoRaWAN® protocol and the other hop between the network and application server by using secure transport solutions such as HTTPS and VPNs.


For more information on LoRaWAN® Security please visit

Was this article helpful?



Explore Related Articles about Device Security

Bluetooth in Fleet management

Bluetooth® in Fleet Management

Designed for short-range communication, this technology can also be applied in fleet management to gather real-time and actionable data from vehicle components, enhancing data collection, diagnostics, and preventative maintenance strategies and accuracy.

Remote Worker

Remote Worker Monitoring

Typically, lone worker tracking involves monitoring employees or assets in areas that do not have cellular coverage and often require some form of duress or “man-down” alerting.

After Hours Tracking: Construction Site at night

After Hours Tracking

During work hours, assets are under heavy use by various operators. However, we only need a few updates per day, to assist the operations team in locating the assets at specific times of the day.