Outdated software still runs core processes in most organizations as of mid-2026. It looks stable until the first real exploit or compliance deadline arrives. The surface risk is obvious: no more patches. The deeper, underestimated friction is what happens when you finally try to move off it. Compatibility breaks cascade through custom integrations, licensed line-of-business apps, and reporting tools that were never designed for the next major version. That cascade is what keeps teams frozen longer than the CVEs themselves.

Windows 10 reached end of support on 14 October 2025. Lansweeper data from July 2026 shows roughly one in six Windows devices in monitored environments still run it. Those machines carry nearly three times the active CVEs of Windows 11 systems—an average of 1,903 versus 652. Healthcare and retail sit higher than the mean. The same pattern appears across server and runtime stacks. Docker Engine, certain Windows Server releases, older Python, Node.js, PostgreSQL, and Java builds all appear in the CISA Known Exploited Vulnerabilities catalog with high risk scores.

The operational reality in 2026 is that “it still works” has become the most expensive phrase in IT. Maintenance already consumes the majority of many budgets. Every deferred upgrade adds another layer of brittle dependencies. When a forced event finally arrives—an insurance questionnaire, a customer audit, a ransomware group scanning for the exact unpatched version—the cost arrives as downtime and emergency licensing, not just remediation tickets.

Why Teams Stay on Unsupported Software

Most holdouts are not negligence. They are rational short-term decisions that compound.

• Custom or vendor-locked applications certified only against a specific OS or runtime. Moving breaks the certification and requires re-testing or paid re-certification.
• Line-of-business systems with years of accumulated configuration that no one fully documents. The original implementers have left.
• Hardware that cannot meet the minimum requirements of the next supported OS without capital spend.
• Extended Security Updates that feel cheaper in the current fiscal year than a full migration project.

In practice the ESU path for Windows 10 and older Server releases buys time measured in months, not years. Once the paid window closes, the system is permanently unpatchable. Attackers know the dates as well as the vendors do. CISA KEV entries for these platforms keep growing because new vulnerabilities continue to be discovered and weaponized against the still-running population.

The same dynamic plays out in open-source and commercial runtimes. Java 8 builds from certain vendors lose standard support in late 2026. Node.js and MySQL versions hit EOL on predictable schedules. Teams that treat these as “backend details” discover the hard way that their front-end and integration layers still call the old libraries.

The Security Exposure Is Not Theoretical

Nearly half of the entries in CISA’s Known Exploited Vulnerabilities catalog link to end-of-life or end-of-service software. Research from 2026 shows that vulnerabilities in unsupported systems are significantly more likely to be actively weaponized. Once a product stops receiving patches, every newly disclosed CVE becomes a permanent open door.

Ransomware operators continue to favor known, unpatched flaws over pure zero-days for initial access. Firewall and VPN appliances, unmaintained CMS platforms, and older container engines appear repeatedly in incident reports. When the first foothold is an EOL component, lateral movement often targets the same aging domain controllers or file servers that were left behind for “compatibility.”

Compliance pressure tightens the same noose. Cyber insurance questionnaires increasingly ask for evidence that critical systems are on supported versions. Regulators in finance, healthcare, and critical infrastructure treat unsupported software as a control failure. A system that cannot receive a security update cannot meet the spirit of most current frameworks.

The Real Friction: Update Cascades

Security risk gets the headlines. The operational cascade is what actually stops migration projects.

Start with a Windows 10 workstation that still runs a critical desktop application certified only for that OS. The application talks to a backend still running on Windows Server 2012 R2 under the final year of ESU. That backend authenticates against an older domain functional level and feeds data into a reporting tool built on an unsupported Java runtime. Updating any single piece breaks the chain. The project plan that looked like “upgrade the OS” becomes a multi-month coordination exercise across application owners, database teams, and external vendors.

In the deployments I have seen, the first failure point is almost always the undocumented integration. A scheduled task that still calls a deprecated API. A licensing server that only speaks the old protocol. A printer or specialized peripheral whose driver never made it to the new OS. Each of these surfaces only after the pilot group is already live, forcing a rollback and another delay cycle.

Container environments add their own version of the same problem. An application image built years ago on an EOL base OS or outdated Docker Engine continues to run. The host is patched, but the container inherits the old attack surface. Scanning tools flag it; remediation requires rebuilding the image and re-validating every dependent service. Teams that lack automated rebuild pipelines simply leave the old images in place.

The cost shows up in three places:

1. Direct project spend for testing, licensing, and temporary parallel environments.
2. Opportunity cost as engineering time stays locked on keeping the old stack alive instead of delivering new capability.
3. Risk premium in the form of higher insurance rates, longer audit cycles, and the constant low-level anxiety that the next critical CVE will force an emergency change window.

Practical Steps That Reduce Exposure Now

Inventory first. Most organizations still lack a single authoritative list of what is actually running. Agent-based discovery tools that report OS build, installed software versions, and last patch date remain the fastest way to surface the real population of Windows 10, old Server releases, and unsupported runtimes. Prioritize internet-facing and high-privilege systems. Anything that authenticates users or holds regulated data sits at the top of the list.

Map dependencies before you schedule the upgrade. For every critical application, document the exact OS, runtime, database, and integration endpoints it requires. If the vendor still offers a supported path, get the current certification matrix in writing. If the vendor has already declared the product EOL, treat that as a hard deadline rather than a negotiation point.

Use extended support only as a bridge with a documented exit date. Paying for ESU on Windows 10 or older Server versions buys calendar time. It does not reduce the CVE count. Schedule the migration project against the ESU end date, not against an open-ended “when we get to it.”

For runtimes and libraries, treat transitive dependencies as first-class risk. A supported application can still pull in EOL packages. Software composition analysis that flags end-of-life components inside the dependency graph catches what traditional OS patching misses.

When the cascade looks too large for a big-bang cutover, isolate. Network segmentation, application control, and strict egress filtering around the legacy systems reduce the blast radius while the migration proceeds. This is not a permanent control. It is a temporary containment measure that buys the project team breathing room.

Licensing strategy matters. Organizations that already hold volume or enterprise agreements often discover they already own the rights to the next supported versions. Working with a Trusted Site that understands the existing entitlements can turn a capital request into a true-up or software assurance conversation instead of a new purchase cycle.

What Changes in the Next Twelve Months

Several high-impact platforms reach or have already passed EOL in the 2026 calendar. Windows Server 2012/2012 R2 ESU ends in October 2026. Multiple LTS runtimes and database versions close their free support windows. The population of permanently unpatchable systems will grow unless migration projects stay on schedule.

AI-assisted vulnerability discovery is compressing the time between disclosure and active exploitation. Unsupported software has no patch pipeline, so the only defense is removal or isolation. Organizations that treat EOL dates as soft guidelines will find the exploit window shorter than their change-control process.

The organizations moving fastest treat software currency as a continuous process rather than a periodic project. They maintain an authoritative inventory, enforce supported-version policies at the procurement and architecture gates, and measure the percentage of assets still on unsupported platforms as a standing operational metric. The ones that still treat upgrades as discretionary projects keep rediscovering the same cascade every time a new critical CVE appears.

The practical next action is concrete. Pull the current asset report for every system still showing Windows 10, Windows Server 2012/2016 under ESU, or any runtime past its published support date. Rank them by business criticality and external exposure. Assign an owner and a target migration quarter to each. The longer that list sits without owners and dates, the larger the eventual cascade becomes.