Skip to content
Opinion / Commentary

End-of-Life Equipment Is Not a Budget Problem — It's a Security Architecture Decision

The framing of end-of-life network equipment as a procurement or budget problem is systematically incorrect. EoL equipment with active CVEs is a deliberate security architecture choice to operate known-exploitable infrastructure. Treating it as such changes the conversation, the decision-makers involved, and the urgency applied.

CipherWatch Editorial · Security Intelligence Platform
5 min read
Commentary

Every major enterprise network equipment EoL crisis follows the same arc. Vendor announces end-of-life with 12–18 months notice. Security and network teams flag the requirement for hardware replacement. The replacement is de-scoped or deferred in the annual budget process — hardware refresh has a visible cost, and the risk of not replacing EoL equipment is abstract and future-dated. The EoL date arrives. The devices remain in production. A ransomware group or nation-state actor exploits the now-unpatched vulnerabilities. The organisation responds to an incident that was predictable, predicted, and deferred for financial reasons.

SonicWall Generation 6 is the current iteration. It will not be the last.

The traditional framing of this problem — “we need budget to replace EoL equipment” — is correct but incomplete. It treats the risk as primarily a procurement problem that gets resolved when budget is approved. The more accurate framing is: the organisation has decided to deliberately operate known-exploitable network infrastructure because the cost of the alternative was higher than the estimated cost of the risk.

That framing changes everything about the conversation.

The Difference Between a Budget Decision and an Architecture Decision

When a security team says “we need $180,000 to replace EoL VPN appliances,” the conversation becomes a budget negotiation. Finance evaluates cost; operations considers complexity; the decision sits with whoever controls the capital expenditure budget. If the money isn’t available, the hardware stays. The security team’s responsibility ends at the recommendation.

When the conversation is framed as “we are choosing to operate internet-facing VPN infrastructure with known, unpatched CVEs because we have not allocated resources to replace it,” the decision has a different character. It is an explicit risk acceptance, which under most security governance frameworks requires formal documentation, CISO acknowledgement, and often board or risk committee awareness.

It also involves different decision-makers. Risk acceptance decisions in the enterprise typically involve legal, compliance, insurance, and executive leadership — not just the budget owner. The CISO is accountable for the risk recommendation. The organisation’s cyber insurance programme may have specific exclusions for knowingly operated EoL infrastructure with active CVEs. Regulatory frameworks (NIS2 for essential services; DORA for financial entities) may require reporting of known unmitigated critical vulnerabilities affecting in-scope systems.

Surfacing EoL equipment decisions as formal risk acceptance, rather than deferred procurement, changes the stakeholder set and creates a paper trail that matters both for governance accountability and for post-incident forensics.

What Formal Risk Acceptance Actually Requires

If an organisation does explicitly choose to continue operating EoL network equipment with unpatched CVEs — and in some cases this is the right short-term decision, given migration complexity — the risk acceptance should include:

Specific CVEs acknowledged: Not “EoL equipment has unknown future vulnerabilities” but “CVE-2024-12802 is unpatched on these specific devices, with CVSS 9.1 (CISA), active exploitation confirmed.”

Compensating controls documented: What is in place to reduce the risk during the operating period: IP allowlisting, upstream WAF, increased monitoring, restricted user base.

Residual risk assessment: With compensating controls, what is the realistic exploitation probability? The SonicWall/Akira data — 86% of SonicWall-involved breach claims involve Akira — provides a concrete data point for this assessment.

Migration timeline committed: When will the EoL device be replaced? The risk acceptance is time-bounded. Operating EoL equipment without a committed replacement date is not risk acceptance with compensating controls; it is indefinite risk acceptance with no exit.

Review date: When will the risk acceptance be reviewed? If a new critical CVE is published for the EoL device, the risk acceptance should be re-evaluated, not automatically renewed.

The Budget Problem Remains, But It Is Not the Same Problem

None of this makes the hardware replacement budget materialise from thin air. The money still needs to be found, the migration still needs to happen, and the operational complexity is real.

What changes is the governance structure around the decision to defer. When EoL equipment with active CVEs is on the formal risk register with executive acknowledgement, it is significantly more likely to receive priority in the next budget cycle — because the risk is explicit, documented, and owned by someone whose accountability extends beyond the operational inconvenience of replacement.

The security teams that successfully accelerated EoL replacements in the past year did not succeed by getting better at budget negotiations. They succeeded by reframing the question: not “can we afford to replace this?” but “can we document and defend our decision to continue operating known-exploitable infrastructure at this specific risk level, with these specific compensating controls, for this specific time period?” When the answer to that question requires a paper trail and executive sign-off, the budget tends to appear.

SonicWall Generation 6 is done. Its devices will not be patched again. The question for organisations still running them is not whether to replace them, but how to document the decision they are currently making, and how quickly they can exit it.

Share this article