Is End-of-Life Software a SOC 2 or ISO 27001 Finding?

End-of-life software isn't automatically an audit finding. Undocumented end-of-life software is. Here is what auditors test, layer by layer, and the evidence that passes.

Today, Windows Server 2012 runs out of road

As of the end of today, October 13, 2026, Windows Server 2012 and 2012 R2 stop receiving security updates at any price. Microsoft's lifecycle page shows the third and final year of Extended Security Updates ending on this date. There is no fourth year to buy.

Any server still running either version is now unpatchable by its vendor. That makes this a good moment to answer the question compliance teams keep asking: does running end-of-life software fail an audit?

Is end-of-life software a SOC 2 or ISO 27001 finding?

Not automatically. Neither SOC 2 nor ISO 27001 bans end of life software. Both require you to identify vulnerable components and manage the risk. End-of-life software becomes a finding when it is unknown, undocumented, or unmanaged: no inventory entry, no risk owner, no compensating control, and no plan to retire it.

Both frameworks treat it as a vulnerability management question. The controls are explicit about the obligation, not the outcome:

• SOC 2 CC7.1 expects detection and monitoring procedures that surface vulnerable configurations and newly discovered vulnerabilities.
• ISO 27001:2022 Annex A 8.8 expects timely information about technical vulnerabilities, an evaluation of exposure, and appropriate measures.
• NIST SP 800-53 SA-22 says it directly: replace unsupported components, or provide continued support through another source, with isolation to reduce the risk.

So the auditor's real question is not "is anything old?" It is "do you know what is unsupported, and can you show you're handling it?" We made the same distinction in supportability, not age: age is a proxy, and supportability is the thing that matters.

The end-of-life layers nobody inventories

Operating systems get noticed. Windows 10 and Windows Server 2012 had years of warnings. The riskier end-of-life software lives one layer down, inside servers that look healthy at the operating system level.

Many widely used components have reached end of life in the last two years, according to endoflife.date:

• CentOS 7 ended on June 30, 2024. Many servers still run it, because it worked.
• Python 3.8 ended in October 2024, and Python 3.9 in October 2025.
• PostgreSQL 12 ended in November 2024, and PostgreSQL 13 in November 2025.
• PHP 8.1 ended in December 2025.
• Node.js 18 ended in April 2025, and Node.js 20 in April 2026.
• Ubuntu 20.04 standard support ended in May 2025. Extended security maintenance through Ubuntu Pro runs to 2030, but only if you subscribe.

None of these announce themselves. A container built two years ago keeps running its original runtime. A database nobody touches stays on its original major version. The operating system inventory looks clean while the application stack underneath is past its vendor's last patch.

Containers make this worse, not better. A base image pins a runtime version at build time, and a scanner that only reads the host operating system never sees it. The same Python 3.8 interpreter can run inside a dozen images on a host whose own operating system is fully supported.

That is why an inventory that stops at the operating system will fail the auditor's question. Annex A 8.8 and CC7.1 don't distinguish between layers. A vulnerable PostgreSQL instance is as much a technical vulnerability as a vulnerable kernel.

What turns end-of-life software into a finding

From the auditor's side, the pattern is consistent across frameworks. An end-of-life component becomes a finding when one of these is missing:

1. It is in the inventory. You can't manage what you haven't listed, and "we didn't know" is the weakest position in any audit.
2. Someone owns the risk. A named person accepted it, with a date.
3. A compensating control exists. Typically network isolation, restricted access, or extra monitoring, matching what SA-22 suggests.
4. There is a dated plan to retire it, or a contract for continued support.
5. The exception expires. An exception with no end date is a permanent risk acceptance, and auditors read it that way.

PCI DSS goes further than SOC 2 or ISO 27001. Its requirement 12.3.4 requires a review of hardware and software at least every 12 months, tracking of vendor end-of-life announcements, and a remediation plan approved by senior management. Even if you aren't in PCI scope, that is a sound template for the evidence an ISO 27001 or SOC 2 auditor will find convincing.

Extended support counts, if you can prove it

Paid extended support is a legitimate answer under every framework above, because it restores a vendor patch stream. Windows ESU, Ubuntu Pro's extended maintenance, and commercial support for end-of-life runtimes all qualify as continued support in the sense SA-22 describes.

The catch is proof. A support contract shows that patches are available. It doesn't show that they were applied. For each covered system, the evidence has to show that updates are actually installing, month after month. We covered that gap for Windows 10 in what auditors accept after October 13: enrolled is not the same as patched.

Why a point-in-time inventory isn't enough

Most teams build their end-of-life inventory once a year, for the audit. That works for a SOC 2 Type I, which looks at a single date. It fails a SOC 2 Type II, which covers a period of usually six to twelve months.

Software crosses its end-of-life date in the middle of audit periods. Python 3.9 and PostgreSQL 13 both did, a few weeks apart, late in 2025. An inventory taken in September shows them as supported. By December, every instance of either was out of support, and nothing changed on the servers themselves.

Continuous evidence closes that gap, and it is what infrastructure trust means for supportability. When each host reports what it runs, and each component is checked against its vendor's lifecycle, the day something crosses end of life becomes a dated event in the record. That is a much stronger position than discovering it during fieldwork.

It is the same principle as compliance evidence, not a fire drill, applied to supportability. It also bounds how stale any posture check can be.

A practical end-of-life control

Here is a control that holds up under SOC 2, ISO 27001, and PCI DSS alike:

• Inventory every layer: operating system, runtime, database, and major libraries, per host.
• Attach a lifecycle date to each component from the vendor or a maintained source, and check it continuously, not annually.
• Look 12 months ahead. Anything reaching end of life within a year gets an owner and a plan now.
• Register every exception with an owner, a compensating control, and an expiry date.
• Prove continued support where you pay for it by showing updates installing per host.
• Keep the history so an auditor can see when each component crossed end of life and what happened next.

The takeaway

• End-of-life software isn't automatically a SOC 2 or ISO 27001 finding. Unknown or undocumented end-of-life software is.
• Windows Server 2012 and 2012 R2 lose their last paid security updates today. There is no further extension.
• The risky end-of-life layer is usually runtimes and databases, not the operating system.
• Extended support counts as continued support, but only with per-host proof that updates are installing.
• End-of-life dates fall inside audit periods, so the inventory has to be continuous to be true.

Find out what's already past end of life in your environment: scan 10 devices free and get a verdict for each one in under an hour.