Legacy apps are about to become your biggest identity risk

AI finds the bug. Identity decides the damage.

Last month, Appian CEO Matt Calkins said something that should have made every CISO pause: "Legacy apps are a security risk with Mythos." The claim, stripped of marketing, is that AI can now find exploitable weaknesses in legacy systems at a scale humans never could.

Mythos isn't a one-off. AI-assisted reverse engineering, agentic vulnerability scanning, and automated fuzzing are all moving in the same direction. The cost of finding exploitable weaknesses in software the world has stopped maintaining is dropping fast.

This breaks an assumption that a generation of security programs is built on.

The assumption that just expired

For decades, many legacy systems were "secure enough" because breaking them didn't scale.

The economics worked like this. A motivated attacker could find a vulnerability in a regional bank's homegrown loan origination system, or in a manufacturer's twenty-year-old MRP application. But it took expertise, time, and money. Each system was a custom project — different language, different runtime, undocumented behaviors, peculiar local logic. The skills didn't transfer from target to target. The ROI on attacking the long tail was low.

That math is changing. AI is doing to vulnerability discovery what it's already done to translation, code generation, and image classification: collapsing a specialist task into a commodity capability. An attacker no longer needs deep familiarity with COBOL or with a specific ERP's quirks. They need a model, a wrapper, and a target.

Security through obscurity has flipped from a defense to a liability. The systems that were safest because they were strangest are about to become the easiest to enumerate.

The serious question isn't whether this is happening — every credible security researcher is now describing some version of it — but how much time enterprises have before defenders see the same shift on the other side of the firewall.

The identity gap

Now consider where most enterprises actually sit on identity.

The systems with strong identity controls are the modern ones: the SaaS platforms with SCIM, the cloud infrastructure with federated identity, the productivity stack that's already onboarded into the IdP. These got attention because they were new, easy to integrate, and visible to the security team.

The systems that run the business — mainframes, core banking, on-premises ERP, custom sector-specific applications — sit outside the control plane. They're managed by tickets, by spreadsheets, by individual administrators who've been at the company long enough to know who should have what. The result, predictably:

• Over-permissioned accounts that accumulated access over years of role changes
• Service accounts whose ownership has been lost to attrition
• Local admin entitlements that exist because somebody once needed them for a migration in 2014
• Unused identities that were never offboarded because nobody owned the process

This is the same long tail that drives the 80/20 problem in IGA programs. It's also the surface that just got materially more dangerous, because the systems with the worst identity hygiene are the same systems where vulnerability discovery is about to become cheap.

Blast radius is an identity question

When prevention gets harder, blast radius matters more. And blast radius is defined by identity. Four questions decide how bad a successful exploit actually gets:

• What can this account access? An identity with narrow, just-in-time entitlements is a contained incident. An identity with accumulated standing privilege is a breach.

• How far can it move laterally? Identities that exist in isolation contain the damage. Identities that are reused across systems — same usernames, same service accounts, same credentials — turn one compromised system into a foothold for ten.

• Who owns it? An account with a clear owner gets investigated, rotated, and revoked when something looks wrong. An orphaned account is a backdoor that nobody is paid to notice.

• Would anyone notice if it were used? Identity activity that flows into a monitored pipeline produces alerts. Activity inside a system that isn't connected to the control plane produces nothing.

These four questions are the blast radius framework. In a world where exploitation gets cheaper every quarter, they're the questions that decide whether a finding becomes a footnote or a board-level incident.

Most enterprises can answer them confidently for their tier-1 modern apps. Most cannot answer them for the systems that actually run the business.

The reframe

You can't rewrite every legacy application overnight. Most enterprises can't rewrite any of them on a meaningful timeline. The cost is too high, the dependencies too entrenched, the operational risk too severe.

But you don't have to rewrite the application to control the identities inside it. The identities can be governed even when the underlying system can't be modernized — joiners, movers, and leavers reflected in the legacy app the same day as in Workday; entitlements reviewed on the same cadence as the SaaS estate; orphaned accounts visible in the same dashboard as everything else.

That's the work that actually changes blast radius.

In a world where AI can find the bug, identity controls the damage.