End-of-life (EOL) software is any operating system, database, framework, or appliance firmware for which the vendor has stopped shipping security patches — meaning every new vulnerability discovered after that date stays open, permanently, on every system still running it. "End of support" is not a soft warning; it is a hard line after which you receive no patches for new CVEs, no vendor security advisories, and no official fix path, while attackers continue to find and weaponise flaws in that exact software. For Indian businesses this creates compounding exposure: unpatched entry points for ransomware, compliance findings during audits (DPDP, ISO 27001, sector regulator reviews), and cyber-insurance claims that can be reduced or denied if a breach traces back to software the vendor had already declared unsupported. The honest response is not always "upgrade immediately" — it is to build an EOL register, apply compensating controls where migration isn't yet possible, and put a funded, CFO-approved plan in place for the systems that cannot stay as they are.
What "end of support" actually changes, technically
When a vendor ends support for a product, three things stop simultaneously, each with a distinct consequence.
No patches for newly discovered vulnerabilities. Security researchers and attackers do not stop finding flaws in old software just because the vendor stopped fixing them — if anything, EOL software becomes a more attractive target because any newly found flaw is guaranteed to stay open forever. Microsoft's own lifecycle documentation is explicit about this: Windows 7 reached the end of extended support in January 2020, and any vulnerability found in Windows 7 after that date has no official Microsoft fix, ever. The same pattern applies to Windows Server 2012 and 2012 R2, whose extended support ended in October 2023, and to Windows 10, which reached end of support in October 2025.
No vendor security advisories reach you. Vendors typically stop issuing CVE advisories, mitigation guidance, and threat intelligence for products past end of life. You lose the early-warning channel that told you "this specific flaw is being actively exploited, here is the workaround" — often how organisations learn to prioritise patching before an exploit goes public.
No official fix path exists even if you want to pay for one. Extended support contracts (where vendors sell additional years of patches for a fee) themselves have hard end dates. Once those lapse too, there is no purchasable path back to a supported state short of migrating off the product entirely.
Why this is a business risk, not just an IT risk
Treating EOL software as "something IT will get to eventually" misreads the exposure. It shows up in four places a founder or CFO actually cares about.
- Attack surface. Every internet-facing or network-reachable EOL system is a permanently open door for any future vulnerability class discovered in that product family, not just the ones already known today.
- Compliance findings. Auditors under ISO 27001, SOC 2, or sector-specific reviews explicitly check for unsupported software as a control failure — it is one of the most common findings in Indian SMB audits because it is easy to detect and hard to argue against.
- Cyber-insurance consequences. Insurers increasingly ask about patch management and supported software versions during underwriting, and a breach that traces to software the vendor had already declared end-of-life can affect claim outcomes.
- DPDP and data-protection exposure. Under India's Digital Personal Data Protection Act, 2023, "reasonable security safeguards" is the operative compliance standard for protecting personal data (see meity.gov.in for the Act and rules). A breach through a known-unsupported system is difficult to reconcile with "reasonable safeguards" in front of a regulator or during an audit.
Building an EOL register: the starting point
You cannot manage what you have not inventoried. An EOL register is a simple, living document — not a one-time audit — that tracks every piece of software and firmware against its published support timeline.
A usable register needs, at minimum:
| Field | Why it matters |
|---|---|
| System / application name | Unambiguous identification |
| Vendor and product version | Ties directly to the vendor's published lifecycle page |
| Published end-of-support date | The trigger date for risk escalation, not a guess |
| Internet-facing? (Y/N) | Determines urgency — exposed systems get compensating controls first |
| Business criticality | Determines how much migration disruption is tolerable |
| Data sensitivity (personal data, financial, none) | Ties directly to DPDP and audit exposure |
| Current status | Supported / approaching EOL / EOL-unmitigated / EOL-compensated / migration in progress |
| Owner | A named person, not a team, so nothing sits unowned |
Figures above are illustrative of where EOL exposure typically concentrates, not a measured statistic from a named study.
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanThe honest options when you cannot upgrade immediately
Not every EOL system can be migrated overnight — a line-of-business application tied to unsupported hardware, or a vendor that has shut down entirely, are real constraints, not excuses. The decision tree below is how to think through what to do next.
When a compensating-controls bridge is the honest answer, it needs to be a real set of controls, not a single firewall rule:
- Network segmentation. Isolate the EOL system on its own VLAN or subnet with tightly scoped access rules, so a compromise cannot spread to the rest of the network.
- Strict egress control. Restrict outbound connections from the EOL system to only what it needs — most ransomware and exfiltration techniques require the compromised host to call out, and a tightly filtered egress path removes that option.
- Virtual patching at the WAF. A web application firewall in front of an EOL web-facing system can block known exploit patterns for that product's vulnerability class at the network edge. This buys time; it does not fix the underlying exposure.
- Enhanced monitoring and logging. Since the system cannot be patched, detection becomes the primary control — log everything reachable from and to that system, and alert on anomalies more aggressively than you would for a supported host.
- Removing unnecessary services and accounts. Reducing what runs on the EOL box reduces what can be exploited, even without a patch.
Building a migration business case a CFO will approve
EOL systems linger for years usually because nobody has built a business case a CFO can approve. A credible case needs four things, none of which require inventing numbers.
- Frame it as risk reduction, not a technology refresh. Tie the migration directly to the register entries: which systems, which data sensitivity, which compliance exposure. "We are removing three unsupported systems that hold personal data and would be audit findings under DPDP" lands differently than "we want to upgrade the server."
- Quantify what you can, qualify what you can't. You may not have a precise cost-of-breach number specific to your business, and you should not invent one — but you can state, qualitatively, that a ransomware incident on a line-of-business system typically means operational downtime, incident response cost, and potential regulatory exposure, all of which a migration avoids.
- Sequence by exposure, not by convenience. Internet-facing and personal-data-holding EOL systems go first; internal, low-sensitivity systems can follow on a longer timeline. This sequencing itself is a CFO-friendly argument — it shows the spend is being applied where the risk is highest, not spread evenly regardless of exposure.
- Attach a fixed timeline to every compensating-control bridge. A CFO can approve "isolate now, migrate by [date]" far more easily than an open-ended request, because it converts an ongoing risk into a bounded, budgetable project with a known end.
Making this operational
Start with the register, not the migration plan — you cannot sequence or fund what you have not inventoried. Once it exists, apply the decision tree above system by system, and attach a fixed deadline to every compensating-control bridge so a system never stays unsupported and internet-exposed indefinitely. CERT-In publishes advisories relevant to unpatched software risk at cert-in.org.in, and MeitY's DPDP Act materials at meity.gov.in are the reference point for the "reasonable security safeguards" standard above. Dhisattva AI Pvt Ltd built Bachao.AI so Indian SMBs get continuous, automated visibility into exactly this class of exposure, rather than discovering an EOL system during an incident or an audit.
For more on building a practical vulnerability management programme, see the Bachao.AI blog.