Skip to main content
Cisco Meraki Documentation

MT Sensors Security Architecture


This article aims to provide a comprehensive overview of the security features and practices implemented in the design and operation of Cisco Meraki MT Sensors. With the increasing reliance on IoT devices for various applications, ensuring the security and integrity of these devices is of paramount importance.

The MT Sensor portfolio offers a robust and scalable solution for collecting and analyzing environmental data in a wide range of settings. These sensors are designed to monitor and measure parameters including temperature, humidity, air quality, energy usage and more.

However, the deployment of IoT devices introduces potential security risks, including unauthorized access, data breaches, and malicious attacks. To address these concerns, Meraki has implemented a comprehensive security architecture to protect the MT Sensors and the data they generate.

This article will explore various layers of security employed by Meraki MT Sensors. Physical security measures, network security protocols, data encryption and authentication mechanisms will all be covered, to ensure end-to-end security. By thoroughly understanding the security measures implemented by Meraki, users and stakeholders can make informed decisions regardig the deployment and integration of MT Sensors into their networks.

Security Architecture

Physical Security

JTAG Interface Removal

As Cisco Meraki controls the manufacturing process end-to-end, any physical connections to the board or MCU (Micro Controller Unit) is removed in order to prevent malicious firmware being sideloaded directly onto the MT sensors. Even if an attacker physically adds a connector, the MCUs no-read protection mechanism will prevent malicious users from gaining access to the internal memory. This ensures physical integrity of the sensor.

Cisco Trustworthy Technologies

 Along with the physical removal of the headers, the MT sensors also heavily leverage the Cisco Trustworthy Technology as part of the security model as described below.

Image Signing

Image signing is a two-step process for creating a unique digital signature for a given block of code. First, a hashing algorithm, similar to a checksum, is used to compute a hash value of the block of code. The hash is then encrypted with a Cisco private key, resulting in a digital signature that is attached to and delivered with the image. Signed images may be checked at runtime to verify that the software has not been modified.

Trust Anchor module (TAm)

This proprietary, tamper-resistant chip is found in many Cisco products and features nonvolatile secure storage, Secure Unique Device Identifier, and crypto services, including random number generation (RNG), secure storage, key management, and crypto services to the running OS and applications.

Some of the benefits of using TAm are:

  • SUDI helps to enable anti-counterfeit checks, along with authentication and remote provisioning

  • X.509 SUDI certificate installed at manufacturing provides a unique device identity

  • Secure, on-board storage

  • RNG/crypto services support secure communications

Network Security

 Graph illustrating MT sensor connection path to the Dashboard (MT sensor - BLE Connectivity - MR / MV (Gateway) - Cloud Management - Meraki Dashboard)

The Cisco Meraki Sensors use Bluetooth Low Energy radio to communicate with their gateways (MV and MR). Because BLE is used for communication, an IP stack is not required. This enables users to deploy Meraki MT sensors across their physical infrastructure without having to account for network segmentation, which is common for other IoT solutions. It helps the organization reduce challenges often incurred to ensure network security and further reduce network surfaced attack vectors.

The telemetry data from the sensors is sent to the gateway using a data encryption mechanism described below. The gateway then uses its existing connectivity to the Cisco Meraki Cloud to transfer the data. More details on the communication mechanism on the gateway can be found here.

Authentication and Encryption

Device Identity - SUDI

The Meraki sensors use Secure Unique Device Identifier, or SUDI, which is an X.509v3 certificate to maintain the product identifier and serial number. 

The identity is implemented at manufacturing and is chained to a publicly identifiable root certificate authority. The SUDI can be used as an unchangeable identity for configuration, security, auditing, and management. The SUDI credential for MT sensors stored in the Trust Anchor module is based on Elliptic Curve Diffie-Hellman (ECDH).

The SUDI certificate, the associated key pair, and its entire certificate chain are stored in the tamper-resistant Trust Anchor module chip. Furthermore, the key pair is cryptographically bound to a specific Trust Anchor chip and the private key is never exported. This feature makes cloning or spoofing the identity information virtually impossible.

Device Authentication and Encryption

In the context of Cisco Meraki MT Sensors, the Meraki Dashboard acts as the verification authority to validate the authenticity of the sensor that is connecting to the gateway. This is done by uploading the public key of the aforementioned SUDI certificate for that particular sensor to the Dashboard during the manufacturing process.

This is an important step as it ensures the authenticity of the MT sensor and only allows validated sensors as an inbound connection.

Diagram illustrating auth process for MT(Can I connect? > Validation by MR/MV > Cloud > This sensor is authorized to send data. Use this unique key to tag all communication > Cloud > MR/MV > Sensor

Once the MT sensor has been identified and authenticated, the MT sensor and Meraki Dashboard then creates a shared Long Term Key (LTK) derived from the shared secrets. That key is then used to encrypt that data in transit.

The state diagram below outlines the process that is used to ensure the authenticity of the sensor and also derive the LTK for data encryption.

LTK encryption process: Sensor knows Dashboard public key G® built into firmware, Dashboard knows Device SUDI pubkey and certificate GA uploaded at manufacturing. Dashboard:generates ephemeral key Y -  MT: Generates ephemeral key X - Dashboard: Use key B and Y to generate shared ECDH secrets, MT: Use SUDI key A and X to generate shared ECDH secrets - Dashboard and MT: Derive LTK from shared secrets - Dashboard: Securely transfer LTK - MT: Telemetry encrypted and authenticated using LTK

Using the LTK, the sensor encrypts the telemetry data and sends it to the gateway which subsequently uses the shared LTK to decrypt the data. This ensures that the data in transit is encrypted.


In conclusion, the Meraki MT Sensors provide robust security measures and practices to ensure the protection, integrity, and confidentiality of data generated by these devices.

Leveraging an end-to-end manufacturing process, the devices are secured against potential attack vectors. Regular security audits are also performed, to maintain up-to-date security standards.

  • Was this article helpful?