Windows 10 ESU Year 2: The October 2026 Decision

ESU is deliberately narrow. Enrolled Windows 10 PCs receive critical and important security updates as classified by Microsoft. The program does not restore new features, customer-requested nonsecurity updates, design changes, or general support for Windows 10. Support for activation, installation, and possible ESU regressions is limited; organizations needing broader technical support require an appropriate support arrangement.

Windows 10 computers do not stop booting when a coverage period ends. The issue is that newly discovered operating-system vulnerabilities may no longer receive the program’s updates on an unenrolled device. That creates a growing operational and compliance exception, especially for internet-connected endpoints, privileged workstations, and machines handling regulated or sensitive information.

The decision by October is therefore not “does the PC still work?” It is “which devices still justify running an operating system outside normal support, and what funded control covers that decision?”

Microsoft’s Windows 10 ESU page lists commercial Year 1 at $61 USD per device through Volume Licensing and says the price doubles every consecutive year. That implies a Year 2 list amount of $122 per device. Microsoft also states that ESU must be purchased by year and that customers entering in Year 2 must acquire Year 1 because coverage is cumulative.

The cumulative rule changes the economics. A device newly enrolled for Year 2 does not simply cost the Year 2 amount. The organization must cover the prerequisite year as well, even though it cannot recover the earlier coverage period. That makes postponement an operational delay, not a way to avoid Year 1 licensing.

Treat these amounts as planning inputs, not a universal invoice. Education programs, cloud entitlements, reseller agreements, taxes, currency, and licensing changes can produce a different transaction. Microsoft says ESU is available at no additional cost for eligible Windows 10 virtual machines in several Microsoft-hosted services, and Windows 10 endpoints accessing Windows 365 Cloud PCs can receive entitlement under stated conditions. Verify that the exact deployment meets the current terms rather than applying a cloud exception to every device in a tenant.

For a focused cost model, use Windows 10 ESU cost, then replace list assumptions with a dated quote and licensing review.

A total such as “2,400 Windows 10 PCs remain” is not enough to choose a path. Export an inventory that includes device ID, assigned user or room, site, model, serial, processor, memory, storage, firmware state, TPM version and status, secure-boot state, Windows edition and build, management enrollment, last check-in, last patch, encryption status, primary applications, peripheral dependencies, and owner.

Add four business fields: planned disposition, exception reason, target date, and accountable approver. These turn a technical export into an operating plan.

Clean the data before pricing. Remove decommissioned records, duplicates, lab images, stale directory objects, and machines that have not checked in. Reconcile endpoint management with identity, procurement, and physical inventory. A device appearing in one tool but nowhere else is a question, not automatically a license.

Then place each device into a decision lane:

Avoid an “unknown” lane that lasts indefinitely. Unknown devices should have a discovery owner and deadline.

Windows 11 eligibility is more than a CPU generation. Microsoft’s hardware requirements include a compatible 64-bit processor, memory and storage minimums, UEFI with Secure Boot capability, TPM 2.0, and graphics and display requirements. Enterprise deployment also depends on firmware configuration, drivers, management tooling, applications, peripherals, network services, and user workflows.

Run Microsoft’s supported readiness tooling through the management platform, then validate exceptions. TPM may exist but be disabled or not ready. Secure Boot may be supported but unavailable because of legacy partitioning. A compatible device can still lack storage headroom for a reliable feature update. A driver can pass basic installation and fail a specialized scanner, label printer, lab instrument, or assistive-technology workflow.

Do not use unsupported Windows 11 installation as a fleet strategy. It can produce machines outside the intended support model and obscure the lifecycle problem rather than solve it. When a hardware exception is proposed, document vendor support, update behavior, security implications, and the accountable risk decision.

Many migrations stall because the organization tested Windows, not the work. Create an application catalog with business owner, technical owner, current version, vendor support statement, authentication dependencies, browser or runtime dependencies, add-ins, local data paths, printing, peripheral integration, packaging method, license method, and rollback plan.

Prioritize applications by impact and uncertainty. A widely deployed current browser needs less ceremony than a low-volume clinical, manufacturing, public-safety, finance, or classroom application tied to specialized hardware. Test representative workflows with actual users. “The executable opened” is not acceptance.

Record outcomes as pass, pass with remediation, fail, or not tested. A pass should name the version and test date. A remediation should have an owner and deployment method. A failure should identify the business consequence and alternative. “Vendor says compatible” is useful evidence but does not replace site testing when local integrations matter.

Include identity and management in the pilot. Check sign-in, MFA, certificates, VPN or zero-trust access, Wi-Fi, printing, endpoint detection, data-loss controls, disk encryption, patch rings, remote support, software delivery, and device recovery. Migration failures often live in these seams.

ESU is defensible when it buys time for a specific constraint: a vendor-supported application update is scheduled, replacement equipment has a known lead time, a site renovation changes the endpoint need, or a business process has a funded redesign. The exception should identify the devices, reason, owner, coverage period, compensating controls, and final migration date.

An ESU bridge is weaker when it covers every unresolved device without distinction. The organization pays more while uncertainty remains. A Year 2 purchase should not become an automatic argument for Year 3.

Apply risk-based controls during the bridge. Remove local administrator rights where not required. Limit network access to necessary services. Strengthen application allowlisting and endpoint monitoring. Ensure supported browsers and business applications remain patched. Block direct internet access for fixed-function devices if the workflow permits. Separate specialized equipment from general user networks. Maintain tested backups and recovery instructions.

These measures do not turn Windows 10 into Windows 11 or replace ESU. They reduce exposure while the approved exit plan executes.

The license line alone can favor delay, especially when a device still looks serviceable. Include the rest of the period.

For ESU, count cumulative licenses, deployment labor, exception administration, additional monitoring, application support, parts, battery or storage failures, help-desk time, and the eventual refresh. For replacement, count device and warranty, accessories, docking and display compatibility, imaging or provisioning, data migration, user downtime, disposal, application remediation, and financing or deployment services.

Then add the value of the result. A new device can improve performance, battery life, wireless capability, manageability, and warranty coverage. An ESU device preserves the current workflow and avoids immediate disruption. Neither value is universal; it depends on user role and site.

Model at least three scenarios: refresh before October, mixed refresh plus ESU bridge, and broad Year 2 enrollment. Show cash timing, labor capacity, device risk, and the number of unresolved exceptions at the end. The lowest first-year spend can be the most expensive two-year plan if it delays the same replacement without reducing the fleet.

For refresh hardware, define Windows 11 edition, processor platform, memory, storage, wireless, ports, camera and audio, security features, warranty, repair model, country-of-origin requirements when applicable, and approved substitutions. Ask for stable configurations when deployment tooling depends on driver consistency.

Do not let a price-only substitute break the tested image or accessory set. A “same or better” processor does not guarantee the same network adapter, dock behavior, firmware management, or repair process. Require written approval for material changes.

At receiving, capture serials and models, inspect damage, verify configuration, enroll devices, update asset assignment, and record acceptance failures. Keep a small spare pool sized to the user population and service model rather than ordering an arbitrary percentage.

Buying ESU does not prove a device receives updates. Build a compliance view that separates license assignment, activation, device eligibility, successful installation, last scan, and latest applicable security update. A device can appear in the purchasing record while activation failed or the endpoint stopped checking in.

Pilot the complete chain on representative devices and sites: licensing, activation key or subscription handling, prerequisite updates, deployment policy, restart, update installation, management reporting, and recovery after failure. Include machines behind proxies, on slow links, off the corporate network, and managed by different tools.

Create exception reasons that lead to action: not eligible, not activated, not reporting, update failed, insufficient disk, powered off, retired, duplicate, or pending replacement. Assign an owner and aging threshold to each. A single “noncompliant” count hides the work.

After each monthly release, reconcile the ESU population with vulnerability and endpoint records. Sample devices physically or through remote verification. Investigate systems that report updates but lack current security telemetry, or vice versa. Preserve the reports and remediation tickets as evidence that the bridge is being operated rather than merely licensed.

Refresh projects often underestimate deskside details. Document how users back up local data, move browser state and certificates, reconnect printers and specialty devices, recover encrypted files, and return old equipment. Define what support can copy and what must not leave the old machine.

At handoff, verify the user can complete the critical workflow, not just sign in. Record the old and new asset assignments and enforce a return deadline. Quarantine returned devices, preserve data under records policy, sanitize with an approved method, and update disposition records. Devices held “just in case” should be offline and time-limited; otherwise they quietly re-enter service without ESU or management.

Communications should explain what changes, when, what the user must do, expected downtime, and where to get help. Avoid framing the project as a cosmetic Windows upgrade. Users are more likely to cooperate when they understand why local files, unsupported peripherals, or long-delayed restarts create real migration risk.

Keep the final exception list visible to site leadership. Each record should name the device, reason, ESU coverage, compensating controls, replacement date, and owner. Review it monthly until the count reaches zero or a newer approved plan replaces it.

Record approvals and closure evidence with the asset history.