SSO reduces password friction, but it does not eliminate every credential type or every application dependency. Teams still need controls for systems that do not support SAML, plus privileged access assets such as certificates and access keys. Without a secondary control plane, those items become unmanaged exceptions with higher exposure.
Why This Matters for Security Teams
Single sign-on simplifies user access, but it does not replace the credential lifecycle behind every system that sits outside the SSO boundary. Organisations still run on API keys, service account secrets, certificates, SSH keys, and legacy applications that cannot speak SAML or modern federation. Those assets often become the real attack path, especially when they are shared, long-lived, or stored outside central identity governance.
That is why password and secret controls remain necessary even in mature SSO environments. The issue is not user convenience alone; it is coverage. Attackers do not need to defeat the login portal if they can harvest a hardcoded token from code, a certificate from a pipeline, or a privileged secret from a collaboration tool. NHIMG has documented how secret sprawl escapes the codebase and lands in operational tooling in the Guide to the Secret Sprawl Challenge, while industry guidance in the OWASP Non-Human Identity Top 10 treats unmanaged secrets as a distinct identity risk. In practice, many security teams discover the exception path only after a token has already been used from an unexpected workload or external system.
How It Works in Practice
SSO should be treated as one control plane, not the entire identity program. The practical model is to use SSO for interactive human access, then layer separate controls for non-interactive credentials that support workloads, privileged operations, and unsupported applications. That usually means inventorying all secret types, assigning ownership, setting rotation and expiry rules, and enforcing storage in a secrets manager rather than in source code, tickets, chat, or CI/CD variables.
For high-risk credentials, the best practice is to reduce standing exposure by issuing short-lived credentials where possible and revoking them automatically when a job completes. NIST control families in NIST SP 800-53 Rev 5 Security and Privacy Controls support access restriction, auditability, and configuration discipline, but they do not remove the operational need to manage secrets themselves. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful here because it reflects the real distinction security teams must make: static secrets remain valid until someone finds them, while dynamic secrets shrink the exposure window.
- Maintain an authoritative inventory of passwords, API keys, certificates, and service tokens.
- Classify each secret by system criticality, privilege level, and rotation feasibility.
- Use separate vaulting, rotation, and monitoring for non-SSO dependencies.
- Detect secrets in code, CI/CD, chat, and ticketing systems before they become reusable access paths.
This guidance tends to break down in legacy environments where embedded credentials are hardcoded into applications, because those systems cannot rotate safely without application refactoring.
Common Variations and Edge Cases
Tighter secret controls often increase operational overhead, requiring organisations to balance faster delivery against stronger credential hygiene. That tradeoff is especially visible in platform teams, mergers, and vendor-heavy estates where SSO coverage is uneven and exceptions proliferate quickly.
Some environments can move most access to federation, but there is no universal standard for eliminating passwords and secrets entirely. Mainframes, vendor portals, break-glass accounts, machine-to-machine integrations, and third-party SaaS connectors may still require standalone credentials. In those cases, the goal is not to pretend the secret is gone, but to make it short-lived, traceable, and owned. NHIMG’s 52 NHI Breaches Analysis shows how often failures cluster around unmanaged identities rather than the SSO front door, and current guidance suggests treating every exception as a governed identity object rather than a convenience artifact.
Organisations should also be cautious about assuming passwordless or SSO-first architectures eliminate the need for secret scanning. They do not. Secrets still appear in build systems, logs, onboarding scripts, and admin workflows, and those leaks often create the exact foothold attackers need to bypass central login controls.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Addresses unmanaged non-human credentials that remain outside SSO coverage. |
| NIST CSF 2.0 | PR.AA-1 | Identity and credential management still applies to non-SSO systems and secrets. |
| NIST SP 800-63 | IAL/Authenticator guidance | Explains why authenticators still need lifecycle control beyond federation. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust still requires explicit control of every access path, including secrets. |
| NIST AI RMF | GOVERN | Operational governance is needed to prevent unmanaged credential exceptions. |
Inventory and govern every non-human credential, including legacy passwords, tokens, and certificates.
Related resources from NHI Mgmt Group
- Which identity controls should organisations prioritise alongside single sign-on to support secure cloud adoption?
- Why do passwords still persist even when organisations know they are risky?
- Why do organisations still struggle with sensitive data exposure even when they have DLP controls in place?
- Why do organisations still accumulate access risk even after they invest in SSO coverage?
