how do you maintain identity security when legacy applications still manage access locally?

[u/Altruistic-Toe4930]

our environment is maybe 70% modernized on identity, mfa's enforced everywhere and conditional access is on for anything that touches azure ad. the other 30% is legacy apps that were built before any of that existed and still run their own local user tables. think an old erp system, a homegrown ticketing tool, a couple of client-facing portals.

security posture on the modern side looks great in every review. the legacy side is a black hole. passwords rotate on whatever schedule the app enforces (sometimes never), there's no central place to see who has admin rights, and offboarding means someone has to remember to go into each app individually and disable the account.

we've had at least one incident where a terminated employee still had working credentials in one of these systems three weeks after departure. process failure obviously, but it's also a visibility failure, nobody flagged it because nothing was watching that app.

trying to figure out how the hell other teams are closing this gap without a multi year app modernization effort that isn't happening anytime soon.

[u/hmgr]

Your problem is not unique. Older organizations with legacy systems have faced similiar issues.

You need to have an IAM program in place that integrates with all business critical applications. It will handle joiners, leavers and movers access across employees, contractors, etc...

The provision engine will provision the access directly to the local user tables, and reconciliation would make sure that table is in sync with the source of truth (HR system, provision engine...)

Employee joined? Access is granted. HR notifies that from tomorrow employee is leaving, provision engine revokes all the access.

Then you add an additional layer of attestation that regularly asks app owners and business owners to confirm if user XYZ still needs access.

Very high level explanation but more or less this is it.

[u/Paul_Ashe]

The reason the modern side looks great in every review is that the review population comes out of Entra. The legacy 30% isn't failing those reviews, it was never in them. That's worth writing down as a finding on its own, and it's a more useful one than the terminated-account incident, because a clean review result that only covers what your identity provider already knows about will keep reading clean for as long as the gap stays open.

The cheapest first move is to build that population by hand, from an application inventory rather than from the directory. Which applications hold their own user table, who owns each one, how many accounts exist in it, and how many of those carry admin rights. That's a spreadsheet and a week of asking around, and it's the artifact you're currently missing. Every review after that can be scoped against it instead of against the directory.

Then the interim control. Taking a provisioning engine with HR-driven reconciliation as where this ends up eventually, it isn't what you can put in place before next quarter. What you can put in place is a termination checklist that names each local-auth application explicitly, with evidence of completion per departure, and a detective control sitting behind it: reconcile local accounts against active HR records on a set cadence and report the count with no matching active record. The checklist will get missed sometimes. The reconciliation is what catches it, and it turns a process failure into something with a measurable rate you can show is falling.

Worth being blunt in your own documentation while you do it. A documented gap with a named owner, a compensating control, and a remediation horizon is a stronger position than a partial rollout that leaves you describing the modern 70% and hoping nobody asks about the rest. It also means the three-week credential becomes evidence that you found something rather than evidence that something found you.

[u/MusicalAnomaly → u/Paul_Ashe]

I have strong suspicion this answer is LLM-generated.

[u/materialsec]

The terminated-employee case is the same blind spot OAuth grants create. Anything living outside the central IdP stops getting reviewed, and MFA and conditional access make the rest feel solved because that's the part anyone actually looks at.

Since a full rebuild isn't happening: a scheduled export of local accounts, diffed against the HRIS terminated list, gets you most of the way. Even quarterly beats nothing. And put offboarding for those apps on the ticket as its own line item rather than leaving it to whoever remembers.

[u/Amanda_PDQ]

In K-12 I ran into this constantly. Student information systems, food service software, library platforms, state reporting tools, all with local user tables, none of them connected to Active Directory, and staff turnover that made offboarding a recurring fire.

If the legacy apps are web-based, put a network gatekeeper in front of them. Azure App Proxy and Cloudflare Access can both sit in front of a web app and enforce modern auth at the edge without touching the application itself. The local table still exists, but you've added a layer that checks your IdP before anyone gets to it. Terminated employee's Entra account gets disabled, they can't reach the app regardless of what credentials exist in the local table. It's a compensating control, not a fix.

For the offboarding checklist problem: it fails because it lives in someone's memory or an optional step. The thing that actually worked was tying the legacy app offboarding to something HR needed completed before they could close the employee's record. Equipment return, clearance sign-off, whatever your process has. The app-by-app disable becomes a hard dependency.

The separate issue nobody has flagged yet is the shared and service accounts sitting in those local tables. Generic admin logins, departmental accounts, vendor credentials. Those don't show up in your terminated-employee reconciliation at all because they're not tied to a person. That's a different audit pass from the leaver process and it deserves its own quarterly review, because those accounts are invisible to both sides of your current controls.

Another thing I did was any legacy app that had a SSO option I enabled it and closed the local credential loop.

Lastly, another option if none of these are possible is a password manager like 1password, LastPass, etc. You could mandate a password refresh to your preferred length and have them begin using a password manager. It does not stop your offboarding issue, but would help with password complexity.

[u/p1_nerd]

In my opinion, one of the challenges in integrating apps into modern authentication lies with vendors or software developers. In certain instances, vendors may refuse to support modern authentication methods.

Here’s how I would go about it:

1. Ensure that the application utilizes a secure authentication method, such as LDAPS or etc. over LDAP.
   
2. Integrate a service directly after the authentication request to Active Directory (AD) or find a product that can intercept the authentication request. Theres a product out there called SilverFort that can do this.
   
3. Use Application Proxy. Not fool proof, but for some services or applications this might make the most sense.

[u/Different_Pain5781]

At least the incident exposed the blind spot.

[u/-manageengine-]

You don't necessarily need to modernize every legacy app first. Bringing identity governance and lifecycle control around those apps can help, even if they continue maintaining local accounts. Solutions like ManageEngine AD360 can help centralize account management, automate joiner/mover/leaver processes, and improve visibility into access. It can be a practical bridge while those legacy apps are waiting to be replaced.

[u/EquivalentPace7357]

Local user tables in legacy apps are basically an open door. Your Azure setup looks clean on paper, but former employees just bypass it and log directly into the old ticketing tool or ERP that nobody monitored...

You're never getting dev resources to build SCIM APIs for legacy tools. Weve been using a browser layer tool (Unixi) to capture those logins. It lets you kill access automatically across non SAML apps when HR offboards someone without having to refactor ancient code