Arrow Intelligent Solutions blog

Back in December 2025, Microsoft quietly reworked the telephone activation process for Windows, Office, Server, and Remote Desktop Services products, with no announcement and no fanfare. Customers who rely on this process for offline devices, air-gapped systems, or downgrade scenarios started noticing that the old phone number simply stopped working. I've gotten enough questions about it that it's time to walk through exactly what changed, why it changed, and how to get through it the first time.

The short version: the phone call is gone, but the capability is not. Microsoft has moved the whole process to a web portal. I've been calling it the “portal activation process” since Microsoft hasn't given it an official new name yet. Here's what you need to know.

Why Do You Still Need This Process?

Telephone activation (now portal activation) isn't something most users ever touch, but it's essential for a specific set of scenarios that are common in the Windows IoT and embedded world:

• Downgrading a product to an older version using a key that has already been previously activated
• Activating an offline or air-gapped device that has no internet connectivity

Both are everyday realities for OEMs and embedded customers, so this isn't an edge case; it's a process many of you will experience repeatedly.

Step 1: Start the Process With slui 4

Nothing has changed on the device side to kick things off. Open the Run prompt and type:

slui 4

SLUI stands for Software Licensing User Interface, and this command has always triggered the telephone activation screen. It will still display a phone number on screen, but don't bother dialing it. Calling that number now just gets you a recording directing you to the portal at https://aka.ms/aoh .

The important thing to grab from this screen is your Installation ID. That's the number you'll carry over to the portal in the next step. If your device is genuinely offline, you'll need a second computer or a phone to continue, something to keep in mind if you support customers working in secure areas where stepping out to get online isn't simple.

Step 2: Sign In to the Portal

This is the part that trips people up. When you get to the portal, Microsoft now requires you to sign in. This is new; in the past, telephone activation was essentially anonymous.

To be clear about what this sign-in does and doesn't do: your login is not tied to the license itself. It's tied to tracking the number of activations you personally perform. If you're doing this for normal, legitimate reasons, there's nothing to worry about. If you're running thousands of activations, don't be surprised if Microsoft reaches out to ask why.

The screen you'll land on can look like it's asking for a government tenant or a government Azure cloud login. It is not. You just need a standard Entra ID (formerly Microsoft account) to sign in. Ignore the government tenant option, and click through to proceed with a normal sign-in.

Step 3: Choose “Activate a Microsoft Product”

Once you're signed in, you'll see an option for volume license key management; skip that. You want “Activate a Microsoft Product.” From there, you'll see the full family of supported products:

• Windows
• Office
• Server
• Remote Desktop Services

This list also covers the Windows IoT lineup, Windows IoT Server, Windows IoT client, and the Office LTSC products, even though they aren't named.

Choosing Windows opens the full version history, including legacy operating systems like Windows 8.1, 8, 7, Vista, and XP. Since Windows licenses are perpetual, it's not unusual to be activating a much older OS under downgrade rights, and the portal accounts for that.

Step 4: Enter the Installation ID

This step has a quirky UI element worth calling out ahead of time. The screen presents six boxes, but you can't click on them individually to type. Instead, click into the top field and start typing your Installation ID. Once you've entered at least 14 digits, the system automatically populates the six boxes below.

After the full Installation ID is entered, the portal generates a Confirmation ID.

Step 5: Finish Activation on the Device

Take that Confirmation ID back to the original device and enter it into the activation screen. If everything lines up, you'll see confirmation that the product has been successfully activated.

What This Means for Offline and Air-Gapped Environments

For most customers, this is a net improvement. You no longer must navigate an automated phone system or figure out international dialing codes. But for organizations with secure or restricted areas, the sign-in requirement adds a wrinkle: someone may now need to physically leave that secure space to reach a second device with internet access and a browser, rather than simply picking up a phone from within it. It's worth building that extra step into your activation procedures if it applies to your environment.

To Summarize

Microsoft removed the phone call from telephone activation in December 2025 without any formal announcement, replacing it with a web-based portal. The process still supports the same core scenarios, downgrade rights, and offline/air-gapped activation, but now requires signing in with an Entra ID, which Microsoft uses to track activation volume rather than to tie the login to a specific license. Once you know to expect the sign-in screen and the quirky Installation ID entry field, the new process is quicker than the old one.

FAQs

Do I still need to call a phone number?
No. Calling the number shown on the slui 4 screen now returns a recording directing you to the web portal instead.

Will I lose the ability to activate offline or air-gapped devices?
No. Offline and air-gapped activation is still fully supported; you just complete the portal steps on a second, internet-connected device or phone rather than the offline device itself.

Does signing in link my account to the software license?
No. Your sign-in is used only to track how many activations you're performing, not to associate your identity with the license itself.

Do I need a government tenant or government Azure account to sign in?
No. A standard Entra ID (formerly a Microsoft account) is all that's required. The government tenant option on the sign-in screen does not apply to this process.

Which products does the new portal support?
Windows (including legacy versions back through XP), Office, Server, and Remote Desktop Services, which also covers the Windows IoT and Office LTSC product lines.

Questions? If you have additional questions on the Microsoft activation process or on Windows IoT in general, reach out to the Arrow Microsoft IoT team at windowsiot@arrow.com or visit Arrow.com/winiot. We will respond to your inquiry within 24 hours.

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.