The application is still the right tool. The business still runs on it. The interface still does what people need. The problem is not the application itself. The problem is what it considers proof that the right person is using it.

The cheapest application to modernise is the one that already does its job. The trick is to leave it doing that job while you change what it accepts as proof of identity.

The era they were built in

The Windows business applications that quietly run accounting, scheduling, distribution, dispatch, dealership management, lab workflows and shop-floor systems were written in a different world. Domain logon was the perimeter. Once a user was at the workstation, they were trusted. Sign-in, where it existed inside the application, was typically a local username and password — sometimes shared across a team, sometimes never expiring, sometimes coded into a configuration file.

That was acceptable for a long time. The networks were closed. The users were employees. The compromise vectors were physical. The application’s authentication was strong enough for the threat model it faced.

What changed around them

Three things changed at roughly the same time, and the change in each one was substantial.

  • The attacker shifted to credentials. Most modern intrusions begin with stolen or phished credentials, not with broken perimeter security. Password-only sign-in is now the weakest link by a wide margin.
  • The expectation shifted to federated identity. Modern IT environments centralise identity into a small number of providers — Entra ID, Okta, Google Workspace, ADFS, Auth0, OCI IDCS and others. Applications outside that fold are increasingly treated as policy exceptions to be explained.
  • The audit shifted to evidence. Cyber insurers, regulators and frameworks like SOC 2, ISO 27001 and NIST 800-63 increasingly ask for evidence that multi-factor authentication is in force across all access to sensitive systems — including the older ones.

The application was fine. The world around it moved.

The three approaches

There are essentially three ways to close the gap:

  1. Rewrite the application. Plausible for small applications, the budget for which already exists. Expensive, slow and risky for anything substantial. Often impossible when the original vendor is gone, the source is incomplete, or the institutional knowledge has retired with the original developer.
  2. Replace the application. Same risks plus the gap between what the legacy application does (often, exactly what the business needs after twenty years of refinement) and what a modern replacement does on day one (typically, not enough).
  3. Bridge the application. Add a modern authentication step in front of the application’s startup or sign-in. The user authenticates through your existing identity provider, with your existing MFA policy. The application receives a verified identity result and behaves as if the user signed in. The application itself is unchanged.

For most legacy desktop and client/server software, the bridge approach is the only realistic answer that delivers a meaningful improvement in months rather than years.

What modern auth actually means here

"Modern authentication" is a loaded phrase. In the context of bridging a legacy Windows application, it has a fairly precise meaning:

  • OIDC / OAuth 2.0 flows rather than passwords stored locally.
  • System-browser sign-in rather than an embedded login dialog inside the application.
  • MFA enforced at the identity provider, where it can be managed once and applied everywhere.
  • Tokens validated against an authoritative source, with proper signature verification, rather than against a hash in a local user table.
  • Audit trail in the identity platform, where security teams already look, rather than in the application’s local log.
The principle

The application does not need to know how the user authenticated. It only needs to know, reliably, that the right user did.

The three objections you will hear

  • "Our application can’t speak OIDC." Correct. It does not need to. The broker speaks OIDC. The application calls the broker. The protocol the application speaks does not change.
  • "We don’t have a modern identity provider." Most organisations now do, even if they do not realise it. Microsoft 365, Google Workspace, Salesforce and many SaaS platforms all bring federated identity. If your organisation has any of these, you have an identity provider available to you.
  • "This will require touching the application code." Usually minimally — a startup-sequence change rather than a logic rewrite. For applications where source is unavailable, integration patterns exist that do not require recompilation at all.

Where the Beanstalk product family fits

Beanstalk Authentication Broker is purpose-built for this gap. It works with the identity providers your organisation already runs, applies your existing MFA policy, and presents a clean integration surface for the legacy application to call. The application stays as it is. The identity story comes up to current standards.

The realistic timeline

A bridged authentication approach typically takes days to weeks per application family, not months. The replacement project, if it happens, can then proceed at the pace the business actually wants — with the audit story, the cyber insurance answer and the security review already in good shape.

This is the rare case where the smaller intervention delivers the larger outcome.

Have a legacy application that does its job, but won’t pass an audit?

You almost certainly have a federated identity provider available, and a path to using it without rebuilding the application. The conversation starts with the application and the IdP — we will tell you quickly whether the fit is straightforward.

Discuss your application View related products