Can IoT Apps be protected with Azure Sphere? Have you worked out how to bridge the hardware gap?

The official commercial launch of Microsoft's Azure Sphere IoT security service platform at the beginning of this year has left many developers itching for a test run on their own IoT Apps. After all, with IoT being an "inelastic demand," it is undoubtedly a good thing to have tech support backed by Microsoft. Furthermore, the three-in-one solution system offered by Azure Sphere – namely, secured MCU, secured OS, and cloud security, looks so perfect that you would expect comprehensive IoT security to be within easy reach.
However, as a new technology, Azure Sphere still needs time to adapt to and accommodate all market needs. Many technicalities require ongoing refinement to meet the challenges posed throughout Azure Sphere's ecosystem. Take the hardware development of IoT devices, for example. A large amount of research remains to be done before "running around naked" can be clothed with "reliable protection." Although Azure Sphere offers certified chips to developers – such as MediaTek's MT3620, it is still only raw material. To build a complete IoT security hardware system, you still need to bridge the design gap in the middle. In other words, before fully "embracing" Azure Sphere, you need to spend some time to figure it out.
Don't fret if you haven't found all the answers. When it comes to hardware development in Azure Sphere, many people are already doing the "worrying" for you. Avnet, for example, offers reliable customized solutions to developers, at every stage of their journey.
"Start with the Hardware" is a feature that makes Azure Sphere stand out from other simple security cloud services. What’s more, you can start right away with MT3620, a mature, Azure Sphere-certified MCU. If you read our previous article "Who is providing the “hard” support behind Microsofts Azure Sphere IoT security platform?", you would already know just how much this chip can do with its built-in Microsoft Pluton security subsystem and Wi-Fi radio, integrating one Arm Cortex-A7 and two Arm Cortex-M4F cores, and abundant peripheral chips.
Those who are familiar with hardware development would know that it is no easy thing to fully grasp how a chip works and apply that knowledge to a product. The developer would not only need to understand the inner workings of the chip through Datesheet and technical documents, but also ensure high connection efficiency between the chip and the peripherals through PCB layout of the surrounding circuits. It requires not only a lot of experience, but also lots of time. However, Avnet offers a shortcut. Its MT3620 module helps developers bridge the hardware gap by integrating RF front-end circuits and necessary interfaces with MT3620 on a small module that is 33mm x 22mm in size. Hence the development time for Sphere-based hardware is dramatically reduced.
The MT3620 module by Avnet comes in two easy-to-implement versions. The chip antenna version has integrated chip antennas, boasting high integration and cost advantages, while the UFL version, which includes two U.FL RF connectors, allows you to connect to external 2.4/5 GHz antennas for better wireless connection performance. The good news is that the two versions are fully compatible, optimizing design flexibility and scalability for developers.
This type of production-ready MT3620 module allows developers with clearly defined goals for their apps to spend more effort on system-level design, instead of wasting time on low chip-level app development.
Figure 1. Avnet Azure Sphere MT3620 Module System Block Diagram, Chip Antenna version (Image source: Element14)
Figure 2. Avnet Azure Sphere MT3620 Module, ULF Antenna version (Image source: Element14)
Of course, the requirements of hardware developers in the real world are multi-layered. For creative developers who want to fully explore the possibilities of Azure Sphere, a single Azure Sphere certified chip module is clearly not sufficient. They need a starter kit that includes the core Azure Sphere MCU, along with IoT app development resources.
Avnet offers an entry-level Azure Sphere MT3620 starter kit specifically for this level of developer. This starter kit includes the abovementioned MT3620 module and a substrate. The former offers computational processing and wireless connection, while the latter includes abundant on-board resources, such as sensors (including a 3D accelerometer, 3D gyroscope, temperature sensor, and ambient light sensor), interfaces (two MikroE Click slots, one I2C Grove connector, a graphic display connector, and a development debugging interface, etc.) and a human-machine interface (optional 128x64 OLED display), forming a complete development platform. Whether you are a developer trying to evaluate the MT3620 chip, or attempting to quickly create a secure IoT App prototype based on Azure Sphere, this kind of platform will meet your needs.
Figure 3. Avnet Azure Sphere Starter Kit on-board resources (Image source: Element14)
Chances are, the target market for these tools, be it the Sphere modules or development tools, would be planning to build new IoT systems and are already considering merging the Azure Sphere security service with system internals at the onset of their designs. They would typically have a dedicated hardware team in charge of top-down, complete forward design and development, based on Azure Sphere certified chips. Microsoft defines this type of user as a "Greenfield" user.
In reality, another type of user exists – ones who wish to upgrade and modify their existing stock devices to attain a level the security on a par with IoTs, when a complete overhaul and replacement of the device hardware is impossible. These users tend to lack professional security and hardware teams for support. Microsoft calls this type of user as a “Brownfield" user. So, how can we bring the stock device of these users under the protection of Azure Sphere? The solution offered by Microsoft is realized by something called a "Guardian Module."
In simple terms, a Guardian Module is an independent security module outside of, and connected to, the IoT device. It has built-in Azure Sphere functionality and serves as the bridge between IoT devices and the Azure Sphere security cloud service. Once the Guardian Module is successfully authenticated in the cloud, it will get a "signed" certificate from the Azure Sphere security service. This certificate is the "passport," and IoT devices connected to the Guardian Module are able to enjoy the series of security cloud services provided by Azure Sphere.
Figure 4. Using the Guardian Module to provide Azure Sphere security cloud service for existing devices (Image source: Microsoft)
The Guardian Module recommended on Microsoft's official website came from Avnet's Guardian 100 module. Users will be able to connect the Guardian 100 module to their existing IoT device through Ethernet or the USB interface, and easily place their device under the protection of Azure Sphere's protection without the need of support from professionals. This "plug-and-play" experience is especially suited for upgrading and modifying those performance-critical and expensive devices.
Figure 5. Avnet Guardian 100 security module (Image source: Element14)
In the end, whether you are a "newbie" who lacks professional resources for IoT security and wants to adopt Azure Sphere's security protection to your device, an IoT app developer who craves a taste of Azure Sphere's powerful capabilities in prototype design, or a user who aims to quickly deploy Azure Sphere MCU in a business package, Avnet has the solution for you. We can show you exactly how to bridge the hardware design gap and have comprehensive IoT security at your fingertips.

