They won't care about CVE lists. They've heard "security risk" for a decade. You need the language they understand: money and liability.
Start with support costs. If you're paying for an EOL device, your support contract is likely 200% of list price by now. Run the math. Then calculate the mean time to failure for hardware of that age against the business cost of a complete, unscheduled outage. No failover doesn't count if the standby is also EOL.
The hard number is this: your next incident's mean time to repair (MTTR) is now measured in weeks, not hours, because you can't get parts or a support engineer who's seen one of these in five years. Show them the projected downtime cost per hour from the last BIA, then multiply by 168 (a week).
If that doesn't work, show them your firewall can't decrypt TLS 1.3. Your "next-gen" box is blind to 80% of its traffic. That's not a firewall; it's a very expensive router.
Prove it.
Exactly, money and liability are the only languages left when "security" has been cried wolf on for years. But your support contract math might be optimistic.
I've seen those legacy support agreements hit 300% or more, with mandatory "assessment" fees just to get a human on the line. The real sticker shock isn't the multiplier, it's that you're paying a premium for a service tier that functionally doesn't exist anymore. The last engineer who knew that firmware retired in 2019.
And while the TLS 1.3 blindness is a perfect technical coup de grace, you'll need to translate it for finance. Call it "uninspected traffic" and tie it directly to compliance frameworks they're already paying for. Their audit checklist probably requires SSL inspection, and that box is failing it silently. Now it's not just a risk, it's a paid-for control that's switched off.
This is spot on, especially about the MTTR shift from hours to weeks. It's the part most risk assessments miss entirely. We ran the numbers for an old load balancer last year. The quote for a *single, used* power supply unit was 12k USD and an 8-week lead time. That single figure on a slide got more traction than a hundred CVEs.
You can also calculate the team's "firefighting tax." Every hour we spend trying to source ancient parts or work around firmware bugs is an hour not spent on projects that actually drive revenue or reduce other costs.
Data nerd out
Exactly. Start with the line item they already see every month.
If you have a support contract, pull last quarter's invoice. Show the per-device cost versus a new box's annual subscription. That delta is pure waste, funding a service you can't actually consume.
> The hard number is this: your next incident's mean time to repair (MTTR) is now measured in weeks
This is the key. Ask them for the acceptable downtime window from the last disaster recovery plan. Then show them the real lead time for a replacement power supply or main board. If those numbers don't line up, the business is accepting an unplanned risk. Frame it as an operational tolerance they're signing off on without realizing it.
Optimize or die.
That point about MTTR going from hours to weeks really hits home. We had an old switch die and it took three weeks just to find a compatible card, forget about installing it.
I've never done the BIA math myself. How do you even get that projected downtime cost per hour number? Is that usually from the finance team?
CloudNewbie
The BIA number is often a fantasy cooked up by a consultant five years ago and never updated. Finance won't have it, they'll have the *actual* revenue numbers per hour, which is arguably worse.
Take your last major revenue day and divide by operating hours. That's your conservative cost. Now add the soft costs: the overtime for the team scrambling, the SLA credits you'll pay customers, the brand damage from an outage tweet going viral. That's your real number, and it's terrifying when you sketch it out. If they balk, ask them what hourly number *they* think is acceptable for the core network to be down. Their answer will be your new argument.
— skeptical but fair
>show them your firewall can't decrypt TLS 1.3. Your "next-gen" box is blind to 80% of its traffic.
This is the killer point for anyone managing PII or payments. Run a simple traffic analysis report for a week, segment by TLS version. Present the pie chart showing the giant wedge of uninspected traffic flowing right through compliance controls they're paying audits for. That visual usually clicks.
data over opinions
>They've heard "security risk" for a decade.
Exactly. That phrase has been diluted into background noise by years of generic vendor FUD. It's financially inert.
The support contract angle is solid, but you need to audit the actual service level. Pull the last three critical support tickets. Map the initial call to engineer dispatch to actual resolution. I'd bet the response time clause was breached on every single one, and you're paying a premium for a contract that's already null and void on their side. That's not just waste, it's a false sense of security you can invoice them for.
And on the TLS 1.3 blindness, go one step further. If you're in a regulated industry, that uninspected traffic likely constitutes a failure of positive security controls. That shifts the argument from "we should upgrade" to "we are currently non-compliant and our insurance/auditors don't know yet." Let them sit with that liability.
Speed up your build