Legacy Apps Are Your Biggest AI Security Risk

Somewhere in your company there's a Visual Basic 6 application that still runs payroll, quoting, or claims. It's run for twenty years. The people who wrote it have mostly retired, and the people who maintain it would rather not touch it. For most of those twenty years, that was a cost problem. In 2026 it became a security problem.

Bain & Company's Technology Report 2026 surveyed chief information security officers about where AI-era risk is concentrated. Legacy platforms came out on top: the exposure CISOs most often called their most material, and the one they're least able to fix on their own. Bain's recommendation is blunt. Treat technical debt as a live cyber exposure, and retire vulnerable technology instead of patching around it.

Attacks now move faster than your patch cycle

Bain estimates that AI has cut a typical cyberattack from about four weeks to about 18 hours. Reconnaissance that took a week now takes an hour. Lateral movement that took a week takes three hours. Attackers don't stop to sleep, and someone with no coding background can now run a campaign that used to require a skilled team.

Defenders are using the same tools, and that creates a second problem. Companies running AI-powered scans report vulnerability alerts rising as much as eightfold. Bain found that more than half of an organization's vulnerabilities sit outside its critical applications, in the legacy systems, APIs, and dependencies nobody watches closely. Finding those weaknesses is getting easier. Fixing them is where legacy systems break down.

Where CISOs say the risk lives

Bain plotted the exposures CISOs named on two axes: how concentrated the risk is, and whether the organization can fix it alone. Modern cloud-native apps sat in the safe corner, low risk and fixable. In-house code and open-source dependencies landed in the middle. Three exposures sat in the top-right corner, high risk and hard to fix independently: network layers, SaaS vendors, and legacy platforms. Legacy platforms drew the most votes of the three.

The reason is structural. A cloud-native app has a pipeline, a test suite, and a team that can ship a fix this afternoon. A legacy app often has none of those. The risk report lands, everyone agrees it matters, and the fix goes on a list.

Why you can't patch your way out

Every legacy stack has its own version of the same problem.

• Visual Basic 6. Microsoft ended support for the development environment in 2008. The runtime still ships with Windows, but the application around it is 32-bit, built on COM, and usually depends on third-party ActiveX controls from vendors that no longer exist. When a scan flags one of those controls, there is often no patched version to install.
• PowerBuilder. Many PowerBuilder applications are client/server: the desktop client talks straight to the database, often with broad credentials. Appeon maintains the product, but plenty of shops run versions several releases behind because upgrading means retesting everything.
• Microsoft Access. An Access application is a file on a shared drive. Anyone who can run the app needs read and write access to that share, and the built-in password protection was never designed to stop a determined attacker.

In each case, the weakness lives in the architecture, not in a line of code. You can wrap these systems in firewalls, VPNs, and monitoring, and many companies do. That buys time. It doesn't retire the risk, and every month of wrapping adds to the cost of the eventual exit.

The same systems are stalling your AI plans

The security case would be enough on its own, but there's a second cost. Bain's research on agentic AI found that the binding constraint on automation is usually missing context: the exception logic and business rules that live in people's heads or buried in old code. An AI agent can't apply a pricing rule it can't read. If that rule sits in a 1998 VB6 module, your agent strategy is waiting on your legacy strategy.

Bain makes the point about the whole enterprise too. In its view, the most important work in an AI transformation is redesigning processes and modernizing the data and application environment underneath them. Legacy apps sit at the bottom of that stack.

Accountability is shifting as well. Bain recommends holding the CIO and CTO accountable for vulnerability debt, and giving boards granular vulnerability reporting at least monthly. The legacy app that used to be an IT backlog item is becoming a line on the board report.

What retiring the risk looks like

Retiring a legacy platform used to mean a multi-year rewrite with an uncertain end date, which is why so many companies chose wrapping instead. Agentic AI has changed that math.

VELO, our agentic AI modernization platform, takes VB6, PowerBuilder, Access, WebForms, WinForms, Clarion, and Delphi applications to Blazor on Azure. It preserves 100% of your business logic, moves that logic into APIs and documented rules your teams and AI agents can work with, and validates the result against the original application's data. The price is fixed before work begins. Your code runs in an isolated tenant and is removed once the modernization is complete.

A five-minute self-check

If you answer yes to two or more, your legacy estate belongs on your security agenda:

1. Does a business-critical app run on VB6, PowerBuilder, Access, or a similar platform?
2. Does it depend on third-party components whose vendor no longer exists?
3. Do desktop clients connect directly to the database?
4. Would a critical vulnerability in it take more than a month to fix?
5. Is it holding up an AI or automation project?

The fastest way to know where you stand is an assessment. It shows what's in your application and how much of it can be modernized, before you commit to anything.