Contents

Azure Internet of Things

Overview
Introduction
Choose the right IoT solution
Azure IoT services and technologies
Support and help options
Security
Recommendations
Security from the ground up
Security best practices
Security architecture
Secure deployment
 What is Azure Internet of Things (IoT)?
4/21/2020 • 3 minutes to read • Edit Online

The Azure Internet of Things (IoT) is a collection of Microsoft-managed cloud services that connect, monitor, and
control billions of IoT assets. In simpler terms, an IoT solution is made up of one or more IoT devices that
communicate with one or more back-end services hosted in the cloud.

IoT devices
An IoT device is typically made up of a circuit board with sensors attached that use WiFi to connect to the internet.
For example:
A pressure sensor on a remote oil pump.
Temperature and humidity sensors in an air-conditioning unit.
An accelerometer in an elevator.
Presence sensors in a room.
There's a wide variety of devices available from different manufacturers to build your solution. For a list of devices
certified to work with Azure IoT Hub, see the Azure Certified for IoT device catalog. For prototyping, you can use
devices such as an MXChip IoT DevKit or a Raspberry Pi. The Devkit has built-in sensors for temperature, pressure,
humidity, and a gyroscope, accelerometer, and magnetometer. The Raspberry Pi lets you attach many different
types of sensor.
Microsoft provides open-source Device SDKs that you can use to build the apps that run on your devices. These
SDKs simplify and accelerate the development of your IoT solutions.

Communication
Typically, IoT devices send telemetry from the sensors to back-end services in the cloud. However, other types of
communication are possible such as a back-end service sending commands to your devices. The following are
some examples of device-to-cloud and cloud-to-device communication:
A mobile refrigeration truck sends temperature every 5 minutes to an IoT Hub.
The back-end service sends a command to a device to change the frequency at which it sends telemetry to
help diagnose a problem.
A device sends alerts based on the values read from its sensors. For example, a device monitoring a batch
reactor in a chemical plant, sends an alert when the temperature exceeds a certain value.
Your devices send information to display on a dashboard for viewing by human operators. For example, a
control room in a refinery may show the temperature, pressure, and flow volumes in each pipe, enabling
operators to monitor the facility.
The IoT Device SDKs and IoT Hub support common communication protocols such as HTTP, MQTT, and AMQP.
IoT devices have different characteristics when compared to other clients such as browsers and mobile apps. The
device SDKs help you address the challenges of connecting devices securely and reliably to your back-end service.
Specifically, IoT devices:
Are often embedded systems with no human operator (unlike a phone).
Can be deployed in remote locations, where physical access is expensive.
 May only be reachable through the solution back end.
May have limited power and processing resources.
May have intermittent, slow, or expensive network connectivity.
May need to use proprietary, custom, or industry-specific application protocols.

Back-end services
In an IoT solution, the back-end service provides functionality such as:
Receiving telemetry at scale from your devices, and determining how to process and store that data.
Analyzing the telemetry to provide insights, either in real time or after the fact.
Sending commands from the cloud to a specific device.
Provisioning devices and controlling which devices can connect to your infrastructure.
Controlling the state of your devices and monitoring their activities.
Managing the firmware installed on your devices.
For example, in a remote monitoring solution for an oil pumping station, the cloud back end uses telemetry from
the pumps to identify anomalous behavior. When the back-end service identifies an anomaly, it can automatically
send a command back to the device to take a corrective action. This process generates an automated feedback loop
between the device and the cloud that greatly increases the solution efficiency.

Azure IoT examples

For real-life examples of how organizations use Azure IoT, see Microsoft Technical Case Studies for IoT.

Next steps
For some actual business cases and the architecture used, see the Microsoft Azure IoT Technical Case Studies.
For some sample projects that you can try out with an IoT DevKit, see the IoT DevKit Project Catalog.
For a more comprehensive explanation of the different services and how they're used, see Azure IoT services and
technologies.
For an in-depth discussion of IoT architecture, see the Microsoft Azure IoT Reference Architecture.
 Choose the right IoT solution
2/5/2020 • 2 minutes to read • Edit Online

To build an IoT solution for your business, you typically choose to use either the platform services or the managed
app platform approach.
Platform services provide the building blocks for customized and flexible IoT applications. You have more options
to choose and code when you connect devices, and ingest, store, and analyze your data. Azure IoT platform services
include the products Azure IoT Hub and Azure Digital Twins.
A managed app platform lets you get started building apps more quickly than platform services by reducing the
number of decisions needed to achieve results. The managed app platform takes care of most elements of your
solution, so you can focus on adding industry knowledge, and scaling and connecting devices. Azure IoT Central is a
managed app platform.
To choose between these two approaches, you should consider:
How you want to manage your solution.
What level of customization and control you want over your solution.
What pricing structure you want.

Management
Where do you want to spend your system management time and resources?
Choose the platform services approach to have full control over the underlying services in your solution. For
example, you want to:
Manage scaling and securing services to meet your needs.
Make use of in-house or partner expertise to onboard devices and provision services.
Choose the managed app platform approach to take advantage of a platform that handles scale, security,
and management of your IoT applications and devices.

Control
What elements of your solution do you want to customize?
Choose the platform services approach for total customization and control over the solution architecture.
Choose the managed app platform approach to customize branding, dashboards, user roles, devices, and
telemetry. However, you don't want to handle the underlying IoT system management overhead.

Pricing
What pricing structure best fits your needs?
Choose the platform services approach to fine-tune services and control my overall costs.
Choose the managed app platform approach for a simple, predictable pricing structure.

Summary
The platform services approach is appropriate for a business with cloud solution and device expertise that wants to:
 Fine-tune the services in the solution.
Have a high degree of control over the services in the solution.
Fully customize the solution.
The managed app platform approach is appropriate for a business that:
Doesn't want to dedicate extensive resources to system design, development, and management.
Does want a predictable pricing structure.
Does want some customization capabilities.

Next steps
For a more comprehensive explanation of the different services and platforms, and how they're used, see Azure IoT
services and technologies.
To learn more about the key attributes of successful IoT solutions, see the 8 attributes of successful IoT solutions
white paper.
For an in-depth discussion of IoT architecture, see the Microsoft Azure IoT Reference Architecture.
 Azure technologies and services for creating IoT
solutions
2/5/2020 • 5 minutes to read • Edit Online

Azure IoT technologies and services provide you with options to create a wide variety of IoT solutions that enable
digital transformation for your organization. For example, you can:
Use Azure IoT Central, a managed IoT application platform, to build and deploy a secure, enterprise-grade IoT
solution. IoT Central features a collection of industry-specific application templates, such as retail and
healthcare, to accelerate your solution development process.
Extend the open-source code base for an Azure IoT solution accelerator to implement a common IoT scenario
such as remote monitoring or predictive maintenance.
Use Azure IoT platform services such as Azure IoT Hub and the Azure IoT device SDKs to build a custom IoT
solution from scratch.

Azure IoT Central

The IoT Central application platform reduces the burden and cost of developing, managing, and maintaining
enterprise-grade IoT solutions. IoT Central's customizable web UI in lets you monitor device conditions, create
rules, and manage millions of devices and their data throughout their life cycle. The API surface within IoT Central
gives you programmatic access to configure and interact with your IoT solution.
Azure IoT Central is a fully managed application platform that you can use to create custom IoT solutions. IoT
Central uses application templates to create solutions. There are templates for generic solutions and for specific
industries such as energy, healthcare, government, and retail. IoT Central application templates let you deploy an
IoT Central application in minutes that you can then customize with themes, dashboards, and views.
Choose devices from the Azure Certified for IoT device catalog to quickly connect to your solution. Use the IoT
Central web UI to monitor and manage your devices to keep them healthy and connected. Use connectors and APIs
to integrate your IoT Central application with other business applications.
As a fully managed application platform, IoT Central has a simple, predictable pricing model.

Azure IoT solution accelerators

The Azure IoT solution accelerators are a collection of customizable enterprise-grade solutions. You can deploy
these solutions as they are, or develop a custom IoT solution using the open-source Java or .NET source code.
Azure IoT solution accelerators provide a high level of control over your IoT solution. The solution accelerators
include prebuilt solutions for common IoT scenarios that you can deploy to your Azure subscription in minutes.
The scenarios include:
Remote monitoring
Connected factory
Predictive maintenance
Device simulation
The open-source code base for all the solution accelerators is available on GitHub. Download the code to
customize a solution accelerator to meet your specific IoT requirements.
The solution accelerators use Azure services such as Azure IoT Hub and Azure Storage that you must manage in
your Azure subscription.

Custom solutions
To build an IoT solution from scratch, or extend a solution created using IoT Central or a solution accelerator, use
one or more of the following Azure IoT technologies and services:
Devices
Develop your IoT devices using one of the Azure IoT Starter Kits or choose a device to use from the Azure Certified
for IoT device catalog. Implement your embedded code using the open-source device SDKs. The device SDKs
support multiple operating systems, such as Linux, Windows, and real-time operating systems. There are SDKs for
multiple programming languages, such as C, Node.js, Java, .NET, and Python.
You can further simplify how you create the embedded code for your devices by using the IoT Plug and Play
Preview service. IoT Plug and Play enables solution developers to integrate devices with their solutions without
writing any embedded code. At the core of IoT Plug and Play, is a device capability model schema that describes
device capabilities. Use the device capability model to generate your embedded device code and configure a cloud-
based solution such as an IoT Central application.
Azure IoT Edge lets you offload parts of your IoT workload from your Azure cloud services to your devices. IoT
Edge can reduce latency in your solution, reduce the amount of data your devices exchange with the cloud, and
enable off-line scenarios. You can manage IoT Edge devices from IoT Central and some solution accelerators.
Azure Sphere is a secured, high-level application platform with built-in communication and security features for
internet-connected devices. It includes a secured microcontroller unit, a custom Linux-based operating system, and
a cloud-based security service that provides continuous, renewable security.
Cloud connectivity
The Azure IoT Hub service enables reliable and secure bidirectional communications between millions of IoT
devices and a cloud-based solution. Azure IoT Hub Device Provisioning Service is a helper service for IoT Hub. The
service provides zero-touch, just-in-time provisioning of devices to the right IoT hub without requiring human
intervention. These capabilities enable customers to provision millions of devices in a secure and scalable manner.
IoT Hub is a core component of the solution accelerators and you can use it to meet IoT implementation challenges
such as:
 High-volume device connectivity and management.
High-volume telemetry ingestion.
Command and control of devices.
Device security enforcement.
Bridging the gap between the physical and digital worlds
Azure Digital Twins is an IoT service that enables you to model a physical environment. It uses a spatial intelligence
graph to model the relationships between people, spaces, and devices. By corelating data across the digital and
physical worlds you can create contextually aware solutions.
Iot Central uses digital twins to synchronize devices and data in the real world with the digital models that enable
users to monitor and manage those connected devices.
Data and analytics
IoT devices typically generate large amounts of time series data, such as temperature readings from sensors. Azure
Time Series Insights can connect to an IoT hub, read the telemetry stream from your devices, store that data, and
enable you to query and visualize it.
Azure Maps is a collection of geospatial services that use fresh mapping data to provide accurate geographic
context to web and mobile applications. You can use a REST API, a web-based JavaScript control, or an Android
SDK to build your applications.

Next steps
For a hands-on experience, try one of the quickstarts:
Create an Azure IoT Central application
Send telemetry from a device to an IoT hub
Try a cloud-based remote monitoring solution
 Azure IoT support and help options
9/22/2020 • 2 minutes to read • Edit Online

Here are suggestions for where you can get help when developing your Azure IoT solutions.

Create an Azure support request

Explore the range of Azure support options and choose the plan that best fits, whether you're a developer just
starting your cloud journey or a large organization deploying business-critical, strategic applications. Azure
customers can create and manage support requests in the Azure portal.
Azure portal
Azure portal for the United States government

Post a question on Microsoft Q&A

For quick and reliable answers on your technical product questions from Microsoft Engineers, Azure Most Valuable
Professionals (MVPs), or our expert community, engage with us on Microsoft Q&A, Azure’s preferred destination
for community support.
If you can't find an answer to your problem using search, submit a new question to Microsoft Q&A. Use one of the
following tags when you ask your question:
Azure IoT
Azure IoT Central
Azure IoT Edge
Azure IoT Hub
Azure IoT Hub Device Provisioning Service (DPS)
Azure IoT SDKs
Azure Digital Twins
Azure RTOS
Azure Sphere
Azure Time Series Insights
Azure Maps

Post a question on Stack Overflow

For answers on your developer questions from the largest community developer ecosystem, ask your question on
Stack Overflow.
If you do submit a new question to Stack Overflow, please use one or more of the following tags when you create
the question:
Azure IoT Central
Azure IoT Edge
Azure IoT Hub
Azure IoT SDKs
 Azure Digital Twins
Azure RTOS
Azure Sphere
Azure Time Series Insights
Azure Maps

Submit feedback on Azure Feedback

To request new features, post them on Azure Feedback. Share your ideas for making Azure IoT services work better
for the applications you develop:

SERVIC E A Z URE F EEDB A C K URL

Azure IoT (Hub, DPS, SDKs) https://feedback.azure.com/forums/321918-azure-iot

Azure IoT Central https://feedback.azure.com/forums/911455-azure-iot-central

Azure IoT Device Catalog https://feedback.azure.com/forums/916948-azure-iot-device-

catalog

Azure IoT Edge https://feedback.azure.com/forums/907045-azure-iot-edge

Azure IoT Solution Accelerators https://feedback.azure.com/forums/916438-azure-iot-

solution-accelerators

Azure Maps https://feedback.azure.com/forums/909172-azure-maps

Azure Time Series Insights https://feedback.azure.com/forums/906859-azure-time-

series-insights

Azure Digital Twins https://feedback.azure.com/forums/916621-azure-digital-

twins

Azure Sphere https://feedback.azure.com/forums/915433-azure-sphere

Stay informed of updates and new releases

Learn about important product updates, roadmap, and announcements in Azure Updates.
News and information about Azure IoT is shared at the Azure blog and on the Internet of Things Show on Channel
9.
Also, share your experiences, engage and learn from experts in the Internet of Things Tech Community.

Next steps
What is Azure IoT?
 Security recommendations for Azure Internet of
Things (IoT) deployment
4/21/2020 • 3 minutes to read • Edit Online

This article contains security recommendations for IoT. Implementing these recommendations will help you fulfill
your security obligations as described in our shared responsibility model. For more information on what Microsoft
does to fulfill service provider responsibilities, read Shared responsibilities for cloud computing.
Some of the recommendations included in this article can be automatically monitored by Azure Security Center.
Azure Security Center is the first line of defense in protecting your resources in Azure. It periodically analyzes the
security state of your Azure resources to identify potential security vulnerabilities. It then provides you with
recommendations on how to address them.
For more information on Azure Security Center recommendations, see Security recommendations in Azure
Security Center.
For information on Azure Security Center see the What is Azure Security Center?

General
REC O M M EN DAT IO N C O M M EN T S SUP P O RT ED B Y A SC

Stay up-to-date Use the latest versions of supported -

platforms, programming languages,
protocols, and frameworks.

Keep authentication keys safe Keep the device IDs and their -
authentication keys physically safe after
deployment. This will avoid a malicious
device masquerade as a registered
device.

Use device SDKs when possible Device SDKs implement a variety of -

security features, such as, encryption,
authentication, and so on, to assist you
in developing a robust and secure
device application. See Understand and
use Azure IoT Hub SDKs for more
information.

Identity and access management

REC O M M EN DAT IO N C O M M EN T S SUP P O RT ED B Y A SC
 REC O M M EN DAT IO N C O M M EN T S SUP P O RT ED B Y A SC

Define access control for the hub Understand and define the type of -
access each component will have in
your IoT Hub solution, based on the
functionality. The allowed permissions
are Registry Read, RegistryReadWrite,
ServiceConnect, and DeviceConnect.
Default shared access policies in your
IoT hub can also help define the
permissions for each component based
on its role.

Define access control for backend Data ingested by your IoT Hub solution -
services can be consumed by other Azure
services such as Cosmos DB, Stream
Analytics, App Service, Logic Apps, and
Blob storage. Make sure to understand
and allow appropriate access
permissions as documented for these
services.

Data protection
REC O M M EN DAT IO N C O M M EN T S SUP P O RT ED B Y A SC

Secure device authentication Ensure secure communication between -

your devices and your IoT hub, by using
either a unique identity key or security
token, or an on-device X.509 certificate
for each device. Use the appropriate
method to use security tokens based on
the chosen protocol (MQTT, AMQP, or
HTTPS).

Secure device communication IoT Hub secures the connection to the -

devices using Transport Layer Security
(TLS) standard, supporting versions 1.2
and 1.0. Use TLS 1.2 to ensure
maximum security.

Secure service communication IoT Hub provides endpoints to connect -

to backend services such as Azure
Storage or Event Hubs using only the
TLS protocol, and no endpoint is
exposed on an unencrypted channel.
Once this data reaches these backend
services for storage or analysis, make
sure to employ appropriate security and
encryption methods for that service,
and protect sensitive information at the
backend.

Networking
REC O M M EN DAT IO N C O M M EN T S SUP P O RT ED B Y A SC
 REC O M M EN DAT IO N C O M M EN T S SUP P O RT ED B Y A SC

Protect access to your devices Keep hardware ports in your devices to -

a bare minimum to avoid unwanted
access. Additionally, build mechanisms
to prevent or detect physical tampering
of the device. Read IoT security best
practices for details.

Build secure hardware Incorporate security features such as -

encrypted storage, or Trusted Platform
Module (TPM), to keep devices and
infrastructure more secure. Keep the
device operating system and drivers
upgraded to latest versions, and if space
permits, install antivirus and
antimalware capabilities. Read IoT
security architecture to understand how
this can help mitigate several security
threats.

Monitoring
REC O M M EN DAT IO N C O M M EN T S SUP P O RT ED B Y A SC

Monitor unauthorized access to your Use your device operating system's -

devices logging feature to monitor any security
breaches or physical tampering of the
device or its ports.

Monitor your IoT solution from the Monitor the overall health of your IoT -
cloud Hub solution using the metrics in Azure
Monitor.

Set up diagnostics Closely watch your operations by -

logging events in your solution, and
then sending the diagnostic logs to
Azure Monitor to get visibility into the
performance. Read Monitor and
diagnose problems in your IoT hub for
more information.

Next steps
For advanced scenarios involving Azure IoT, you may need to consider additional security requirements. See IoT
security architecture for more guidance.
 Security for Internet of Things (IoT) from the ground
up
10/22/2019 • 11 minutes to read • Edit Online

The Internet of Things (IoT) poses unique security, privacy, and compliance challenges to businesses worldwide.
Unlike traditional cyber technology where these issues revolve around software and how it is implemented, IoT
concerns what happens when the cyber and the physical worlds converge. Protecting IoT solutions requires
ensuring secure provisioning of devices, secure connectivity between these devices and the cloud, and secure data
protection in the cloud during processing and storage. Working against such functionality, however, are resource-
constrained devices, geographic distribution of deployments, and a large number of devices within a solution.
This article explores how the IoT solution accelerators provide a secure and private Internet of Things cloud
solution. The solution accelerators deliver a complete end-to-end solution, with security built into every stage from
the ground up. At Microsoft, developing secure software is part of the software engineering practice, rooted in
Microsoft's decades long experience of developing secure software. To ensure this, Security Development Lifecycle
(SDL) is the foundational development methodology, coupled with a host of infrastructure-level security services
such as Operational Security Assurance (OSA) and the Microsoft Digital Crimes Unit, Microsoft Security Response
Center, and Microsoft Malware Protection Center.
The solution accelerators offer unique features that make provisioning, connecting to, and storing data from IoT
devices easy and transparent and, most of all, secure. This article examines the Azure IoT solution accelerators
security features and deployment strategies to ensure security, privacy, and compliance challenges are addressed.

Introduction
The Internet of Things (IoT) is the wave of the future, offering businesses immediate and real-world opportunities
to reduce costs, increase revenue, and transform their business. Many businesses, however, are hesitant to deploy
IoT in their organizations due to concerns about security, privacy, and compliance. A major point of concern comes
from the uniqueness of the IoT infrastructure, which merges the cyber and physical worlds together, compounding
individual risks inherent in these two worlds. Security of IoT pertains to ensuring the integrity of code running on
devices, providing device and user authentication, defining clear ownership of devices (as well as data generated by
those devices), and being resilient to cyber and physical attacks.
Then, there’s the issue of privacy. Companies want transparency concerning data collection, as in what’s being
collected and why, who can see it, who controls access, and so on. Finally, there are general safety issues of the
equipment along with the people operating them, and issues of maintaining industry standards of compliance.
Given the security, privacy, transparency, and compliance concerns, choosing the right IoT solution provider
remains a challenge. Stitching together individual pieces of IoT software and services provided by a variety of
vendors introduces gaps in security, privacy, transparency, and compliance, which may be hard to detect, let alone
fix. The choice of the right IoT software and service provider is based on finding providers that have extensive
experience running services, which span across verticals and geographies, but are also able to scale in a secure and
transparent fashion. Similarly, it helps for the selected provider to have decades of experience with developing
secure software running on billions of machines worldwide, and have the ability to appreciate the threat landscape
posed by this new world of the Internet of Things.

Secure infrastructure from the ground up

The Microsoft Cloud infrastructure supports more than one billion customers in 127 countries/regions. Drawing on
Microsoft's decades-long experience building enterprise software and running some of the largest online services
in the world, the Microsoft Cloud provides higher levels of enhanced security, privacy, compliance, and threat
mitigation practices than most customers could achieve on their own.
The Security Development Lifecycle (SDL) provides a mandatory company-wide development process that embeds
security requirements into the entire software lifecycle. To help ensure that operational activities follow the same
level of security practices, SDL uses rigorous security guidelines laid out in Microsoft's Operational Security
Assurance (OSA) process. Microsoft also works with third-party audit firms for ongoing verification that it meets its
compliance obligations, and Microsoft engages in broad security efforts through the creation of centers of
excellence, including the Microsoft Digital Crimes Unit, Microsoft Security Response Center, and Microsoft Malware
Protection Center.

Microsoft Azure - secure IoT infrastructure for your business

Microsoft Azure offers a complete cloud solution, one that combines a constantly growing collection of integrated
cloud services—analytics, machine learning, storage, security, networking, and web—with an industry-leading
commitment to the protection and privacy of your data. Microsoft's assume breach strategy uses a dedicated red
team of software security experts who simulate attacks, testing the ability of Azure to detect, protect against
emerging threats, and recover from breaches. Microsoft's global incident response team works around the clock to
mitigate the effects of attacks and malicious activity. The team follows established procedures for incident
management, communication, and recovery, and uses discoverable and predictable interfaces with internal and
external partners.
Microsoft's systems provide continuous intrusion detection and prevention, service attack prevention, regular
penetration testing, and forensic tools that help identify and mitigate threats. Multi-factor authentication provides
an extra layer of security for end users to access the network. And for the application and the host provider,
Microsoft offers access control, monitoring, anti-malware, vulnerability scanning, patches, and configuration
management.
The solution accelerators take advantage of the security and privacy built into the Azure platform along with the
SDL and OSA processes for secure development and operation of all Microsoft software. These procedures provide
infrastructure protection, network protection, and identity and management features fundamental to the security of
any solution.
The Azure IoT Hub within the IoT solution accelerators offers a fully-managed service that enables reliable and
secure bi-directional communication between IoT devices and Azure services such as Azure Machine Learning and
Azure Stream Analytics by using per-device security credentials and access control.
To best communicate security and privacy features built into the Azure IoT solution accelerators, this article breaks
down the suite into the three primary security areas.
Secure device provisioning and authentication
The solution accelerators secure devices while they are out in the field by providing a unique identity key for each
device, which can be used by the IoT infrastructure to communicate with the device while it is in operation. The
process is quick and easy to set up. The generated key with a user-selected device ID forms the basis of a token
used in all communication between the device and the Azure IoT Hub.
Device IDs can be associated with a device during manufacturing (that is, flashed in a hardware trust module) or
can use an existing fixed identity as a proxy (for example CPU serial numbers). Since changing this identifying
information in the device is not simple, it is important to introduce logical device IDs in case the underlying device
hardware changes but the logical device remains the same. In some cases, the association of a device identity can
happen at device deployment time (for example, an authenticated field engineer physically configures a new device
while communicating with the solution backend). The Azure IoT Hub identity registry provides secure storage of
device identities and security keys for a solution. Individual or groups of device identities can be added to an allow
list, or a block list, enabling complete control over device access.
Azure IoT Hub access control policies in the cloud enable activation and disabling any device identity, providing a
way to disassociate a device from an IoT deployment when required. This association and disassociation of devices
is based on each device identity.
Additional device security features include:
Devices do not accept unsolicited network connections. They establish all connections and routes in an
outbound-only fashion. For a device to receive a command from the backend, the device must initiate a
connection to check for any pending commands to process. Once a connection between the device and IoT
Hub is securely established, messaging from the cloud to the device and device to the cloud can be sent
transparently.
Devices only connect to or establish routes to well-known services with which they are peered, such as an
Azure IoT Hub.
System-level authorization and authentication use per-device identities, making access credentials and
permissions near-instantly revocable.
Secure connectivity
Durability of messaging is an important feature of any IoT solution. The need to durably deliver commands and/or
receive data from devices is underlined by the fact that IoT devices are connected over the Internet, or other similar
networks that can be unreliable. Azure IoT Hub offers durability of messaging between cloud and devices through a
system of acknowledgments in response to messages. Additional durability for messaging is achieved by caching
messages in the IoT Hub for up to seven days for telemetry and two days for commands.
Efficiency is important to ensure conservation of resources and operation in a resource-constrained environment.
HTTPS (HTTP Secure), the industry-standard secure version of the popular http protocol, is supported by Azure IoT
Hub, enabling efficient communication. Advanced Message Queuing Protocol (AMQP) and Message Queuing
Telemetry Transport (MQTT), supported by Azure IoT Hub, are designed not only for efficiency in terms of resource
use but also reliable message delivery.
Scalability requires the ability to securely interoperate with a wide range of devices. Azure IoT hub enables secure
connection to both IP-enabled and non-IP-enabled devices. IP-enabled devices are able to directly connect and
communicate with the IoT Hub over a secure connection. Non-IP-enabled devices are resource-constrained and
connect only over short distance communication protocols, such as Zwave, ZigBee, and Bluetooth. A field gateway
is used to aggregate these devices and performs protocol translation to enable secure bi-directional
communication with the cloud.
Additional connection security features include:
The communication path between devices and Azure IoT Hub, or between gateways and Azure IoT Hub, is
 secured using industry-standard Transport Layer Security (TLS) with Azure IoT Hub authenticated using
X.509 protocol.
In order to protect devices from unsolicited inbound connections, Azure IoT Hub does not open any
connection to the device. The device initiates all connections.
Azure IoT Hub durably stores messages for devices and waits for the device to connect. These commands are
stored for two days, enabling devices connecting sporadically, due to power or connectivity concerns, to
receive these commands. Azure IoT Hub maintains a per-device queue for each device.
Secure processing and storage in the cloud
From encrypted communications to processing data in the cloud, the solution accelerators help keep data secure. It
provides flexibility to implement additional encryption and management of security keys.
Using Azure Active Directory (AAD) for user authentication and authorization, Azure IoT solution accelerators can
provide a policy-based authorization model for data in the cloud, enabling easy access management that can be
audited and reviewed. This model also enables near-instant revocation of access to data in the cloud, and of devices
connected to the Azure IoT solution accelerators.
Once data is in the cloud, it can be processed and stored in any user-defined workflow. Access to each part of the
data is controlled with Azure Active Directory, depending on the storage service used.
All keys used by the IoT infrastructure are stored in the cloud in secure storage, with the ability to roll over in case
keys need to be reprovisioned. Data can be stored in Azure Cosmos DB or in SQL Database, enabling definition of
the level of security desired. Additionally, Azure provides a way to monitor and audit all access to your data to alert
you of any intrusion or unauthorized access.

Conclusion
The Internet of Things starts with your things—the things that matter most to businesses. IoT can deliver amazing
value to a business by reducing costs, increasing revenue, and transforming business. Success of this
transformation largely depends on choosing the right IoT software and service provider. That means finding a
provider that not only catalyzes this transformation by understanding business needs and requirements, but also
provides services and software built with security, privacy, transparency, and compliance as major design
considerations. Microsoft has extensive experience with developing and deploying secure software and services
and continues to be a leader in this new age of Internet of Things.
The solution accelerators build in security measures by design, enabling secure monitoring of assets to improve
efficiencies, drive operational performance to enable innovation, and employ advanced data analytics to transform
businesses. With its layered approach towards security, multiple security features, and design patterns, the solution
accelerators help deploy an infrastructure that can be trusted to transform any business.

Additional information
Each solution accelerator creates instances of Azure services, such as:
Azure IoT Hub : Your gateway that connects the cloud to devices. You can scale to millions of connections
per hub and process massive volumes of data with per-device authentication support helping you secure
your solution.
Azure Cosmos DB : A scalable, fully-indexed database service for semi-structured data that manages
metadata for the devices you provision, such as attributes, configuration, and security properties. Azure
Cosmos DB offers high-performance and high-throughput processing, schema-agnostic indexing of data,
and a rich SQL query interface.
Azure Stream Analytics : Real-time stream processing in the cloud that enables you to rapidly develop and
deploy a low-cost analytics solution to uncover real-time insights from devices, sensors, infrastructure, and
 applications. The data from this fully-managed service can scale to any volume while still achieving high
throughput, low latency, and resiliency.
Azure App Ser vices : A cloud platform to build powerful web and mobile apps that connect to data
anywhere; in the cloud or on-premises. Build engaging mobile apps for iOS, Android, and Windows.
Integrate with your Software as a Service (SaaS) and enterprise applications with out-of-the-box connectivity
to dozens of cloud-based services and enterprise applications. Code in your favorite language and IDE
—.NET, Node.js, PHP, Python, or Java—to build web apps and APIs faster than ever.
Logic Apps : The Logic Apps feature of Azure App Service helps integrate your IoT solution to your existing
line-of-business systems and automate workflow processes. Logic Apps enables developers to design
workflows that start from a trigger and then execute a series of steps—rules and actions that use powerful
connectors to integrate with your business processes. Logic Apps offers out-of-the-box connectivity to a vast
ecosystem of SaaS, cloud-based, and on-premises applications.
Azure Blob storage : Reliable, economical cloud storage for the data that your devices send to the cloud.

Next steps
Read about IoT Hub security in Control access to IoT Hub in the IoT Hub developer guide.
 Security best practices for Internet of Things (IoT)
11/12/2019 • 6 minutes to read • Edit Online

Securing an Internet of Things (IoT) infrastructure requires a rigorous security-in-depth strategy. This strategy
requires you to secure data in the cloud, protect data integrity while in transit over the public internet, and securely
provision devices. Each layer builds greater security assurance in the overall infrastructure.

Secure an IoT infrastructure

This security-in-depth strategy can be developed and executed with active participation of various players involved
with the manufacturing, development, and deployment of IoT devices and infrastructure. Following is a high-level
description of these players.
IoT hardware manufacturer/integrator : Typically, these players are the manufacturers of IoT hardware
being deployed, integrators assembling hardware from various manufacturers, or suppliers providing
hardware for an IoT deployment manufactured or integrated by other suppliers.
IoT solution developer : The development of an IoT solution is typically done by a solution developer. This
developer may part of an in-house team or a system integrator (SI) specializing in this activity. The IoT
solution developer can develop various components of the IoT solution from scratch, integrate various off-
the-shelf or open-source components, or adopt solution accelerators with minor adaptation.
IoT solution deployer : After an IoT solution is developed, it needs to be deployed in the field. This process
involves deployment of hardware, interconnection of devices, and deployment of solutions in hardware
devices or the cloud.
IoT solution operator : After the IoT solution is deployed, it requires long-term operations, monitoring,
upgrades, and maintenance. These tasks can be done by an in-house team that comprises information
technology specialists, hardware operations and maintenance teams, and domain specialists who monitor
the correct behavior of overall IoT infrastructure.
The sections that follow provide best practices for each of these players to help develop, deploy, and operate a
secure IoT infrastructure.

IoT hardware manufacturer/integrator

The following are the best practices for IoT hardware manufacturers and hardware integrators.
Scope hardware to minimum requirements : The hardware design should include the minimum
features required for operation of the hardware, and nothing more. An example is to include USB ports only
if necessary for the operation of the device. These additional features open the device for unwanted attack
vectors that should be avoided.
Make hardware tamper proof : Build in mechanisms to detect physical tampering, such as opening of the
device cover or removing a part of the device. These tamper signals may be part of the data stream
uploaded to the cloud, which could alert operators of these events.
Build around secure hardware : If COGS permits, build security features such as secure and encrypted
storage, or boot functionality based on Trusted Platform Module (TPM). These features make devices more
secure and help protect the overall IoT infrastructure.
Make upgrades secure : Firmware upgrades during the lifetime of the device are inevitable. Building
devices with secure paths for upgrades and cryptographic assurance of firmware versions will allow the
 device to be secure during and after upgrades.

IoT solution developer

The following are the best practices for IoT solution developers:
Follow secure software development methodology : Development of secure software requires
ground-up thinking about security, from the inception of the project all the way to its implementation,
testing, and deployment. The choices of platforms, languages, and tools are all influenced with this
methodology. The Microsoft Security Development Lifecycle provides a step-by-step approach to building
secure software.
Choose open-source software with care : Open-source software provides an opportunity to quickly
develop solutions. When you're choosing open-source software, consider the activity level of the community
for each open-source component. An active community ensures that software is supported and that issues
are discovered and addressed. Alternatively, an obscure and inactive open-source software project might not
be supported and issues are not likely be discovered.
Integrate with care : Many software security flaws exist at the boundary of libraries and APIs. Functionality
that may not be required for the current deployment might still be available via an API layer. To ensure
overall security, make sure to check all interfaces of components being integrated for security flaws.

IoT solution deployer

The following are best practices for IoT solution deployers:
Deploy hardware securely : IoT deployments may require hardware to be deployed in unsecure locations,
such as in public spaces or unsupervised locales. In such situations, ensure that hardware deployment is
tamper-proof to the maximum extent. If USB or other ports are available on the hardware, ensure that they
are covered securely. Many attack vectors can use these as entry points.
Keep authentication keys safe : During deployment, each device requires device IDs and associated
authentication keys generated by the cloud service. Keep these keys physically safe even after the
deployment. Any compromised key can be used by a malicious device to masquerade as an existing device.

IoT solution operator

The following are the best practices for IoT solution operators:
Keep the system up-to-date : Ensure that device operating systems and all device drivers are upgraded to
the latest versions. If you turn on automatic updates in Windows 10 (IoT or other SKUs), Microsoft keeps it
up-to-date, providing a secure operating system for IoT devices. Keeping other operating systems (such as
Linux) up-to-date helps ensure that they are also protected against malicious attacks.
Protect against malicious activity : If the operating system permits, install the latest antivirus and
antimalware capabilities on each device operating system. This practice can help mitigate most external
threats. You can protect most modern operating systems against threats by taking appropriate steps.
Audit frequently : Auditing IoT infrastructure for security-related issues is key when responding to security
incidents. Most operating systems provide built-in event logging that should be reviewed frequently to
make sure no security breach has occurred. Audit information can be sent as a separate telemetry stream to
the cloud service where it can be analyzed.
Physically protect the IoT infrastructure : The worst security attacks against IoT infrastructure are
launched using physical access to devices. One important safety practice is to protect against malicious use
of USB ports and other physical access. One key to uncovering breaches that might have occurred is logging
of physical access, such as USB port use. Again, Windows 10 (IoT and other SKUs) enables detailed logging
 of these events.
Protect cloud credentials : Cloud authentication credentials used for configuring and operating an IoT
deployment are possibly the easiest way to gain access and compromise an IoT system. Protect the
credentials by changing the password frequently, and refrain from using these credentials on public
machines.
Capabilities of different IoT devices vary. Some devices might be computers running common desktop operating
systems, and some devices might be running very light-weight operating systems. The security best practices
described previously might be applicable to these devices in varying degrees. If provided, additional security and
deployment best practices from the manufacturers of these devices should be followed.
Some legacy and constrained devices might not have been designed specifically for IoT deployment. These devices
might lack the capability to encrypt data, connect with the Internet, or provide advanced auditing. In these cases, a
modern and secure field gateway can aggregate data from legacy devices and provide the security required for
connecting these devices over the Internet. Field gateways can provide secure authentication, negotiation of
encrypted sessions, receipt of commands from the cloud, and many other security features.

See also
To learn more about securing a solution created by an IoT solution accelerator, see Secure your IoT deployment.
Read about IoT Hub security in Control access to IoT Hub in the IoT Hub developer guide.
 Internet of Things (IoT) security architecture
11/12/2019 • 24 minutes to read • Edit Online

When designing a system, it is important to understand the potential threats to that system, and add appropriate
defenses accordingly, as the system is designed and architected. It is important to design the product from the
start with security in mind because understanding how an attacker might be able to compromise a system helps
make sure appropriate mitigations are in place from the beginning.

Security starts with a threat model

Microsoft has long used threat models for its products and has made the company’s threat modeling process
publicly available. The company experience demonstrates that the modeling has unexpected benefits beyond the
immediate understanding of what threats are the most concerning. For example, it also creates an avenue for an
open discussion with others outside the development team, which can lead to new ideas and improvements in the
product.
The objective of threat modeling is to understand how an attacker might be able to compromise a system and then
make sure appropriate mitigations are in place. Threat modeling forces the design team to consider mitigations as
the system is designed rather than after a system is deployed. This fact is critically important, because retrofitting
security defenses to a myriad of devices in the field is infeasible, error prone and leaves customers at risk.
Many development teams do an excellent job capturing the functional requirements for the system that benefit
customers. However, identifying non-obvious ways that someone might misuse the system is more challenging.
Threat modeling can help development teams understand what an attacker might do and why. Threat modeling is
a structured process that creates a discussion about the security design decisions in the system, as well as changes
to the design that are made along the way that impact security. While a threat model is simply a document, this
documentation also represents an ideal way to ensure continuity of knowledge, retention of lessons learned, and
help new team onboard rapidly. Finally, an outcome of threat modeling is to enable you to consider other aspects
of security, such as what security commitments you wish to provide to your customers. These commitments in
conjunction with threat modeling inform and drive testing of your Internet of Things (IoT) solution.
When to do threat modeling
Threat modeling offers the greatest value when you incorporate it into the design phase. When you are designing,
you have the greatest flexibility to make changes to eliminate threats. Eliminating threats by design is the desired
outcome. It is much easier than adding mitigations, testing them, and ensuring they remain current and moreover,
such elimination is not always possible. It becomes harder to eliminate threats as a product becomes more mature,
and in turn ultimately requires more work and a lot harder tradeoffs than threat modeling early on in the
development.
What to consider for threat modeling
You should look at the solution as a whole and also focus on the following areas:
The security and privacy features
The features whose failures are security relevant
The features that touch a trust boundary
Who performs threat modeling
Threat modeling is a process like any other. It is a good idea to treat the threat model document like any other
component of the solution and validate it. Many development teams do an excellent job capturing the functional
requirements for the system that benefit customers. However, identifying non-obvious ways that someone might
misuse the system is more challenging. Threat modeling can help development teams understand what an attacker
might do and why.
How to perform threat modeling
The threat modeling process is composed of four steps; the steps are:
Model the application
Enumerate Threats
Mitigate threats
Validate the mitigations
The process steps
Three rules of thumb to keep in mind when building a threat model:
1. Create a diagram out of reference architecture.
2. Start breadth-first. Get an overview, and understand the system as a whole, before deep-diving. This
approach helps ensure that you deep-dive in the right places.
3. Drive the process, don’t let the process drive you. If you find an issue in the modeling phase and want to
explore it, go for it! Don’t feel you need to follow these steps slavishly.
Threats
The four core elements of a threat model are:
Processes such as web services, Win32 services, and *nix daemons. Some complex entities (for example
field gateways and sensors) can be abstracted as a process when a technical drill-down in these areas is not
possible.
Data stores (anywhere data is stored, such as a configuration file or database)
Data flow (where data moves between other elements in the application)
External Entities (anything that interacts with the system, but is not under the control of the application,
examples include users and satellite feeds)
All elements in the architectural diagram are subject to various threats; this article the STRIDE mnemonic. Read
Threat Modeling Again, STRIDE to know more about the STRIDE elements.
Different elements of the application diagram are subject to certain STRIDE threats:
Processes are subject to STRIDE
Data flows are subject to TID
Data stores are subject to TID, and sometimes R, when the data stores are log files.
External entities are subject to SRD

Security in IoT
Connected special-purpose devices have a significant number of potential interaction surface areas and interaction
patterns, all of which must be considered to provide a framework for securing digital access to those devices. The
term “digital access” is used here to distinguish from any operations that are carried out through direct device
interaction where access security is provided through physical access control. For example, putting the device into
a room with a lock on the door. While physical access cannot be denied using software and hardware, measures
can be taken to prevent physical access from leading to system interference.
As you explore the interaction patterns, look at “device control” and “device data” with the same level of attention.
“Device control” can be classified as any information that is provided to a device by any party with the goal of
changing or influencing its behavior towards its state or the state of its environment. “Device data” can be
classified as any information that a device emits to any other party about its state and the observed state of its
environment.
In order to optimize security best practices, it is recommended that a typical IoT architecture is divided into several
component/zones as part of the threat modeling exercise. These zones are described fully throughout this section
and include:
Device,
Field Gateway,
Cloud gateways, and
Services.
Zones are broad way to segment a solution; each zone often has its own data and authentication and authorization
requirements. Zones can also be used to isolation damage and restrict the impact of low trust zones on higher
trust zones.
Each zone is separated by a Trust Boundary, which is noted as the dotted red line in the following diagram. It
represents a transition of data/information from one source to another. During this transition, the data/information
could be subject to Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of
Privilege (STRIDE).

The components depicted within each boundary are also subjected to STRIDE, enabling a full 360 threat modeling
view of the solution. The following sections elaborate on each of the components and specific security concerns
and solutions that should be put into place.
The following sections discuss standard components typically found in these zones.
The device zone
The device environment is the immediate physical space around the device where physical access and/or “local
network” peer-to-peer digital access to the device is feasible. A “local network” is assumed to be a network that is
distinct and insulated from – but potentially bridged to – the public Internet, and includes any short-range wireless
radio technology that permits peer-to-peer communication of devices. It does not include any network
virtualization technology creating the illusion of such a local network and it does also not include public operator
networks that require any two devices to communicate across public network space if they were to enter a peer-to-
peer communication relationship.
The field gateway zone
Field gateway is a device/appliance or some general-purpose server computer software that acts as
communication enabler and, potentially, as a device control system and device data processing hub. The field
gateway zone includes the field gateway itself and all devices that are attached to it. As the name implies, field
gateways act outside dedicated data processing facilities, are usually location bound, are potentially subject to
physical intrusion, and has limited operational redundancy. All to say that a field gateway is commonly a thing one
can touch and sabotage while knowing what its function is.
A field gateway is different from a mere traffic router in that it has had an active role in managing access and
information flow, meaning it is an application addressed entity and network connection or session terminal. An
NAT device or firewall, in contrast, does not qualify as field gateways since they are not explicit connection or
session terminals, but rather a route (or block) connections or sessions made through them. The field gateway has
two distinct surface areas. One faces the devices that are attached to it and represents the inside of the zone, and
the other faces all external parties and is the edge of the zone.
The cloud gateway zone
A cloud gateway is a system that enables remote communication from and to devices or field gateways from
several different sites across public network space, typically towards a cloud-based control and data analysis
system, a federation of such systems. In some cases, a cloud gateway may immediately facilitate access to special-
purpose devices from terminals such as tablets or phones. In the context discussed here, “cloud” is meant to refer
to a dedicated data processing system that is not bound to the same site as the attached devices or field gateways.
Also in a Cloud Zone, operational measures prevent targeted physical access and are not necessarily exposed to a
“public cloud” infrastructure.
A cloud gateway may potentially be mapped into a network virtualization overlay to insulate the cloud gateway
and all of its attached devices or field gateways from any other network traffic. The cloud gateway itself is not a
device control system or a processing or storage facility for device data; those facilities interface with the cloud
gateway. The cloud gateway zone includes the cloud gateway itself along with all field gateways and devices
directly or indirectly attached to it. The edge of the zone is a distinct surface area where all external parties
communicate through.
The services zone
A “service” is defined for this context as any software component or module that is interfacing with devices
through a field- or cloud gateway for data collection and analysis, as well as for command and control. Services are
mediators. They act under their identity towards gateways and other subsystems, store and analyze data,
autonomously issue commands to devices based on data insights or schedules and expose information and
control capabilities to authorized end users.
Information-devices versus special-purpose devices
PCs, phones, and tablets are primarily interactive information devices. Phones and tablets are explicitly optimized
around maximizing battery lifetime. They preferably turn off partially when not immediately interacting with a
person, or when not providing services like playing music or guiding their owner to a particular location. From a
systems perspective, these information technology devices are mainly acting as proxies towards people. They are
“people actuators” suggesting actions and “people sensors” collecting input.
Special-purpose devices, from simple temperature sensors to complex factory production lines with thousands of
components inside them, are different. These devices are much more scoped in purpose and even if they provide
some user interface, they are largely scoped to interfacing with or be integrated into assets in the physical world.
They measure and report environmental circumstances, turn valves, control servos, sound alarms, switch lights,
and do many other tasks. They help to do work for which an information device is either too generic, too
expensive, too large, or too brittle. The concrete purpose immediately dictates their technical design as well the
available monetary budget for their production and scheduled lifetime operation. The combination of these two
key factors constrains the available operational energy budget, physical footprint, and thus available storage,
compute, and security capabilities.
If something “goes wrong” with automated or remote controllable devices, for example, physical defects or control
logic defects to willful unauthorized intrusion and manipulation. The production lots may be destroyed, buildings
may be looted or burned down, and people may be injured or even die. This is a whole different class of damage
than someone maxing out a stolen credit card's limit. The security bar for devices that make things move, and also
for sensor data that eventually results in commands that cause things to move, must be higher than in any e-
commerce or banking scenario.
Device control and device data interactions
Connected special-purpose devices have a significant number of potential interaction surface areas and interaction
patterns, all of which must be considered to provide a framework for securing digital access to those devices. The
term “digital access” is used here to distinguish from any operations that are carried out through direct device
interaction where access security is provided through physical access control. For example, putting the device into
a room with a lock on the door. While physical access cannot be denied using software and hardware, measures
can be taken to prevent physical access from leading to system interference.
As you explore the interaction patterns, look at “device control” and “device data” with the same level of attention
while threat modeling. “Device control” can be classified as any information that is provided to a device by any
party with the goal of changing or influencing its behavior towards its state or the state of its environment. “Device
data” can be classified as any information that a device emits to any other party about its state and the observed
state of its environment.

Performing threat modeling for the Azure IoT reference architecture

Microsoft uses the framework outlined previously to do threat modeling for Azure IoT. The following section uses
the concrete example of Azure IoT Reference Architecture to demonstrate how to think about threat modeling for
IoT and how to address the threats identified. This example identifies four main areas of focus:
Devices and Data Sources,
Data Transport,
Device and Event Processing, and
Presentation

The following diagram provides a simplified view of Microsoft’s IoT Architecture using a Data Flow Diagram model
that is used by the Microsoft Threat Modeling Tool:
It is important to note that the architecture separates the device and gateway capabilities. This approach enables
the user to leverage gateway devices that are more secure: they are capable of communicating with the cloud
gateway using secure protocols, which typically requires greater processing overhead that a native device - such as
a thermostat - could provide on its own. In the Azure services zone, assume that the Cloud Gateway is represented
by the Azure IoT Hub service.
Device and data sources/data transport
This section explores the architecture outlined previously through the lens of threat modeling and gives an
overview of how to address some of the inherent concerns. This example focuses on the core elements of a threat
model:
Processes (both under your control and external items)
Communication (also called data flows)
Storage (also called data stores)
Processes
In each of the categories outlined in the Azure IoT architecture, this example tries to mitigate a number of different
threats across the different stages data/information exists in: process, communication, and storage. Following is an
overview of the most common ones for the “process” category, followed by an overview of how these threats
could be best mitigated:
Spoofing (S) : An attacker may extract cryptographic key material from a device, either at the software or
hardware level, and subsequently access the system with a different physical or virtual device under the identity of
the device the key material has been taken from. A good illustration is remote controls that can turn any TV and
that are popular prankster tools.
Denial of Ser vice (D) : A device can be rendered incapable of functioning or communicating by interfering with
radio frequencies or cutting wires. For example, a surveillance camera that had its power or network connection
intentionally knocked out cannot report data, at all.
Tampering (T) : An attacker may partially or wholly replace the software running on the device, potentially
allowing the replaced software to leverage the genuine identity of the device if the key material or the
cryptographic facilities holding key materials were available to the illicit program. For example, an attacker may
leverage extracted key material to intercept and suppress data from the device on the communication path and
replace it with false data that is authenticated with the stolen key material.
Information Disclosure (I) : If the device is running manipulated software, such manipulated software could
potentially leak data to unauthorized parties. For example, an attacker may leverage extracted key material to inject
itself into the communication path between the device and a controller or field gateway or cloud gateway to
siphon off information.
Elevation of Privilege (E) : A device that does specific function can be forced to do something else. For example,
a valve that is programmed to open half way can be tricked to open all the way.

C O M P O N EN T T H REAT M IT IGAT IO N RISK IM P L EM EN TAT IO N

Device S Assigning identity to Replacing device or Authenticating the

the device and part of the device device, using
authenticating the with some other Transport Layer
device device. How do you Security (TLS) or
know you are talking IPSec. Infrastructure
to the right device? should support using
pre-shared key (PSK)
on those devices that
cannot handle full
asymmetric
cryptography.
Leverage Azure AD,
OAuth

TRID Apply tamperproof The risk is if someone The most effective

mechanisms to the is tampering the mitigation is a trusted
device, for example, device (physical platform module
by making it hard to interference). How are (TPM) capability that
impossible to extract you sure, that device allows storing keys in
keys and other has not been special on-chip
cryptographic tampered with. circuitry from which
material from the the keys cannot be
device. read, but can only be
used for
cryptographic
operations that use
the key but never
disclose the key.
Memory encryption
of the device. Key
management for the
device. Signing the
code.

E Having access control If the device allows for Having authorization

of the device. individual actions to scheme for the device
Authorization scheme. be performed based
on commands from
an outside source, or
even compromised
sensors, it allows the
attack to perform
operations not
otherwise accessible.

Field Gateway S Authenticating the If someone can spoof TLS RSA/PSK, IPSec,
Field gateway to Field Gateway, then it RFC 4279. All the
Cloud Gateway (such can present itself as same key storage and
as cert based, PSK, or any device. attestation concerns
Claim based.) of devices in general –
best case is use TPM.
6LowPAN extension
for IPSec to support
Wireless Sensor
Networks (WSN).
 C O M P O N EN T T H REAT M IT IGAT IO N RISK IM P L EM EN TAT IO N

TRID Protect the Field Spoofing attacks that Memory encryption,

Gateway against trick the cloud TPM’s, authentication.
tampering (TPM?) gateway thinking it is
talking to field
gateway could result
in information
disclosure and data
tampering

E Access control
mechanism for Field
Gateway

Here are some examples of threats in this category:

Spoofing : An attacker may extract cryptographic key material from a device, either at the software or hardware
level, and subsequently access the system with a different physical or virtual device under the identity of the device
the key material has been taken from.
Denial of Ser vice : A device can be rendered incapable of functioning or communicating by interfering with radio
frequencies or cutting wires. For example, a surveillance camera that had its power or network connection
intentionally knocked out cannot report data, at all.
Tampering : An attacker may partially or wholly replace the software running on the device, potentially allowing
the replaced software to leverage the genuine identity of the device if the key material or the cryptographic
facilities holding key materials were available to the illicit program.
Tampering : A surveillance camera that’s showing a visible-spectrum picture of an empty hallway could be aimed
at a photograph of such a hallway. A smoke or fire sensor could be reporting someone holding a lighter under it. In
either case, the device may be technically fully trustworthy towards the system, but it reports manipulated
information.
Tampering : An attacker may leverage extracted key material to intercept and suppress data from the device on the
communication path and replace it with false data that is authenticated with the stolen key material.
Tampering : An attacker may partially or completely replace the software running on the device, potentially
allowing the replaced software to leverage the genuine identity of the device if the key material or the
cryptographic facilities holding key materials were available to the illicit program.
Information Disclosure : If the device is running manipulated software, such manipulated software could
potentially leak data to unauthorized parties.
Information Disclosure : An attacker may leverage extracted key material to inject itself into the communication
path between the device and a controller or field gateway or cloud gateway to siphon off information.
Denial of Ser vice : The device can be turned off or turned into a mode where communication is not possible
(which is intentional in many industrial machines).
Tampering : The device can be reconfigured to operate in a state unknown to the control system (outside of known
calibration parameters) and thus provide data that can be misinterpreted
Elevation of Privilege : A device that does specific function can be forced to do something else. For example, a
valve that is programmed to open half way can be tricked to open all the way.
Denial of Ser vice : The device can be turned into a state where communication is not possible.
Tampering : The device can be reconfigured to operate in a state unknown to the control system (outside of known
calibration parameters) and thus provide data that can be misinterpreted.
Spoofing/Tampering/Repudiation : If not secured (which is rarely the case with consumer remote controls), an
attacker can manipulate the state of a device anonymously. A good illustration is remote controls that can turn any
TV and that are popular prankster tools.
Communication
Threats around communication path between devices, devices and field gateways, and device and cloud gateway.
The following table has some guidance around open sockets on the device/VPN:

C O M P O N EN T T H REAT M IT IGAT IO N RISK IM P L EM EN TAT IO N

Device IoT Hub TID (D)TLS (PSK/RSA) to Eavesdropping or Security on the

encrypt the traffic interfering the protocol level. With
communication custom protocols, you
between the device need to figure out
and the gateway how to protect them.
In most cases, the
communication takes
place from the device
to the IoT Hub (device
initiates the
connection).

Device to Device TID (D)TLS (PSK/RSA) to Reading data in Security on the

encrypt the traffic. transit between protocol level
devices. Tampering (MQTT/AMQP/HTTP/
with the data. CoAP. With custom
Overloading the protocols, you need
device with new to figure out how to
connections protect them. The
mitigation for the DoS
threat is to peer
devices through a
cloud or field gateway
and have them only
act as clients towards
the network. The
peering may result in
a direct connection
between the peers
after having been
brokered by the
gateway

External Entity Device TID Strong pairing of the Eavesdropping the Securely pairing the
external entity to the connection to the external entity to the
device device. Interfering the device NFC/Bluetooth
communication with LE. Controlling the
the device operational panel of
the device (Physical)

Field Gateway Cloud TID TLS (PSK/RSA) to Eavesdropping or Security on the

Gateway encrypt the traffic. interfering the protocol level
communication (MQTT/AMQP/HTTP/
between the device CoAP). With custom
and the gateway protocols, you need
to figure out how to
protect them.
 C O M P O N EN T T H REAT M IT IGAT IO N RISK IM P L EM EN TAT IO N

Device Cloud TID TLS (PSK/RSA) to Eavesdropping or Security on the

Gateway encrypt the traffic. interfering the protocol level
communication (MQTT/AMQP/HTTP/
between the device CoAP). With custom
and the gateway protocols, you need
to figure out how to
protect them.

Here are some examples of threats in this category:

Denial of Ser vice : Constrained devices are generally under DoS threat when they actively listen for inbound
connections or unsolicited datagrams on a network, because an attacker can open many connections in parallel
and not service them or service them slowly, or the device can be flooded with unsolicited traffic. In both cases, the
device can effectively be rendered inoperable on the network.
Spoofing, Information Disclosure : Constrained devices and special-purpose devices often have one-for-all
security facilities like password or PIN protection, or they wholly rely on trusting the network, meaning they grant
access to information when a device is on the same network, and that network is often only protected by a shared
key. That means that when the shared secret to device or network is disclosed, it is possible to control the device or
observe data emitted from the device.
Spoofing : an attacker may intercept or partially override the broadcast and spoof the originator (man in the
middle)
Tampering : an attacker may intercept or partially override the broadcast and send false information
Information Disclosure: an attacker may eavesdrop on a broadcast and obtain information without
authorization Denial of Ser vice: an attacker may jam the broadcast signal and deny information distribution
Storage
Every device and field gateway has some form of storage (temporary for queuing the data, operating system (OS)
image storage).

C O M P O N EN T T H REAT M IT IGAT IO N RISK IM P L EM EN TAT IO N

Device storage TRID Storage encryption, Reading data from the Encryption, message
signing the logs storage (PII data), authentication code
tampering with (MAC), or digital
telemetry data. signature. Where
Tampering with possible, strong
queued or cached access control
command control through resource
data. Tampering with access control lists
configuration or (ACLs) or permissions.
firmware update
packages while
cached or queued
locally can lead to OS
and/or system
components being
compromised

Device OS image TRID Tampering with OS Read-only OS

/replacing the OS partition, signed OS
components image, Encryption
 C O M P O N EN T T H REAT M IT IGAT IO N RISK IM P L EM EN TAT IO N

Field Gateway storage TRID Storage encryption, Reading data from the BitLocker
(queuing the data) signing the logs storage (PII data),
tampering with
telemetry data,
tampering with
queued or cached
command control
data. Tampering with
configuration or
firmware update
packages (destined
for devices or field
gateway) while cached
or queued locally can
lead to OS and/or
system components
being compromised

Field Gateway OS TRID Tampering with OS Read-only OS

image /replacing the OS partition, signed OS
components image, Encryption

Device and event processing/cloud gateway zone

A cloud gateway is a system that enables remote communication from and to devices or field gateways from
several different sites across public network space, typically towards a cloud-based control and data analysis
system, a federation of such systems. In some cases, a cloud gateway may immediately facilitate access to special-
purpose devices from terminals such as tablets or phones. In the context discussed here, “cloud” is meant to refer
to a dedicated data processing system that is not bound to the same site as the attached devices or field gateways,
and where operational measures prevent targeted physical access but is not necessarily to a “public cloud”
infrastructure. A cloud gateway may potentially be mapped into a network virtualization overlay to insulate the
cloud gateway and all of its attached devices or field gateways from any other network traffic. The cloud gateway
itself is not a device control system or a processing or storage facility for device data; those facilities interface with
the cloud gateway. The cloud gateway zone includes the cloud gateway itself along with all field gateways and
devices directly or indirectly attached to it.
Cloud gateway is mostly custom built piece of software running as a service with exposed endpoints to which field
gateway and devices connect. As such it must be designed with security in mind. Follow SDL process for designing
and building this service.
Services zone
A control system (or controller) is a software solution that interfaces with a device, or a field gateway, or cloud
gateway for the purpose of controlling one or multiple devices and/or to collect and/or store and/or analyze device
data for presentation, or subsequent control purposes. Control systems are the only entities in the scope of this
discussion that may immediately facilitate interaction with people. The exceptions are intermediate physical control
surfaces on devices, like a switch that allows a person to turn off the device or change other properties, and for
which there is no functional equivalent that can be accessed digitally.
Intermediate physical control surfaces are those where governing logic constrains the function of the physical
control surface such that an equivalent function can be initiated remotely or input conflicts with remote input can
be avoided – such intermediated control surfaces are conceptually attached to a local control system that leverages
the same underlying functionality as any other remote control system that the device may be attached to in
parallel. Top threats to the cloud computing can be read at Cloud Security Alliance (CSA) page.

Additional resources
For more information, see the following articles:
SDL Threat Modeling Tool
Microsoft Azure IoT reference architecture

See also
To learn more about securing a solution created by an IoT solution accelerator, see Secure your IoT deployment.
Read about IoT Hub security in Control access to IoT Hub in the IoT Hub developer guide.
 Secure your Internet of Things (IoT) deployment
11/7/2019 • 7 minutes to read • Edit Online

This article provides the next level of detail for securing the Azure IoT-based Internet of Things (IoT) infrastructure.
It links to implementation level details for configuring and deploying each component. It also provides
comparisons and choices between various competing methods.
Securing the Azure IoT deployment can be divided into the following three security areas:
Device Security : Securing the IoT device while it is deployed in the wild.
Connection Security : Ensuring all data transmitted between the IoT device and IoT Hub is confidential and
tamper-proof.
Cloud Security : Providing a means to secure data while it moves through, and is stored in the cloud.

Secure device provisioning and authentication

The IoT solution accelerators secure IoT devices using the following two methods:
By providing a unique identity key (security tokens) for each device, which can be used by the device to
communicate with the IoT Hub.
By using an on-device X.509 certificate and private key as a means to authenticate the device to the IoT Hub.
This authentication method ensures that the private key on the device is not known outside the device at
any time, providing a higher level of security.
The security token method provides authentication for each call made by the device to IoT Hub by associating the
symmetric key to each call. X.509-based authentication allows authentication of an IoT device at the physical layer
as part of the TLS connection establishment. The security-token-based method can be used without the X.509
authentication, which is a less secure pattern. The choice between the two methods is primarily dictated by how
secure the device authentication needs to be, and availability of secure storage on the device (to store the private
key securely).

IoT Hub security tokens

IoT Hub uses security tokens to authenticate devices and services to avoid sending keys on the network.
Additionally, security tokens are limited in time validity and scope. Azure IoT SDKs automatically generate tokens
without requiring any special configuration. Some scenarios, however, require the user to generate and use
security tokens directly. These scenarios include the direct use of the MQTT, AMQP, or HTTP surfaces, or the
implementation of the token service pattern.
More details on the structure of the security token and its usage can be found in the following articles:
Security token structure
Using SAS tokens as a device
Each IoT Hub has an identity registry that can be used to create per-device resources in the service, such as a
queue that contains in-flight cloud-to-device messages, and to allow access to the device-facing endpoints. The IoT
Hub identity registry provides secure storage of device identities and security keys for a solution. Individual or
groups of device identities can be added to an allow list, or a block list, enabling complete control over device
access. The following articles provide more details on the structure of the identity registry and supported
operations.
IoT Hub supports protocols such as MQTT, AMQP, and HTTP. Each of these protocols uses security tokens from the
IoT device to IoT Hub differently:
AMQP: SASL PLAIN and AMQP Claims-based security ( {policyName}@sas.root.{iothubName} with IoT hub-
level tokens; {deviceId} with device-scoped tokens).
MQTT: CONNECT packet uses {deviceId} as the {ClientId} , {IoThubhostname}/{deviceId} in the
Username field and an SAS token in the Password field.
HTTP: Valid token is in the authorization request header.
IoT Hub identity registry can be used to configure per-device security credentials and access control. However, if an
IoT solution already has a significant investment in a custom device identity registry and/or authentication scheme,
it can be integrated into an existing infrastructure with IoT Hub by creating a token service.
X.509 certificate -based device authentication
The use of a device-based X.509 certificate and its associated private and public key pair allows additional
authentication at the physical layer. The private key is stored securely in the device and is not discoverable outside
the device. The X.509 certificate contains information about the device, such as device ID, and other organizational
details. A signature of the certificate is generated by using the private key.
High-level device provisioning flow:
Associate an identifier to a physical device – device identity and/or X.509 certificate associated to the device
during device manufacturing or commissioning.
Create a corresponding identity entry in IoT Hub – device identity and associated device information in the
IoT Hub identity registry.
Securely store X.509 certificate thumbprint in IoT Hub identity registry.
Root certificate on device
While establishing a secure TLS connection with IoT Hub, the IoT device authenticates IoT Hub using a root
certificate that is part of the device SDK. For the C client SDK, the certificate is located under the folder "\c\certs"
under the root of the repo. Though these root certificates are long-lived, they still may expire or be revoked. If
there is no way of updating the certificate on the device, the device may not be able to subsequently connect to the
IoT Hub (or any other cloud service). Having a means to update the root certificate once the IoT device is deployed
effectively mitigates this risk.
Securing the connection
Internet connection between the IoT device and IoT Hub is secured using the Transport Layer Security (TLS)
standard. Azure IoT supports TLS 1.2, TLS 1.1, and TLS 1.0, in this order. Support for TLS 1.0 is provided for
backward compatibility only. Check TLS support in IoT Hub to see how to configure your hub to use TLS 1.2, as it
provides the most security.

Securing the cloud

Azure IoT Hub allows definition of access control policies for each security key. It uses the following set of
permissions to grant access to each of IoT Hub's endpoints. Permissions limit the access to an IoT Hub based on
functionality.
Registr yRead . Grants read access to the identity registry. For more information, see identity registry.
Registr yReadWrite . Grants read and write access to the identity registry. For more information, see
identity registry.
Ser viceConnect . Grants access to cloud service-facing communication and monitoring endpoints. For
example, it grants permission to back-end cloud services to receive device-to-cloud messages, send cloud-
to-device messages, and retrieve the corresponding delivery acknowledgments.
DeviceConnect . Grants access to device-facing endpoints. For example, it grants permission to send
device-to-cloud messages and receive cloud-to-device messages. This permission is used by devices.
There are two ways to obtain DeviceConnect permissions with IoT Hub with security tokens: using a device
identity key, or a shared access key. Moreover, it is important to note that all functionality accessible from devices is
exposed by design on endpoints with prefix /devices/{deviceId} .
Service components can only generate security tokens using shared access policies granting the appropriate
permissions.
Azure IoT Hub and other services that may be part of the solution allow management of users using the Azure
Active Directory.
Data ingested by Azure IoT Hub can be consumed by a variety of services such as Azure Stream Analytics and
Azure blob storage. These services allow management access. Read more about these services and available
options:
Azure Cosmos DB: A scalable, fully-indexed database service for semi-structured data that manages
metadata for the devices you provision, such as attributes, configuration, and security properties. Azure
Cosmos DB offers high-performance and high-throughput processing, schema-agnostic indexing of data,
and a rich SQL query interface.
Azure Stream Analytics: Real-time stream processing in the cloud that enables you to rapidly develop and
deploy a low-cost analytics solution to uncover real-time insights from devices, sensors, infrastructure, and
applications. The data from this fully-managed service can scale to any volume while still achieving high
throughput, low latency, and resiliency.
Azure App Services: A cloud platform to build powerful web and mobile apps that connect to data
anywhere; in the cloud or on-premises. Build engaging mobile apps for iOS, Android, and Windows.
Integrate with your Software as a Service (SaaS) and enterprise applications with out-of-the-box
connectivity to dozens of cloud-based services and enterprise applications. Code in your favorite language
and IDE (.NET, Node.js, PHP, Python, or Java) to build web apps and APIs faster than ever.
Logic Apps: The Logic Apps feature of Azure App Service helps integrate your IoT solution to your existing
line-of-business systems and automate workflow processes. Logic Apps enables developers to design
 workflows that start from a trigger and then execute a series of steps—rules and actions that use powerful
connectors to integrate with your business processes. Logic Apps offers out-of-the-box connectivity to a vast
ecosystem of SaaS, cloud-based, and on-premises applications.
Azure Blob storage: Reliable, economical cloud storage for the data that your devices send to the cloud.

Conclusion
This article provides overview of implementation level details for designing and deploying an IoT infrastructure
using Azure IoT. Configuring each component to be secure is key in securing the overall IoT infrastructure. The
design choices available in Azure IoT provide some level of flexibility and choice; however, each choice may have
security implications. It is recommended that each of these choices be evaluated through a risk/cost assessment.

See also
Read about IoT Hub security in Control access to IoT Hub in the IoT Hub developer guide.