How do you decide when an end-of-life application is too risky to install or keep in use? We have several perpetual Bluebeam licenses, including Revu 17, which reached end of life in 2023. The software is only used occasionally for specific PDF-related tasks, so the business may not want to pay for an annual subscription just to support a few users. We also have older Adobe installations and may soon face similar issues with Foxit perpetual licenses.
These applications run on individual workstations rather than servers or business-critical infrastructure, and users do not need their internet-based collaboration features. Would blocking the applications from making network connections be a reasonable mitigation, or should unsupported software be removed regardless? How do you balance security, compliance, licensing, support effort, and the cost of replacing software that is used infrequently?
4 Answers
IT should explain the technical and security risk, but the business usually decides whether to accept, mitigate, or eliminate that risk. Put the concerns in writing, including the lack of security updates, possible compliance issues, vendor support limitations, and any required controls. If leadership chooses to keep the software, get the decision and risk acceptance documented rather than silently carrying the responsibility yourself.
Also check cyber-insurance and compliance requirements. Some policies require production software to remain supported, which can make an unsupported application unacceptable even when its technical risk appears small.
My threshold is case by case. Local, noncritical software that can run normally on a supported operating system and does not access the network may remain in service if there is a clear business reason. Internet-facing, business-critical, privileged, or sensitive-data software is a much harder no once security updates stop.
If the organization insists on keeping it, define compensating controls such as blocking network access, limiting users and permissions, isolating it in a virtual machine, and preventing it from opening untrusted files. Set a review date and a replacement plan instead of allowing the exception to continue indefinitely.
Do not compare only the subscription price with the old perpetual license. Include the IT labor required to keep the old version working: releasing licenses from dead machines, troubleshooting compatibility problems, tracking installations, and dealing with unsupported issues. Log the time spent on those tasks. A subscription that costs a few hundred dollars per year may be cheaper than several hours of technician time, especially when the software vendor is removing license-management features or ending transfers between workstations.
For Bluebeam in particular, verify the support and license-transfer deadlines for each version. A perpetual license may let you keep using the installed copy, but it does not guarantee updates, support, cloud access, or the ability to move the license to replacement hardware.
Treat it as a risk assessment rather than using the EOL date alone. An offline PDF editor that handles non-sensitive files is very different from an unsupported browser, plugin, or internet-facing service. Consider whether the application connects to the internet, processes sensitive data, runs with elevated privileges, and whether a compromise would affect other systems.
If the software does not need cloud features, block its executable's inbound and outbound network access with firewall policy. For higher-risk cases, use a dedicated or virtualized workstation with limited network access. Document the remaining risk and have the appropriate business owner formally accept it if the software must remain in use.
That seems to fit our situation. The programs are on end-user machines and we do not use their online features, but the workstations are still connected to the local network. I will need to confirm whether application-level network blocking is sufficient for each product and document the decision.
The distinction between assessing the risk and accepting it is important. I will also check our insurance policy and any regulatory requirements before treating network isolation as an acceptable workaround.