Forge University
Industry News

The Executive Case for Sunsetting Software Before Regulators Force Your Hand

September 2, 2026

Randy Hall, CEO— AI-assisted and reviewed prior to publication.

Old server rack beside a modern data center building, symbolizing legacy technology being phased out

Sunsetting legacy software is a budget and staffing decision, not a background IT task, because unsupported systems now draw direct regulatory attention and carry a measurable cost premium. Leadership that treats decommissioning as routine maintenance ends up making the call under breach pressure instead of on its own schedule, which is the more expensive way to do it.

Why Is CISA Suddenly Ordering Agencies to Rip Out Old Network Gear?

CISA issued Binding Operational Directive 26-02 requiring federal civilian agencies to identify and decommission end-of-support edge devices such as firewalls, routers, VPN gateways, and load balancers on a fixed timeline. The directive exists because CISA's guidance on end-of-support edge devices states plainly that agencies must decommission all identified EOS edge devices from agency networks, replacing devices as needed with vendor-supported devices that can receive current security updates, and report every decommission back to the agency.

This is not a theoretical hardening exercise. Reporting on the order noted that the directive focuses on edge devices, many of which remain in service long after vendors stop issuing security updates, and that the threat of exploitation to information systems running end-of-support edge devices is substantial and constant, according to Nextgov/FCW's coverage of the mandate. CISA's own leadership was direct about the private sector implication: an agency official said other organizations should follow the same lead, adding that "unsupported devices should never remain on enterprise networks."

Cisco's breakdown of the directive explains why edge devices specifically draw this level of concern. These devices are essential gatekeepers of network security but become vulnerable once they reach end-of-support status, creating significant security risks that make them prime targets for sophisticated threat actors, including nation-state adversaries, in part because they are internet-facing and often integrated with identity management systems, according to Cisco's analysis of BOD 26-02. That combination of exposure and privilege is exactly why an aging firewall or VPN concentrator is worth more to an attacker than almost anything else on the network.

What Does This Mean If You Are Not a Federal Agency?

You are not bound by CISA's directive, but the pattern behind it is a preview of what regulators, auditors, and insurers will start expecting from everyone. Federal policy tends to become the floor for compliance frameworks, procurement requirements, and cyber insurance underwriting within a few budget cycles, and the direction of travel is already visible.

The U.S. has started legislating around this problem directly. A recent policy analysis noted that the National Defense Authorization Act for fiscal year 2026 mandates a new framework for integrating technical debt assessment, tracking, and management into IT investment decisions and budget justification materials, per Aspen Digital's review of end-of-life technology policy. Once "technical debt" becomes a line item regulators expect you to track and justify, ignoring it stops being a quiet operational choice.

The financial case is already measurable outside of any mandate. Organizations carrying heavy technical debt from outdated platforms and manual compliance workarounds face materially higher breach costs than those running modernized environments, with one analysis of IBM's breach cost data finding average breach costs of $5.28 million for organizations with high system complexity, often caused by outdated platforms, compared to $3.92 million for modernized environments, as reported by IT Convergence's review of obsolete software risk. That gap is roughly a third of a million dollars per incident, before you count downtime or regulatory exposure.

The scale of the exposure is also larger than most leadership teams assume. Research on unsupported software found that roughly 20% of critical enterprise assets run end-of-life open source software containing high-severity vulnerabilities, and vulnerabilities in end-of-life or end-of-support systems are four times more likely to be weaponized by attackers, according to HeroDevs' analysis of legacy software risk. One in five critical systems carrying that kind of risk is not a footnote in a board presentation, it is the headline.

Environment typeAverage breach costDriving factor
High system complexity, legacy-heavy$5.28 millionOutdated platforms, manual compliance workarounds
Modernized, supported environment$3.92 millionCurrent patching, automated controls

The Real Decision Isn't the Breach, It's the Debt You're Carrying

Framing this as a patching problem understates it. The more useful frame for a leadership team is technical debt: every EOL system you keep running is a liability that compounds interest in the form of rising breach probability, shrinking vendor support, and eventual forced replacement on someone else's timeline. CISA's own guidance is blunt about the assumption you should make, noting that the agency does not assume that all running legacy products are fully patched or that all end-of-life products have been decommissioned, from CISA's implementation guidance on BOD 26-04. Translate that into your own environment: nobody, including your own security team, should assume your asset inventory is complete or current.

That is the real budget conversation. Replacing an EOL edge device on your own timeline, with a tested migration plan and a defined rollback window, costs a fraction of an emergency replacement forced by an active exploitation campaign or a regulator's finding. Sunsetting software well means planning the decommission before the vendor's support clock runs out, not after an incident forces the question.

Who on Your Team Can Actually Plan a Decommission?

This is where most organizations discover a skills gap rather than a budget gap. Decommissioning an edge device, a legacy application, or an entire network segment without creating an outage requires someone who understands the current architecture, the dependencies riding on top of it, and how to design its replacement in the same motion, and that combination of network design and lifecycle judgment is not something a general IT generalist role reliably covers.

Building that capability on your team is a training decision leadership can make directly. Certification paths built around modern, policy-driven network architecture teach the design skills that decommissioning actually requires, which is why CompTIA's CloudNetX certification is worth evaluating for anyone on your team who owns network infrastructure decisions, since it is built around the same hybrid, cloud-integrated network thinking that a responsible EOL replacement plan depends on. If you want a clearer picture of what a training plan around this looks like before committing budget, the curriculum overview and FAQ walks through how the material maps to real infrastructure decisions rather than just exam objectives.

A practical decommission plan, whether you are following a CISA-style mandate or just running your own audit, tends to include the same core steps regardless of environment:

  • A complete, current inventory of every device and application, including anything shadow IT introduced without a formal request
  • A documented support status for each asset, flagging anything approaching or past its vendor's end-of-support date
  • A replacement or migration plan for each flagged asset, tested in staging before it touches production
  • A defined reporting or sign-off process so decommissioning actually gets tracked instead of quietly stalling

None of that is exotic. It is discipline, and discipline is exactly what a trained team executes reliably while an understaffed one defers indefinitely. If you want a study plan built around closing this specific gap on your team, you can start training whenever you're ready to move past the audit-and-defer cycle.

The Decision Leadership Actually Has to Make

The CISA directive is a federal mandate, but the underlying math applies everywhere: every quarter you delay a planned decommission is a quarter you are running on borrowed time against a vendor clock you did not set. Waiting for the WannaCry-style event to force the conversation costs more in every dimension that leadership actually tracks, from breach cost to downtime to regulatory scrutiny.

The organizations that will handle this well over the next few budget cycles are the ones treating legacy replacement as a standing line item with a trained owner, not an emergency fund. That owner needs real architecture skills, not just a ticket queue, and that is a hiring or training decision you can make now instead of after the next exploitation campaign picks your unsupported edge device as its target.

Start training free at Forge University

Sunsetting Legacy Software: The Business Case for Decommissioning — Forge University Blog