Arrow Intelligent Solutions blog

Don’t Panic, But Don’t Ignore It Either

I spend a lot of time talking about Windows products going End of Life (EOL) or End of Support (EOS), but this time the conversation is a little different. Secure Boot certificates were not something most customers ever thought about until Microsoft announced the original certificates would begin expiring in June 2026. Since then, I’ve been getting a steady stream of questions.

The first question almost everyone asks is: “Are my devices going to stop booting?”

The short answer is no. In most cases, devices are not suddenly going to fail in June 2026 or turn into bricks overnight. But for OEMs building or supporting Windows IoT devices with Secure Boot enabled, especially long-life LTSC systems, this is something you should understand and start planning for now rather than later.

First, What Is Secure Boot?

Secure Boot has been around since the Windows 8 days, but unless you work directly with firmware, BIOS configuration, or device imaging, there is a good chance you have never really thought much about it.

At a very high level, Secure Boot helps protect the device before Windows even starts loading. It uses trusted certificates stored in the firmware to verify that the boot software is legitimate and has not been tampered with. If something untrusted tries to load during startup, Secure Boot is designed to block it. Think of it as a trusted handshake between the firmware and the operating system during boot.

Now here’s the important part for the embedded and IoT world. Unlike the commercial PC space, where Secure Boot became a major Windows 11 requirement, in the Windows IoT LTSC world, Secure Boot has often remained optional. A lot of embedded devices out there never enabled it in the first place. That means there are OEMs reading this blog right now who probably don’t need to worry about this at all.

But there are also plenty of OEMs who intentionally enabled Secure Boot because they wanted a stronger security posture for devices running in medical, retail, industrial, transportation, kiosk, or other dedicated-purpose environments. If that’s your deployment, keep reading.

So, What Is Expiring?

Microsoft originally issued Secure Boot certificates back in 2011, and those certificates begin expiring in June 2026. Microsoft is now replacing them with updated 2023 certificates that are already being distributed through Windows updates and newer servicing processes.

That’s really what this announcement is about. Microsoft is refreshing the trust infrastructure behind Secure Boot. The confusion comes from assuming expired certificates automatically mean systems stop functioning. That is not how this works.

What Happens If You Do Nothing?

Again, your devices will probably keep booting and running normally for quite some time. That’s the important part to understand because there is a lot of unnecessary panic floating online right now.

The bigger issue is that devices still relying on the older Secure Boot certificates may eventually lose the ability to receive future protections tied to the Windows boot process. Over time, this can affect boot-level security mitigations, revocation lists, and other updates tied to the Secure Boot trust chain.

For a normal office laptop that gets replaced every few years, maybe that’s just another IT maintenance task. For a Windows IoT LTSC device expected to remain deployed in the field for 7 or 10 years, it becomes a lifecycle planning issue.

Why Embedded and IoT OEMs Need to Pay Attention?

One thing I’ve learned over the years in the embedded space is that IoT devices do not behave like normal PCs. They are often offline, air-gapped, heavily locked down, or running in environments where updates undergo lengthy validation cycles before deployment.

I’ve seen situations in manufacturing environments where even a minor update requires months of testing before getting approvals. I’ve seen medical devices where servicing changes involve regulatory review. I’ve seen retail and kiosk systems where the image deployed today may remain mostly unchanged for years. That’s why this matters more in the IoT LTSC world.

If your devices are online and receiving normal Windows updates, the process may be straightforward. But if your systems are offline, tightly managed, or using custom firmware configurations, you should start reviewing this now rather than wait until the expiration date nears.

The First Thing I Would Do

I’d start with one simple question: “Did we enable Secure Boot on this product?”

If Secure Boot is not enabled, this may be a non-event for you. If Secure Boot is enabled, then I recommend you start inventorying affected systems, reviewing servicing methods, checking firmware versions, and validating whether the updated certificates are already being applied through your update process.

To check if Secure Boot is enabled, follow the path below. Also review your original OEM image and firmware configuration documentation:
 
Windows Security > Device Security > Secure Boot

Do not assume that because Microsoft released an update, everything will automatically work perfectly across every hardware platform and image configuration. Some systems may also require firmware updates in addition to standard Windows servicing updates, which is why OEMs should carefully validate the process on production hardware before broad deployment.

What Devices Should OEMs Be Most Concerned About?

The devices that deserve the closest attention are those in which Secure Boot was intentionally enabled by the OEM. Here’s a comprehensive list:

• Windows 11 IoT Enterprise LTSC 2024 devices with Secure Boot enabled
  These are probably the most important systems to review. While Secure Boot was optional in the Windows IoT LTSC world, many OEMs enabled it intentionally for stronger device security.
• Windows 11 IoT Enterprise GAC devices have not yet been updated to newer builds like 25H2
  These systems should be carefully reviewed to ensure the newer Secure Boot infrastructure is being applied correctly.
• Windows 10 IoT Enterprise devices using Secure Boot
  These systems are also part of the older Secure Boot certificate chain and should be included in your review process.
• Older Windows 8-based or legacy embedded systems with Secure Boot enabled
  These devices are often forgotten because they have been running reliably for years, but they still rely on the older certificate infrastructure.
• Air-gapped, offline, or tightly managed devices
  These are the systems I worry about the most. If your devices are disconnected from normal update processes or use highly controlled servicing procedures, you need a clear plan to validate and deploy the updated certificates manually.
• Devices with long deployment lifecycles
  If your systems are expected to remain in the field for 7 to 10 years or longer, this should be reviewed as part of your lifecycle planning process.

How Can You Check Whether the New Certificates Are Installed?

Microsoft made this easier by exposing Secure Boot status directly in Windows Security. You can check the status by opening the same path indicated in the earlier section:

Windows Security > Device Security > Secure Boot

If the system has been properly updated, you should see a green dot or check mark indicating that Secure Boot protections are active and up to date. See my YouTube video that walks through how to verify Secure Boot certificate status and what to look for on the device.

To Summarize

This is not a panic situation, but it is one of those infrastructure changes that Windows IoT OEMs should take seriously, especially for long-life LTSC deployments.

If Secure Boot is disabled, you may not need to do anything. If Secure Boot is enabled, now is the time to understand your deployment, validate your update strategy, and make sure your devices are prepared well before the older certificates expire.

If you have questions about Secure Boot certificates, Windows IoT LTSC deployments, or long-life embedded servicing strategies, reach out to the Arrow Microsoft IoT team.

Questions? Reach out to our experts at Arrow Electronics. We will respond to your inquiry within 24 hours.

Windows 10 IoT Enterprise LTSB 2016 will reach End of Life on July 31, 2026, and End of Support on October 13, 2026. Afterthese dates, systems stop receiving security updates or hotfixes. Extended Security Updates (ESU)  bridge the vital gap between product end of support and full platform migration, giving organizations additional time to secure deployed systems while planning their next move.

ESUs are not guaranteed for every Microsoft product and have been available only in limited quantities, often restricted. For example, ESUs began with Windows XP Pro and was only available to OEMs shipping more than 50,000 devices. With Windows 7, Microsoft expanded access to IoT OEMs with no minimum volume, but required the purchase of 100 support hours, which limited adoption due to cost.

With Windows 10, Microsoft broadened ESU availability to include both commercial customers and consumers, including Home and Pro editions. For the OEM IoT channel, many Windows 10 products already include long lifecycle support. However, for older releases, such as Windows 10 IoT Enterprise 2015 and 2016, the expectation was that OEMs would migrate to newer LTSC releases, such as 2019 or 2021, to maintain support. In practice, migration is not always straightforward. Many OEMs require additional time to transition deployed systems. Here, ESU provides a structured path to extend security coverage during that transition period.

While Windows 10 IoT Enterprise LTSB 2015 will not receive ESU support, the 2016-based products are officially eligible for up to three years of additional coverage.

Why the 2016 Release Remains Critical

Windows 10 IoT Enterprise LTSB 2016 launched on August 2, 2016, one year after the initial Windows 10 release. Although it is unusual for Microsoft to release an LTSB/LTSC version so quickly, the 2016 release, based on build 1607, delivered meaningful improvements:

• More stable kernel and driver stack
• Improved security baselines
• Enhanced Device Guard and Credential Guard capabilities

For fixed-function and long lifecycle devices, this release was a significant upgrade over the 2015 version. As a result, many OEMs moved quickly to the 2016 release, and it became a leading SKU in the embedded IoT channel. This installed base is a key reason Microsoft is offering ESU for this version.

Key Deadlines for the 2016 Lifecycle

It is vital to distinguish between the End of Life (licensing) and End of Support (security updates). These dates represent the point of no return for your supply chain and security audits.

Windows Champ Tip: After July 31, 2026, you can no longer buy a 2016 license. To continue shipping 2016 images legally, you must purchase a Windows 11 IoT Enterprise LTSC 2024 High End COA and exercise your downgrade rights.

Products Confirmed for ESU

The following 2016-era products are confirmed for the ESU program:

• Windows 10 IoT Enterprise LTSB 2016: Support ends October 13, 2026.
• Windows Server Embedded 2016: Support ends January 12, 2027.
• SQL Server Embedded 2016: Support ends July 14, 2026.

While official part numbers are still pending, ESU pricing is expected to follow the traditional tiered escalation. In this model, Year 1 serves as the base price, Year 2 typically doubles in cost, and Year 3 doubles again. Microsoft uses this tiered structure to encourage timely OEM migration to modern LTSC versions.

Summary

The 2016 product line is approaching a hard transition point. ESU provides a defined, time-bound option to maintain security while completing migration efforts. It is not a long-term strategy, but it is a critical tool for managing risk in the interim.

Questions? Reach out to our experts at Arrow Electronics. We will respond to your inquiry within 24 hours.

The new SQL Server IoT 2025 is now available! If you build devices, appliances, or embedded systems that ship with a database inside, SQL Server IoT 2025 is worth a serious look. It brings the SQL Server 2025 engine into long-life, fixed-function products. You get the full engine, the same AI features, the same JSON and vector capabilities, and the same security improvements. The only difference is that it is packaged and licensed for OEM and embedded scenarios.

In my experience supporting embedded customers, the pattern is consistent. More data at the edge, tight security requirements, long product lifecycles, and pressure to support AI without adding cloud dependencies. SQL Server IoT 2025 helps you handle those problems without changing how you design your systems. You can use the same T-SQL, drivers, tools, containers, and development workflow.

AI where your device runs

The biggest change in SQL Server IoT 2025 is the built-in AI stack. The database now supports a native vector type, semantic search, hybrid search, and local or remote model execution. You can generate embeddings inside the engine, and you can run AI agents through a secure REST endpoint that SQL Server manages.

Nothing in this requires a cloud connection unless you choose to use one. You can keep models local by using Ollama or ONNX Runtime. You can also call cloud models through Azure OpenAI or OpenAI.

For embedded systems, this means you can build features that previously required a cloud round-trip. Examples include local anomaly detection, troubleshooting assistance, natural language search of manuals or logs, and smarter automation. If you already store your device data in SQL Server, the new vector features let you use that data immediately.

Security that matches modern requirements

The platform is secure out of the box. SQL Server IoT 2025 carries forward the security updates from SQL Server 2025. That includes TLS 1.3, TDS 8.0, PBKDF hashing, managed identities, and stricter defaults. This helps you ship hardware that is ready for audit and compliance checks. For teams in healthcare, manufacturing, or other controlled industries, this reduces significant design risk.

Performance improvements that help small systems

Most devices in the field run on constrained compute, so predictable behavior underload becomes more important than raw horsepower. SQL Server IoT 2025 benefits from improvements like optimized locking, Lock After Qualification, tempdb governance, faster failover, and reduced contention during heavy workloads.

Your device can run more predictable workloads with fewer stalls. It starts faster, handles concurrency better, and gives you cleaner behavior when something on the system misbehaves.

Better ways to move data out of the device

You also get Change Event Streaming, which pushes changes directly to Azure Event Hubs. The engine streams committed transactions without extra system tables. This helps when your design needs low-latency reporting or coordination with services outside the device.

If you use Microsoft Fabric, SQL Server IoT 2025 supports database mirroring directly into OneLake. That gives you a simple path to analytics or long-term storage without writing ETL code.

Developer workflow stays simple

Stability in the toolchain is just as important as stability in the engine. SQL Server IoT 2025 uses the same drivers, SSMS, VS Code extension, containers, and deployment workflow. You also get the new JSON type, JSON indexing, RegEx functions, Base64 utilities, and improved T-SQL functions that SQL Server 2025 introduces.

When an upgrade is worth it

If you are trying to decide whether this upgrade is worth it, these are the points that usually guide the decision:

• If your device is running SQL Server 2014 or 2016, you are past or near the end of mainstream support and the extended support runway is shrinking fast. SQL Server IoT 2025 offers a long-life option with a modern engine, stronger security, and a cleaner feature set for long-term maintenance. You also get improvements like accelerated recovery, better indexing behavior, and up-to-date drivers.
• If your product roadmap includes AI features or if customers are asking for analytics without sending data off the device, SQL Server IoT 2025 gives you a built-in way to handle that.
• If your company is standardizing on Fabric or Azure Arc, IoT 2025 fits neatly into that architecture.
• • If your design team is trying to reduce custom code around queues, logs, or sync processes, IoT 2025 reduces that work.

SQL Server IoT 2025 Options

FAQs

Is SQL Server IoT 2025 different from SQL Server 2025?
The engine is the same. SQL Server IoT 2025 is licensed for embedded and OEM scenarios and includes the support lifecycle those products need. All features come from SQL Server 2025, including AI, vector search, JSON, CES, and Fabric mirroring.

Are there pricing or licensing changes?
No. SQL Server IoT 2025 keeps the same pricing and licensing structure.

Does SQL Server IoT 2025 support both Windows and Linux?
Yes. You can run the IoT edition on either platform, with full feature parity. The Linux engine carries the same improvements as SQL Server 2025, including TLS 1.3, custom password policies, and tmpfs for container workloads.

Can I use SQL Server IoT 2025 offline?
Yes. The product does not require a cloud connection. You can run local models, local inference, local vector search, and local analytics entirely inside the device.

What are the OS and upgrade requirements?
Windows Server 2019 or newer, current Linux distributions, and upgrades from SQL Server 2014 and above. Database compatibility levels range from 100 to 170.

Does SQL Server IoT 2025 support Fabric mirroring?
Yes. You can mirror operational databases to Fabric without writing ETL. Data flows into OneLake and stays updated in near real time. This keeps the device workload light while letting you centralize analytics.

Can SQL Server IoT 2025 run in containers?
Yes. It works in the same container images as SQL Server 2025. You also get the Linux improvements such as TLS 1.3 support and tmpfs for tempdb-heavy workloads.

Does Arrow have more information on SQL Server IoT 2025?
Yes. Please learn more about SQL Server IoT 2025 here.