Azure Sphere OS version 26.06 is now available
Azure Sphere OS version 26.06 is now available in the Retail feed. This release includes updates to Azure Sphere OS only; it does not include an updated SDK. If your devices are connected to the internet, they will receive the updated OS from the cloud. The 26.06 OS Retail release includes significant underlying build system updates and addresses several CVEs. For self-help inquiries or technical support, review the Azure Sphere support options.Azure Sphere is updating its Certificate and Trusted Key Stores
Azure Sphere is updating the keys that it uses to verify service identities, and that images have been securely signed, as part of a regular security best practises refresh cycle. Customers do not need to take any action for in-field production devices, though should be aware that devices will reboot twice when installing this update. For customers with certain manufacturing, development, or field servicing scenarios, you may need to take extra steps to ensure that newly signed images are trusted by the device. What is an image signing key used for, and why update it? Azure Sphere devices only trust signed images, and that signature is verified every time software is loaded. Every production software image on the device – including the bootloader, the Linux kernel, the OS, and customer applications, as well as any capability file used to unlock development on, or field servicing of devices – is signed by the Azure Sphere Security Service (AS3), based on image signing keys held by Microsoft. As for any modern public/private key system, keys are rotated every few years to reduce the risk of exploitation. Note that once an image is signed, it generally remains trusted by the device. There is a separate mechanism based on one-time programmable fuses to revoke older OS software with known vulnerabilities such as DirtyPipe and prevent rollback attacks – we used this most recently in the 22.09 OS release. When is this happening? The next update to the image signing certificate is targeted for March 30th. When that happens, all uses of AS3 to generate new production-signed application images or capabilities will result in images signed using the new key. Ahead of that, we will update the trusted key-store (TKS) of Azure Sphere devices, so that the TKS incorporates all existing keys and the new keys. This update will be automatically applied to every connected device over-the-air. Note that device TKS updates happen ahead of any pending updates to OS or application images. In other words, if a device comes online that is due to receive a new-key-signed application or OS, it will first update the TKS so that it trusts that application or OS. We are targeting update of the TKS for March 23rd. The next time that each Azure Sphere device checks for updates (or up to 24 hours later if using the update deferral feature), the device will apply the TKS update and reboot. The TKS update is independent of an OS update, and it will apply to devices using both the retail and retail-eval feeds. Do I need to take any action? No action is required for production-deployed devices. There are three non-production scenarios where you may need to take extra steps to ensure that newly signed images are trusted by the device. The first is for manufacturing. If you update and re-sign the application image you use in manufacturing, but you are using an old OS image with an old TKS, then that OS will not trust the application. Follow these instructions to sideload the new TKS as part of manufacturing. The second is during development. If you have a dev board that you are sideloading either a production-signed image or a capability to, and it has an old TKS, then it will not trust that capability or image. This may make the “enable-development” command fail with an error such as “The device did not accept the device capability configuration.” This can be remedied by connecting the device to a network and checking that the device is up-to-date. Another method is to recover the device – the recovery images always include the latest TKS. The third is for field servicing. During field servicing you need to apply a capability to the device as it has been locked down after manufacturing using the DeviceComplete state. However, if that capability is signed using the new image signing key and the device has been offline - so it has not updated its TKS - then the OS will not trust the capability. Follow these instructions to sideload the new TKS before applying the field servicing capability.Azure Sphere is Retiring in 2031 - What you need to know
On 20 March 2026, Microsoft publicly announced that the Azure Sphere service is retiring and will stop supporting customer application, OS, bug and security updates, along with DAA certificate issuance, on 31 July 2031. This date will also mark the end of extended support for the MT3620 microcontroller. Why is this happening? Azure Sphere pioneered secure IoT connectivity, combining bespoke hardware, a secure Linux-based OS, and a cloud-based security service, elevating industry standards for microcontroller security. As the IoT landscape advances, customers are now able to access secure microcontrollers from a wide range of silicon vendors and pair these with Microsoft next-generation solutions for greater flexibility and scalability. Key dates to be aware of Through 31 July 2031, Azure Sphere devices will continue to operate as they do today. After this date, devices will no longer receive application or OS updates, bug fixes, or security patches. After 31 July 2031, The Azure Sphere Service, including Device Attestation and Authentication (DAA), will be retired, which will affect device authentication and connectivity to Azure IoT and other upstream services. On 31 July 2026, the MT3620 silicon will become end-of-life, as announced by the silicon manufacturer. These timelines are intentionally long to allow for thoughtful planning and validation. What this means for your solutions Existing devices can continue running throughout the support period without interruption. Solutions that need to operate beyond the retirement timeframe will require updated hardware designs using alternative silicon. Customers with OEM license agreements will receive formal notice regarding support timelines. If additional production is required ahead of 2031, there will be a final opportunity by 31 July 2026 to renew existing agreements. Planning ahead Many customers are already using this period to refresh device designs, align future hardware roadmaps, and evaluate modern Azure IoT services for connectivity, identity, and device management. Microsoft and our partners are available to support you as you assess options and plan forward. Recommended action Plan for hardware redesign to replace MT3620 silicon in future product iterations. Consider PSA/SESIP Level 3+, or similar, certified silicon as a guideline for silicon with similar security properties. Express any required purchasing intent and OEM license renewals via Avnet by 31 July 2026, if additional production is needed. Evaluate alternative IoT solutions, including: Azure IoT Hub with Azure Device Registry (ADR) and X.509 Certificate Management for Device Identity and Fleet Management. Azure IoT Hub for Device Connectivity and Data Ingestion. Device Update for Azure IoT Hub for Firmware Updates. Microcontrollers with a PSA Certified Attestation API, or similar, for integration into your chosen Attestation solution. FIPS 140-3 compliant crypto libraries for trustworthy At-rest and In-transit Data Encryption. You can find further information about alternative Azure IoT services at the Azure IoT Documentation and Azure IoT solutions pages. Help and support If you have questions, get answers from community experts in Microsoft Q&A. If you have a support plan and need technical help, create a support request.Azure Sphere OS version 25.12 is now available for evaluation
Azure Sphere OS version 25.12 is now available for evaluation in the Retail Eval feed. Whilst this release encompasses no customer-facing changes, it represents significant under-the-hood build system changes, as such, this release will operate for an extended evaluation period, until February 2026, enabling additional time for customer evaluation testing. Following this period, a second evaluation release, 26.02, will be launched to the Retail Eval feed for the standard 14-day testing period, and subsequently promoted to the Retail feed. This means that 25.12 will not be promoted to the Retail feed, and that the next Retail release will be 26.02. During this time, please verify that your applications and devices operate properly with both the 25.12, and subsequent 26.02 release, before it is deployed broadly to devices in the Retail feed. The 25.12 OS Retail Eval release includes significant underlying build system updates. Learn more: For more information on Azure Sphere OS feeds and setting up an evaluation device group, see Azure Sphere OS feeds and Set up devices for OS evaluation. For self-help inquiries or technical support, review the Azure Sphere support options.Azure Sphere OS version 25.10 is now available
Azure Sphere OS version 25.10 is now available in the Retail feed. This release includes updates to Azure Sphere OS only; it does not include an updated SDK. If your devices are connected to the internet, they will receive the updated OS from the cloud. The 25.10 OS Retail release includes quality and underlying build system updates. For self-help inquiries or technical support, review the Azure Sphere support options.Azure Sphere OS version 25.10 is now available for evaluation
Azure Sphere OS version 25.10 is now available for evaluation in the Retail Eval feed. The retail evaluation period for this release provides 14 days (about 2 weeks) of testing. During this time, please verify that your applications and devices operate properly with this release before it is deployed broadly to devices in the Retail feed. The 25.10 OS Retail Eval release includes quality and underlying build system updates. For more information on Azure Sphere OS feeds and setting up an evaluation device group, see Azure Sphere OS feeds and Set up devices for OS evaluation. For self-help inquiries or technical support, review the Azure Sphere support options.Azure Sphere May 2025 Services release is now available
Today we are releasing an update to the Azure Sphere Services, comprising: Ability to pause or re-enable Legacy access Change to expired certificate download behavior Ability to block devices from receiving Azure Sphere issued certificates There are no OS or SDK updates in this release. Ability to pause or re-enable Legacy access You can now pause Azure Sphere (Legacy) tenant operations using the Azure portal, and you also reverse this by enabling Azure Sphere (Legacy) if paused. Azure Sphere (Legacy) is retiring on 27 September 2027, and users must migrate to Azure Sphere (Integrated). The ability to pause and enable Legacy operations assists with migration in the following ways: Once you have migrated Legacy use cases, you can pause the Legacy interface to assure yourself that there are no remaining use cases for Legacy, because any use of Legacy will now result in an error You can re-enable Legacy temporarily to enable you to migrate any remaining use cases that you discover For security, once you know that Legacy is no longer needed, we recommend you should pause Legacy to avoid any operations being conducted via that interface As of this release, newly created Azure Sphere catalogs will have Legacy access paused by default. Catalogs created by integrating an existing Azure Sphere Legacy tenant will continue to have Legacy access enabled by default, to enable migration to occur without disruption. Change to expired certificate download behavior Azure Sphere services will no longer allow you to download expired tenant/catalog certificates. This does not impact production use cases since those certificates are already expired. The metadata for those certificates is still available when viewing your tenant/catalog's list of certificates, but requests for the certificate body via the Legacy CLI, Integrated CLI and Portal will result in a "null" or "not found" response. Ability to block devices from receiving Azure Sphere issued certificates Customers may now block devices from receiving device certificates from Azure Sphere via a support request. This capability might be useful in instances such as if a device becomes lost or stolen, or if an organization wishes to decommission a device. This would prevent services like Azure IoT Hub, which are configured to trust Azure Sphere-issued certificates, from trusting such devices. Please reach out to azsppgsup@microsoft.com if you need this capability.Azure Sphere 25.04 SDK release is now available
Today we are releasing an update to the Azure Sphere SDK and associated tooling, comprising: Updated Azure Sphere SDK 25.04 for Windows and for Linux Updated the azure-sphere extension 1.0.2 for Azure CLI Updated Azure Sphere extensions for Visual Studio and for Visual Studio Code There are no OS or services updates in this release. New and changed features in the 25.04 SDK The 25.04 release of the Azure Sphere SDK includes the following changes: Addition of SDK support for Ubuntu 24.04 LTS The 25.04 SDK adds support for Ubuntu 24.04 LTS. The Linux SDK installer can determine the LTS version of Ubuntu you are running and download and install the appropriate SDK. End of SDK support for Ubuntu 20.04 LTS Ubuntu 20.04 is no longer supported by Canonical as of May 2025, so we have removed support for Ubuntu 20.04 from the Azure Sphere SDK. Error message update for azsphere register-user command The azsphere register-user command in the Azure Sphere (Legacy) CLI is no longer supported. We have updated the error message in case this command is used to be clearer. Alternative methods should be used to register Azure Sphere (Legacy) users. Addition of message regarding retirement of Azure Sphere (Legacy) The Azure Sphere (Legacy) interfaces, including the Azure Sphere (Legacy) API (also known as PAPI) and the Azure Sphere (Legacy) CLI (also known as azsphere), will be retired on 27 September 2027. A retirement message has been added to the Azure Sphere CLI and will be displayed when you run the --help parameter for a command. For more information about retirement and how to migrate to Azure Sphere (Integrated), see this blog post. Removal of Azure Sphere Classic CLI The Azure Sphere classic CLI is an old version of the CLI that predated the Legacy CLI. We announced retirement of this in 2023, and this version is now retired and removed from the SDK. We recommend using Azure Sphere (Integrated). Updates to the azure-sphere extension for Azure CLI The azure-sphere extension for the Azure CLI version 1.0.2 is now available. This includes support for the az sphere image-package pack-application command and other improvements. Updates to Visual Studio and Visual Studio Code extensions This release includes the following updates to the Azure Sphere extensions for Visual Studio and for Visual Studio Code: Updates to the user interfaces to support the Azure Sphere extension for the Azure CLI Bug fixes For technical inquiries, please visit Microsoft Q&A or Stack Overflow. If you require technical support and have a support plan, please submit a support ticket in Microsoft Azure Support or work with your Microsoft Technical Account Manager. If you would like to purchase a support plan, please explore the Azure support plans.Azure Sphere – Certificate store update
Update 26 February 2025: We have released an update which will result in all devices (regardless of whether they are on the Retail or Retail Eval feed) installing this update and rebooting. This update does not change the OS version. Azure Sphere is updating the set of certificates it uses to establish trust with TLS endpoints, following best practices for security. The only impact on production devices is that they will experience a reboot when we release the new certificate store to devices, similar to the reboot during an OS update or an update to the trusted key store. What is a certificate store used for, and why update it? Azure Sphere devices store a public root certificate like any device or browser would to establish an HTTPS connection with an endpoint that is signed with a publicly trusted certificate. The Azure IoT platform transitioned from the Baltimore CyberTrust Root to DigiCert Global Root G2. These certificates are primarily intended for establishing connections to Azure IoT services, such as the Device Provisioning Service and IoT Hub, but are also useful for apps connecting to any HTTPS service that chains up to these same public trust certificates. While Azure IoT transitioned to DigiCert Global Root G2, the Baltimore CyberTrust Root certificate has remained valid, and has been included in the Azure Sphere certificate store for compatibility. Certificate management is a strength of the Azure Sphere platform, as this is managed by Microsoft on your behalf. However, this certificate is expiring on May 12 th 2025, and removing it from the certificate store is a best practice to prevent connectivity to improperly configured web services relying on expired certificates. When is this happening? The next update to the image signing certificate is targeted for February 26 th 2025. When that happens, all HTTPS attempts to services using the Baltimore CyberTrust Root will cease to function. Azure IoT services have already transitioned to the DigiCert Global Root G2, along with Azure Sphere services so this should not impact any Microsoft managed connectivity. However, it is a good practice to audit all app endpoint targets prior to this rollout to ensure any services your app targets do not still utilize the Baltimore CyberTrust Root certificate. If you do have a dependency and would like to request an extension for this update, please contact us at AZSPPGSUP@microsoft.com. After this update is released, the next time that each Azure Sphere device checks for updates (or up to 24 hours later if using the update deferral feature), the device will apply the certificate store update and reboot. The certificate store update is independent of an OS update, and it will apply to devices using both the retail and retail-eval feeds. Do I need to take any action? No action is required for production-deployed devices; however, we recommend auditing all services specific to your app that might utilize the Baltimore CyberTrust Root certificate.
