Single sign-on is the easy half

Most identity projects are described as SSO projects, and most of the risk in them is somewhere else.

Single sign-on answers one question: can this person authenticate to this application right now. It is a valuable question and a solved problem. Federation is mature, the standards are stable, and connecting an application that supports them properly is routine work.

The question SSO does not answer is whether the account should exist at all.

The gap

When someone leaves, disabling their account at the identity provider stops new federated sign-ins. It may not revoke an application session that is already active, and it does not, on its own, do anything to the account inside the application. That account still exists. It may still hold data, still own records, still count against a license. And this is the part that matters: it may still be reachable by any authentication path that does not go through the identity provider. A local password set before federation. An API token. A personal access token in a repository. A service account the person created and named after themselves.

The gap is widest when just-in-time provisioning is used without lifecycle provisioning. Accounts are created automatically on first login, while JIT itself provides no corresponding deactivation path.

What provisioning standards actually deliver

Automated provisioning closes the gap by making the identity provider authoritative for the account lifecycle, not just the login. Creation, updates and deactivation are pushed to the application rather than reconciled by hand.

In practice, support is uneven in ways that only appear during implementation:

• Some applications create users but never deactivate them.
• Some deactivate but do not release the license, so the cost stays.
• Some push group membership but ignore role or entitlement changes within the application.
• Some support the standard on an enterprise tier only, which turns an identity decision into a contract negotiation.
• Some implement it correctly but document the behavior poorly, so you only find out by testing.

Vendor documentation tells you what the integration supports. Testing tells you what it actually does in your tenant: provision a test user, change their attributes, deactivate them, and observe what happens in the application afterwards.

Group architecture

The most common structural mistake is mapping application access directly to job titles. Titles change for reasons that have nothing to do with access, they are inconsistent across departments, and they are owned by whoever writes offer letters.

A two-layer model holds up better. The first layer is authoritative and derived from the HR system: department, employment type, location, manager. Nobody edits these by hand. The second layer is application-facing groups, populated by rules that read the first layer. Access is granted to the second layer only.

The benefit is that a change in the HR system propagates automatically, and every access decision has a written rule behind it rather than a memory of why someone was added. When an auditor asks why a particular person has a particular entitlement, the answer is a rule, not an archaeology exercise.

Applications that cannot federate

There are always some. A platform with no support for the standard, a legacy internal tool, something acquired with a company. The options are limited and worth stating plainly:

Front it with an access proxy so the authentication decision moves to a layer that does federate. Script the lifecycle against the application's own API on a schedule. Or accept manual management and put the application into a scheduled access review with a named owner.

The third is a legitimate choice. What is not legitimate is the fourth option, which is to leave it unmanaged and not write it down. The register of what is not automated is as important as the automation.

The test that matters

Every identity architecture should be verified the same way. Create a test identity, grant it a realistic set of access, then offboard it exactly as a real departure would be handled. Wait a day. Then go into each application and look.

Whatever is still alive is your actual offboarding posture. Not the runbook. Not the diagram.

Explore this expertise: Identity & Access Management

All technical notes