r/IdentityManagement • u/LetPrestigious3916 • 2d ago
How do you manage application access when not everything is Entra-integrated?
I’m working in IAM and one of the challenges I’m facing is managing access across applications that use completely different authentication methods.
For example, we have applications where:
Entra ID SSO is used, so access can be managed through Entra groups/app assignments.
AD accounts / Kerberos SSO are used, so the user logs in with their corporate AD account.
Some applications have their own local accounts with separate usernames/passwords.
Some applications may have no proper IAM integration or centralised access control at all.
The problem is: if someone asks IAM, “What access does this user have?”, how do you give a reliable answer when access is spread across Entra, AD, and local application accounts?
For applications with Entra SSO, it’s relatively straightforward. But for local accounts, how do you manage the lifecycle, ownership, access reviews, joiner/mover/leaver process, and overall visibility?
I’m interested in how other organisations handle this from an IAM governance perspective.
Do you maintain an application/access inventory outside of Entra? Do you use an IGA tool to track local accounts? Or do you rely on application owners to maintain the access information?
What would be considered a good/practical approach for managing this in a larger organisation?
3
u/Classic_Show_3612 1d ago
That was our use case. We ended up reviewing a bunch of iga tools and found that one called access auditor was the best for our use case, like this. We had a big mix of azure, cloud, legacy, database, random. Their fuzzy id was the key for us to be able to really show WHO has access to what. So that's a must have. Right price, works as promised.
The only thing no tool can do is find out which applications are in use. In our case, we have a finance contact that provided a master vendor list. From that, we could filter to recurring payments and then had a jr person find out if that really was an app. If someone paid on their own, that is a bit tougher. So we have finance hr policy about a security review BEFORE they authorize any payments to vendors. Still tricky on the I paid for it and my boss approved it. The expense report should still get categorized as "software" or services or something like that. Those can kick out.
So we got close. Once we found the app, getting the data imported into our iga tool was trivial. Some had api, some did not. Either way, easy to combine once we found it. Then of course those the support sso/entra, pull it in for SSO because why not. But the iga tool knows all, does alerts, access reviews, all that stuff. It's one of the first steps in our off-boarding process to find out what this person has. We even stuck assets like badges, laptops, phones, into it to have the full "identity" picture.
1
u/jc_AccessOwl 1d ago
Finance data is a great place to start looking.
Problem: free tools won't show up... with employees signing up for AI tools left and right this is a growing problem.
3
u/pewpewlazor 2d ago
Having worked with IAM for around 10 years, I can say this is a very common challenge and one that tends to become more visible as the organization matures.
The first thing I would separate is knowing that an application exists from being technically integrated with it.
In larger organisations, you would ideally have some form of authoritative application inventory, often a CMDB, where you can identify the applications in the organisation, their owners, criticality, authentication method, etc. IAM can then use this as the starting point for understanding the identity and access landscape. Entra ID alone will never give you the complete picture because, as you point out, plenty of applications sit outside Entra and AD.
From there, I would take a risk-based approach. Not every application needs the same level of IAM governance. A local low-risk application used by three people probably doesn't justify the same investment as a business-critical application containing sensitive data.
For the applications that matter, I would want to establish at least:
- Who owns the application?
- How are users authenticated?
- How is access granted and revoked?
- What accounts and entitlements exist?
- Who is responsible for approving access?
- How are joiners, movers and leavers handled?
- How is access reviewed periodically?
You can manage this in a spreadsheet until you realize that is not working and then..
An IGA platform can then become the governance layer across these different technologies. Ideally, you integrate applications directly and automate provisioning/deprovisioning. Where that isn't technically or economically feasible, you can still govern them through manual fulfilment processes. IAM/IGA records that access was requested and approved, an application owner or administrator performs the change, and the action is confirmed back into the process.
The same applies to access reviews. Even if you cannot automatically provision a local account, you may still be able to import the application's accounts and entitlements into the IGA platform and have the appropriate owner certify them. We call these file based integration, usually using a csv file. For applications where even that isn't possible, the application owner needs to remain accountable for maintaining and reviewing access.
So I don't think the realistic goal is necessarily "IAM can technically control every account in the organisation."
The goal is more:
"We know which applications matter, who owns them, how access is managed, who is accountable for it, and we have appropriate governance based on the risk."
Then, as the IAM programme matures, you progressively move the higher-value applications from manual governance → visibility/reconciliation → automated lifecycle management.
Trying to integrate everything from day one is usually both unrealistic and very expensive.
1
1
2
u/jc_AccessOwl 1d ago edited 1d ago
As with anything this depends largely on what tools you have access to and how your org is set up. But let me share what I've seen.
Your situation is highly typical. Even with a fancy enterprise SSO tool it's inevitable to have a spreadsheet out there for edge cases. For an average team I've seen that SSO really only covers ~1/3rd of the full stack. As others mentioned, people focus SSO on the core tools and the ones "in scope" for access reviews and care less about the rest.
Modern identity governance tools help solve your question in a few ways. First, they let you manually track apps in their dashboard. Even though you have to type/click yourself, it keeps it in one place so you don't have spreadsheets you forget about. That theoretically covers every app. Second, they'll let you connect internal apps via API if said internal apps support that. And third, they make it dead simple for application owners to keep information up to date. They can do it in Slack. They just have to press a single button. They don't have to be technical. Fourth, instead of relying on SCIM/SAML or API connectors at all they use service accounts where actions are performed by an agent. A big reason companies don't add tools into central SSO is they'd have to upgrade to enterprise tiers. The service account approach removes that need. You can replicate some of these things without a tool. That's what I've seen help.
I'm talking about younger IGA tools by the way. Not the big ones as they are all dependant on SCIM/SAML and you run into the same problem. I'm associated with AccessOwl, one of these younger IGA tools. But you can do your own research on others like Corma or YeshID. They all understand that it's not feasible to "put everything on SSO". So you have multiple options for connection or manual tracking.
If you have like ~5 local accounts you can keep it on a spreadsheet. But if you have lots of apps and it's causing you headaches just look for an IGA tool that layers on top of Entra.
1
u/InspectionHot8781 1d ago
For non SAML web apps and local accounts that Entra can’t touch natively, we had to move enforcement to the browser layer (using Unixi) to get SSO, audit logs, and offboarding covered. For internal legacy desktop apps, we still rely on an IGA tool linked to application owner reviews.
1
1
u/Low_Play_8942 19h ago
I’d keep a central application inventory even when provisioning stays manual. each app should still have an owner, access review process and clear joiner/leaver steps
7
u/ohnowwhat 2d ago
Sad truth is you'll never achieve 100% coverage.
Find your crown jewels, ensure as many as possible enterprise-critical apps are properly governed, whichever apps have compliance and regulations requirements and be proud of yourself if you ever come close to 80%