What End-of-Life Software Actually Means
Every software product has a lifecycle. The vendor supports it, issues security patches, and fixes vulnerabilities — until they stop. When a product reaches its end-of-life (EOL) date, the vendor ends security patch support. From that point forward, newly discovered vulnerabilities in that product will never receive a patch. The software becomes permanently vulnerable to any exploit developed after its EOL date.
This is different from a product that simply has unpatched vulnerabilities. Those can be fixed. EOL software cannot be fixed through patching. The only remediation is replacement or architectural mitigation — and assessors know the difference.
Common examples in small DIB environments: Windows 10 (EOL October 2025), Windows Server 2012/2016 R2, PHP 7.x, Python 2.x, older versions of network operating systems, and unsupported third-party applications that handle CUI data flows. If any of these are in your CUI boundary, you have a compliance exposure.
The CMMC Requirement — SI.L2-3.14.1
CMMC Level 2 requirement SI.L2-3.14.1 comes from NIST SP 800-171 requirement 3.14.1:
The phrase "identify, report, and correct information system flaws" is where EOL software becomes a direct finding. An EOL product running in your CUI environment is a known, documented flaw for which no correction exists through the normal patching process. You have identified it. You cannot report it as corrected. You cannot install a security update because none will be released.
The NIST 800-171A assessment guide — the document C3PAO assessors follow — directs assessors to verify that your flaw remediation process addresses software that is no longer supported by the vendor. Running EOL software in scope of your assessment is not a gray area. It is an objective finding.
SI.L2-3.14.1 carries a 5-point SPRS deduction and is not POA&M eligible. A finding here cannot be deferred — it must be corrected before you can achieve a passing assessment or self-attest with confidence.
SPRS Score Impact
Your SPRS score starts at 110. Every requirement you cannot demonstrate as fully implemented reduces that score by a defined point value. SI.L2-3.14.1 is weighted at 5 points — one of the heavier penalties in the scoring model.
| Requirement | Domain | SPRS Weight | POA&M Eligible | EOL Relevance |
|---|---|---|---|---|
| SI.L2-3.14.1 | SI | 5 pts | No | Direct finding for EOL software in CUI boundary |
| SI.L2-3.14.2 | SI | 3 pts | No | Malicious code protection; EOL AV products without updates |
| CA.L2-3.12.3 | CA | 3 pts | No | Continuous monitoring — EOL status must be tracked and visible |
| RA.L2-3.11.2 | RA | 3 pts | No | Vulnerability scan findings on EOL software have no patch resolution |
A single EOL operating system in scope can cascade across multiple requirements. An EOL OS creates a flaw remediation finding (SI.L2-3.14.1), generates unresolvable vulnerability scan findings (RA.L2-3.11.2), and undermines your claim of continuous monitoring (CA.L2-3.12.3) — because continuous monitoring of a system you cannot patch is not a control, it is surveillance of a known vulnerability with no path to resolution.
endoflife.date — The Reference Source
endoflife.date is an open-source, community-maintained project that tracks support lifecycle dates for hundreds of software products — operating systems, programming language runtimes, databases, web servers, network operating systems, and more. It surfaces EOL dates, extended support windows, and current support status in a machine-readable format.
For a CMMC compliance program, it solves a real operational problem: vendor lifecycle pages are inconsistent, scattered, and not organized for bulk lookup. endoflife.date normalizes this data into a single API with consistent date fields, allowing tools to programmatically check whether a product version is currently supported.
The project's API returns structured data for each product: the version string, release date, end-of-life date, whether the version is still actively supported, and whether extended support (ESU) is available. That structure maps directly to what you need for a CMMC flaw remediation inventory.
How 1TEN Integrates endoflife.date
1TEN now queries the endoflife.date API directly within the platform. When you document software assets in your system inventory — operating systems, server applications, runtime environments, databases — 1TEN checks each product and version against endoflife.date and surfaces the support status alongside your asset record.
This integration does three things for your compliance posture:
| Capability | What It Does | Requirement It Supports |
|---|---|---|
| EOL Status Display | Shows current support status for each inventoried software product and version — active, EOL, or approaching EOL | SI.L2-3.14.1 — Flaw Remediation |
| Approaching EOL Alerts | Flags products within 12 months of their end-of-life date so you can plan migration before it becomes a finding | CA.L2-3.12.3 — Continuous Monitoring |
| Assessment Evidence | Generates a software inventory report with EOL status columns — a direct artifact for your SSP and C3PAO evidence package | SI.L2-3.14.1, RA.L2-3.11.2 |
The goal is to shift EOL management from reactive (discovered during assessment) to proactive (tracked continuously inside your compliance program). A C3PAO assessor reviewing your SI.L2-3.14.1 implementation wants to see that you have a documented process for identifying unsupported software. A live inventory with EOL dates pulled from a trusted source is stronger evidence than a spreadsheet last updated before your assessment prep began.
What Counts as EOL in a CMMC Assessment
The relevant question is not "is this software EOL in general" — it is "is this EOL software in scope of my CUI boundary." Scope matters. An EOL product on a network segment completely isolated from CUI processing is a different risk profile than the same product on a workstation used to open technical drawings.
For scoping purposes, assessors look at systems that store, process, or transmit CUI, plus Security Protection Assets (SPAs) — systems that protect or monitor the CUI environment even if they don't touch CUI directly. A firewall running an EOL firmware version is in scope as a SPA.
| Asset Type | EOL Risk Level | Notes |
|---|---|---|
| Workstations handling CUI | Critical | EOL OS is a direct SI.L2-3.14.1 finding with no mitigation path |
| Servers in CUI boundary | Critical | EOL OS or server application (IIS, Apache, SQL Server) carries same weight |
| Network devices (firewalls, switches) | High | SPAs — in scope even without direct CUI contact |
| Runtime environments (PHP, Python, .NET) | High | EOL runtime on an in-scope server creates flaw remediation gap |
| Databases in CUI boundary | High | EOL database version (MySQL 5.7, SQL Server 2012) is a finding |
| Out-of-scope isolated systems | Lower | Still represents operational risk; confirm boundary isolation is documented |
Extended Support Updates (ESU) programs — like Microsoft's paid ESU for Windows 10 or Windows Server 2012 — extend patch availability past the standard EOL date. If your organization is enrolled in an ESU program and actively applying those patches, the product is not EOL from an assessment standpoint. Document your ESU enrollment and patch application records. 1TEN tracks ESU availability as part of the endoflife.date integration.
Remediation Options When You Find EOL Software
The straightforward answer is upgrade or replace. That is also the only answer that fully closes SI.L2-3.14.1. But assessors understand that not all upgrades happen overnight, and they look for evidence that you have a plan and are executing against it.
| Option | Closes SI.L2-3.14.1? | Notes |
|---|---|---|
| Upgrade to supported version | Yes | The only option that fully closes the requirement |
| Enroll in ESU (if available) | Yes, while active | Requires documented enrollment and patch records; time-limited |
| Remove from CUI boundary scope | Yes, if scope is valid | Architectural isolation must be documented and defensible |
| Replace with supported alternative | Yes | Migration to a supported product version or competing product |
| Compensating controls only | No | Does not satisfy SI.L2-3.14.1; may reduce risk but cannot substitute for the requirement |
A note on compensating controls: some organizations attempt to offset EOL software risk with network segmentation, enhanced monitoring, or application whitelisting. These reduce the blast radius of an exploit but they do not satisfy the flaw remediation requirement. Assessors will credit them as risk mitigations in your overall posture, but SI.L2-3.14.1 will remain a finding until the EOL software is gone or replaced.
If you're mid-migration at the time of assessment, bring documentation: the migration project plan, current status, and a realistic completion date. A contractor who can show an active, resourced upgrade project is in a materially better position than one who acknowledges the finding without a remediation path.
What Assessors Want to See for SI.L2-3.14.1
C3PAO assessors use the NIST 800-171A assessment guide to evaluate SI.L2-3.14.1. They look for three things: a documented flaw remediation policy, a process for identifying flaws (which includes EOL status), and evidence that identified flaws are corrected within your defined timeframe.
For EOL software specifically, the evidence package should include:
| Artifact | What It Shows |
|---|---|
| Software inventory with version data | All in-scope systems documented with product names and version strings |
| EOL status records | Support status for each product — sourced from vendor pages or endoflife.date |
| Flaw remediation policy | Written policy defining your patch cadence and handling of unsupported software |
| Patch application records | Last 90 days of patch history for in-scope systems |
| ESU enrollment records (if applicable) | Proof of enrollment and associated patch records |
| Migration plan (if upgrading) | Documented plan with timeline if EOL software upgrade is in progress |
1TEN generates the software inventory and EOL status report as an exportable artifact tied directly to your SI.L2-3.14.1 implementation statement in the SSP. The goal is that your evidence package for this requirement is a single, coherent document — not a collection of spreadsheets assembled the week before assessment.
Frequently Asked Questions
Windows 10 reached end-of-life on October 14, 2025. Standard security updates ended on that date. If you are running Windows 10 on in-scope systems and are not enrolled in Microsoft's paid ESU program, those systems represent an SI.L2-3.14.1 finding. Upgrading to Windows 11 or enrolling in ESU (which extends patch support for up to three years) are both valid paths. 1TEN tracks Windows 10 ESU availability and prompts you to document your enrollment status.
EOL software in your CUI boundary creates an objective finding against SI.L2-3.14.1, which carries a 5-point SPRS deduction and is not POA&M eligible. Whether that finding fails your overall assessment depends on how your C3PAO handles the finding and whether you can demonstrate active remediation. There is no scenario where EOL software in scope is simply accepted — it must be resolved, removed from scope, or covered by an active ESU program.
The compliance question is whether the vendor is still releasing security patches, not what marketing term they use. If the vendor is actively releasing security updates, the product is supported from an assessment standpoint — document the vendor's support statement and your patch records. If the vendor has stopped releasing security patches regardless of the label, treat it as EOL and plan accordingly.
This is a common situation in small DIB environments — an older engineering or manufacturing application that requires a specific OS version to run. Your options are: (1) work with the application vendor on a supported OS version, (2) replace the application with one that runs on a supported OS, (3) isolate the system completely from your CUI boundary so it falls out of assessment scope — and document that isolation thoroughly, (4) virtualize the application on a supported host OS if the application can run in a VM without connectivity to CUI systems. None of these are fast, which is exactly why early EOL tracking matters.
At minimum, quarterly — tied to your vulnerability scanning and asset review cadence. The 1TEN platform checks EOL status continuously against your documented asset inventory and flags products approaching EOL within 12 months, so you are not discovering an upcoming deadline during assessment prep. Products transition to EOL on fixed, publicly announced dates. There is no excuse for being surprised.
No single source is authoritative in a compliance context — the vendor's own lifecycle documentation is the primary reference. endoflife.date aggregates vendor data and is widely accurate, but it is a reference tool, not an official compliance registry. For your SSP and evidence package, link your EOL status claims to the original vendor lifecycle page (Microsoft's product lifecycle search, Red Hat's product lifecycle, etc.). 1TEN uses endoflife.date for real-time status checks and surfaces vendor source links so your documentation points to the primary source.