Skip to main content

SSO & Identity Federation Governance

In one line: SSO (Single Sign-On) and federation centralize human identity so people authenticate once to a trusted identity provider and access many systems — a real security win (one place to enforce MFA, one place to cut off access) — but the part everyone neglects is the lifecycle: deprovisioning when someone leaves and periodic access reviews, because orphaned accounts and accumulated permissions are how insiders and attackers slip through.

In plain English

In a real organization, a person needs access to dozens of systems — email, cloud, code, HR tools, a hundred SaaS apps. If each has its own separate login, you get a mess: password reuse, no consistent MFA, and — the dangerous part — no reliable way to remove someone's access everywhere when they leave. SSO fixes this by having everyone authenticate through one trusted identity provider (IdP); log in once, and that identity grants access to all the connected apps. Federation is the same idea stretched across organizational boundaries (e.g., logging into a partner's system with your company identity). The security upside is huge: one place to enforce strong authentication, and one place to instantly revoke all access. But SSO is only half the story. The half everyone forgets is the identity lifecycle — especially offboarding: when someone leaves or changes roles, is their access actually removed everywhere? Orphaned accounts and "I still have access to my old team's systems" are among the most common, most boring, and most dangerous gaps in real organizations. This lesson is identity at human scale — and the unglamorous governance that makes it secure.

SSO and federation: centralizing identity​

SSO lets a user authenticate once, to a central identity provider (IdP), and then access many applications without logging in again to each. Identity federation extends trust between identity systems — including across organizations — so an identity from one domain is accepted by another (via standards like SAML and OIDC/OAuth).

The security case for centralizing identity is strong:

  • One place to enforce strong authentication. Require MFA (ideally phishing-resistant passkeys) once, at the IdP, and it protects every connected app — instead of hoping each app implements MFA well.
  • One place to revoke. Disable the central identity and access to all connected systems is cut at once — the single most important offboarding capability.
  • Fewer credentials, less reuse. One strong identity beats dozens of separate passwords that get reused and phished.
  • Central visibility. Authentication across the whole estate flows through one place you can log and monitor.
Terms, defined once
  • SSO (Single Sign-On) — authenticate once to a central provider, access many apps.
  • Identity Provider (IdP) — the trusted system that authenticates users and asserts their identity to apps.
  • Federation — extending identity trust across systems/organizations, so one domain's identity is accepted by another.
  • SAML / OIDC / OAuth — the standard protocols for SSO and federation.
  • Provisioning — creating accounts and granting access when someone joins or changes roles.
  • Deprovisioning (offboarding) — removing accounts and access when someone leaves or no longer needs it. The most-forgotten step.
  • Orphaned account — an account still active after its owner has left or no longer needs it; a prime attack target.
  • Access review (recertification) — periodically re-verifying that people still need the access they have, and removing what they don't.
  • Joiner-Mover-Leaver (JML) — the identity lifecycle: onboarding, role changes, offboarding.

The lifecycle everyone forgets: deprovisioning and reviews​

SSO is exciting; governance is boring — which is exactly why it's neglected, and why it's where real risk accumulates. Identity has a lifecycle (Joiner-Mover-Leaver), and the security failures cluster at Mover and Leaver:

Worked example: the access that should have been removed

An employee joins the sales team (provisioned access to CRM, email, sales tools). Two years later they transfer to engineering — and get new access (code repos, cloud). But here's the common failure: their old sales access is never removed. Now they have both. Repeat across several role changes and they accumulate broad, unjustified access — privilege creep at the human-identity level. They're now an oversized target: compromise their account and an attacker inherits years of accumulated access spanning multiple teams.

Then they leave the company — and in too many real organizations, some of their accounts stay active. An orphaned account with no owner is a gift to an attacker (or to the disgruntled former employee): valid credentials, no one watching, often missed by offboarding. Departed-employee access and orphaned accounts are repeatedly cited in real insider-threat and breach reports.

The fixes are unglamorous but decisive:

  • Deprovision promptly and completely on departure — ideally automated, so disabling the central identity cuts all federated access at once (the SSO payoff). Manual offboarding checklists miss things.
  • Adjust access on role change — remove the old when granting the new, so privilege doesn't accumulate.
  • Run periodic access reviews — managers recertify that their reports still need each access; anything unjustified is revoked. This catches the creep that slips through day-to-day.

This is least privilege over time: not just granting minimally, but continuously removing what's no longer needed. Access that's never reviewed only ever grows.

Why centralized identity is also a single point of (high-value) failure​

One honest caveat: centralizing identity concentrates risk. If the IdP is the key to everything, then compromising the IdP compromises everything — which is why the identity provider itself must be defended with the highest rigor: strong MFA (phishing-resistant), tight admin access, heavy monitoring, and careful protection of the trust relationships (a forged SAML assertion or a compromised IdP admin is catastrophic). This isn't an argument against SSO — decentralized identity is worse (no consistent MFA, no clean revocation). It's a reminder that the IdP is now your crown-jewel system and must be treated as such. The benefit (one place to control) and the risk (one place to lose) are two sides of the same centralization.

Why it matters​

  • It's how identity scales securely. Dozens of separate logins per person is unmanageable and insecure; SSO/federation is the only sane way to enforce strong auth and clean revocation across an estate.
  • Offboarding gaps are a top real-world risk. Orphaned accounts and unremoved access appear constantly in insider-threat and breach reports — boring, common, and dangerous. Governance is where this is fixed.
  • It completes least privilege. Granting minimally is half; removing access as roles change and people leave is the other half. Without lifecycle governance, least privilege erodes into privilege creep.

Common pitfalls​

Where people commonly trip up
  • Doing SSO but neglecting deprovisioning. The biggest payoff of centralized identity is instant revocation — wasted if offboarding is slow or incomplete. Automate prompt, complete deprovisioning.
  • Adding access on role change without removing the old. This is human-scale privilege creep. Adjust access on every move, not just additively.
  • No periodic access reviews. Permissions only accumulate without recertification. Run regular reviews where owners confirm or revoke access.
  • Orphaned accounts. Accounts that outlive their owner's need are valid credentials nobody watches. Find and disable them.
  • Under-protecting the IdP. Centralized identity makes the IdP a crown-jewel target; weak MFA or loose admin access there compromises everything. Defend it with the highest rigor.
  • Relying on manual offboarding checklists. Humans miss systems. Automate deprovisioning through the central identity so one action cuts all federated access.

Page checkpoint​

Required checkpoint

Did SSO & federation click?

Pass to unlock the Next button below

What's next​

→ Continue to KMS & Secrets at Scale — managing the cryptographic keys and secrets that protect everything, across a whole cloud environment, with rotation and auditable access.

→ Going deeper: the MFA enforced at the IdP is authentication; least privilege over time is Foundations; monitoring the IdP is detection.