Official intent
Reduce technical debt by retiring the unsupported, end-of-life, and legacy systems attackers rely on. The official source remains authoritative.
Read the official campaign ↗Technical debt is a security liability. End-of-life operating systems, unpatched appliances, and legacy protocols are the footholds adversaries count on you keeping. Treat retirement as a planned program: find the debt, rank it by exposure, and either upgrade, replace, isolate, or decommission it on a schedule.
Who this applies to: Any organization older than a few years. The smaller the IT team, the more likely debt is being carried silently because nobody has time to retire anything.
Why it matters
Unsupported software stops receiving security fixes, so known exploits stay open forever. Legacy systems are also the ones with weak authentication and flat network access — exactly what an intruder needs to move. Paying down this debt removes whole classes of risk instead of patching them one at a time.
Risks this reduces
- Exploitation of vulnerabilities in software that will never be patched again
- Weak legacy authentication and protocols that bypass modern controls
- Appliances and firmware quietly past end-of-support at the network edge
- Compounding cost and risk from migrations that are started but never finished
Who owns it
IT leader
Executive sponsor, Application owners, MSP
High
Medium to high
Ownership is a named person, not a department. If nobody can be named, that is the first finding.
Dependencies and prerequisites
Leans on: IT-02 — Asset inventory
- An asset inventory that records version and end-of-support dates
- An executive sponsor who can fund retirement and hold deadlines
- A named owner for each legacy application, not just each server
Action timeline
- List systems already past end-of-support
- Flag any that are internet-facing
- Confirm no internet-facing system is running unsupported software; isolate anything that is
- Disable the legacy protocols you can turn off without a project — SMBv1, TLS 1.0/1.1, basic authentication
- Rank legacy systems by exposure and business impact
- Isolate the worst offenders that cannot be retired yet
- Build a funded retirement/upgrade roadmap
- Disable legacy protocols (SMBv1, TLS 1.0/1.1, basic auth)
- Retire or replace the top items
- Add end-of-support dates to the asset inventory
The 90-day target for this practice is the Measured level below: coverage and effectiveness are reported, and exceptions are handled rather than accumulated.
Step-by-step implementation
- Use the asset inventory to find unsupported, end-of-life, and unmaintained systems and protocols.
- Rank each by exposure (internet-facing, holds CUI, widely reachable) and by business dependency.
- For each, choose a path: upgrade, replace, isolate behind compensating controls, or decommission.
- Sequence the work into a funded roadmap and put executive weight behind the deadlines.
- Track end-of-support dates in the inventory so future debt is retired before, not after, it goes unsupported.
What good looks like
Seven levels, used identically across every practice, scorecard, and download on this site. The distinction that matters most is between having a tool, deploying it to the correct scope, and operating it consistently.
- Absent
Nobody knows what is past end-of-support, and nothing is scheduled for retirement.
Is there anything at all — a tool, a document, a person who owns it? - Documented
End-of-life systems are identified and each has a written retirement or isolation intent.
Is the intent written down, with a named owner and a scope? - Configured
The highest-risk legacy systems are isolated behind enforced compensating controls.
Is it switched on and set up somewhere — even if only in part of the estate? - Deployed
A funded, sequenced roadmap covers every identified legacy system, and the first retirements are complete.
Does it cover everything in scope, with the exceptions written down? - Measured
Count and exposure of unsupported systems are reported, with the trend heading down each quarter.
Can you state a number for coverage or effectiveness, and show the trend? - Governed
Lifecycle management is a standing responsibility with budget, review, and refresh before end-of-support rather than after.
Is there an accountable owner, a review cadence, and retained evidence?
Validation procedures
Until these pass, the practice is configured — not deployed.
- Confirm no internet-facing system is running unsupported software.
- Verify legacy protocols are disabled by testing that they no longer negotiate.
- Check that each remaining legacy system has a dated retirement or isolation plan.
Evidence to retain
Lifecycle/retirement policy and the funded roadmap
Evidence legacy protocols are disabled and systems are isolated
Roadmap progress report against retirement dates
Confirmation scan showing no unsupported internet-facing systems
Retaining these supports your own assurance and gives a reviewer something concrete to examine. It does not constitute an assessment or satisfy a contractual requirement on its own.
Operating metrics
| Metric | How it is calculated | Directional target |
|---|---|---|
| Unsupported systems in production | Systems running software past vendor end-of-support. | Trending to zero; none internet-facing at any point. |
| Legacy protocol availability | Services still negotiating deprecated protocols, tested rather than assumed. | Zero outside a dated, owned exception. |
| Roadmap adherence | Retirement milestones completed ÷ milestones due. | Above 80% each quarter. |
Targets are directional guidance for your own programme, not compliance thresholds.
Common failure modes
“We will retire it next year” repeated indefinitely, isolating a legacy box on paper but leaving it flat on the network, and forgetting appliances and firmware that also reach end-of-support. A migration that never funds the last 10% is not a retirement.
Two sized paths
Start with the two questions that matter: what is internet-facing, and what holds sensitive data? Retire or isolate anything unsupported in those two groups first and accept that the rest waits. One line item in the annual budget for lifecycle refresh does more than a debt-scoring exercise you will not maintain.
Track end-of-support dates as an inventory attribute with automated alerting a year ahead, and make lifecycle refresh a standing budget line rather than a project. Score debt by exposure and business dependency so sequencing survives leadership changes, and prevent new debt by requiring a supported-life commitment before a product is adopted.
Tool categories
Categories, not recommendations. This site ranks no vendors and accepts no paid placement.
Retiring or isolating a legacy system usually breaks something nobody documented. Identify the consumers of every legacy service before you change it, stage the change, and keep a rollback. The last ten percent of a migration is where debt programs quietly stall.
Framework mappings
Independent mappings are aids to your own analysis — not authoritative equivalence, not coverage, and not a compliance determination. Read the caveat on every row before using it.
Why: The same reasoning carries to the inherited CMMC practices.
What this does not claim: Supports the requirement; it does not satisfy it on its own and does not establish an assessment outcome. Scope, implementation quality, and evidence decide that.
Why: The CSF asset lifecycle outcome covers systems through decommissioning, which is exactly this practice.
What this does not claim: The CSF describes outcomes, not testable controls.
Why: CIS requires that unsupported software be addressed or documented with a mitigation, which is the substance of this practice.
What this does not claim: CIS is a voluntary benchmark. Alignment with it carries no contractual weight.
Method: Read against the primary source text, then classified by relationship type and confidence. No automated mapping tool was used. How mappings are made →
NIST SP 800-171 relationships have their own requirement-level section below, with links into the full mapping experience.
Related NIST SP 800-171 requirements
Requirement-level relationships from the site’s independent 800-171 mapping. Each one names what it does and does not claim — a practice supports implementation of a requirement; it never satisfies one by itself. Expand a row for the rationale and caveat.
NIST SP 800-171 Rev. 2
3.4.1Baseline configurations and inventoriesOperational supportModerate
Why: The requirement runs 'throughout the respective system development life cycles', and retirement is the life-cycle stage most organizations skip: tracking end-of-life systems and actually decommissioning them is what keeps the inventory true and the baselines maintainable.
What this does not claim: 800-171 contains no technical-debt requirement, so this is a reasoned relationship rather than a stated one. Retiring systems neither builds the inventory nor authors a baseline; the practice keeps both records honest at the end of the life cycle and contributes nothing at the beginning.
Review status: Technical review complete.
Open the 3.4.1 page →3.14.1Flaw identification and remediationPartial implementation supportModerate
Why: End-of-life systems are flaws no patch will ever correct. Retiring them — this practice's core activity — is flaw remediation executed at the lifecycle level: the exposure is removed rather than perpetually managed.
What this does not claim: May partially address the requirement. Timely identification and correction of flaws in the systems the organization keeps is patching-cycle work this practice does not perform, and 800-171 contains no technical-debt requirement — the relationship is reasoned from the requirement's remediation intent, not stated in its text.
Review status: Technical review complete.
Open the 3.14.1 page →NIST SP 800-171 Rev. 3
03.04.06Least FunctionalityContextual relationshipModerate
Why: Retiring legacy systems removes nonessential and nonsecure functions wholesale — a decommissioned server is the most complete service disablement there is — and the practice's exposure-first sequencing tells the least-functionality review where to look first.
What this does not claim: The requirement's substance is configuration work on the systems that remain: mission-essential capability, a defined prohibited list, periodic review, and disablement. The practice shrinks and informs that work without performing any of it, so the relationship is contextual rather than implementation.
Review status: Pending NIST SME review.
Open the 03.04.06 page →03.16.02Unsupported System ComponentsDirect implementation supportHigh
Why: Retiring the systems attackers count on you keeping is this requirement in campaign language: strategic technical debt reduction exists to find unsupported and end-of-life components and replace them on a deliberate, funded schedule. No practice-requirement pair in this group is a closer fit.
What this does not claim: Supports implementation of the requirement without exhausting it: the requirement also demands documented risk-mitigation options for every component that genuinely cannot be replaced, and a retirement roadmap that goes silent about its exceptions leaves that half unimplemented. An assessor reads the unsupported-component register against the asset inventory, not against the roadmap's ambitions.
Review status: Pending NIST SME review.
Open the 03.16.02 page →Review status
| Technical review | Reviewed |
|---|---|
| Editorial review | Reviewed |
| Reviewed by | inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering |
| Last reviewed | |
| Official source verified | |
| Content version | 1.0 |