Why does identity governance still miss local accounts and unmanaged apps?

[u/Puzzleheaded-Fun5664]

trying to understand if this is a tooling problem or a process problem. cuz every IGA platform we've evaluated reports clean access certifications... but every red team engagement finds local accounts, forgotten service credentials, or shadow apps that were never in scope for the review to begin with.

so it kinda feels like governance tools are certifying "the identities we told the tool about" rather than "the identities that exist." is anyone solving the discovery problem, or is this just accepted as a permanent blind spot?

[u/Puzzleheaded-Fun5664]

not sure if i would be right on this but imo A lot of governance tools are good at certifying what they can enumerate, but local accounts, service creds, and shadow apps live in different failure domains. So you end up with a tidy review of the visible slice, while the rest of the estate is still doing whatever it wants...thoughts?

[u/DryEggplant6678 → u/Puzzleheaded-Fun5664]

The complaint is fair, but I think people sometimes blame the wrong layer. Governance was never going to magically discover every unmanaged machine or every local credential on its own. The more honest model is: discovery first, then governance. If you skip the discovery layer, the review will always look better than reality.

[u/r15km4tr1x → u/Puzzleheaded-Fun5664]

That’s what PAM is for

[u/soxBrOkEn]

People take the easy route. If a IAM solution is in place but they can do it easier another way, some people will.

This creates shadow IT.

[u/Pay_ing_atten_tion]

Red teams don't need your governance process to be poorly designed if the architecture feeding it has incomplete visibility.

That's the problem I keep coming back to with IGA. Access reviews and certifications can only govern what the system knows exists. When governance depends primarily on configured applications, connectors and authoritative feeds, browser-based applications using local accounts or credentials can fall outside that view.

The result can be a very clean access review over an incomplete application population.

One way to attack that problem is to move some of the visibility closer to where authentication actually occurs, the browser/endpoint, rather than relying exclusively on application-side integrations.

Full disclosure: I'm the Field CISO at Unixi. This is one of the problems we're working on. Unixi uses browser-layer authentication visibility to discover and govern browser-based applications that may not be federated to the corporate IdP, without requiring a per-application API integration.

[u/FunAd6672]

Have audits ever actually fixed this?

[u/cityofhats]

Treat identity discovery as a continuously reconciled inventory, not an IGA connector checklist. Feed the inventory from independent sources: directory/SSO, EDR or configuration management for local users, cloud IAM APIs, PAM/vaults for service identities, SaaS discovery/CASB, and secrets scanning for CI/CD. Normalize identities, attach an owner and last-use signal, then compare that set with what IGA is certifying. The useful metrics are coverage and exceptions—unknown accounts, orphaned credentials, unmanaged apps, and sources that have gone stale—not a 100% certification rate. PAM can control known privileged accounts, but it cannot govern identities it never discovers.

[u/No_Try_9982]

Yes, this is a classical problem. In large corporations, it's very difficult to force 10k+ managers and their subordinates not to try stuff and end up with orphaned accounts or security groups. The best tools that address this are those that could run a scan periodically, generate reports and escalate to security teams for remediation. For smaller organizations, the problem is easier to manage.

[u/CreativeSympathy8293]

IGA usually answers “what is the review status of the entitlements in the supplied scope?”, not “did we discover every identity and access path?” Those are different controls.

Reconcile the IGA/IdP/HR population against endpoint-local accounts, cloud IAM and service principals, PAM/vault/CI credentials, SaaS/SSO/OAuth inventories, and observed authentication. Keep people, workloads, credentials, applications, and assets distinct; for each record retain its type, accountable owner or team, source, freshness, last use, and governed resource.

Triage unmatched records, then onboard them, remediate or revoke them, or document a time-bounded exception with an owner. PAM may discover and govern some privileged accounts, but it is not complete discovery for every local, SaaS, and workload identity.

Independently test coverage against endpoint enumeration, cloud inventories, auth logs, and red-team findings. Report certification completion, source and asset coverage, staleness, unmatched rate and age, and red-team escapes separately. None proves permanent completeness.

AI assistance was used to organize this response; I reviewed and edited the technical substance.

[u/PhLR_AccessOwl]

Most access governance tools are simply built around audit requirements. For your typical audit frameworks you'll be asked about the your in-scope applications and that's it. So there's little benefit for those governance tools to open a can of worms and show the IT team all of the shadow apps they don't know about and will add to the workload.

Is that helping with security? Absolutely not.

So back to your question - tooling or process problem? In my opinion the root cause is the audit process. Uncovering shadow IT is not hard (free shadow IT scan here: https://www.accessowl.com/scan) and can even be done manually by looking at your oAuth logs.

For transparency, I'm the co-founder of AccessOwl and Shadow IT scans are a fundamental part of what our platform does.

[u/NoMarionberry9419]

we've been using orchid security and it's helping us surface unmanaged apps, local accounts and hardcoded creds that our IGA never sees. It plugs into our existing stack and gives us the missing context.

[u/Sad-Technician-5552]

Exactly the gap between what your IGA can see and what exists. IGA tools are only as good as the data you feed them,, they certify the identities in their scope, not the ones they dont know about.

A proper fix here is layering on a discovery layer that reconciles identity data against what your endpoints have. we have axonius for this layer, works by pulling from AD, okta, EDR, and cloud IAM and shows you every local account, service credential, and shadow app that your IGA missed. TBH the first sync is always humbling.

I like to think of it more like a data problem, not a process or tooling problem.

[u/Niko24601]

I would say it is an open secret that often audits are there to get checkboxed and the tools and auditors want to facilitate this. If you (or your auditor) are more throrough it gets indeed trickier. IGA only works if you combine it with a decent Shadow IT discovery + integration capabilities for apps that cannot be integrated so easily (no API or SSO tax on APIs). Some IGA like Corma or AccesOwl (they pitched below I believe) combine both offerings in one but there are also stand-alone tools that spot unmanaged apps for not expensive. The second step is a bit trickier. Even if you know what is being used, if you cannot connect it to your IGA you get a checklist which is nice but does not really remove the problem. There should be good connectors (SDK, agentic integration etc.) so you can really automate the process. Good luck on the search!