Teams often mistake central login for complete control coverage. In reality, SSO does not automatically govern local application accounts, service identities, or privilege assigned outside the identity provider. The most common mistake is assuming one authentication path means one governance model, when the two are not the same.
Why This Matters for Security Teams
SSO is often treated as proof that access is governed end to end, but it usually only covers one front door. Service accounts, API keys, local application users, and privilege granted directly in the application can all sit outside the identity provider’s control plane. That gap matters because attackers rarely stop at the login page. Once they find unmanaged access paths, they move laterally through the parts of the stack SSO never touched. NIST’s NIST Cybersecurity Framework 2.0 is clear that identity governance has to cover access outcomes, not just authentication events.
NHIMG research shows why this is still a live problem: 96% of organisations store secrets outside secrets managers in code, config files, and CI/CD tools, and 97% of NHIs carry excessive privileges. That means “SSO coverage” can look strong on paper while the real blast radius remains broad and poorly inventoried. In practice, many security teams discover the missing controls only after a service account is abused or a local admin path is found in production, rather than through intentional coverage design.
How It Works in Practice
Effective SSO coverage starts by separating authentication from governance. SSO answers who can log in through the central provider, but it does not automatically answer who can operate inside each application, who can assume privileged roles, or which machine identities can bypass the human login flow altogether. Teams need a coverage model that inventories all access paths and assigns an owner to each one.
Current best practice is to map every application and workload to one of three buckets:
- Federated access, where the IdP enforces the primary login and the app trusts assertions from that provider.
- Local or legacy access, where the application maintains its own users, roles, or break-glass accounts.
- Non-human access, where service identities, tokens, certificates, and automation credentials authenticate independently of SSO.
Once those paths are identified, security teams can decide what should be federated, what should be decommissioned, and what must be governed with separate controls such as secrets rotation, PAM, JIT elevation, or workload identity. The key operational point is that SSO coverage should be measured by effective control over access paths, not by the percentage of users that successfully authenticate through the IdP. The NHIMG Ultimate Guide to NHIs documents how often organisations miss this distinction, especially where service accounts and long-lived secrets remain outside identity governance. Teams should also watch for direct privilege assignment in cloud consoles and admin panels, because those grants can persist even when SSO is fully deployed. These controls tend to break down in hybrid estates with legacy applications, embedded service accounts, and developer-managed credentials because the authoritative identity source is fragmented across platforms.
Common Variations and Edge Cases
Tighter SSO enforcement often improves visibility but increases operational overhead, so teams have to balance central control against application compatibility and recovery needs. That tradeoff is especially visible in older environments where federation is not supported, vendor portals require separate local accounts, or break-glass access must remain outside the normal SSO path.
There is no universal standard for what counts as “full” SSO coverage, so guidance is still evolving. Some organisations measure only workforce applications, while others include service portals, cloud consoles, and admin workflows. The right answer depends on whether the control objective is user convenience, access review simplification, or reduction of standing privilege. For non-human identities, the bar should be higher: credentials, tokens, and API keys need separate governance even if the human operator logs in through SSO. NHIMG’s Azure Key Vault privilege escalation exposure illustrates how privilege can expand outside the login model when secret and role boundaries are not reviewed together. Organisations that rely on SSO metrics alone often overstate coverage in environments with SaaS integrations, CI/CD automation, and shared admin accounts, because the user directory looks clean while the actual privilege surface remains untouched.
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 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 | SSO misses unmanaged service identities and secrets outside IdP control. |
| NIST CSF 2.0 | PR.AC-1 | Identity management must cover access pathways, not just central authentication. |
| NIST AI RMF | GOVERN | Coverage questions hinge on accountable governance across all identity types. |
Define ownership for every access path, including local accounts and machine identities.
