Most organizations deploy SSO, declare victory, and move on. The controls that make SSO genuinely effective take longer to implement and receive far less attention than the initial rollout. This guide covers those controls, organized around what SSO does well and what requires additional work beyond it.
SSO is foundational infrastructure, not a finished security program. Getting SSO deployed is the prerequisite. What follows is the set of decisions that determine whether the deployment produces security outcomes or just security theater.
The practices below split into two layers. The first layer hardens the authentication infrastructure SSO creates. The second extends governance to the terrain SSO doesn't cover. Both matter, but most organizations underinvest in the second because the first feels more concrete.
The Quick Reference
Layer One: Hardening the Authentication Layer
SSO concentrates authentication behind one credential and one session model. That concentration is a security improvement over distributed passwords, but failures at the authentication layer now have broader consequences. These practices address the risks that live at the SSO layer itself.
Deploy Phishing-Resistant MFA, Not Just Any MFA
The most important single decision in SSO security is the type of MFA enforced at the authentication layer, and most organizations have made the wrong one.
Push-notification MFA (approve/deny prompts to a phone) is the most widely deployed form of SSO-layer MFA. It's also increasingly fallible. AiTM (Adversary-in-the-Middle) phishing intercepts the authentication session in real time, capturing the session token after MFA has already been successfully completed. The attacker relays the credential through a convincing proxy page, the user completes the MFA prompt against what they believe is the legitimate site, and the attacker receives a valid session. Push fatigue attacks compound this further: flood users with MFA prompts until one is accidentally approved.
Phishing-resistant MFA (FIDO2 security keys or passkeys) closes the AiTM vector because authentication cryptographically binds to the legitimate origin domain. A credential captured through a spoofed page cannot replay against the real one. For SSO admin accounts in particular, this isn't optional. An SSO admin account behind push notifications is the single most valuable phishing target in the organization.
Rollout sequence: Start with admin accounts and privileged users where the blast radius of a compromise is largest. Expand to the broader workforce on a phased timeline. TOTP (authenticator app codes) is a meaningful step above push notifications and a reasonable interim for users where hardware keys aren't yet practical.
Treat Session Security as SSO Security
A session token issued after successful SSO authentication is what downstream applications trust. Stealing it bypasses authentication entirely because authentication already happened.
This is the dominant technique in identity-based attacks that circumvent MFA. Once the token exists, the login event is over. Session policy is therefore as important as authentication policy, and the two need to be managed as a unit.
Token lifetimes should be segmented by application risk. A session token valid for 24 hours gives an attacker 24 hours of access after extraction. Applications holding sensitive data, financial records, or admin capabilities warrant shorter lifetimes (2-4 hours). Lower-risk applications can tolerate longer sessions. The segmentation is what matters, not a blanket policy.
Step-up re-authentication brings the authentication check to moments of elevated risk rather than relying on a session that may be hours old. Admin console access, bulk data exports, financial record modifications, security configuration changes: all of these warrant re-verification at the moment of the action, not just at the morning login.
Device trust evaluates the health of the device requesting access as part of the session model. A valid token on a compromised device is a compromised session. Managed device status and endpoint health checks make stolen tokens harder to replay on attacker-controlled hardware.
Session revocation needs to be tested, not assumed. Verify that deactivating a user in SSO actually terminates their active downstream sessions. For many applications it doesn't, and that gap matters most during offboarding.
Disable Local Authentication on Connected Applications
Connecting an application to SSO doesn't eliminate its native login path. Most applications keep both active, and the direct path bypasses every SSO control you've configured.
A user who set a password before SSO was rolled out, or who was provisioned with a local account by an application admin, can authenticate directly without going through SSO. Your MFA enforcement, conditional access policies, and single-logout controls don't apply to them.
Where the application supports SSO-only enforcement, enable it. Where it doesn't, at minimum rotate and vault residual passwords and monitor those login paths for activity. An application that can be entered two ways is only as secure as the weaker one.
Build and Test Recovery Paths
The failure mode organizations actually experience isn't the SSO platform going down. It's a locked account with no rehearsed recovery path.
An MFA device goes missing, an account gets flagged, an admin error locks the wrong user out. Without pre-built recovery procedures these become emergencies. With them they're inconveniences.
Breakglass admin accounts with direct application access, stored in a vault and rotated on a defined schedule, are the minimum. Test them quarterly. Document which applications have local auth fallbacks and which don't. For applications with no fallback, have a defined vendor escalation path. The recovery procedure should be boring because it was practiced, not improvised under pressure.
Layer Two: Governing What SSO Doesn't Cover
The practices above address the authentication layer. The practices below address the terrain that lies beyond it, where persistent, accumulating risk lives in most SSO deployments.
SSO governs the applications connected to it. Everything outside that boundary is structurally outside SSO's visibility and control, regardless of how well the SSO itself is configured. Closing these gaps requires a governance layer, not better SSO configuration.
Know Which Applications Are Actually Behind SSO
Most SSO deployments have less complete coverage than IT teams assume, and the gap grows every quarter.
The initial rollout covers major platforms. Enrollment then slows as remaining apps require more effort or hit SSO tax barriers. Meanwhile teams adopt new applications continuously: corporate cards, free-tier accounts, AI tools that entered use last quarter. The gap between "connected to SSO" and "in actual use" widens steadily.
Run a full discovery across the application estate and compare it against the SSO-enrolled list. The delta is your non-SSO perimeter: apps with real data and real access that receive none of SSO's controls. Discovery beyond SSO audit logs (finance and expense data, endpoint signals, browser activity) surfaces the shadow IT that SSO enrollment never captured.
This inventory is the foundation for every other governance practice. You cannot review, deprovision, or govern access to applications you don't know exist.
Enforce Least Privilege at the Permission Level, Not the Group Level
SSO group-based access is efficient to configure and systematically prone to drift. Across promotions, lateral moves, and role changes, users accumulate permissions that nobody tracks and nothing removes.
Someone joins a group for a project. The project ends. The membership persists. Groups grow broader because adding people is immediate and removing them requires someone to notice, care, and act. Over time groups become broader than intended, and mappings that bundle four applications because one rule was easier than four produce access nobody consciously approved.
The response has two parts. First, provision at the permission level where possible. "Member of the Sales group" tells certifiers nothing about which Salesforce permission sets, which data repositories, or which reporting capabilities that membership grants. Permission-level provisioning by default means adding only what the current role requires, not what the previous occupant accumulated.
Second, review group-to-access mappings on a defined schedule, not just group membership. The question isn't only who is in a group but whether the group should still grant everything it currently does. Groups created for projects and never archived, mappings bundling unrelated applications, permission sets that expanded without review: all require periodic scrutiny that membership-level reviews don't surface.
Deprovision at the Application Level, Not Just the SSO Level
This is the practice gap that produces the most durable security exposure. SSO deactivation is the most visible offboarding step and it is not complete deprovisioning.
SSO deactivation blocks the federated login path. It doesn't deactivate the account inside each connected application, revoke API tokens and OAuth grants, terminate active sessions (which are often controlled by the application and may run for 30 days or indefinitely), or touch any application outside the SSO perimeter. For a typical mid-market organization where SSO covers 30% of the application estate, deactivating the SSO account addresses 30% of the former employee's access footprint.
Complete offboarding requires:
- Account deactivation at the application level inside each connected app
- API token and OAuth grant revocation
- Active session termination, confirmed per application
- Coverage of non-SSO applications, which requires the inventory above
- Data transfer before deletion: document ownership, open tickets, Slack archival
The evidence dimension matters too. SSO deactivation logs show when the login path was blocked. Compliance frameworks want confirmation that access inside each application was removed. Those are different artifacts, and only the second answers the auditor's actual question.
Run Access Reviews That Cover the Full Estate
Access reviews scoped to SSO-connected applications certify the best-governed slice of the environment while the rest accumulates unchecked.
The reviews complete on schedule and produce a compliance artifact, but partial coverage means partial assurance. The applications outside the review scope are often the ones with the most accumulated drift because they've never been reviewed at all.
Effective access reviews need two properties most SSO-based reviews lack. First, scope: every discovered application, including non-SSO apps, needs to appear in the same certification cycle. Second, data: certifiers need actual entitlement data showing what permissions a user holds inside each application and when they last used them, not a list of names to approve from memory. A review where certifiers approve group membership without seeing what that membership grants produces decisions indistinguishable from rubber stamps.
Quarterly reviews on a full-estate scope with entitlement data catch privilege drift, orphaned accounts, and over-broad group mappings between provisioning events. They also generate the access certification evidence compliance frameworks require for the applications SSO logs alone can't account for.
Where Zluri Fits in This Program
Zluri is an identity security platform for autonomous enterprises, built to operationalize the Layer Two practices above alongside whichever SSO platform is already in place.
Discovery runs through eight parallel pathways (direct API integrations, finance and expense system data, endpoint agents, MDMs, CASBs, browser plugins, HRMS feeds, and SSO data) to surface the full application estate, including shadow IT and non-SCIM apps that SSO enrollment never captured. This inventory makes the non-SSO perimeter visible and governable rather than invisible.
Lifecycle automation handles provisioning and deprovisioning at the application level: attribute-based access configuration inside applications at join and through role changes, not just account creation through SCIM. Deprovisioning workflows execute inside each application with per-action Run Logs confirming Completed, Failed, or Pending per app, so the offboarding record is evidence of what was actually removed rather than an assumption based on SSO deactivation.
Access reviews run with actual entitlement and usage data across the full estate, covering federated and non-federated applications in the same certification cycle. Certifiers see what permissions a user holds, when those permissions were last used, and whether the current access aligns with their role.
ISPM (Identity Security Posture Management) runs continuously between review cycles, surfacing identity risk signals (inactive accounts with standing access, excessive permissions, ungoverned OAuth grants, policy violations) and providing 1,500+ automated remediations so risk doesn't accumulate unchecked between scheduled reviews.
The SSO layer and Zluri operate as complements. SSO handles authentication. Zluri handles the governance lifecycle that authentication alone doesn't address.
Frequently Asked Questions
What is the most important SSO best practice?
Phishing-resistant MFA at the authentication layer is the highest-leverage single control for authentication-layer risk. For overall program maturity, the practice with the most persistent impact is running full-estate access reviews with actual entitlement data, because it catches the privilege drift, orphaned accounts, and shadow IT exposure that accumulate continuously over time.
What's the difference between SSO security and identity governance?
SSO security addresses the authentication layer: hardening the login event, strengthening MFA, managing session tokens, and configuring conditional access. Identity governance addresses the access lifecycle: whether entitlements are appropriate, whether access is removed when someone leaves, what exists outside the SSO perimeter, and whether access reviews generate meaningful evidence. Both are necessary. Most organizations have significantly more investment in the first than the second.
Should I enforce SSO-only authentication across all connected applications?
Yes, wherever the application supports it. Applications that retain local authentication paths alongside SSO can be accessed through those paths regardless of SSO policy, bypassing MFA enforcement and session controls. SSO-only enforcement closes that side door. Where applications don't support enforcement, vault and monitor residual credentials.
How often should access reviews run?
Quarterly is the standard for most compliance frameworks and a reasonable frequency for catching privilege drift before it compounds. High-risk applications warrant more frequent review or continuous monitoring rather than periodic certification. Reviews running less than annually provide insufficient assurance for meaningful security programs.
How do I handle applications that can't connect to SSO?
They still need governance. Start with discovery so you know they exist. Build deprovisioning workflows that reach inside the application directly. Include them in access reviews on the same schedule as SSO-connected apps. The controls differ from federated governance but the requirement is identical: known, monitored, and included in lifecycle processes.
What evidence does a complete offboarding process need to produce?
For compliance frameworks, the question is: can you confirm that for each application the employee had access to, access was removed, when, and by what action? An SSO deactivation timestamp answers this for the login path only. A per-application deprovisioning record with timestamps and completion status per app answers it completely, and is what auditors for SOC 2, ISO 27001, and HIPAA are actually requesting.
.svg)
