This is one of those areas where most IAM advice quietly falls apart.
On paper, identity looks clean. You centralize everything in your IdP. Users authenticate through SSO. Access is controlled through groups. Lifecycle is automated.
In practice, a meaningful portion of your environment does not support SAML at all.
These are the apps that sit just outside the clean architecture:
So when people ask how to manage access for these apps, they are really asking:
How do you control access when your IdP cannot enforce it?
If you look at how experienced IT and security teams answer this, the pattern is consistent. They are not solving it with a single tool. They are layering controls and accepting that access lives in multiple places.
The first move most practitioners make is to shift focus from authentication to lifecycle.
Even if an app does not support SAML, it may support:
Teams will try to connect these into systems like Okta, Microsoft Entra ID, or Google Workspace, or they will build scripts to handle it.
The goal is simple and pragmatic:
This is the baseline that experienced operators insist on.
But they are also very clear about the limitation. Provisioning controls whether an account exists. It does not control what that account can do.
That distinction shows up everywhere.
Once SAML is not available, the center of gravity shifts.
Access is no longer controlled in the IdP. It is controlled inside each individual application.
That means:
Teams try to map these roles to job functions, but over time things drift. People change roles. Temporary access becomes permanent. Permissions accumulate.
One of the more candid ways practitioners describe this is: Every non-SAML app becomes its own identity system.
And that creates a predictable set of problems:
You are not managing identity once. You are managing it dozens of times.
For apps that only support username and password, teams often fall back to password managers like 1Password, LastPass, or Bitwarden.
This shows up frequently in real environments, especially for:
It gives you some control:
But most experienced teams treat this as a compromise.
You lose individual accountability. You lose clean auditability. You lose the ability to model permissions in a meaningful way.
It works. It is just not where you want to end up.
When access cannot be fully centralized, teams rely heavily on offboarding.
This becomes the moment where you reduce risk.
Practitioners will:
This is where discipline matters. If offboarding is weak, gaps accumulate quickly.
But even strong offboarding has a dependency. You have to know what to remove.
And that brings you back to discovery.
Some teams bring in SaaS management platforms like BetterCloud or Torii to help organize the chaos.
These tools are useful for:
They can support lifecycle workflows and help surface obvious issues like orphaned accounts.
But the feedback from practitioners is consistent.
They help you find and organize access. They do not deeply control it.
They are a coordination layer, not an enforcement layer.
Without SAML, access reviews become much more manual.
Teams will export user lists from each app, compare them to HR systems, and ask managers to validate access.
This is time-consuming and often frustrating:
Still, experienced teams do this regularly because there is no shortcut.
If access lives in the app, it has to be reviewed in the app.
One of the more advanced answers you will hear, especially from security-focused teams, is to pay attention to OAuth.
Apps that do not support SAML often integrate through Google Workspace or Microsoft 365.
Users grant permissions like:
This creates a layer of access that:
Teams that have dealt with real incidents tend to call this out explicitly as a blind spot.
It is not enough to manage users. You also have to manage what users have delegated.
If you step back, the answers from practitioners all converge on the same reality.
There is no clean, centralized way to manage access for non-SAML apps using traditional IAM approaches.
Instead, teams are combining:
Each piece helps. None of them gives a complete answer.
Because access is not actually centralized anymore.
It lives in multiple places at once:
When an app does not support SAML, access does not disappear.
It just moves somewhere else.
The question is not really:
How do I manage this app without SAML?
The better question is:
Where does access live for this app, and how do I control it there?
That might mean:
Because the goal is not to force everything through SSO.
The goal is to understand what people and systems can actually do, and keep that aligned with intent.
If you are dealing with apps that do not support SAML, the experienced approach looks like this:
And keep one thing in mind.
A user existing in a system is not the same as their access being controlled.
