Your SSO Implementation

Your identity provider is the front door to everything. Every SaaS app, every cloud console, every internal tool that’s federated through SSO trusts your IdP to vouch for your people’s identities. That’s a lot of trust concentrated in one place. If your IdP is poorly configured, if the admin accounts are weakly protected, if session policies are too permissive, if nobody’s monitoring for token abuse — then your SSO isn’t a security improvement. It’s a single point of failure that gives attackers access to your entire ecosystem in one move.

This guide covers the specific configurations and policies that harden your SSO deployment from “technically functional” to “actually secure.”

DO / DON’T

DO:

• Enforce MFA at the IdP for every authentication — no exceptions
• Use phishing-resistant MFA (FIDO2/hardware keys) for IdP administrator accounts
• Configure session timeouts that balance security with usability
• Monitor for impossible travel, anomalous logins, and token abuse
• Audit OAuth application consents quarterly
• Restrict who can register new OAuth/SAML applications
• Maintain a break-glass access procedure that bypasses SSO for emergencies

DON’T:

• Allow IdP admin access without hardware key MFA
• Set SSO session lifetimes to days or weeks — hours are appropriate
• Let any employee consent to new OAuth applications without admin approval
• Forget to revoke SSO access for third-party apps you no longer use
• Assume disabling an IdP account revokes all active sessions immediately
• Skip logging and alerting on authentication events at the IdP

Hardening Your Identity Provider

Your IdP is Tier 0 infrastructure — the most sensitive system in your environment. Treat it accordingly.

Admin Account Protection

• Dedicate separate accounts for IdP administration. Your IdP admin should not be the same account you use for email and daily work. Create purpose-specific admin accounts that are only used for IdP management.
• Require FIDO2 hardware keys for all IdP admin accounts. Not TOTP. Not SMS. Hardware keys. The IdP admin can modify authentication policies, create accounts, forge trust relationships, and access token-signing certificates. This is the most powerful account in your environment.
• Limit the number of IdP admins. Two to four people, maximum. Everyone else gets delegated roles with scoped permissions (e.g., helpdesk can reset passwords but can’t modify authentication policies).
• Enable breakglass accounts. Maintain one or two emergency admin accounts with hardware key MFA, stored in a physical safe, documented in your disaster recovery plan. Test them quarterly. These are your lifeline if the primary admins are locked out.

Authentication Policies

• Enforce MFA for every authentication at the IdP level. This means every login, every session, every connected service requires MFA at the identity provider — not at the individual service. Centralize the MFA requirement. CISA recommends MFA on all accounts, with phishing-resistant MFA for privileged accounts.
• Block legacy authentication protocols. IMAP, POP3, SMTP basic auth, and ActiveSync basic auth bypass modern authentication (and therefore bypass MFA). In Azure AD/Entra ID: Conditional Access > Block legacy authentication. In Google Workspace: disable less secure app access. In Okta: disable non-modern authentication.
• Implement Conditional Access policies. Gate access based on risk signals: device compliance, network location, sign-in risk level, user risk level. Example policies:
  • Require MFA when signing in from outside the corporate network.
  • Block sign-in from countries where you don’t operate.
  • Require compliant/managed devices for access to sensitive applications.
  • Force password change on high-risk sign-ins.

Token-Signing Certificate Protection

The token-signing certificate is the crown jewel. Whoever holds it can forge authentication assertions for any person to any connected service — the “Golden SAML” attack. Per MITRE ATT&CK T1606.002:

• If you use on-premises ADFS, store the certificate in a Hardware Security Module (HSM), not in the Windows certificate store.
• If you use a cloud IdP (Azure AD/Entra ID, Okta, Google), the provider manages the certificate — but you should still monitor for unauthorized certificate rotation or export events.
• Rotate the certificate on a schedule (annually minimum) and after any suspected compromise.
• Restrict access to certificate management to the smallest possible set of admins.

Session Management

Sessions are the authorization artifact that outlives the authentication event. Get the policies wrong and a stolen session cookie is as good as stolen credentials.

Session Timeouts

• IdP session lifetime: 8-12 hours for standard accounts. This balances daily usability (one login in the morning) with risk exposure.
• Privileged accounts: 1-4 hours maximum. Re-authentication should be frequent for admin access.
• Idle timeout: 30-60 minutes of inactivity should trigger re-authentication. Don’t let sessions live forever because someone left a browser tab open.
• Maximum session lifetime: Even active sessions should expire and require full re-authentication at least once per day. This limits the damage from a stolen session cookie.

Session Revocation

• Understand the revocation gap. When you disable an account in your IdP, existing sessions at connected SPs may remain valid until they expire. SAML and OIDC do not have a universal real-time session revocation mechanism. Mitigate this by keeping SP session lifetimes short (1-2 hours) and implementing backchannel logout where supported (OpenID Connect Back-Channel Logout).
• For emergency revocations (compromised accounts, hostile departures): disable the IdP account AND manually revoke sessions at critical SPs (cloud consoles, email, file storage) AND rotate any credentials the person had access to.

Monitoring and Detection

What to Watch For

• Impossible travel: Authentication from New York at 9 AM and from Moscow at 9:15 AM. Either they have a very fast plane or the account is compromised.
• Anomalous application access: An account that normally uses Slack and Salesforce suddenly accessing AWS console or Azure portal.
• Token replay indicators: The same token being presented from different IP addresses or user agents.
• Bulk authentication failures: A spike in failed MFA challenges could indicate a credential stuffing attack against your IdP.
• New OAuth application consents: Someone just granted a third-party app access to read all emails. Was that intentional?

Where to Look

• Azure AD/Entra ID: Sign-in logs, audit logs, risky sign-ins, Identity Protection dashboard.
• Okta: System Log, ThreatInsight, Suspicious Activity Report.
• Google Workspace: Login audit log, OAuth token audit log, Admin console alerts.
• Forward IdP logs to your SIEM. NIST SP 800-92 covers log management, and your IdP logs are among the most important telemetry you have.

OAuth Application Governance

OAuth consent phishing is on the rise. An attacker tricks someone into authorizing a malicious application that then has persistent API access to their data — no password needed, MFA irrelevant.

• Restrict application consent to admins. In Azure AD: Enterprise applications > Consent and permissions > User consent settings > Do not allow user consent. In Google Workspace: Security > API controls > App access control.
• Review consented applications quarterly. Look at every third-party app that has been granted access to your organization’s data. Revoke anything that’s no longer needed or wasn’t explicitly approved.
• Block high-risk permission scopes. Applications requesting Mail.ReadWrite, Files.ReadWrite.All, or Directory.ReadWrite.All should require admin review.
• Maintain an approved application list. Pre-approve applications your organization uses and block everything else until reviewed.

If It Already Happened

If you suspect your SSO has been compromised — unauthorized logins, forged tokens, or a compromised IdP admin account:

1. Disable the compromised accounts immediately at the IdP level.
2. Revoke all active sessions — at both the IdP and every connected SP. Don’t wait for session expiry.
3. Rotate the token-signing certificate if there’s any possibility it was exposed. This invalidates all existing SAML assertions.
4. Audit the IdP configuration. Check for unauthorized changes: new admin accounts, modified authentication policies, new federated trust relationships, new OAuth applications.
5. Review all connected SP logs. Look for access from the compromised account across every federated application. The attacker may have accessed resources you haven’t noticed.
6. Engage incident response. A compromised IdP is a total environment compromise until proven otherwise. CISA’s advisory on detecting post-compromise threats in cloud environments provides the investigation playbook.
7. Communicate to affected parties. If customer data or partner systems were accessible through the compromised SSO, disclosure obligations likely apply.

Your SSO is only as strong as the weakest configuration in the chain. Go through this list. Check every setting. The convenience of single sign-on comes with the responsibility of single-point-of-failure protection.