Scaling Industrial AI at the Edge with Helin and Azure IoT
Remote industrial sites generate operational data continuously, but the ability to act on that data in near real time can be challenging. Bandwidth is often limited; connectivity is inconsistent, and the analysis needed to turn raw signals into insight typically depends on cloud connection. When worker safety is on the line, that gap matters even more, since a person entering a hazardous zone has to be detected and flagged on site independent of a cloud connection. Meeting those conditions calls for a secure, repeatable foundation, one that trains models in the cloud, runs inference locally, governs distributed edge devices, and turns the right signals into insight. Helin Data built that foundation: an edge-to-cloud platform that combines local inference, industrial data collection, and fleet observability on Azure. RedZone, Helin's vision AI application for hazardous-zone monitoring, is the first proof point of this platform. It uses the CCTV cameras already installed on a rig to detect when a person enters a defined danger zone around active equipment, triggering a local alert through an on-site interface and status lights, and logging the event for later safety and operational analysis. Because inference runs at the edge, RedZone can detect and alert without waiting on a connection to the cloud, while Azure handles centralized management, analysis, and model lifecycle activities. What sets this solution apart Designed for constrained environments – Inference runs directly on the edge box, so RedZone keeps detecting and alerting even through network outages, with no dependence on the cloud at runtime. Only priority events and metadata detected by RedZone sync to Azure, which keeps bandwidth use low on a constrained connection such as satellite connectivity used at some offshore sites. Secure, scalable fleet governance – Devices onboard automatically through Device Provisioning Service (DPS) with per-device X.509 certificates. Every device is listed in Azure Device Registry (in preview) and projected as native ARM resources, so updates and configuration changes can be targeted, governed, and audited using standard Azure tooling. Helin adds multi-level security, including public key infrastructure (PKI), data encryption, and industry-trusted authentication, protecting data as it moves from the rig to the cloud. Helin's observability layer spans device health, firmware updates, application status, and the data pipeline, so organizations can promptly identify and investigate potential issues across the edge-to-cloud pipeline. A closed edge-to-cloud AI loop – Models are trained and versioned in Azure Machine Learning, then deployed to the edge for local inference. Detections stream back into Microsoft Fabric, where the data can inform model evaluation and future model versions, closing the loop between the field and the cloud. A reusable application foundation – RedZone runs on the same platform and loop that can be adapted for additional customer scenarios. A different hazard, a different zone, or a different operational question can become its own application. Delivering a governed device fleet Azure IoT Hub and DPS provide secure device connectivity, messaging, and automated provisioning. The Azure IoT Hub integration with Azure Device Registry, currently in public preview, represents devices as Azure resources, providing a foundation for Azure-native fleet inventory and governance. Together, these services help Helin onboard, connect, and manage distributed edge deployments. Azure Device Registry (public preview with Azure IoT Hub): Provides the management plane, representing each device as an Azure Resource Manager resource so it can be governed with the same patterns used for other Azure resources including role-based access control, resource groups, tags, and resource-level management, with namespaces acting as the organizational and security boundary. Azure Device Registry integration with Azure IoT Hub and Microsoft-backed X.509 certificate management is in public preview and is not recommended for production workloads. Azure IoT Hub and DPS: Deliver secure onboarding and bidirectional messaging between the devices and the cloud. Helin Data Edge Inference and Data Collector: Runs vision AI inference at the edge and connects into the industrial control systems already on site, so each detection carries operational context. Industrial data is collected, contextualized, buffered, and filtered locally before important signals are sent to Azure. Microsoft Fabric: Ingests telemetry and turns it into an operational model for analysis and reporting, giving organizations clearer insight into their operations. Customer Impact This solution is already proven in a demanding industrial environment. When Helin Data implemented RedZone on Noble’s Maersk Discoverer rig, RedZone detected a person entering a hazardous zone and raised an alert in roughly 150 milliseconds. Processing the detection locally is particularly important offshore, where limited connectivity makes a cloud-dependent response impractical. Helin’s broader edge platform is already supporting Noble across its operations. The offshore drilling contractor, which operates a fleet of more than 40 rigs, uses Helin’s Remote CCTV Manager to provide authorized personnel with live video from more than 20 rigs. Reduced resolution streams sync to Noble’s secure Azure environment for viewing while full resolution recordings stay at the rig to reduce bandwidth use. Together, these examples demonstrate the broader platform pattern: process high-volume data locally, transmit the signals that matter, and centrally manage applications deployed across a distributed industrial fleet. Closing RedZone shows what becomes possible when Azure IoT Hub is used as more than a device-connectivity service. Combined with secure provisioning, Azure-native device governance, edge inference, model lifecycle management, and Microsoft Fabric, it becomes part of a repeatable platform for building and operating industrial AI applications at scale. For customers, the value extends beyond a single safety scenario. The same foundation can support new applications across worker safety, operational visibility, process improvement, and other industrial use cases, without rebuilding the underlying device and data infrastructure each time. Helin brings the industrial application expertise; Azure provides the scalable foundation on which those applications can be deployed, governed, and continuously improved. Take the next step Read the customer case study, Improving safety across a fleet of drilling rigs Learn more about RedZone in Seeing the Human Layer: Helin Brings Edge Vision AI to Industrial Operations on Azure. Explore Helin’s Intelligent Edge Application Platform is now available in Azure Marketplace Resources Deploy Azure IoT Hub with Device Registry integration and certificate management (preview) Azure IoT Hub Documentation Product documentation | Helin DocumentationHow Mesh Systems Builds on Azure IoT Hub and Azure IoT Operations to Accelerate Industrial AI
Manufacturers generate vast amounts of operational data, yet its complexity and fragmentation across historians, Operational Technology (OT) systems, and cloud platforms can slow AI adoption at scale. As organizations invest in AI to enhance productivity, quality, and decision making, the ability to connect and contextualize operational data becomes critical. Azure IoT Hub, Azure IoT Operations, and Mesh address this challenge together, spanning the full path from device connectivity to actionable AI-powered insights. Mesh brings deep Azure IoT platform experience and a practical path to industrial AI, with MeshCloud built on Azure IoT Hub, an open-source .NET Akri framework for Azure IoT Operations, and MeshInsights delivering generative AI-powered operational intelligence. This expertise is backed by a long history with Azure; Mesh launched its first IoT solution on Azure in private preview in 2009 and remained an early adopter of every major Azure IoT service since. Together, Azure IoT Hub, Azure IoT Operations, and Mesh give manufacturers a streamlined way to unify operational data and apply AI where it matters most. Unlocking legacy data with Mesh's Akri Connector Industrial organizations often struggle to modernize operations because critical operational data sits isolated inside historians and legacy Operational Technology (OT) systems. Many manufacturers are also wary of integrations that create new dependencies and limit future flexibility. Azure IoT Operations addresses this through an open architecture built around Akri, connecting industrial data sources while preserving interoperability across hardware and software environments. Mesh built on this foundation with its Akri Historian Connector, bringing historian and legacy operational data into Azure IoT Operations through prebuilt connectivity rather than source-by-source integration work. The result is faster access to operational data ready for analytics, AI, and industrial automation. The key features of this connector include: Restart-safe data continuity: Manufacturers can trust that operational data keeps flowing even through outages or restarts, with no data loss and no time spent recovering or reprocessing data. Secure, flexible authentication: Modern and legacy industrial systems connect under one security model, meeting enterprise-grade authentication standards without restructuring existing infrastructure. A foundation other connectors can be built on: The underlying framework handles the heavy lifting, so teams only need to build what's unique to each new OT data source. This means faster time to value for every new data source. Built in alignment with Azure IoT Operations roadmap: The connector stays up to date automatically, as new Azure IoT Operations features become available. This means manufacturers have access to the latest capabilities as the platform evolves. Together, Mesh and Azure IoT Operations give organizations a production-ready path from the shop floor into Azure IoT Operations and onward to Microsoft Fabric. Delivering Scalable Connected Products with Azure IoT Hub and MeshCloud MeshCloud helps manufacturers move from connected product pilots to fleet scale deployments faster by providing a platform build on Azure IoT Hub and other Azure native services. Azure IoT Hub provides per-device identity, support for MQTT, AMQP, and HTTPS, and built-in capabilities like device twins, direct methods, and rules-based message routing. Azure Device Provisioning Service (DPS) extends this foundation with zero-touch, just-in-time onboarding using X.509, TPM, or symmetric key attestation. Mesh operates as one cohesive engineering practice across the full connected product lifecycle, delivering hardware, firmware, wireless, edge, and cloud integration natively for Azure IoT Hub and Azure IoT Operations. That end-to-end scope is what MeshCloud, their Azure-native connected product platform, brings together. MeshCloud embeds Azure IoT Hub and DPS into an Azure-native connected product platform, giving organizations a faster path to connected product delivery without sacrificing control, scale, or solution ownership. The platform comes together across four layers: Edge to cloud: Connected devices, from MCU controllers to tablets and phones, register and authenticate through DPS and connect securely to IoT Hub, giving organizations a direct, secure line from shop floor to enterprise systems. Messaging and command: Event Hubs and Container Apps move telemetry and commands between devices and the cloud, with asset and ontology data exposed for digital twin management and device control. IT and operations: Azure Monitor, OpenTelemetry, Microsoft Entra, and Application Gateway bring platform observability, identity management, and secure ingress together, equipping IT and operations teams with a unified way to manage and secure the environment. Analytics and visualization: Telemetry flows into Azure Data Explorer and Microsoft Fabric for processing and storage, with Grafana, Power BI, and a Device Health UI giving teams fleet-wide visibility. This architecture enables organizations to move from pilot projects to fleet-scale deployments using Azure-native services, while maintaining interoperability across devices, connectivity protocols, and analytics platforms. For manufacturers, this means less time integrating infrastructure and more time delivering operational insights, connected services, and AI-powered workflows. Advancing Industrial Intelligence with MeshInsights As organizations connect more assets and operational systems, the next challenge becomes turning information into consistent actions and decisions. Microsoft Azure provides the cloud, data, and AI foundation for intelligent operational workflows, while giving organizations control over their data and business processes. Mesh extends this foundation through MeshInsights. MeshInsights is Mesh's AI agent offering for connected-product manufacturers. Mesh works with organizations to define a specific operational decision worth automating, such as classifying an alert or determining the right service response, and builds an evaluation standard from real telemetry, service history, and expert-validated examples. AI agents are then developed and measured against that standard, acting automatically on high-confidence cases and routing the rest to the organization's own experts. This extends connected systems beyond monitoring and reporting into trusted, auditable operational decisions. By combining Azure IoT platform services with MeshInsights, Mesh helps organizations move from connected infrastructure to autonomous, AI-driven action without changing where their data lives or who owns the architecture. Why This Matters Industrial transformation increasingly depends on strong collaboration between hyperscale cloud platforms and ecosystem partners who bring operational expertise, deployment acceleration, and industry-specific engineering capabilities. Mesh Systems demonstrates how partners can build differentiated value on top of Azure IoT platform services while helping organizations accelerate deployment timelines, standardize industrial data architectures, and operationalize AI across connected environments. Organizations are already putting this value to work in everyday operations. BUNN's cloud-connected coffee machines now give technicians a head start before every service call. As Kurt Powell, Executive Vice President at BUNN, put it: "With this solution, we know exactly which component to fix before we get there." WLS Lighting Systems has turned that same visibility into measurable savings at scale. Built on MeshCloud and Azure IoT, WLS's netLiNK gives property owners remote monitoring and control over individual light fixtures. Kevin Fletcher, President National Accounts at WLS, shared that the company has saved customers a little over $50 million in electrical costs since bringing netLiNK to market. Together, Azure IoT Hub, Azure IoT Operations, and Mesh Systems help manufacturers reduce integration complexity and operationalize industrial data, creating a foundation for AI driven operations spanning plant, edge, and cloud. The result: manufacturers spend less time on integration and more time improving productivity, resiliency, and decision making across their operations. Learn More Explore Mesh Systems solutions on Azure Marketplace: https://marketplace.microsoft.com/en-us/product/saas/mesh-systems.cloud?tab=Overview Read customer success stories: https://meshsystems.com/case-study-eaton-1/ Learn more about Azure IoT Operations: https://azure.microsoft.com/products/iot-operations/Direct IoT Hub-to-Fabric message routing, with context preserved via CloudEvents, in Public Preview
Announcing Public Preview of Microsoft Fabric Eventstreams as a native Azure IoT Hub routing endpoint. Customers can now send device telemetry directly into Fabric without building custom integration pipelines, using the same routing rules, filters, and enrichments configurable in IoT Hub. Events are delivered using the CloudEvents envelope, which preserves critical metadata for downstream analytics.
Announcing new security enhancements across Azure IoT services
Security is foundational to the connected products and solutions our customers build. It shapes every decision, from how devices are provisioned to how they connect and receive updates. As device fleets scale and attackers probe new vectors, from the network layer to the software supply chain, customers are asking for stronger security defaults at each of these stages. Today we’re strengthening all three. Customers managing connected devices get a modern transport-security baseline with TLS 1.3 for Azure IoT Hub, identity-based provisioning that removes long-lived secrets with managed identity support for linking an IoT Hub to DPS, and encrypted update delivery with TLS downloads for Device Update for IoT Hub. TLS 1.3 and managed identity are in Public Preview; TLS downloads is Generally Available. At a glance Feature Service Status TLS 1.3 support Azure IoT Hub Public Preview Managed identity for Hub linking Azure IoT Device Provisioning Service + IoT Hub Public Preview TLS downloads (encrypted update delivery) Device Update for IoT Hub Generally Available TLS 1.3 support for Azure IoT Hub (Public Preview) Azure IoT Hub now supports TLS 1.3 through new endpoints that sit alongside the existing classic endpoint: Classic endpoint: <hub>.azure-devices.net TLS 1.3 Device endpoint: <hub>.device.azure-devices.net TLS 1.3 Service endpoint: <hub>.service.azure-devices.net The new device and service endpoints support TLS 1.3, and also support TLS 1.2 with a reduced, security-compliant cipher suite set. Devices connect through the device endpoint for device-to-cloud telemetry and cloud-to-device messages, while backend and management applications built on the service SDK connect through the service endpoint. The existing endpoint remains available, so customers can adopt the new endpoints on their own timeline rather than through a forced migration. No enablement action is needed: the new endpoints are provisioned automatically on new and existing hubs, and customers adopt TLS 1.3 by pointing their device or service clients at the new hostnames. TLS 1.3 gives customers a more modern security baseline for IoT connectivity. Just as importantly, this release introduces a clearer separation between device traffic and service traffic through dedicated endpoints, which makes the connectivity model easier to understand and evolve over time. This design also reflects how real IoT deployments work. Many customers cannot update every device or backend integration at once, so a side-by-side endpoint model helps teams test, validate, and roll out changes in stages. Learn more about Azure IoT Hub support for TLS 1.3. Managed identity support for Hub linking (Public Preview) We are also introducing managed identity support for linking an IoT Hub to DPS. DPS links to an IoT Hub securely to assign devices to the right hubs at scale, and until now, that link has relied on connection-string (shared access key) authentication. This dependency on a shared key results in customers keeping local authentication enabled on the IoT Hub, even when their security policies call for disabling it in favor of Microsoft Entra ID. Managed identity support removes that constraint: DPS can now authenticate to IoT Hub using a managed identity backed by Microsoft Entra ID so the Hub linking no longer requires a connection string. As a result, customers can disable local authentication on the IoT Hub, remove long-lived shared keys from the provisioning path, and simplify credential lifecycle management and security governance with no shared keys to rotate, store, or accidentally leak. Together, TLS 1.3 and managed identity strengthen the same Hub linking scenario: TLS 1.3 modernizes how devices and services connect to IoT Hub, while managed identity gives Azure services credential-free authentication during provisioning. Learn more about how to link an IoT Hub to DPS using managed identity. Secure update delivery: TLS downloads for Device Update for IoT Hub (Generally Available) Device Update for IoT Hub can now deliver update content over HTTPS, encrypting update content in transit between the Device Update service and your devices. For customers managing large fleets, this brings update delivery in line with the same modern transport-security expectations now applied to device and service connectivity, and helps teams meet encryption-in-transit and compliance requirements. Download security is a deployment-level setting available in Device Update data plane API version 2026-06-01. New deployments created with this version use HTTPS by default, while existing deployments continue using their current configuration. Customers that require HTTP downloads can still explicitly select HTTP. You can configure download security in the Azure portal when creating a deployment, or through the REST API, SDKs, Azure CLI, and automation workflows. Earlier API versions support HTTP downloads only. Before enabling HTTPS, confirm your devices are ready. Devices must support HTTPS downloads, trust the required root certificate authorities, and support TLS 1.2 or TLS 1.3. Some constrained or embedded devices may require code changes; see additional considerations for constrained or embedded devices. Learn more about download security for Device Update for IoT Hub. Why this matters together With these enhancements, Azure IoT services are taking another step toward secure, modern device onboarding, connectivity, and lifecycle management. TLS 1.3 modernizes how devices and services connect, managed identity removes secrets from the provisioning flow, and TLS download protects update content in transit. Each addresses a different layer of the security model, and together they reflect Microsoft's ongoing, security-first commitment to the platforms our customers build on. Customers can adopt TLS 1.3 for IoT Hub and managed identity for Hub linking in Preview today and put TLS downloads for Device Update into production right now. Get started Explore the documentation and share your feedback: TLS 1.3 for Azure IoT Hub (Preview) Managed identity for Hub linking (Preview) Download security (TLS) for Device Update for IoT Hub For questions or feedback, email us at iotdeviceonboarding@microsoft.comResource Guide: Making Physical AI Practical for Real‑World Industrial Operations
Microsoft’s adaptive cloud approach enables organizations to turn operational technology (OT) data into intelligent actions, autonomously, without requiring everything to live in the cloud by unifying cloud-to-edge management plane, data plane, and intelligence platform. At the center of this approach are key foundational technologies: Key Purpose Offering Direct-to-cloud device management + telemetry ingestion Azure IoT Hub Industrial connectivity + edge data plane Azure IoT Operations Unified analytics + real-time intelligence Microsoft Fabric On-device AI inferencing runtime Foundry Local Microsoft Azure IoT Gartner winner: Microsoft named a Leader in the 2025 Gartner® Magic Quadrant™ for Global Industrial IoT Platforms See it all come together Before diving into each component, watch this end-to-end demo showing how Azure IoT Operations, Azure IoT Hub, Microsoft Fabric, and Foundry Local work as one stack across the edge-to-cloud lifecycle - Making industrial AI practical for real-world operations with adaptive cloud. How these components work together Azure IoT Operations and Azure IoT Hub collect real-time data from operational assets and send semantically-ready, modeled data to Microsoft Fabric, where it's contextualized with enterprise data for downstream analytics. Microsoft Foundry extends to the edge through Foundry Local, so the same tooling used to deploy and manage AI models in the cloud applies to edge use cases. All of it integrates into Azure Resource Manager, bringing OT devices, assets, and edge AI models into the same management and security paradigm as every other Azure-managed resource. This blog walks through where to get started with each product capability: 1. Manage Cloud-Connected Devices and Telemetry with Azure IoT Hub Azure IoT Hub is a fully managed cloud service that enables secure bidirectional communication, device-to-cloud telemetry ingestion, cloud-to-device command execution, per-device authentication, remote management and more. Telemetry from IoT Hub can also be routed downstream into analytics platforms like Microsoft Fabric for visualization or AI modeling. Recommended Usage: Devices that utilize IoT Hub are distributed, stand-alone devices with fixed-functions. These devices typically do not require cloud-managed containerized workloads or cloud-managed proximal industrial protocol connectivity. Examples of appropriate device-to-cloud IoT Hub endpoint devices include water monitoring stations, vehicle telematics, distributed fluid level sensors, etc. Resources Current in-market services overview: IoT Hub: What is Azure IoT Hub? - Azure IoT Hub DPS: Overview of Azure IoT Hub Device Provisioning Service - Azure IoT Hub Device Provisioning Service ADU: Introduction to Device Update for Azure IoT Hub Building scalable solutions with Azure IoT platform: Best practices for large-scale IoT deployments - Azure IoT Hub Device Provisioning Service Scale Out an Azure IoT Hub-based Solution to Support Millions of Devices - Azure Architecture Center Azure IoT Hub scaling Try out our preview of new IoT Hub capabilities (integration with Azure Device Registry and Certificate Management) Learn more about these capabilities on our blog post: Azure IoT Hub + Azure Device Registry (Preview Refresh): Device Trust and Management at Fleet Scale… Integration with Azure Device Registry (preview): Integration with Azure Device Registry (preview) - Azure IoT Hub Microsoft-backed X.509 certificate management (preview): What is Microsoft-backed X.509 Certificate Management (Preview)? - Azure IoT Hub How to start with the preview: Deploy IoT Hub with ADR integration and certificate management (Preview) - Azure IoT Hub 2. Connect Industrial Assets with Azure IoT Operations Azure IoT Operations provides a unified data plane for the edge that runs on Azure Arc–enabled Kubernetes clusters and supports open industrial standards. It allows organizations to connect and capture equipment telemetry, normalize OT data locally, route hot-path signals to real-time analytics, securely manage layered industrial networks, and more. Edge‑processed data can then be sent upstream to Microsoft Fabric for AI‑driven analysis. Recommended Usage: Azure IoT Operations is intended to be the data plane for an adaptive cloud deployment extending the management, data, and AI capabilities of the Microsoft cloud to an on-prem device. This device binds to these cloud planes providing a platform for local data processing and intermittent connectivity. The target for these devices range from a small-gateway-style PC to a full data center. Azure IoT Operations endpoints enable cloud-managed containerized workloads and cloud-managed proximal industrial protocol connectivity. Examples of appropriate adaptive cloud and Azure IoT Operations endpoints include, on-robot computers, industrial machine controllers, retail store sensor/vision processing, and top-of-factory site infrastructure for line of business applications. Resources Azure IoT Operations Overview Azure IoT Operations Documentation Hub Releases · Azure/azure-iot-operations Quickstart: explore-iot-operations/quickstart at main · Azure-Samples/explore-iot-operations Latest release update: Open-source framework for scaling robotics from simulation to production on Azure + NVIDIA: microsoft/physical-ai-toolchain Demo video showcasing this in action: Making industrial AI practical for real-world operations with adaptive cloud How we built the demo: explore-iot-operations/quickstart at main · Azure-Samples/explore-iot-operations Edge-AI: microsoft/edge-ai: Production-ready Infrastructure as Code, applications, pluggable components, and… Latest Announcements & Blogs Making Physical AI Practical for Real-World Industrial Operations: Part 1 | Microsoft Community Hub Making Physical AI Practical for Real-World Industrial Operations: Part 2 | Microsoft Community Hub Introducing small form factor infrastructure: embed intelligence into physical systems Unlock Industrial Intelligence | Microsoft Hannover Messe 2026 From pilots to production: How Microsoft and partners are accelerating intelligent operations Partner Solutions How Mesh Systems Builds on Azure IoT Hub and Azure IoT Operations to Accelerate Industrial AI | Microsoft Community Hub Unlocking the Human Telemetry Layer for Safer Industrial Operations | Microsoft Community Hub Unlocking Smart Manufacturing: Siemens Industrial Edge Meets Azure IoT Operations Solving the Data Challenge for Manufacturers with Sight Machine & Azure IoT Operations | Microsoft Community Hub Microsoft and Rockwell Automation: Transforming Industrial AI Together | Microsoft Community Hub 3. Advanced Analytics with Microsoft Fabric Microsoft Fabric delivers a unified, end‑to‑end analytics platform that transforms streaming OT telemetry into real‑time insights and live dashboards. Fabric Operations Agents monitor industrial signals to recommend targeted actions, while Fabric IQ provides a shared semantic foundation that enables AI agents to reason over enterprise data with business context. Together, Fabric turns live industrial data into AI‑powered operational intelligence. Resources Get Started with Microsoft Fabric Learning Path Fabric Real-Time Intelligence documentation - Microsoft Fabric | Microsoft Learn Create and Configure Operations Agents - Microsoft Fabric | Microsoft Learn Fabric IQ documentation - Microsoft Fabric | Microsoft Learn 4.Run AI Models On‑Device with Foundry Local Foundry Local extends on‑device AI to Arc‑enabled Kubernetes edge clusters, providing a Microsoft‑validated inferencing layer for running AI models in industrial, disconnected or sovereign environments. Resources Foundry Local on Azure Local Documentation Participate in Foundry Local on Azure Local preview form Foundry Local on Azure Local: HELM deployment Demo Customer Stories Chevron: Chevron plans facilities of the future with Azure IoT Operations Husqvarna: Husqvarna Group Boosts Operational Efficiency with Azure Adaptive Cloud Ecopetrol: Azure IoT Operations and Azure IoT for energy help Ecopetrol optimize energy distribution while lowering operational costs P&G: Procter & Gamble cuts model deployment time up to 90% with Azure IoT Operations Toyota: Toyota Industries innovates its paint shop processes with Azure industrial AI and Azure IoT HubAzure IoT guidance for DigiCert Global Root G1 trust-store updates in sovereign clouds
At a glance The technology industry is retiring trust in an older root certificate - the DigiCert Global Root G1. As operating systems, firmware images, and CA certificate bundles update over time, some clients may stop trusting this older root. This can affect both your Azure IoT devices and the applications that connect to Azure IoT service APIs. If those devices or application hosts run on Linux or rely on a system trust store that receives periodic updates, this post explains what you might see and the simple steps to stay connected. This guidance is relevant only for a subset of Azure IoT customers using Azure Government (Fairfax) or Azure China (Mooncake) environments, and only if devices or applications adopt operating system, firmware, or trust-store updates that remove trust for the DigiCert Global Root G1 certificate. Azure public cloud customers are not affected because Azure IoT public cloud endpoints already use newer certificate chains. This is a client-side trust-store change, not a security incident, service outage, or certificate expiration event. Scope: Azure public cloud customers are not affected. This guidance applies only to specific Azure Government (Fairfax) and Azure China (Mooncake) scenarios where updated client trust stores no longer trust DigiCert Global Root G1. Could this affect my deployment? For most Azure IoT customers, the answer is no. If you use Azure IoT in the Azure public (commercial) cloud, you are not affected by this change. Azure IoT public cloud endpoints already use newer certificate chains and do not rely on the DigiCert Global Root G1 certificate. This guidance is relevant only for a subset of customers using Azure Government (Fairfax) or Azure China (Mooncake) environments, and only if: Your devices or applications rely on operating system trust stores. You recently applied Linux operating system, firmware, container image, OpenSSL, NSS, or CA certificate bundle updates. You began seeing TLS connectivity or provisioning errors after those updates were installed. If your devices continue to connect normally and you have not observed any TLS-related issues following recent updates, no action is required at this time What should I do? If your devices and applications are connecting normally, no action is required. If you manage Linux-based devices or applications that rely on operating system trust stores, we recommend validating OS, firmware, and CA bundle updates in a test environment before production rollout. If connectivity issues appear following a trust-store update, contact Microsoft Support for assistance. What you may observe After an operating system, firmware, or CA-certificate-bundle update, an affected device or application may show the symptoms below. These typically appear first in test or QA environments, because fleets and application environments usually stage updates before production. Failure to connect to Azure IoT during the TLS handshake. A certificate trust, “untrusted root,” or “unknown CA” error. Telemetry, provisioning, or service-API calls stop, while clients still running the previous trust store keep working normally. Why it could happen Your device or application validates the Azure IoT server certificate against the list of trusted root certificates in its local trust store. As updates remove the older DigiCert Global Root G1 from that store, a client that still expects it may reject the connection - even though the server certificate is valid. The change is on the client side, in the trust store, not in the Azure service. What you should check If you see connectivity or provisioning failures, confirm the following: Was there a recent OS, firmware, or CA-bundle update on the affected devices or application hosts? Do clients still running the previous trust store continue to connect? If so, the cause is a trust-store change. Is the error a certificate or trust error rather than an authentication error? What we recommend A few simple steps keep your devices and applications connected through this change: Validate firmware and OS updates in a test ring before production rollout, the single most effective way to catch trust-store changes early. If clients begin failing after such an update, pause the rollout and, where feasible, roll back the update on the affected device or application host to restore connectivity. Contact Microsoft Support if you see connectivity or provisioning failures following an OS, firmware, or CA-bundle update. Support can confirm the cause and guide you through the appropriate next steps for your configuration. Questions If you have questions, contact Microsoft Support or your Microsoft account team.Unlocking the Human Telemetry Layer for Safer Industrial Operations
What if we could track human health & safety conditions as precisely as we do with machines, and take immediate actions to protect our greatest asset, our people? Many industrial organizations still lack visibility into real-time human conditions, even as worker safety and operational risk remain major investment priorities. One of the most important operational signals has largely remained outside the industrial data estate: the human telemetry. VOORMI and Microsoft have joined forces to fill this gap in understanding real human conditions. Through the Mij™ platform, VOORMI brings human telemetry into Azure IoT, enabling enterprises to integrate worker conditions such as heat stress and fatigue into the same operational architecture already used for machines and industrial systems. VOORMI, SWNR’s performance apparel brand, is among the first to bring this technology into garments designed for real industrial field conditions. This integration brings their proprietary wearable technology directly into high-impact worker safety and field operations scenarios. The partnership helps establish a new telemetry layer for industrial operations, allowing human, machine, and environmental signals to converge and drive safer operations, real-time awareness, and adaptive AI workflows. Bringing the Human Signal into Industrial AI with Azure Industrial organizations increasingly recognize that many safety, productivity, and operational challenges occur at the intersection of people and machines. Workers operate in high-heat environments, hazardous conditions, remote sites, and physically demanding field scenarios where situational awareness matters in real time. Historically, worker telemetry has remained fragmented across proprietary wearable platforms and disconnected safety systems, creating governance and operational challenges for enterprise IT and OT teams. Mij™ is designed differently, integrating directly into customer-controlled Azure environments through Azure IoT Operations running at the edge or Azure IoT Hub in the cloud rather than introducing another isolated platform. Running intelligence at the edge enables virtual safety agents and operational workflows to execute closer to the worker, supporting low-latency responses, local interaction with OT systems, and operational resilience even in disconnected or bandwidth-constrained environments. This gives enterprises flexibility to support real-time worker safety responses at the edge while also enabling long-term analytics, reporting, and operational intelligence through Microsoft Fabric. Telemetry from garment-integrated sensors flows through edge gateways into Azure services including Azure IoT Operations, Azure Data Explorer, Azure Managed Grafana, and Microsoft Fabric. The result is a unified operational environment where worker telemetry can live beside machine, site, and environmental data under the customer’s existing identity, security, governance, and analytics model. The vision is simple and transformative: make human telemetry a trusted, first-class industrial data source. Azure Digital Operations as the Intelligence Layer The reference architecture demonstrates how Azure IoT Operations can serve as a scalable operational intelligence layer for worker safety and connected operations scenarios across manufacturing, energy, and field environments. Mij™-enabled garments broadcast Bluetooth Low Energy (BLE) telemetry that can be processed locally through edge gateways and routed into Azure IoT Operations using MQTT and dataflows. Data is then operationalized through Azure Data Explorer and visualized using Azure Managed Grafana dashboards for field operations, worker safety, fleet health, gateway monitoring, and operational readiness scenarios. Telemetry can also be made available to Foundry Local-hosted GenAI agents to support real-time, context aware safety guidance, such as prompting workers operating in high-heat conditions to hydrate or seek cooler environments. While Mij™-enabled garments are the initial implementation, the edge device-to-cloud architecture creates a broader onboarding point for additional wearable, sensor, and field telemetry scenarios over time. This allows enterprises to bring more human and operational signals into a unified Azure-native operational environment. The architecture also supports flexible ingestion patterns for environments where dedicated edge gateways are not practical. Using Microsoft Entra External ID, Azure Container Apps, and Azure IoT Hub, telemetry can securely flow into Azure services without exposing operational infrastructure credentials to client devices. This pattern aligns with the broader Azure adaptive cloud approach: enabling customers to run distributed edge-native services on Arc-enabled Kubernetes infrastructure while maintaining centralized security, governance, and analytics capabilities across the enterprise. Depending on customer architecture preferences, telemetry can be processed through Azure IoT Operations at the edge or ingested directly through Azure IoT Hub for cloud-first analytics and downstream processing in services such as Microsoft Fabric. Edge processing also enables real-time sensor fusion across worker telemetry, ambient environmental conditions, machine parameters, and site-level operational signals, supporting faster safety interventions and more context-aware operational decisions. This gives enterprises flexibility in how they balance edge processing, operational responsiveness, governance and privacy requirements. Enabling the Next Generation of Industrial Workflows The long-term opportunity extends well beyond visualization dashboards. As worker telemetry becomes part of the operational fabric, enterprises can begin building more adaptive and intelligent workflows across worker safety, field readiness, incident response, compliance, environmental monitoring, and industrial AI systems. Human telemetry can provide critical real-time context that complements machine and environmental signals enabling more responsive operations and eventually more autonomous decision-support experiences. By bringing human telemetry into enterprise AI and analytics workflows, organizations can build more adaptive operational systems that improve worker safety, situational awareness, and real-time decision making at scale. This partnership reflects a broader industry shift: industrial transformation is no longer only about connected machines. It is about connected operations where people, equipment, environments, and AI systems participate in a shared operational intelligence layer. With SWNR’s Mij™platform and Azure IoT Operations, Microsoft and VOORMI are helping unlock that future. Learn more: Mij™ product page: https://swnrtechnologies.com/pages/mij Learn more about Azure IoT Operations: Documentation & Getting Started See what’s new with Azure IoT Hub: Preview Documentation To get started with a pilot, contact: pilots@swnrtechnologies.comSmaller updates, faster downloads with delta updates in Azure Device Update for IoT Hub
Keeping IoT fleets secure and up to date shouldn't mean shipping the full software image to every device, every time. With delta updates in Azure Device Update for IoT Hub, fleet operators can send only what has changed between versions, reducing download size, bandwidth use, and download time on most networks. In our demo below, an incremental change produced a delta ~97% smaller than the full image — a glimpse of what's possible for small, incremental changes. The timing matters. Security patch cadence keeps rising as Common Vulnerabilities and Exposures (CVEs) accumulate, more fleets (like smart meters and remote agricultural sensors) are running over metered networks such as cellular and satellite, and deployments are crossing scales where every megabyte per device adds up. At that point, full-image rollouts stop being a minor inefficiency and become a real cost and reliability problem. As part of a broader Azure IoT investment in more efficient edge-to-cloud data delivery, the new Device Update reference implementation agent 1.3.0 provides delta updates as a starting point that customers can build, validate, and integrate into their own environments. In this post, we'll walk through what delta updates are, how they work, and what else is new in 1.3.0 — including expanded Linux platform support to build on Debian 13 and Ubuntu 24.04, and new device-side visibility for tighter update control and coordination with device operations. Improving over-the-air (OTA) efficiency with delta updates When deploying OTA updates across a fleet, update size directly affects how quickly and efficiently updates move through the system. Traditional full image updates require every device to download the entire software image, even when only a small portion has changed. As deployments scale, this increases bandwidth usage and delivery overhead. Delta updates take a more efficient approach. Rather than transferring a full image each time, devices download a smaller delta artifact and reconstruct the target version locally, reducing the amount of data transferred across the fleet. By sending only what's changed between versions, delta updates improve efficiency in three ways: Less data on the network. Smaller payloads consume less bandwidth per device, and the savings multiply across large fleets. Faster downloads. Smaller artifacts reduce the time each device spends downloading the update, especially on variable or constrained networks. Lower delivery overhead at scale. With less data per rollout, teams can deliver updates more flexibly across large fleets, reducing the need to stagger deployments for bandwidth caps or capacity windows. This approach works particularly well for frequent, incremental changes such as bug fixes or small feature updates. For larger updates where most of the image has changed, or on devices with limited processing capacity, using a full image update may be more practical. How delta updates work Delta updates fit into the same Device Update deployment model you already use for full image updates. What changes is how update content is delivered and applied on the device. When you import an update into Device Update, you include both the full target update and one or more delta artifacts as part of the same update. When that update is deployed, the Device Update agent on each device picks the right path: If a compatible delta is available, the device downloads the delta, reconstructs the full target update locally, and installs it through the standard update workflow. If no compatible delta is available, the device falls back to downloading and installing the full target update. For details on integrating delta updates into your update workflow, see Deploy delta updates to devices. It guides you through generating delta artifacts on your build machine using the DiffGen reference tool, or as part of your image build process, and setting up the right components on the device to apply them. See the impact: Delta updates in action The following demo shows what a typical incremental change looks like with delta updates: a single-file change between image versions produces a 7 MB delta against a 240 MB full image — roughly a 97% reduction in data transferred for that scenario. Across 10,000 devices, that’s about ~2.3 TB less data crossing your network in a single rollout. Savings may vary depending on how much the versions have changed and how quickly the device can rebuild the full image locally, but they compound quickly at fleet scale. For example, a utility company patching firmware across hundreds of thousands of cellular-connected smart meters, or an agricultural operator updating remote field sensors over satellite links, sees carrier data costs drop significantly during each rollout. To bring this to life, the demo below shows what’s possible with delta updates — generating, deploying, and applying them on a Raspberry Pi device using Device Update for IoT Hub. Beyond delta updates: What’s new in the 1.3.0 reference implementation The 1.3.0 reference implementation also includes improvements that strengthen device-side coordination and expand Linux platform support. Coordinate updates with device workloads On many devices, updates run while the device is doing other work, such as handling sensor data, running a local UI, or managing background tasks. Without visibility into update status, device software can trigger conflicting operations or let battery-powered devices enter sleep mid-update. The 1.3.0 reference implementation helps your device software work alongside the update process rather than against it — coordinating with active updates, keeping devices awake through long downloads, and surfacing update status to local applications. A new device-local agent status API makes this possible: applications on the device can see what the Device Update agent is doing at any time, for example, whether an update is in progress. With that visibility you can: Avoid triggering operations that would conflict with an active update Keep battery-powered or low-power devices awake while an update is downloading or installing Surface update status in local applications or user interfaces Diagnose update behavior using local signals. Because the API runs locally, it works even when network connectivity is limited or intermittent. The payoff is fewer disrupted rollouts, more reliable updates across your fleet, and easier troubleshooting when something needs attention. Expanded Linux platform support The 1.3.0 reference implementation now adds Debian 13 and Ubuntu 24.04 to the Linux distributions you can already build on, including Debian 12 and Ubuntu 22.04. That gives you flexibility to work on newer OS versions without changing your existing update workflow. Call to action Ready to see the benefits? Extending and adapting the 1.3.0 reference implementation is a device-side change — existing service-side deployments and configurations stay as they are, so you can move at your own pace. Build from the Device Update for IoT Hub GitHub repository, integrate delta artifact generation into your build pipeline, and run your first delta in your next rollout to measure the bandwidth and download savings across your fleet. Learn more: Device Update for IoT Hub documentation | Microsoft Learn Deploy delta updates with Azure Device Update for IoT Hub | Microsoft Learn We’d love your feedback. Help shape the future of Azure Device Update for IoT Hub at aka.ms/dufeedback.Azure IoT Hub + Azure Device Registry (Preview Refresh): Device Trust and Management at Fleet Scale
What’s New in this Preview In November 2025, we announced the preview integration of Azure IoT Hub with Azure Device Registry, marking a huge step towards integrating IoT devices into the broader Azure ecosystem. We’re grateful to the customers and partners who participated in the preview and shared valuable feedback along the way. Today, we’re expanding the preview with new capabilities to strengthen security, improve fleet management, and simplify development for connected devices. With this refresh, preview customers can: Automate device certificate renewals with zero-touch, at-runtime operations to minimize downtime and maintain a strong security posture. Integrate existing security infrastructure like private certificate authorities with your Azure Device Registry namespace. Leverage certificate revocation controls to isolate device or fleet-level risks and maintain operational continuity Utilize an improved Azure Portal experience for streamlined configuration and lifecycle management of your devices. Accelerate solution development with expanded IoT Hub and DPS Device SDK compatibility for smoother integration and faster time to value. Together, these enhancements help organizations to secure, govern, and manage their IoT deployments using familiar Azure-native tools and workflows. Why this matters: From Connected Devices to Connected Operations Operational excellence begins by bridging the gap between physical assets and digital intelligence. Consider a global logistics fleet where every vehicle is more than just a machine; it is a trusted, connected, and manageable digital entity in the cloud. As these assets move, they emit a continuous stream of telemetry - from engine vibrations to fuel consumption – directly to a unified data ecosystem, where AI agents can reason over it with greater context. Instead of waiting for a breakdown, these agents detect wear patterns, cross-reference with digital twins, and provide recommendations to reroute a vehicle for service before a failure occurs. This completes a shift from reactive troubleshooting to proactive physical operations. Yet, for many organizations, this transformation is often stalled by fragmented systems where security policies, device registries, and data streams exist in silos. Overcoming this requires a sophisticated stack designed to establish trust, manage device lifecycles, and orchestrate data flows at a global scale: The Digital Operations stack for cloud-connected devices This journey starts with having a secure foundation for fleet management. In an era where perimeter security is no longer enough, organizations need an identity foundation that is both hardware-rooted and deeply integrated with device provisioning. Utilizing robust X.509 certificate management, where keys and credentials are anchored in tamper-resistant hardware, provides high-assurance system integrity across millions of endpoints. Once trust is established, Azure Device Registry creates a unified management plane, where devices are represented as first-class Azure resources, enabling ARM-based fleet management, role-based access control for lifecycle operations, and Azure Policy for enforcement. Simultaneously, IoT Hub provides secure, bidirectional messaging for at-scale fleets. This high-fidelity data provides the essential fuel for Physical AI. By streaming trusted telemetry into Microsoft Fabric, organizations can break down data silos and allow AI agents to reason over real-world events in a centralized analytics environment. The Azure IoT stack provides the essential bridge for cloud-connected devices, enabling customers to transform their industrial environments into highly secure and intelligent ecosystems. For more information on Azure's approach to industrial AI, check out: Making Physical AI Practical for Real-World Industrial Operations. Azure IoT Hub + ADR (Preview): Expanding Fleet and Certificate Lifecycle Management The April 2026 Preview for Azure IoT Hub and Azure Device Registry (ADR) deliver key features to further standardize device identity and enable policy‑driven management for certificates at scale. You can think of device identity in Azure Device Registry like the birth record of a person. When someone is born, certain information becomes permanently associated with them - such as their date and place of birth. In the same way, a device’s identity represents its immutable existence within your solution - things like its serial number, model, or ownership context. However, as that person moves through life, they obtain different credentials that allow them to prove who they are in different situations - such as a driver’s license or passport. These credentials may expire, be renewed, or even replaced entirely over time without changing the person’s underlying identity. In IoT, devices use X.509 certificates as their credential to prove identity to services like IoT Hub. In your Azure Device Registry namespace, you can define the public key infrastructure (PKI) that manage your X.509 certificates and certificate authorities (CAs). In this preview, we are making it easier to integrate with existing security infrastructure and manage certificates at fleet scale. Certificate Management for Cloud-connected Devices in Azure Bring Your Own Certificate Authority (BYO CA) in Azure Device Registry Organizations that already operate sophisticated certificate authorities, with well‑established compliance controls, audit processes, and key custody requirements, want to integrate their trusted CA with the Azure Device Registry operating model. With BYO CA, customers can use their own private certificate authority while still benefiting from Azure’s fully managed device provisioning, and lifecycle management. Azure handles the heavy lifting of issuing, rotating, and revoking issuing certificate authorities (ICAs) and device certificates - while you stay in control of the top-most CA. Full Ownership of Trust and Keys: By bringing their own CA, organizations maintain absolute control over their private keys and security boundaries. Azure never takes custody of the external CA, ensuring existing governance, auditability, and compliance controls remain fully intact. Automated Lifecycle Management: While the CA remains customer-owned, Azure Device Registry automates the issuance, rotation, and revocation of device certificates. This eliminates the need for custom tooling or manual, per-device workflows that typically slow down deployments. Bring your own Certificate Authority in Azure Device Registry Fleet‑Wide Protection with Certificate Revocations Revocation is a mechanism for selective isolation, used to contain a single or group of devices by decommissioning a single device's certificates or the entire anchor of trust. When a single device is compromised, lost, or retired, device certificate revocation enables a precise, targeted response. This allows organizations to isolate individual devices instantly, reduce blast radius, and maintain uninterrupted operations for healthy devices - without rebuilding device identities. ADR propagates the revocation state to IoT Hub, blocking revoked devices until they’re re-provisioned. When a subset of devices requires isolation, policy revocation allows operators to decommission an entire trust anchor rather than managing individual devices. By mapping a specific Issuing CA to a single ADR policy, organizations gain a high-precision containment mechanism. In a single action, an operator can invalidate a compromised CA and then plan for a staged credential rollover across the entire segment. ADR automatically enforces this updated trust chain within IoT Hub, ensuring that only devices with newly issued certificates can connect. This makes large‑scale certificate rotation predictable, controlled, and operationally simple. Revoking the certificate for a single ADR Device on Azure Portal Flexible Options to renew Device Certificates Managing X.509 certificates at scale doesn’t stop once a device is onboarded. Operational certificates are short-lived by design, ensuring devices do not rely on long-lived credentials for authentication. In real-world IoT fleets, devices are often intermittently connected, deployed in hard-to-reach locations, and expected to run continuously - making certificate renewal one of the most operationally challenging parts of device security. Azure IoT Hub now enables device certificate renewal directly through IoT Hub, complementing the role of Device Provisioning Service (DPS). While DPS remains the solution for first-time device onboarding and certificate issuance, IoT Hub renewal is designed for the steady state - keeping already-connected devices securely authenticated over time without introducing downtime. IoT Hub certificate renewal follows similar patterns as other device-initiated operations such as twin updates and direct methods. With this capability, devices can request a new certificate as part of normal operation, using the same secure MQTT connection they already rely on. Support for IoT Hub and Device Provisioning Service (DPS) Device SDKs Managing credential issuance and renewals at scale is only possible if devices can handle their own credential lifecycles. We’ve added Certificate Signing Request (CSR) support to our C, C# (.NET), Java, Python, and Embedded device SDKs for IoT Hub and Device Provisioning Service (DPS). Beyond developer convenience, this provides multiple device-initiated paths for certificate renewal and trust-chain agility. Devices can generate CSRs and request newly signed X.509 certificates through IoT Hub or DPS as part of normal operation. This allows security teams to rotate and update certificates in the field without touching the hardware, keeping fleets secure as certificate authorities and policies evolve over time. Customer Feedback from Preview We’re grateful to the customers and partners who participated in the preview and shared valuable feedback along the way. Hear some of what our customers had to say: "The availability of a built-in certificate manager is a great upgrade in keeping the IoT space more secure."— Martijn Handels, CTO, Helin Data “Secure data is the starting line for industrial AI. With Azure certificate management, at CogitX we can ingest manufacturing signals safely and confidently - then use domain‑aware models to deliver real‑time insights and agentic workflows that improve throughput, quality, and responsiveness.” – Pradeep Parappil, CEO, CogitX Get Started Explore the new capabilities in preview today and start building the next generation of connected operations with Azure IoT Hub and Azure Device Registry: Get Started with Certificate Management in Preview.Advancing Firmware Security: Fleet Visibility and New Capabilities in Firmware Analysis
When we announced general availability of firmware analysis enabled by Azure Arc last October, our goal was clear: help organizations gain deep visibility into the security of the firmware that powers their IoT, OT, and network devices. Since then, adoption has continued to grow as customers use firmware analysis to uncover vulnerabilities, inventory software components, and secure their software supply chain. Leading into the Hannover Messe (HMI) 2026 conference, we’re excited to share the next wave of firmware analysis capabilities, delivering enhancements that help customers connect firmware risk to real-world fleet impact, prioritize vulnerabilities more effectively, scale to larger and more complex firmware images, and expand security analysis for UEFI-based platforms. These updates are driven directly by customer feedback and by the rapidly evolving threat landscape facing embedded and edge devices. Connecting Firmware Risk to Your Deployed Fleet with Azure Device Registry (Preview) Securing connected devices doesn’t stop at identifying vulnerabilities in firmware—it requires understanding where those vulnerabilities exist in your deployed fleet and which devices are affected. We’re excited to announce a new preview integration between firmware analysis enabled by Azure Arc and Azure Device Registry, bringing fleet-level visibility of IoT and OT devices directly into the firmware analysis experience. This helps customers quickly understand how many devices and assets are running a given firmware image, and which ones may be exposed to known security issues. From firmware insights to fleet impact Firmware analysis helps customers uncover security risks hidden deep inside the firmware running IoT, OT, and network devices—risks such as known CVEs, outdated open-source components, weak cryptography, and insecure configurations. Until now, these insights were primarily scoped to the firmware image itself. With this new preview integration, firmware analysis now connects directly to Azure Device Registry, allowing customers to: See how many devices from IoT Hub integration with ADR (preview) and assets from Azure IoT Operations are associated with a specific analyzed firmware image Understand the real-world blast radius of vulnerabilities discovered in firmware Quickly identify which devices may require patching, mitigation, or isolation This preview bridges an important gap between security analysis and operational decision-making. What’s included in this preview With this release, we’re introducing new fleet-level context directly into the firmware analysis experience: A new Devices + Assets count column in the firmware analysis workspace showing how many Azure Device Registry devices and assets are running each analyzed firmware image A click-through experience that lets users view the list of affected devices and assets in Azure Device Registry Visibility spanning both: Devices connected via IoT Hub Assets managed through Azure IoT Operations This information is derived by correlating firmware metadata with device and asset inventory in Azure Device Registry, giving customers immediate insight into deployment exposure. Key use cases Identify vulnerable devices at scale: When critical CVEs are discovered in a firmware image, customers can immediately see how many deployed devices are impacted—without manually correlating spreadsheets, tools, or inventories. Prioritize remediation actions: With fleet visibility, teams can decide whether to patch devices, temporarily isolate affected devices from the network, or disable devices that pose unacceptable risk. Bridge security and operations teams: Security teams gain clear insight into where vulnerabilities exist, while operations teams can quickly act on specific devices and assets—all within the Azure portal. This integration is especially valuable in environments where downtime, safety, or regulatory compliance matter—such as manufacturing, energy, telecommunications, and critical infrastructure. Prioritizing Vulnerabilities with Enhanced CVE Metadata (Preview) The number of publicly disclosed vulnerabilities continues to rise year over year, making it increasingly difficult for security teams to determine which CVEs truly require urgent action. Simply knowing that a vulnerability exists is no longer enough—teams need context to prioritize remediation efforts. With this release, firmware analysis now provides richer metadata for each discovered CVE, helping customers focus on vulnerabilities that pose the greatest real-world risk. New CVE metadata includes: CISA Known Exploited Vulnerabilities (KEV) status – Indicates whether a CVE is listed in the CISA KEV catalog, signaling that the vulnerability is actively exploited in the wild. EPSS score (Exploit Prediction Scoring System) – A data-driven probability score that estimates the likelihood of a vulnerability being exploited in the next 30 days, complementing traditional severity metrics by focusing on exploitation likelihood rather than impact alone. Additional vulnerability context, including CVSS vectors and base scores, CWE classifications, and expanded metadata to support filtering and analysis. Together, these enhancements make it easier to triage findings, align remediation with risk, and communicate priorities across security, engineering, and product teams. Faster Performance for Large and Complex Firmware Images As firmware analysis adoption has grown, we’ve seen customers analyze increasingly large and complex firmware images—particularly in domains like networking equipment, where a single image can generate thousands of findings. To support these scenarios, we’ve made architectural enhancements to the service that significantly improve performance when working with large result sets. Key improvements include: Up to 90% reduction in load times of analysis results, especially for firmware images producing 10,000+ findings More responsive filtering and exploration of results These changes ensure that firmware analysis remains fast and usable at scale, even for complex network and infrastructure firmware images. Expanding UEFI Firmware Analysis (Preview) Modern devices increasingly rely on UEFI firmware as a foundational security boundary. In this release, we’re expanding our UEFI analysis capabilities to provide deeper visibility into UEFI executables and components. New UEFI-focused capabilities include: Detection of OpenSSL libraries and related CVEs within UEFI firmware Binary hardening analysis for UEFI executables, including detection of proper configuration of Data Execution Prevention (DEP) memory protection Continued support for discovering cryptographic material in UEFI images, including embedded certificates and keys This preview allows customers to evaluate the new capabilities, provide feedback, and help shape future enhancements in this area. Note: UEFI SBOM and binary analysis features are currently in preview and intended for evaluation and feedback. Bulk Export of Analysis Results for Supply Chain Collaboration We also recently released a highly requested feature that makes it easier to share firmware analysis results with partners and suppliers. Customers can now: Bulk download analysis results across one or more firmware images Export results as CSV files packaged into a ZIP archive This capability simplifies workflows such as sharing findings with device manufacturers or firmware suppliers, integrating results into downstream analysis or reporting pipelines, and supporting software supply chain security and compliance processes. Looking Ahead We’re excited about the progress we’ve made with this release and what it means for customers securing IoT, OT, and network devices. From connecting firmware risk to fleet-level impact with Azure Device Registry, to richer vulnerability prioritization, improved scalability, and deeper UEFI analysis—these enhancements reinforce firmware analysis as a critical tool for addressing some of the most challenging blind spots in modern infrastructure security. Firmware security is foundational to trustworthy systems—especially as edge devices continue to play a central role in industrial operations, networking, and data collection. If you’re already using firmware analysis and Azure Device Registry, the ADR integration preview will appear directly within the firmware analysis experience as it rolls out. We look forward to your feedback as we continue building secure, observable, and manageable digital operations with Azure. As always, we value your feedback, so please let us know what you think.
