Cellular connectivity + Azure Sphere: security boundaries

Published Sep 22 2020 07:00 AM 8,089 Views

Nicholas Chen, Principal Program Manager, Azure Sphere

Kirsten Soelling, Program Manager, Azure Sphere


Azure Sphere and cellular connectivity

Cellular connectivity is one of the most common functions that customers wish to take advantage of when developing secured IoT solutions. Cellular connectivity is naturally applicable to scenarios in which Wi-Fi or Ethernet connectivity is not readily available. However, we have also seen that cellular connectivity can deliver tremendous value even in places where Ethernet or Wi-Fi are present. For instance, cellular connectivity can simplify device setup and provisioning by removing the dependency on the configuration of local network infrastructure; cellular can sidestep technical or policy obstacles and accelerate deployments.


Although Azure Sphere currently supports connecting through Ethernet and Wi-Fi networks only, it can be a useful building block for a cellular solution. You can introduce cellular connectivity by pairing the Azure Sphere device with a cellular-capable router device. This allows you to take advantage of Azure Sphere’s software update infrastructure, certificate-based authentication, and Azure integration while connecting over cellular.


When using this kind of architecture, it’s extremely important to be aware that there is a security boundary between the Azure Sphere elements and the cellular connectivity elements. Azure Sphere security does not extend beyond its own Wi-Fi or Ethernet interface. Therefore, you will want to be certain that the non-Azure Sphere parts of your solution are adequately and properly secured to ensure that the overall system (and not just the parts running on or behind Azure Sphere) is robust against security threats.

Nick Chen visual .png

Common cellular risks

Connecting a device to the internet through a cellular-enabled router introduces many similar network security risks that are present whenever you connect through other routing devices, such as the Wi-Fi access points or routers found in home and business environments. In these configurations, Azure Sphere is unable to protect the external hardware from threats like being the target of a denial-of-service attack or becoming a part of a botnet. Although the Azure Sphere parts of the system remain secured, the overall device might not be able to reach the Internet, interrupting critical functions like device telemetry and updates. This can affect your business or the customer experience you are trying to deliver.


To avoid any potentially disruptive surprises, it is critical that you identify the boundary between Azure Sphere and the cellular connectivity elements. On some devices this boundary may be difficult to spot, but this boundary is always present. For elements outside of the Azure Sphere security boundary, you should make sure that the manufacturer of the hardware, as well as the cellular service provider, offers the appropriate level of security, services, and support for your use case. For a deep-dive about evaluating the security boundaries and risks of the Azure Sphere cellular connectivity architecture please read our paper, “Cellular connectivity options immediately available to users of Azure Sphere.”


What Solutions are Available Now?

The Azure Sphere ecosystem includes a wide range of solutions representing different levels of integration between Azure Sphere and cellular connectivity. These solutions range from cellular connectivity modules suitable for additional customization to complete cellular Guardian devices ready for connection to brownfield equipment.


Although the options for introducing cellular connectivity to an IoT device may seem varied, fundamentally, the security boundary will be the same. Clearly understanding this boundary—where Azure Sphere security stops—and the security risks that remain to be resolved by you, your system integration partner, or your network provider will help you deliver the most secure and robust solution for your organization or for your customers.

Version history
Last update:
‎Oct 21 2020 11:33 AM
Updated by: