Understanding SSO Security Risks
Single sign-on (SSO) offers convenience by allowing users to log into multiple systems with one set of credentials. However, this convenience also concentrates risk, as evident in the 2025 University of Pennsylvania breach. Attackers compromised a PennKey SSO account and used that access to reach internal systems, including VPN, Salesforce, Qlik, SAP, and SharePoint, resulting in the theft of data on 1.2 million individuals.
This incident does not inherently mean SSO is insecure. When properly configured and protected, SSO can improve security by reducing password sprawl, centralizing access policies, and making it easier to enforce multi-factor authentication (MFA). The key is treating SSO as a critical security control.
Securing SSO Logins
To determine if an SSO login is protected enough, organizations must look beyond whether SSO is enabled and focus on how it is secured. This starts with strong SSO passwords. The latest guidance from NIST emphasizes length and usability, alongside screening for weak or compromised passwords.
NIST recommends at least 15 characters for single-factor passwords and at least eight characters for passwords used alongside MFA. Systems should allow users to create passwords up to 64 characters and check new passwords against blocklists of commonly used, expected, or previously compromised passwords.
Mandatory Complexity Requirements and Routine Password Resets
NIST advises against mandatory complexity requirements and routine password resets, as these can push users toward predictable patterns, such as changing one digit or adding a symbol at the end.
Adding Multi-Factor Authentication (MFA)
A strong SSO password should not be the only barrier between an attacker and applications. MFA adds another layer of protection, making it harder for an attacker to turn a compromised password into a successful login. For SSO, MFA should be enforced consistently across users, apps, and access scenarios.
Organizations should consider moving toward phishing-resistant methods such as FIDO2 security keys, WebAuthn, or passkeys, especially for privileged users and access to sensitive systems.
Securing Assets Behind SSO
Organizations also need to secure the assets that sit behind SSO and control how identity is issued, trusted, and delegated. This includes protecting IdP administrator accounts with phishing-resistant MFA, separate admin accounts, just-in-time access, and close monitoring.
Signing certificates and keys need strict control. SAML certificates and token-signing keys allow applications to trust the identity provider. If exposed or misused, attackers may impersonate users or abuse trusted sessions.
OAuth Secrets and Credentials
OAuth secrets and credentials deserve the same attention. Client secrets, app credentials, and refresh tokens can give attackers long-lived access. These should be stored in a secrets vault, rotated regularly, and reviewed for excessive permissions.
Conclusion on SSO Security
SSO is still worth using, provided it is implemented and protected properly. The benefit for users is simpler access, as they don’t have to remember separate passwords for every application. From a security perspective, SSO gives organizations a central place to manage authentication and enforce controls such as MFA and conditional access.
Ensuring SSO security depends heavily on credential strength and the enforcement of strong passwords. Specops helps with policy management and continuously blocks over 6 billion unique compromised passwords. Specops Secure Access extends this protection by applying MFA to SAML and OIDC-based applications.
Source: BleepingComputer