Update bootloader in Win10 Iot Ent LTSC (21H2) applied images?
The product I work on uses Windows 10 IoT Enterprise LTSC (21H2). I am trying to update the bootloader in the extracted and applied images to the version signed in 2023, to work around the issue with the default bootloader signatures expiring in 2026 (see KB5012170). KB5012170 updates the bootloader on an installed system. I can apply this hotfix to an installed device, and the bootloader on the hidden partition indeed gets updated. However, if I sysprep and extract the image from this machine, and apply it to a new machine, after using bcdboot to set the boot image, the new machine ends up with the old expiring bootloader installed. It seems KB5012170 only updates the "live" version of the bootloader on the hidden partition. It does not update the bootloader that ends up in the extracted image? Updating to Windows 10 IoT 22H2 or Windows 11 IoT is not an option for us for now. I do not want to have to require users to always install KB5012170 every time they install our product moving forward. I would like newly created images of our product to contain the updated bootloader by default. But I cannot find a way to do this. KB5012170 seems to be the only way to get the updated bootloader for our edition of Windows. Is there another way to get the updated bootloader I am missing? Is there a tool or trick that I am missing that would allow us to update the bootloader in the extracted, applied image without requiring a subsequent install of KB5012170?
FPGA vs ASIC for AI at the Edge: What factors influence your hardware choice?
As AI continues to move closer to edge devices, choosing the right hardware platform has become an important design decision. While both FPGAs and ASICs have their strengths, the best choice often depends on the application's requirements. Here are some of the key factors that engineering teams typically evaluate: Performance and latency requirements Power efficiency Development cost and NRE Time-to-market Production volume Need for future hardware updates FPGAs offer flexibility for rapid prototyping and evolving workloads, making them well-suited for early-stage development. ASICs, on the other hand, can provide significant advantages in performance, power consumption, and cost efficiency for high-volume production. I recently came across a technical article that explains these trade-offs in a structured way and found it useful as a reference: https://www.signoffsemiconductors.com/asic-vs-fpga/ I'd be interested to hear how others approach this decision. Have you migrated a design from FPGA to ASIC? What factors influenced your choice? Are there workloads where you would always choose one over the other?Azure 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.com
Smaller 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.Resource 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 Quickstart: explore-iot-operations/quickstart at main · Azure-Samples/explore-iot-operations 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 Unlock Industrial Intelligence | Microsoft Hannover Messe 2026 From pilots to production: How Microsoft and partners are accelerating intelligent operations 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 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.Azure IoT Operations 2603 is now available: Powering the next era of Physical AI
Industrial AI is entering a new phase. For years, AI innovation has largely lived in dashboards, analytics, and digital decision support. Today, that intelligence is moving into the real world, onto factory floors, oil fields, and production lines, where AI systems don’t just analyze data, but sense, reason, and act in physical environments. This shift is increasingly described as Physical AI: intelligence that operates reliably where safety, latency, and real‑world constraints matter most. With the Azure IoT Operations 2603 (v1.3.38) release, Microsoft is delivering one of its most significant updates to date, strengthening the platform foundation required to build, deploy, and operate Physical AI systems at industrial scale. Why Physical AI needs a new kind of platform Physical AI systems are fundamentally different from digital‑only AI. They require: Real‑time, low‑latency decision‑making at the edge Tight integration across devices, assets, and OT systems End‑to‑end observability, health, and lifecycle management Secure cloud‑to‑edge control planes with governance built in Industry leaders and researchers increasingly agree that success in Physical AI depends less on isolated models, and more on software platforms that orchestrate data, assets, actions, and AI workloads across the physical world. Azure IoT Operations was built for exactly this challenge. What’s new in Azure IoT Operations 2603 The 2603 release delivers major advancements across data pipelines, connectivity, reliability, and operational control, enabling customers to move faster from experimentation to production‑grade Physical AI. Cloud‑to‑edge management actions Cloud‑to‑edge management actions enable teams to securely execute control and configuration operations on on‑premises assets, such as invoking methods, writing values, or adjusting settings, using Azure Resource Manager and Event Grid–based MQTT messaging. This capability extends the Azure control plane beyond the cloud, allowing intent, policy, and actions to be delivered reliably to physical systems while remaining decoupled from protocol and device specifics. For Physical AI, this closes the loop between perception and action: insights and decisions derived from models can be translated into governed, auditable changes in the physical world, even when assets operate in distributed or intermittently connected environments. Built‑in RBAC, managed identity, and activity logs ensure every action is authorized, traceable, and compliant, preserving safety, accountability, and human oversight as intelligence increasingly moves from observation to autonomous execution at the edge. No‑code dataflow graphs Azure IoT Operations makes it easier to build real‑time data pipelines at the edge without writing custom code. No‑code data flow graphs let teams design visual processing pipelines using built‑in transforms, with improved reliability, validation, and observability. Visual Editor – Build multi-stage data processing systems in the Operations Experience canvas. Drag and connect sources, transforms, and destinations visually. Configure map rules, filter conditions, and window durations inline. Deploy directly from the browser or define in Bicep/YAML for GitOps. Composable Transforms, Any Order – Chain map, filter, branch, concatenate, and window transforms in any sequence. Branch splits messages down parallel paths based on conditions. Concatenate merges them back. Route messages to different MQTT topics based on content. No fixed pipeline shape. Expressions, Enrichment, and Aggregation – Unit conversions, math, string operations, regex, conditionals, and last-known-value lookups, all built into the expression language. Enrich messages with external data from a state store. Aggregate high-frequency sensor data over tumbling time windows to compute averages, min/max, and counts. Open and Extensible – Connect to MQTT, Kafka, and OpenTelemetry (OTel) endpoints with built-in security through Azure Key Vault and managed identities. Need logic beyond what no-code covers? Drop a custom Wasm module (even embed and run ONNX AI ML models) into the middle of any graph alongside built-in transforms. You're never locked into declarative configuration. Together, these capabilities allow teams to move from raw telemetry to actionable signals directly at the edge without custom code or fragile glue logic. Expanded, production‑ready connectivity The MQTT connector enables customers to onboard MQTT devices as assets and route data to downstream workloads using familiar MQTT topics, with the flexibility to support unified namespace (UNS) patterns when desired. By leveraging MQTT’s lightweight publish/subscribe model, teams can simplify connectivity and share data across consumers without tight coupling between producers and applications. This is especially important for Physical AI, where intelligent systems must continuously sense state changes in the physical world and react quickly based on a consistent, authoritative operational context rather than fragmented data pipelines. Alongside MQTT, Azure IoT Operations continues to deliver broad, industrial‑grade connectivity across OPC UA, ONVIF, Media, REST/HTTP, and other connectors, with improved asset discovery, payload transformation, and lifecycle stability, providing the dependable connectivity layer Physical AI systems rely on to understand and respond to real‑world conditions. Unified health and observability Physical AI systems must be trustworthy. Azure IoT Operations 2603 introduces unified health status reporting across brokers, dataflows, assets, connectors, and endpoints, using consistent states and surfaced through both Kubernetes and Azure Resource Manager. This enables operators to see—not guess—when systems are ready to act in the physical world. Optional OPC UA connector deployment Azure IoT Operations 2603 introduces optional OPC UA connector deployment, reinforcing a design goal to keep deployments as streamlined as possible for scenarios that don’t require OPC UA from day one. The OPC UA connector is a discrete, native component of Azure IoT Operations that can be included during initial instance creation or added later as needs evolve, allowing teams to avoid unnecessary footprint and complexity in MQTT‑only or non‑OPC deployments. This reflects the broader architectural principle behind Azure IoT Operations: a platform built for composability and decomposability, where capabilities are assembled based on scenario requirements rather than assumed defaults, supporting faster onboarding, lower resource consumption, and cleaner production rollouts without limiting future expansion. Broker reliability and platform hardening The 2603 release significantly improves broker reliability through graceful upgrades, idempotent replication, persistence correctness, and backpressure isolation—capabilities essential for always‑on Physical AI systems operating in production environments. Physical AI in action: What customers are achieving today Azure IoT Operations is already powering real‑world Physical AI across industries, helping customers move beyond pilots to repeatable, scalable execution. Procter & Gamble Consumer goods leader P&G continually looks for ways to drive manufacturing efficiency and improve overall equipment effectiveness—a KPI encompassing availability, performance, and quality that’s tracked in P&G facilities around the world. P&G deployed Azure IoT Operations, enabled by Azure Arc, to capture real-time data from equipment at the edge, analyze it in the cloud, and deploy predictive models that enhance manufacturing efficiency and reduce unplanned downtime. Using Azure IoT Operations and Azure Arc, P&G is extrapolating insights and correlating them across plants to improve efficiency, reduce loss, and continue to drive global manufacturing technology forward. More info. Husqvarna Husqvarna Group faced increasing pressure to modernize its fragmented global infrastructure, gain real-time operational insights, and improve efficiency across its supply chain to stay competitive in a rapidly evolving digital and manufacturing landscape. Husqvarna Group implemented a suite of Microsoft Azure solutions—including Azure Arc, Azure IoT Operations, and Azure OpenAI—to unify cloud and on-premises systems, enable real-time data insights, and drive innovation across global manufacturing operations. With Azure, Husqvarna Group achieved 98% faster data deployment and 50% lower infrastructure imaging costs, while improving productivity, reducing downtime, and enabling real-time insights across a growing network of smart, connected factories. More info. Chevron With its Facilities and Operations of the Future initiative, Chevron is reimagining the monitoring of its physical operations to support remote and autonomous operations through enhanced capabilities and real-time access to data. Chevron adopted Microsoft Azure IoT Operations, enabled by Azure Arc, to manage and analyze data locally at remote facilities at the edge, while still maintaining a centralized, cloud-based management plane. Real-time insights enhance worker safety while lowering operational costs, empowering staff to focus on complex, higher-value tasks rather than routine inspections. More info. A platform purpose‑built for Physical AI Across manufacturing, energy, and infrastructure, the message is clear: the next wave of AI value will be created where digital intelligence meets the physical world. Azure IoT Operations 2603 strengthens Microsoft’s commitment to that future—providing the secure, observable, cloud‑connected edge platform required to build Physical AI systems that are not only intelligent, but dependable. Get started To explore the full Azure IoT Operations 2603 release, review the public documentation and release notes, and start building Physical AI solutions that operate and scale confidently in the real world.Will Intune device-only subscription get additional value in FY27
Will the Intune device-only subscription (Microsoft Intune announces device-only subscription for shared resources | Microsoft Community Hub) get the additional features which Intune P1 will get in FY27 (Microsoft 365 adds advanced Microsoft Intune solutions at scale - Microsoft Intune Blog), Intune Remote Help, Intune Advanced Analytics and Intune P2? This would have a huge impact of our planning how to manage special purpose devices in production environments without any user affinity. Deploying security and configuration settings, Windows Autopilot for Windows IoT Enterprise LTSC kiosk deployment, Windows Autopatch (servicing), Remote Help and FOTA for Zebra devices would be drivers to add these production devices to Intune.
