Most organizations know the end-of-support date for their email platform. Far fewer treat it as the day their risk changes. The date sits in a lifecycle spreadsheet, gets handed to the infrastructure team, and becomes a question of extension contracts and upgrade windows. That made sense when email was a utility running in the background. It doesn’t anymore.
Why the date matters more than the flaw
Every email platform has vulnerabilities. That alone isn’t the risk. The risk is the gap between a flaw being disclosed and a fix being applied, and on an unsupported platform, there may be no fix coming.
This year’s Verizon Data Breach Investigations Report found that exploiting vulnerabilities has overtaken stolen credentials as the most common way attackers get in, for the first time in the report’s 19-year history. The same report found that organizations fully fixed only 26% of the vulnerabilities CISA lists as actively exploited, down from 38% a year earlier, and that the median time to patch rose to 43 days.
If supported systems can already take weeks to patch, an unsupported one presents a different problem: organizations can no longer assume a vendor fix will arrive. Newly discovered vulnerabilities may remain exposed, and attackers know which versions no longer get fixes.
The most common response to an approaching deadline is to buy more time: an extended support contract, a paid security update program, a one-year bridge. An extension feels like a decision, but it usually just postpones one, leaving less room to choose well next time. Sometimes buying time is the right call. But it should be done on purpose, with an end date, not repeated by default at every renewal.
That’s why the decision can’t sit with infrastructure alone. For government agencies, banks and healthcare providers, email holds the correspondence regulators care about most. Running it on an unsupported platform isn’t technical debt. It’s a governance position, and it should be taken deliberately by the people accountable for risk, not by default.
An end-of-support event also reopens questions most organizations haven’t asked since they first chose their email platform: where the data lives, whose laws apply to it, and who supports it.
What a deliberate decision looks like
Indonesia’s Ministry of Trade faced this choice when its email environment approached end of support, with around 4,000 government users depending on it. Extending the old platform would have bought time. Instead, the ministry used the deadline to answer exactly those questions.
It moved to Zimbra with a local implementation partner, with minimal disruption to users, and cut long-term licensing and maintenance costs by about 40%.
The cost saving isn’t the most important part. The ministry came out of that transition with a platform it controls, supported by people in the same country and under the same laws. A deadline most organizations experience as a burden became the moment it settled questions of sovereignty and accountability it would otherwise have put off.
Where this leaves IT and risk leaders
The practical shift is small. Put every end-of-support date in the risk register, not just the asset inventory. Plan the move a year ahead, not a month after.
When the date comes, ask more than “how do we keep this running?” Ask three things:
- Will the next platform keep receiving fixes?
- Do you control where your data lives and who can reach it?
- Is someone clearly accountable, and reachable, when something goes wrong?
What sets apart the organizations handling this well is simple: they chose the platform their most sensitive communications run on, rather than drifting into it.
No comments yet.