Windows NT 3.1 to 8.1 Release History: Security Changes by Version

Every Windows release from NT 3.1 to Windows 8.1 is now out of support, and each one added a security layer the next version kept. NT brought security identifiers, access tokens and access control lists. Windows 2000 brought Active Directory. XP Service Pack 2 brought Data Execution Prevention. Vista brought User Account Control and ASLR. Windows 7 brought AppLocker. Windows 8 brought Secure Boot and Early Launch Antimalware.

The support clocks stopped one by one. Microsoft's lifecycle pages put the end of extended support for Windows XP at 8 April 2014, Vista at 11 April 2017, Windows 7 at 14 January 2020 (paid Extended Security Updates ran to 10 January 2023 for some editions), Windows 8 at 12 January 2016 and Windows 8.1 at 10 January 2023, with no ESU offered for 8.1. Older versions no longer appear in Microsoft's lifecycle search at all. If one of these systems is still on your network, the job is to find it, isolate it and plan its replacement.

Key takeaways

• The NT line won. Windows 95, 98 and Me ran on a DOS based core with no real per user security. Every Windows you run today descends from NT, whose security reference model (SIDs, tokens, ACLs) is still the core of Windows 11.
• Security defaults arrived in steps. 2000 added a directory, XP SP2 turned on memory protections, Vista split the administrator token and randomised memory layout, 7 added application allowlisting, and 8 moved trust into the firmware boot path.
• Every version from XP to 8.1 is past end of extended support. The last public security updates for Windows 7 ESU customers and for Windows 8.1 shipped in January 2023.
• ESU was never universal. Windows 7 ESU covered only Professional, Enterprise and Professional for Embedded Systems through volume licensing. Windows 8.1 had no ESU at all.
• Version numbers mislead. Windows 8.1 reports itself as 6.2 (Windows 8) to any app without a Windows 8.1 manifest, and a Windows 7 box without Service Pack 1 lost support in April 2013.
• Legacy Windows survives where hardware and certification lock it in: lab instruments, medical imaging, factory HMIs, kiosks and point of sale. You cannot patch it, so you segment it, strip its network services and watch it.

Windows versions from NT 3.1 to 8.1 at a glance

Microsoft's lifecycle search covers Windows XP and later. Windows 2000, NT 4.0, NT 3.x, 95, 98 and Me are not listed there any more, so the years below for those versions are the commonly documented release years, not lifecycle dates. For XP onward, every date comes from the Microsoft Learn lifecycle page for that product.

Two notes on reading those dates. Microsoft Learn stores lifecycle dates as UTC timestamps, so the XP page shows an extended end of "4/9/2014 6:59:59 AM", which is the end of 8 April 2014 in Redmond. The same offset applies to every row: Windows 7's raw extended end of 15 January 2020 at 06:59 UTC is the end of 14 January 2020 Pacific time. The lifecycle start date can also differ from the launch event you remember: Windows 8.1 starts on 13 November 2013 in the lifecycle record.

The version numbers come from Microsoft's Win32 operating system version table. Windows XP is 5.1, the 64-bit edition of XP shares 5.2 with Server 2003, Vista is 6.0, 7 is 6.1, 8 is 6.2 and 8.1 is 6.3. The DOS based versions carried their own 4.x numbers, which is one reason old inventory tools sometimes confuse Windows 95 with NT 4.0.

If you came here for later releases, see our Windows 11 version history, the Windows Server release history from 2016 to 2025, and whether Windows 10 is still safe after Extended Security Updates. This post stops at 8.1 on purpose.

How the DOS based line differed from the NT line

For most of the 1990s Microsoft shipped two different operating systems under one brand.

The DOS based line (Windows 95, 98 and Me) was built for compatibility with DOS and 16-bit Windows software on consumer hardware. A large part of the system still ran shared 16-bit code, and there was no meaningful boundary between users. The file system was FAT, which has no permissions at all. Any program could write anywhere on the disk, patch system files or load a driver. There was nothing to "elevate" to, because everything already ran with full control.

The NT line (NT 3.1, 3.5, 3.51, 4.0, then 2000) was a new kernel designed for workstations and servers. It ran a protected kernel separate from user mode processes and introduced NTFS, where every file and folder carries a security descriptor. NT required a real logon, and the secure attention sequence (Ctrl+Alt+Delete) was routed to the system so that a program could not fake the logon screen to capture a password.

Windows XP merged the two lines in 2001. From then on, home and business editions both ran on NT, which is why the security features in the rest of this post apply to every consumer PC from XP onward.

Why the NT security model mattered

The NT design gave Windows the same building blocks it still uses, and Microsoft's current Win32 documentation describes them in nearly the same terms.

• Security identifiers (SIDs). Every user, group and computer account gets a unique, variable length value that identifies it. Windows makes access decisions on SIDs, never on names, which is why renaming the Administrator account does not change what it can do.
• Access tokens. When a user signs in, the system builds an access token holding the user's SID, group SIDs and privileges. Every process the user starts runs with a copy of that token, and every access check compares the token with the object being opened.
• Access control lists. Each securable object (a file, registry key, process, service or named pipe) has a security descriptor. Its discretionary ACL lists access control entries that allow or deny specific rights to specific SIDs. Its system ACL controls auditing.
• Privileges. System wide rights such as backing up files, loading drivers or debugging programs are granted separately from file permissions, so they can be assigned narrowly.

This mattered because it made "who is running this code" a question the operating system could answer and enforce. Every later control in this post, from UAC to AppContainer, is built by changing what goes into a token or adding a check alongside the ACL.

What Windows 2000 added

Windows 2000 (NT 5.0) moved Windows from single machine security to managed fleets. Microsoft's Active Directory Domain Services documentation describes AD DS as the foundation for distributed networks built on Windows 2000 Server and later, providing secure, structured, hierarchical storage for users, computers, printers and services.

The domain model built around Active Directory came with the tools Windows administrators still use, which we describe here as features rather than tie each to a release:

• Kerberos authentication for domain logons, with tickets issued by a key distribution center on each domain controller and NTLM kept for compatibility, a decision administrators are still unwinding in 2026.
• Encrypting File System (EFS). Microsoft's file encryption documentation describes it as cryptographic protection of individual files on NTFS volumes using a public key system. Losing the user's key without a recovery agent means losing the files.
• Group Policy. Central configuration of security settings, software and scripts for every machine in a domain, the mechanism most later controls in this post were deployed through.

Windows 2000 is also the oldest release in Microsoft's current version table (5.0), and the domain model it introduced is still the one most enterprises run.

What changed with Windows XP and XP Service Pack 2

Windows XP (NT 5.1) had a lifecycle start date of 31 December 2001. It brought the NT kernel to home users, along with fast user switching and a consumer friendly NTFS default. Many home users ran as administrator, because many programs of the time failed otherwise.

The Trustworthy Computing memo

On 15 January 2002, Bill Gates emailed every full time Microsoft employee a memo titled "Trustworthy computing". It called Trustworthy Computing "the highest priority for all the work we are doing" and set availability, security and privacy as goals ahead of new features. The memo is often treated as the start of Microsoft's modern security programme: development teams stopped for security reviews, and the practices that later became the Security Development Lifecycle grew out of that period. You can read the text as published by Wired at the time; Microsoft's own news site copy now returns a 404.

Service Pack 2 (2004)

XP Service Pack 2 has a lifecycle start date of 17 September 2004. The security change Microsoft's current documentation ties to it is Data Execution Prevention.

Microsoft's DEP documentation describes it as a system level memory protection built in starting with Windows XP and Windows Server 2003, and points to its guide on configuring memory protection in XP SP2. DEP marks memory pages as non executable, so code injected into a stack or heap buffer cannot simply run. On XP it protected core system binaries by default and other programs only when opted in.

Staying on an old service pack had a cost: SP2 itself reached end of support on 13 July 2010, and only SP3 (lifecycle start 21 April 2008) stayed supported to April 2014.

XP service packs and support

Microsoft's Fixed Lifecycle Policy explains why these service pack rows matter: to stay eligible for support, customers "may be required to deploy the latest Service Pack". An XP machine on SP2 in 2012 was already unsupported, two years before the headline end date.

CISA's 2014 warning

When XP support ended, the US Computer Emergency Readiness Team (now part of CISA) published alert TA14-069A on 10 March 2014. It stated that after 8 April 2014, XP would no longer receive security patches, assisted support or software updates, and advised users to migrate to a supported operating system. For users who stayed, it suggested using a browser other than Internet Explorer to reduce some risk. That last line is worth reading as what it was: a stopgap, not a plan.

What Windows Vista introduced

Vista (NT 6.0, lifecycle start 25 January 2007) was the biggest security redesign of the client OS since NT itself. It was also widely disliked, largely because of the prompts that came with the first item on this list.

User Account Control and integrity levels

User Account Control changed what an administrator's logon produces. Microsoft's UAC documentation describes the result: when an administrator signs in, Windows creates two tokens, a standard user token used for normal work and a full administrator token used only when an app needs it. Asking for the administrator token triggers a consent prompt, shown on the secure desktop by default so that other programs cannot click it or draw over it. Standard users get a credential prompt instead.

Underneath, Vista added Mandatory Integrity Control. Microsoft's Win32 documentation defines four integrity levels (low, medium, high and system). Standard users run at medium, elevated processes at high. A process at a lower integrity level cannot write to an object at a higher one, even if the object's DACL would allow it. UAC also has a policy setting, "Virtualize file and registry write failures to per user locations", which Microsoft's UAC settings page says redirects writes from programs that run as administrator and store data in protected folders such as Program Files.

ASLR and other memory protections

Address space layout randomization loads executables, DLLs, stacks and heaps at different addresses on each boot or launch, which makes memory corruption bugs much harder to turn into reliable code execution. Microsoft's linker documentation states that ASLR "was first available in Windows Vista". It applies to images built with the /DYNAMICBASE flag, which is on by default in modern toolchains but was not for software built in the XP era. That gap matters for legacy fleets: an old line of business binary on Vista or 7 may not be randomised at all.

BitLocker

BitLocker Drive Encryption is Windows' built in full volume encryption. Microsoft's BitLocker overview says it gives the most protection with a TPM, which helps confirm a device was not tampered with while offline. We have not found a current Microsoft page that dates its first release or edition list, so this post does not attribute those details to a version.

Driver signing on x64

Microsoft's kernel mode code signing policy table shows that on Windows Vista and Windows 7 (and on Windows 8 and later with Secure Boot off), kernel drivers must be signed on 64-bit systems, while 32-bit systems require no signature. On 64-bit systems, that closed the easy route of loading an unsigned driver to tamper with the kernel.

SMB version 2

Microsoft's SMB documentation confirms SMBv2 arrived in Windows Vista and Windows Server 2008. That detail returns later, because legacy machines that cannot speak SMBv2 or later are the ones that keep SMBv1 alive on a network.

Vista support

What Windows 7 added or softened

Windows 7 (NT 6.1, lifecycle start 22 October 2009) kept Vista's security architecture and made it easier to live with.

• UAC prompt behaviour. Windows 7 kept Vista's UAC model. Microsoft's UAC settings let administrators choose whether elevation prompts switch to the secure desktop; turning that off weakens the protection against other programs interacting with the prompt.
• AppLocker. Microsoft's App Control and AppLocker overview states that AppLocker "was introduced with Windows 7" and lets organisations control which applications run, through rules based on publisher, path or file hash. The same page adds that AppLocker does not meet Microsoft's servicing criteria for being a security feature. It is a policy tool to stop users running unapproved software, not a boundary Microsoft promises to defend against a determined attacker.

Windows 7 Service Pack 1 and ESU

Service Pack 1 (lifecycle start 22 February 2011) was required for support: the original release lost support on 9 April 2013. After the end of extended support on 14 January 2020, Microsoft sold Extended Security Updates for up to three more years.

The Windows 7 lifecycle page is precise about who could buy ESU: Professional, Enterprise and Professional for Embedded Systems editions, through specific volume licensing programmes. Home Premium, Ultimate and Starter machines got nothing after January 2020. Microsoft's ESU FAQ describes the programme as Critical and Important security updates only, a temporary bridge that does not extend the product's lifecycle or add technical support. The browser ended separately: Microsoft Edge version 109 was the last Edge release for Windows 7 and 8.1, supported with critical security fixes until 10 October 2023.

What Windows 8 and 8.1 brought

Windows 8 (NT 6.2, lifecycle start 30 October 2012) moved the trust boundary down into the boot process and up into a new app sandbox.

UEFI Secure Boot

Microsoft's threat mitigation overview describes UEFI Secure Boot as a firmware security standard built into PCs by manufacturers "beginning with Windows 8". With Secure Boot on, the firmware checks the signature of the boot loader against keys in its database before running it, and the Windows boot loader checks the kernel and boot drivers in turn. A bootkit that replaces the boot loader no longer starts. Microsoft's OEM Secure Boot page now carries an important 2026 notice: the Secure Boot certificates originally issued in 2011, the ones Windows 8 era devices were built with, begin expiring in June 2026, and Microsoft is rolling out replacements. Old machines that never receive the updated certificates will keep booting, but they will not trust boot components signed only under the new certificates.

Microsoft's code signing policy table also shows that on Windows 8 and 8.1 with Secure Boot on, the driver signing rules extend to 32-bit systems as well as 64-bit.

Early Launch Antimalware

Microsoft's driver documentation describes Early Launch Antimalware (ELAM) as a supported way for antimalware software to start before other third party boot drivers, so it can check them before they initialise. It lists Windows 8, 8.1, 10 and 11 as the systems it applies to. Combined with Secure Boot and measured boot into the TPM, this closed much of the gap rootkits had used on earlier versions.

SmartScreen, Defender and AppContainer

• SmartScreen reputation checks. Microsoft's Defender SmartScreen overview describes warnings before downloaded programs without established reputation run. We have not found a Microsoft page dating when the check moved into the operating system, so we do not attribute it to Windows 8.
• Built in antivirus. Microsoft's threat mitigation overview states that Microsoft Defender Antivirus "has been improved significantly since it was introduced in Windows 8". Windows 8 was the first release with a full antimalware engine included by default rather than as a separate download.
• AppContainer. Microsoft's AppContainer documentation calls it "a security feature introduced in Windows 8": a sandbox that restricts an app's access to system resources, other apps and user data unless permitted. Capability SIDs grant access to specific resources such as documents, cameras and location. Microsoft's Mandatory Integrity Control page adds that a low integrity process cannot obtain access to a process associated with an app container.
• SMB 3. Microsoft's SMB page confirms SMBv3 arrived in Windows 8 and Windows Server 2012, adding SMB encryption.

Windows 8.1

Windows 8.1 (NT 6.3, lifecycle start 13 November 2013) was a free update that Windows 8 users had to install to keep receiving fixes after 12 January 2016. Microsoft's mitigation overview notes that Windows 8.1 implemented protected processes in a way third party antimalware services could use, so the security software itself was harder for malware to tamper with; Windows 10 later used protected processes "more broadly". Windows 8.1 also changed version reporting: apps without a Windows 8.1 manifest are told they are on 6.2, Windows 8.

Microsoft's Windows 8.1 end of support announcement states that support ended on 10 January 2023, that the product would get no further security updates, non security updates, bug fixes or technical support, and that Microsoft would not offer ESU for Windows 8.1.

Security features by version

When you assess a legacy machine, an XP SP3 host speaks only SMB 1, has no ASLR and almost certainly runs everything as administrator. A Windows 7 host without SP1 is unsupported on every axis. Even a fully patched Windows 8.1 host stopped getting fixes in January 2023.

Why legacy Windows still runs in OT, medical and kiosk settings

The machines that still run XP, 7 or 8.1 in 2026 are rarely there by neglect. They are there because something else is fixed to them.

• Certified systems. A medical imaging workstation, a laboratory analyser or a validated pharmaceutical process is approved as a whole. Changing the operating system can mean recertification by the device maker or a regulator, and the maker may not offer it for an older model.
• Industrial control. Human machine interfaces and engineering workstations in plants were often built on the Windows of their day and expected to run as long as the machine they control, which can be twenty years or more.
• Hardware drivers. Instrument cards, CNC controllers and older peripherals may have drivers only for 32-bit XP or 7, with no signed 64-bit driver for anything newer.
• Kiosks and embedded editions. Point of sale, ticketing and signage systems often ran embedded editions with their own support dates, then kept running after those dates passed.

None of this makes the machine safer, only slower to remove, so the practical answer is containment plus a dated replacement plan.

The risk is not theoretical. Microsoft's bulletin MS17-010, published 14 March 2017, fixed remote code execution flaws in the SMBv1 server and was rated Critical for all supported releases. Two months later the May 2017 worm outbreak spread through hosts that lacked it, and machines on unsupported versions had no regular route to the fix. Our posts on EternalBlue and the supply chain side of WannaCry cover that event; the lesson for this post is simply that an SMBv1 speaking host is a liability to every machine that can reach it.

How to find legacy Windows on your network

Start from records, then confirm on the wire. Every command below is read only.

1. Ask Active Directory

If the machines were ever domain joined, their computer objects record the operating system. On a domain joined admin workstation with the RSAT Active Directory module:

Get-ADComputer -Filter * -Properties OperatingSystem,OperatingSystemVersion,OperatingSystemServicePack,LastLogonDate |
  Where-Object { $_.OperatingSystemVersion -match '^(5\.|6\.[0-3])' } |
  Sort-Object OperatingSystem |
  Select-Object Name,OperatingSystem,OperatingSystemVersion,OperatingSystemServicePack,LastLogonDate |
  Export-Csv legacy-windows.csv -NoTypeInformation

The filter matches 5.x and 6.0 to 6.3, which includes the matching server releases. LastLogonDate shows which records are still alive. Machines never joined to the domain will not appear.

2. Check a machine directly

On the host itself, winver shows the edition, version and build, and systeminfo prints the OS name, version and service pack. From PowerShell 2.0 or later (the default on Windows 7):

Get-WmiObject Win32_OperatingSystem | Select-Object Caption,Version,BuildNumber,ServicePackMajorVersion,OSArchitecture

Do not trust a version string from an application log for Windows 8.1, because unmanifested apps are told 6.2.

3. Confirm on the network

Hosts that never joined a domain show up in DHCP leases, switch MAC tables, asset databases and passive network monitoring. In OT networks, prefer passive identification from a span port over active scanning, because some controllers and old embedded stacks misbehave when scanned. Where active checks are allowed, run them from an authorised management host during an agreed window.

On modern Windows file servers you can see which clients still negotiate SMB 1. Microsoft's SMB guidance documents audit logging for SMBv1 access before you remove it:

Set-SmbServerConfiguration -AuditSmb1Access $true
Get-WinEvent -LogName Microsoft-Windows-SMBServer/Audit | Select-Object -First 20 TimeCreated,Message

Each event names a client that still uses SMBv1, which is close to a list of your XP, Server 2003 and misconfigured embedded hosts.

4. Record what each machine does

For every legacy host, write down the owner, the function, the equipment it controls, what it talks to and why it cannot be upgraded. That record is what turns a scary scan result into a decision.

How to isolate a legacy Windows machine

When the system has to stay, reduce what it can reach and what can reach it.

1. Put it in its own network segment. A VLAN or physical network with a firewall in front, allowing only the specific flows the equipment needs (for example, the imaging workstation to the archive server on one port). Deny everything else in both directions, including internet access.
2. Remove SMBv1 from everything else. Microsoft's SMB guidance shows how to disable SMBv1 on Windows 8.1 and later through Windows Features or PowerShell. Once modern hosts refuse SMBv1, an old client can only talk to the services you explicitly bridge for it.
3. Strip services on the host. Disable file and printer sharing, Remote Desktop and remote registry where the function allows, and keep the host firewall on with the narrowest rules.
4. Use a jump host for administration. Support staff should reach the machine from a hardened, patched management host, not from their everyday laptops.
5. Control removable media. USB drives are a common route into isolated systems. Scan media on a separate, supported station before it touches the legacy host.
6. Allowlist where possible. On Windows 7 and later, AppLocker can restrict which executables run, with the caveat Microsoft gives that it is not a security boundary.
7. Monitor the segment. Forward the host's security log if it can send it, and watch the segment's traffic for anything outside the documented flows.
8. Set a replacement date. Agree with the equipment owner on when the system will be replaced or the vendor will provide a supported platform, and track it like any other risk.

For deeper background on running old platforms in industrial and clinical settings, see our posts on manufacturing and OT software supply chains, medical device software supply chain security and legacy software supply chain risks.

Common mistakes

• Reading the build, not the service pack. A Windows 7 machine on build 7600 (no SP1) lost support in April 2013, not January 2020. An XP machine on SP2 lost it in July 2010. Always check ServicePackMajorVersion alongside the version.
• Trusting the version an app reports. Windows 8.1 tells unmanifested apps that it is 6.2. Inventory tools that use the old version APIs undercount 8.1 hosts and overcount Windows 8.
• Assuming ESU covered everything. Windows 7 ESU covered only the Professional, Enterprise and Professional for Embedded Systems editions, through volume licensing, for critical and important security updates. Home editions got nothing, and Windows 8.1 had no ESU at all.
• Forgetting the parts that ended separately. Edge 109 support ended in October 2023. Internet Explorer, the .NET runtimes and drivers each have their own lifecycle. A host may have stopped receiving browser fixes long before or after the OS.
• Assuming a rare out of band fix means servicing resumed. Any update published for an unsupported version after its end date is an exception for one problem, not a return to monthly fixes.
• Networking an unsupported OS without compensating controls. Connecting a legacy instrument "just for file transfer" to the general office network is how a single SMBv1 host becomes the entry point for a whole site.
• Turning off UAC or Secure Boot to make old software work. Both are cheap protections. Find the specific compatibility fix rather than disabling the control system wide.
• Treating AppLocker as a boundary. Microsoft says it is not a security feature in the servicing sense. Use it to reduce risk, not as proof that nothing else can run.
• Losing the record of why the machine exists. Without an owner and a reason, nobody can approve a replacement, and the machine runs forever.
• Ignoring the Secure Boot certificate rollover. Windows 8 era devices were built with 2011 certificates that begin expiring in 2026. Devices still in use that never get updated certificates will eventually fail to trust newer signed boot components.

Where Safeguard fits, honestly

Most of this post is outside what Safeguard does. Safeguard does not patch Windows, manage endpoints, inventory operating systems on a network, detect malware or scan firmware. It cannot make Windows XP or 8.1 supported again. Those jobs belong to Microsoft, your device and endpoint management tools, and your network team.

The honest link is the software around those machines. The applications that run on legacy hosts, and the newer systems that replace them, are built from open source components that need tracking just as much as the operating system does. A replacement imaging application, a historian, a kiosk front end or a data export script all carry dependencies. Safeguard's CLI can scan a repository, a container image or an SBOM file (safeguard scan --dir ., --image <name>, --sbom <file>), match components against vulnerability databases, apply reachability analysis, and the platform shows which projects contain a given component and version. Policies and gates can stop a known vulnerable dependency from shipping in the software you build. None of that patches an operating system.

FAQ

When did Windows XP support end?

Microsoft's lifecycle page lists the end of extended support for Windows XP as 8 April 2014 (the raw timestamp is 9 April 2014 at 06:59 UTC). Only Service Pack 3 was supported to that date; SP2 had already ended on 13 July 2010.

When did Windows 7 support end, and how long did ESU last?

Extended support for Windows 7 ended on 14 January 2020. Extended Security Updates ran for three yearly terms, the last ending on 10 January 2023, and were available only for Professional, Enterprise and Professional for Embedded Systems editions through volume licensing.

Is there any extended support for Windows 8.1?

No. Windows 8.1 support ended on 10 January 2023, and Microsoft's announcement states it would not offer Extended Security Updates for Windows 8.1. Windows 8 itself had already ended on 12 January 2016, when users had to move to 8.1.

What was the difference between Windows 98 and Windows NT?

Windows 98 ran on a DOS based core with FAT file systems, no enforced user separation and no file permissions. Windows NT ran a protected kernel with NTFS, mandatory logon, security identifiers, access tokens and access control lists. XP replaced the DOS based line with NT for home users.

Which Windows version introduced UAC?

Windows Vista introduced User Account Control, along with integrity levels. Windows 7 kept the same model.

Which Windows version introduced Secure Boot?

Windows 8. Microsoft describes UEFI Secure Boot as a firmware standard built into PCs beginning with Windows 8, alongside Early Launch Antimalware. Vista and Windows 7 do not support Secure Boot.

What is the Windows version number for Windows 7 and 8.1?

Windows 7 is version 6.1 and Windows 8.1 is 6.3. Vista is 6.0, Windows 8 is 6.2, XP is 5.1 and Windows 2000 is 5.0. Windows 8.1 reports 6.2 to apps that are not manifested for 8.1.

Is it safe to run Windows XP or 7 offline?

Offline reduces the risk a great deal but does not remove it. USB drives, maintenance laptops and vendor remote access all reach "offline" machines. Treat them as isolated, not safe: control media, document every connection and plan replacement.

How do I find Windows XP and 7 machines on my network?

Query Active Directory for computer objects with OperatingSystemVersion 5.x or 6.0 to 6.3, check systeminfo or WMI on individual hosts, review DHCP and asset records, and turn on SMBv1 audit logging on file servers to see which clients still use SMB 1.

Legacy Windows itself can only be fixed by Microsoft, and for these versions that will not happen. The software you build to replace or sit beside those machines is different: it ships open source components whose fixes you can apply yourself, which is where the steps below apply.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos patch Windows, detect old operating systems or isolate a network segment. They show how Safeguard handles the software you build and run alongside those systems.

The first demo is a real Safeguard CLI session. Asked to fix a lodash CVE, the assistant reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies to the dependencies in a replacement application or a data export tool written for a legacy instrument, whenever a fixed version exists.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. That suits teams whose code for plant or clinical systems cannot leave an internal network, because the scan runs on a machine you control.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. For a migration project, that lets an engineer ask about the components and vulnerabilities in the replacement software from inside Claude, within the tool permissions you set.

Click through it at your own pace, or open it full screen.

To try the CLI, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Microsoft Learn: Windows XP lifecycle
• Microsoft Learn: Windows Vista lifecycle
• Microsoft Learn: Windows 7 lifecycle
• Microsoft Learn: Windows 8 lifecycle
• Microsoft Learn: Windows 8.1 lifecycle
• Microsoft Learn: Windows 8.1 end of support on January 10, 2023
• Microsoft Learn: Fixed Lifecycle Policy
• Microsoft Learn: Extended Security Updates FAQ
• Microsoft Learn: Operating system version
• Microsoft Learn: Targeting your application for Windows
• Microsoft Learn: Security identifiers
• Microsoft Learn: Access tokens
• Microsoft Learn: Access control lists
• Microsoft Learn: Mandatory Integrity Control
• Microsoft Learn: User Account Control overview
• Microsoft Learn: How User Account Control works
• Microsoft Learn: Data Execution Prevention
• Microsoft Learn: /DYNAMICBASE (use address space layout randomization)
• Microsoft Learn: Kernel mode code signing policy
• Microsoft Learn: App Control and AppLocker overview
• Microsoft Learn: Overview of threat mitigations in Windows 10
• Microsoft Learn: Secure Boot (OEM)
• Microsoft Learn: Early launch antimalware
• Microsoft Learn: Microsoft Defender SmartScreen overview
• Microsoft Learn: BitLocker overview
• Microsoft Learn: Detect, enable and disable SMBv1, SMBv2 and SMBv3
• Microsoft Learn: Kerberos authentication overview
• Microsoft Learn: Active Directory Domain Services (Win32)
• Microsoft Learn: File encryption (EFS)
• Microsoft Learn: Implementing an AppContainer
• Microsoft Learn: UAC settings and configuration
• Microsoft Learn: Active Directory Domain Services overview
• CISA: Microsoft Ending Support for Windows XP and Office 2003 (TA14-069A)
• Microsoft Security Bulletin MS17-010
• Wired: Bill Gates, Trustworthy Computing (memo text, January 2002)

Last reviewed: 25 October 2026. All Windows versions in this post are out of support; check Microsoft's lifecycle pages for the editions and dates that apply to your machines.