Compliance
Aug 28, 2026

Does Running EOL Software Violate PCI DSS, HIPAA, or SOC 2?

EOL software is not an automatic violation, but it lands on the wrong side of the controls these frameworks enforce.

Give me the TL;DR
Does Running EOL Software Violate PCI DSS, HIPAA, or SOC 2?
For Qualys admins, NES for .NET directly resolves the EOL/Obsolete Software:   Microsoft .NET Version 6 Detected vulnerability, ensuring your systems remain secure and compliant. Fill out the form to get pricing details and learn more.

Not automatically, but it puts you on the wrong side of the controls these frameworks enforce. PCI DSS 4.0.1 requires vendor-supported software and 30-day critical patching, while HIPAA and SOC 2 require timely vulnerability remediation. When a component is end of life, there is no patch to apply, so the gap becomes documented and auditable.

What does PCI DSS say about unsupported software?

PCI DSS 4.0.1 addresses end-of-life software directly. Requirement 12.3.4 requires organizations to review all hardware and software at least every twelve months to confirm each component still receives vendor support; this was a future-dated best practice that became mandatory on March 31, 2025. Requirement 6.3.3 requires critical patches within 30 days of release, Requirement 6.3.2 requires a maintained software inventory, and Requirement 12.3.2 requires a targeted risk analysis for any deviation, such as running an end-of-life component in a cardholder data environment.

The problem for end-of-life software is that Requirement 6.3.3 cannot be met as written when the vendor no longer issues patches.

How does HIPAA treat end-of-life software?

The HIPAA Security Rule requires a risk analysis and audit controls (§164.312(b)) and expects reasonable and appropriate safeguards for protected health information. An unpatchable known vulnerability in a system that touches that data undermines those safeguards and is difficult to defend as reasonable once a fix is impossible through official channels.

How do SOC 2 and ISO 27001 treat it?

SOC 2 auditors treat running end-of-life software as a documented risk choice, which shifts the burden to your risk analysis and compensating controls. ISO 27001:2022 Annex A Control 8.8 requires timely evaluation and handling of technical vulnerabilities, and an end-of-life component is a visible failure of that control when no remediation path exists.

How do you close the gap?

Maintain an inventory with end-of-life tracking, document a remediation plan, and, for components you cannot retire yet, restore a supported patch stream. With vendor-backed support, the documented remediation plan can reflect active support rather than an open gap, critical patches can be applied within the 30-day window, and the inventory shows a supported component. HeroDevs Never-Ending Support provides that coverage for end-of-life open source.

This article is general information, not legal advice. Confirm requirements with your assessor or counsel.

Frequently asked questions

Is running EOL software an automatic PCI DSS failure?

Not automatically, but it conflicts with Requirements 12.3.4, 6.3.2, 6.3.3, and 12.3.2 and typically creates a finding.

When did PCI DSS Requirement 12.3.4 become mandatory?

March 31, 2025, after a future-dated best-practice period.

Does HIPAA prohibit end-of-life software?

Not by name, but unpatchable vulnerabilities undermine the required reasonable and appropriate safeguards.

How does SOC 2 view EOL software?

As a documented risk choice that shifts the burden to your risk analysis and compensating controls.

Can extended support help with compliance?

Yes. It turns an open, unpatchable gap into a supported component with a patch trail auditors can review.

Table of Contents
Author
Rob Nalen
Chief Operating Officer
Open Source Insights Delivered Monthly