A hard core of Windows 10 devices cannot or will not be migrated to Windows 11, leaving enterprises with a growing security problem as support options run out. According to asset tracking service Lansweeper, Windows 10 still runs on 16.9 percent of the Windows devices it monitors, or "roughly one in six." A year ago, the operating system accounted for about half of the machines in its dataset, falling to the low-to-mid 40 percent range by the time Microsoft ended standard support. The decline continued after that, reaching 18.6 percent in June, but Lansweeper says migration has now slowed to a crawl. This presents a problem because even installations enrolled in the Extended Security Updates (ESU) program, under which Microsoft has committed to fixing security bugs, will eventually become vulnerable. Consumer devices can receive security updates until October 12, 2027, while commercial customers willing to pay can extend coverage until October 10, 2028. After that, the fixes stop. Small and medium-sized businesses (SMBs) are particularly exposed. Lansweeper reckons that 21.4 percent of SMB machines still run Windows 10, with cost usually being the constraint that keeps the legacy operating system running. The exposure is greater in some sectors, with 23 percent of healthcare and pharmaceutical systems sticking with Windows 10, while consumer and retail devices hover at 22.7 percent. According to Lansweeper's data, "a Windows 10 device carries an average of 1,903 active CVEs against 652 on Windows 11. That's a 2.9x gap." Esben Dochy, principal technical evangelist at the company, told The Register that "the Windows 10 average also includes devices that have ESU patches applied." Part of the problem, according to Lansweeper, is "patch diffing," in which Windows 11 fixes can be reverse-engineered to find flaws in Windows 10. "The supported OS effectively hands attackers a map into the unsupported one," Lansweeper said. According to Lansweeper's figures, 14 percent of Windows 10 assets have ESU patches applied. "I think a meaningful share of the remaining Windows 10 estate isn't being actively unpatched by neglect," Dochy said. "It's being held in place by vendor dependency, certification gaps, cost, or accepted risk. Certified equipment is a good example: many medical devices or industrial systems have their OS tied directly to vendor certification, and in some cases a Windows 11-certified version of that device or software doesn't exist yet. The same applies in retail, where devices are often vendor-locked to specific OS versions for compliance or warranty reasons. "For a lot of this hardware, the vendor is contractually responsible for maintaining the device, including any OS changes, so simply enrolling in ESU as a customer may not resolve the underlying problem. The real fix depends on the vendor's own certification timeline for Windows 11, and the cost that comes with the eventual upgrade or replacement. There are also devices sitting in air-gapped or isolated environments, where the risk is knowingly accepted for now rather than actively managed, so ESU enrollment simply isn't a priority." It's not a great situation, and the apparent stalling of Windows 11 adoption doesn't help. Looking at other market share measures such as Statcounter, there was little change in the share of Windows 10 and its successor over the last few months after a surge following the end of support. As Lansweeper noted: "The easy migrations are done. What's left is the hard core: devices that haven't moved because they can't or won't." Compounding the issue is the rising cost of new PC hardware, a trend unlikely to improve in the near term. According to Microsoft, "the ESU program helps reduce the risk of malware and cybersecurity attacks by providing access to critical and important security updates." Microsoft has extended the program for consumer devices, perhaps in recognition that there are an awful lot of Windows 10 machines still out there. Lansweeper's figures also underline the need for administrators to know which Windows 10 devices remain in their estates and whether each is fully patched. While many devices will have some level of protection, others will not, and over time, the proportion of vulnerable Windows 10 devices will grow, particularly where a move to Windows 11 is not an option. ®

UPDATED Patch Tuesday was followed by Oopsie Wednesday for some Dell customers, with Microsoft slamming on the update brakes after the hardware maker reported some problems. Yesterday was Microsoft's monthly security update for Windows. This month was, by all accounts, a bit of a doozy with a record-breaking number of CVEs patched, some of which were classed as critical and under active exploitation. Better get patching then? Well, er, no. Not if you're using a Dell device affected by issues associated with the update. Microsoft admitted it affected "some Dell devices with Intel processors," but stopped short of providing a full list. The Register asked the Windows giant and Dell which models had been hit, but both have yet to respond. Microsoft confirmed on its update page: "This update might not be available for a limited number of Dell devices with Intel processors due to an incompatibility reported by Dell that can potentially cause unexpected shutdowns, poor performance, increased heat, and battery drain." And the fix? "We are working together with Dell to prevent the affected models from experiencing the issue and plan to release a resolution for affected devices in the coming days." While the pair works on a solution, the update is "temporarily unavailable." Thanks to the sheer number of CVEs in the update, the delay is unfortunate, doubly so when considering that only a week ago, Microsoft was fiercely advocating for users to get patches installed as soon as possible due to the speed at which AI systems can detect and exploit vulnerabilities. In this instance, Microsoft has acted quickly to halt the update for affected devices. However, the fact that it got this far and can cause surprise shutdowns, overheating, and performance problems does not speak well of the company's validation and quality procedures. Dell is hardly a bit player in the hardware ecosystem. Somewhere, deep in the heart of Microsoft's Redmond campus, a sad-faced engineer is likely resetting the "Days since we broke something" counter and thinking fondly of the days when the number reached double or triple figures. ® Updated to add on July 16: A Microsoft spokesperson told The Register: "We are aware of the issue and have paused the Windows 11, versions 25H2 and 24H2 (KB5101650) update for impacted devices while we work on a resolution." The company has also updated its Windows release health dashboard. According to the Windows behemoth, the issue occurs on Dell models with an Intel Innovation Platform Framework Processor Participant driver and is related to the new Windows USB-C Connection Manager interface. The problem first cropped up in the preview update on June 23, ahead of patch Tuesday. There's no workaround, and Microsoft has halted the rollout to affected devices until a fix is ready, "in the next few days."

For the first time, the source code of KSOS, backed by the US Department of Defense in the late 1970s and 1980s, is available to the public in the archives of The Unix Heritage Society (TUHS). TUHS volunteers preserve the historical source code and documentation of the original UNIX – or as much of it as is left. A few days ago, in an email to its mailing list, TUHS founder Warren Toomey announced the addition of KSOS to the collection. "KSOS was the US Department of Defense (DoD) Kernelized Secure Operating System (KSOS, formerly called Secure UNIX). KSOS is intended to provide a provably secure operating system for larger minicomputers," he wrote. Despite its age, KSOS sounds surprisingly modern. It was a Unix-compatible OS, implemented in a type-safe programming language, Modula, rather than C. Modula was the late great Niklaus Wirth's successor to Pascal and, in turn, the forerunner to Modula-2 – which we described when it was added to the GNU Compiler Collection in 2022. KSOS was designed to be formally verifiable, so that it could be trusted for use in highly secure systems. It ran on commodity hardware, and its development was sponsored by the US DOD. Very few OS kernels have been formally verified, and one of the best-known modern examples is the seL4 microkernel, as used in the Ironclad OS we covered last year, and also in the new QSOE RISC-V RTOS. KSOS isn't some cutting-edge experimental new Rust effort, like the Asterinas project we described last year or the even newer Maestro project. What became KSOS started in 1978 at Ford Aerospace (yes, that Ford). On the team were Peter Neumann, who later ran the RISKS Digest – The Register was quoting him in 2004 – and Tom Perrine, who described it and its modern relevance in a 2002 article for the USENIX journal ;login:. It's titled "The Kernelized Secure Operating system (KSOS)" [PDF], and at only three and a bit pages long, it's well worth a read. Even then, 24 years ago, projects were struggling to reinvent things KSOS did successfully a couple of decades earlier. That's even more true today. To learn more about how KSOS worked, there's a 1978 Executive Summary [PDF] – which, despite its title, runs to 15 pages. Clearly, executives back then had longer attention spans. Perrine gave a talk about KSOS at DEF CON 20 in 2012, which you can watch on YouTube. KSOS isn't forgotten. For instance, it came up in a talk at last year's FOSDEM: Confidential Computing's Recent Past, Emerging Present, and Long-Lasting Future. Page 8 of the slide deck [PDF] says KSOS was "among the first security-focused kernels, emphasizing formal verification" and "source code was publicly available, rejecting 'security through obscurity.'" KSOS was not confined to academic research. It was used in production. Last October, Perrine explained more in another TUHS email: "KSOS – for PDP-11, originally developed by Ford Aerospace, and then extended at Logicon. It did have a supervisor-mode UNIX-system-call-compatible system. Later, there was also a userland library that implemented something that mostly matched the UNIX system calls. It had no kernel code in common with UNIX. It was written in Modula. "KSOS was used in the Trusted Downgrade System of the multi-level-secure 'all-source' intel fusion system that Logicon built for a few agencies. ACCAT-GUARD and USAFE-GUARD, for example. "KSOS-32 – a VAX 'port' of KSOS (which was then retconned as 'KSOS-11'). The Modula code from -11 was run though Emacs macros to produce Modula-2, and then parts were rewritten as needed. "I worked on both systems at Logicon." It's Perrine we have to thank for KSOS reappearing in public view after 38 years – he released an old tarball of the source code that was preserved by fellow KSOS-32 developer Jeff Makey, and with the help of John O Goyo and Thalia Archibald, it made its way to the TUHS code archive. Now there’s a new quest: find the original compiler used to build it. One thing that may help slightly is that KSOS was not self-hosting: it was compiled under UNIX. We have mentioned TUHS's important work before: for instance, when a tape of UNIX V4 was found in University of Utah boffin Robert Ricci's department — and successfully recovered. Bootnote Mr Goyo also found time to email The Reg FOSS desk about the recovery, for which we thank him. ®

Windows Server 2016 might be long in the tooth but that isn't about to stop Microsoft breaking stuff. The May 12 security update introduced another bug for administrators to worry about. According to Microsoft, if the server hostname is exactly 15 characters long (like, for example, THEY-NEVER-TEST), domain controller discovery might fail. In the notes for the glitch, Microsoft wrote: "When the hostname is 15 characters long, DCLocator calls (for example, using nltest /dsgetdc: /pdc) will return ERROR_INVALID_PARAMETER, preventing applications and administrative tools from locating a domain controller." In other words, anything that depends on a domain controller lookup might stop working. As an example, Microsoft gave Distributed File System (DFS) Namespace management, which would certainly be inconvenient. DFS Namespaces is a Windows Server role that allows admins to group shared folders across different servers into a single namespace. A single path can lead to files located on multiple servers. Unless, of course, the domain controller lookup is broken. Microsoft lists no workaround for affected users, though changing the server hostname to something other than 15 characters would presumably avoid the trigger. "The issue is under investigation, and additional information will be shared as soon as it becomes available," it said. Microsoft still officially supports Windows Server 2016. Mainstream support ended in 2022, but extended support will continue until January 12, 2027. Microsoft is offering up to three more years of support via the Extended Security Updates (ESU) program after that. Earlier this year, Esben Dochy of Lansweeper told The Register that the operating system accounted for just 2.2 percent of all Windows devices it tracks, but 20.3 percent of all servers. That figure is unlikely to have dropped dramatically in the months since, so there is a fair chance that an administrator with a 15-character hostname could be affected. In addition to the Windows Server 2016 problems, the May 2026 security update has failed during installation on some Windows 11 devices when the EFI System Partition is insufficient in size. It is reassuring to know Microsoft's talent for breakage shows no bias toward any particular vintage. ®