End-of-life Software and Compliance
In this blog post, we will discuss the existing and upcoming compliance requirements around end-of-life software. Some are inferred while others are explicit but not all apply to every company.
tldr
PCI DSS 4.0 requires an end-of-life management program in place by March 31st, 2025
NIST SSDF / CISA SSDA recommends not using end-of-life software
OWASP Top 10 recommends not using end-of-life software as best practice
What are compliance requirements for end-of-life software?
PCI DSS v4.0
This is the most stringent compliance framework that requires a program to track end-of-life software and create plans to remediate them.
![](https://cdn.prod.website-files.com/65b1171a4b7fc537296e7c6d/65b77f2bfabd4d1964fe7689_65a007844aff4a993c1e621f_pci-4-12.3.4.png)
On March 31st, 2024 PCI DSS 4.0 takes effect but a few requirements such as control 12.3.4 are future-dated and will take effect a year later on March 31st, 2025. PCI recommends spending 2024 implementing controls needed to fulfill all version 4.0 requirements including the future-dated ones as a best practice.
After March 31st, 2025, all requirements under PCI DSS 4.0 will be considered during an audit.
We cover more in depth PCI DSS compliance and end-of-life software here.
NIST Secure Software Development Framework (SSDF)
NIST SSDF recommends in PW.4.1 and PW.4.1 to avoid end-of-life software and use well maintained/supported third party software in your software supply chain. Well maintained/supported here meaning that vulnerabilities are being patched by the maintainers of the third party software.
![](https://cdn.prod.website-files.com/65b1171a4b7fc537296e7c6d/65b77f2b974c11917bbb4e1a_65a00fb50146f9095d27a8ff_nist-pw.4.1.png)
NIST also recommends a program in place to monitor for newer versions, security patches from the official partners and promptly implement the updates as they come out.
![](https://cdn.prod.website-files.com/65b1171a4b7fc537296e7c6d/65b77f2c7ba9a1afb0618b18_65a00f7d915e97d928953813_nist-pw.4.4.png)
A special callout to CISA's Secure Software Development Attestation form which references PW.4.1 and PW.4.4 as well. Anyone company that sells to the federal government will need to produce then sign this attestation that they are making a best case effort to source well maintained software and regularly fixing end-of-life software.
CISA's attestation is still in review and comment so it is subject to some change but unlikely to be major deviations from the existing draft. We discuss this in more details here.
OWASP Top 10 (2021)
![](https://cdn.prod.website-files.com/65b1171a4b7fc537296e7c6d/65b77f2c2b4968e90cecdd29_65a008782f6120bc4ba84471_owasp-top-10-a06.png)
A:06 specifically calls out vulnerable and outdated components as a popular exploit moving up in priority since the 2017 OWASP Top 10 list. OWASP recommends similar approaches to NIST to inventory your all software, packages, and dependencies' versions and regularly implement fixes to outdated components.
Though OWASP Top 10 is not a compliance framework, it is a very popular standard within the AppSec community and good benchmark for web app security.
Other Compliance Frameworks
There are some compliance frameworks such as SOC 2, ISO 27001, or HIPAA that do not call out end-of-life software specifically but it should not mean it is not important. Most of these frameworks advocate for strong vulnerability management and secured systems to protect user data and good end-of-life management is good vulnerability management.