A company sets up Okta or Google Workspace, connects its main applications, and starts managing access the obvious way: add people to groups to grant, remove them to revoke. It works, visibly, every day. Which is exactly why it takes an audit, an incident, or a surprise license bill to discover that what's running is authentication wearing access management's clothes.
This isn't an argument against SSO. Single sign-on is genuinely one of the best security investments an organization makes: one strong authentication path, MFA enforced in one place, one switch to cut off at offboarding, and an end to password sprawl. Every serious access program is built on top of it.
The argument is narrower and more practical: granting and revoking access through SSO group membership is not access management, and treating it as such leaves specific, predictable gaps. This piece walks through each one, then covers what the right architecture actually looks like, which, importantly, keeps SSO exactly where it is.
What SSO Actually Does, and Does Well
SSO answers one question: is this person who they claim to be. It centralizes authentication — one login, one MFA policy, one session model — across every application federated to it, and it gives IT a single control point for the login path itself.
That's the front door, and a well-run front door matters enormously. But access management is a different set of questions: what is this person entitled to once inside, at what permission level, is that still appropriate, who approved it, and what's the proof. SSO wasn't built to answer any of those, and the gaps below are the consequence.
Gap 1: The Federation Boundary
SSO governs the applications connected to it. Its visibility, and its control, end exactly there.
What lives beyond that boundary is shadow IT: SaaS and AI apps bought directly by teams, departments, and individuals without IT involvement, expensed on a corporate card or adopted free, carrying company data from day one. None of it is federated, which means none of it is touched by a single group grant or revocation. In most organizations this unfederated slice is substantial and growing fastest.
The uncomfortable arithmetic: SSO-based access management governs the sanctioned estate with precision while the least governed, least vetted applications — the ones no security review ever saw — sit entirely outside the model. The access that most needs managing is exactly the access this approach was never built to see.
Gap 2: Group Grants Say Nothing About Permissions
Adding someone to an SSO group answers one question: can this person get into the application. It says nothing about what they can do once in.
"Has access to Salesforce" isn't an access decision; it's the absence of one. The real decisions live a level deeper: which role, which license tier, which permission scope, in which instance. A Sandbox admin and a Production admin are meaningfully different grants, and a group membership expresses neither. Access management at the group level replaces "has the right access" with "has access," and least privilege quietly becomes a slogan, since the model has no vocabulary for privilege at all.
This gap compounds at the mover stage. A department transfer handled through SSO groups means removal from one group and addition to another, but whatever was granted inside applications directly — the elevated role someone picked up for a project, the license tier an app admin assigned by hand — isn't attached to the group and doesn't move with the change. It just stays.
Gap 3: Revoking SSO Doesn't Deprovision Anything
This is the gap with the sharpest consequences, because it corrupts the one moment SSO-based access management feels most reliable: offboarding.
Cutting someone's SSO revokes the login path. It does not deprovision the account. Inside each application, the user record survives, its role and permissions survive, and its license survives — invisible to anyone looking at the SSO dashboard, and still billable every renewal cycle.
The security exposure is worse than the cost. Many applications retain direct login paths alongside SSO; API tokens and personal access keys issued before departure keep working because they never touched the SSO session at all; and an active account inside an application is an active account, whatever the identity provider says about the person. "We disabled their Okta" and "we removed their access" are different claims, and the difference is exactly what an attacker or an auditor goes looking for.
The Jobs SSO Was Never Going to Do
Beyond the three gaps above, an entire layer of access management has no SSO equivalent, because it was never authentication's job.
Access reviews and certification. Periodically verifying who still holds what, with locked, timestamped reports, doesn't exist in an SSO model. Group membership lists aren't certifications, and frameworks like SOX and PCI DSS don't accept them as such.
Request governance. Mid-tenure access needs either flow through a governed request path with approval logic, or through Slack messages to whoever owns the group. SSO offers only the second.
Segregation of duties. Toxic combinations — one identity holding two entitlements that are dangerous together — live at the permission level across applications, a layer the group model can't even represent, let alone evaluate.
Non-human identities. Service accounts and API integrations don't log in through SSO at all. The fastest-growing identity population in most organizations is invisible to an SSO-centered model by definition.
Audit evidence. The question an auditor asks is whether specific access was granted and revoked on specific dates through a controlled process. Group membership history answers a narrower question about logins, and per Gap 3, not even that one reliably.
What This Looks Like When It Surfaces
The failure is quiet until it isn't, and it tends to surface in one of three ways.
An audit asks for offboarding evidence, and the SSO deactivation log turns out not to prove application-level revocation, at which point every departed employee becomes a manual verification exercise across every application. A license true-up reveals seats billed for people who left months ago, alive inside applications their SSO could no longer reach. Or an incident review finds a departed contractor's API token still active, issued from an account everyone assumed was gone.
None of these are exotic. They're the three gaps above, arriving on schedule.
The Right Architecture: SSO as the Floor, Not the Ceiling
None of this argues for less SSO. It argues for being precise about what layer SSO occupies.
SSO is the authentication floor: one login path, one MFA policy, one source of identity truth. Access management is the layer built on top of it, consuming the identity data SSO's directory provides and governing everything downstream — permission-level grants, lifecycle changes evaluated against live attributes, automated provisioning and deprovisioning that reaches inside applications rather than stopping at the login path, reviews, request governance, and evidence.
The two layers aren't competitors, and the evaluation question isn't SSO versus access management. It's whether anything is actually running above the floor.
How Zluri Relates to SSO
Zluri is built as exactly that layer above the floor, using SSO rather than stopping at it.
SSO is one discovery source among eight. SSO data feeds Zluri's application discovery alongside direct integrations, transaction and expense data, agents, MDMs, CASBs, plugins, and manual entry. This is what closes Gap 1: the unfederated estate, shadow SaaS and AI apps included, surfaces in the same inventory as the sanctioned one.
Grants are permission-level, not group-level. Roles and permissions are tracked as structured data — privilege indicators, permission types, instance-specific roles — so Sandbox admin and Production admin are two distinct grants. This is what closes Gap 2 and gives least privilege a vocabulary.
Offboarding deprovisions, not just deactivates. Workflows auto-populate from a person's actual current access footprint and execute revocation inside each application: account, role, license, with per-action run logs proving each one executed. This closes Gap 3 and produces the artifact an audit actually asks for.
SSO stays in the loop. Dedicated SSO Actions run provisioning at the identity-provider level (Okta, Azure AD, Google Workspace groups) inside the same workflows that handle application-level access, so the authentication floor and the governance layer above it operate as one system rather than two disconnected ones.
Frequently Asked Questions
Is SSO part of access management, or a separate thing?
SSO handles authentication, one of the layers access management builds on. It's foundational, not equivalent: access management consumes the identity truth SSO's directory provides and governs authorization, lifecycle, and evidence on top of it. The mistake isn't using SSO; it's stopping there.
If we remove someone from SSO, don't they lose access to everything?
They lose the SSO login path. Their accounts inside applications survive, along with roles, licenses, and any direct login paths or API tokens the applications support. Application-level deprovisioning is a separate step, and the difference between the two is what audits and incident reviews consistently find.
We're a small company. Isn't SSO-based access management enough for now?
It's a reasonable starting point, and the gaps grow with the company rather than appearing suddenly. The practical threshold: once shadow adoption is real, compliance frameworks apply, or headcount changes are frequent enough that mover and leaver errors accumulate, the gaps stop being theoretical. Starting the access layer early is cheaper than reconstructing history later.
Does adding SCIM provisioning to SSO close these gaps?
It narrows Gap 3 for applications that support SCIM well, since deprovisioning can then reach inside those apps. It does nothing for the federation boundary (Gap 1), little for permission-level governance (Gap 2), and nothing for reviews, requests, SoD, or non-human identities. SCIM is a useful pipe, not an access management layer.
.svg)
