They should map the applications that sit outside SSO and quantify how many credentials still depend on local logons. If a meaningful share of the estate bypasses federation, password management remains necessary for governance, offboarding, and secure sharing.
Why This Matters for Security Teams
sso coverage is only meaningful for the applications that actually sit behind the federation layer. The operational risk comes from the shadow estate: legacy apps, admin portals, partner systems, service consoles, and shared accounts that still rely on local logons or static secrets. If teams assume “SSO means done,” they usually miss the credentials that matter most during offboarding, incident response, and privileged access reviews.
That gap is especially visible in non-human identity governance. NHI Management Group notes that Ultimate Guide to NHIs reports only 5.7% of organisations have full visibility into their service accounts, which is a warning sign for any team trying to declare identity coverage complete. Current guidance also aligns with the NIST Cybersecurity Framework 2.0, which treats asset and identity visibility as a prerequisite for control effectiveness, not a box to tick after the fact. In practice, many security teams discover the real access surface only after a termination, breach, or audit forces a manual inventory.
How It Works in Practice
The right sequence is to inventory where authentication is federated, where it is not, and which identities remain outside the SSO boundary. That means mapping applications, service accounts, local admin users, API keys, and break-glass credentials that bypass central identity controls. For NHI-heavy environments, the goal is not just “how many apps support SSO,” but “how many credentials still depend on local logons, static tokens, or manually managed secrets.”
Teams should then classify those gaps by risk and operational dependency. High-risk examples include shared admin accounts, CI/CD credentials, third-party integrations, and old systems that cannot support modern federation. This is where Ultimate Guide to NHIs is useful as a governance reference: it frames discovery, rotation, and offboarding as lifecycle controls, not one-time projects. If a credential can outlive the application owner, it needs a defined owner, rotation policy, and revocation path.
- Build an application inventory that separates SSO-enabled from non-SSO access paths.
- Count local accounts, service credentials, API keys, and shared logins that remain active.
- Identify where offboarding still depends on manual revocation or password resets.
- Use the results to decide whether password management, secrets management, or both are still required.
That assessment should also inform privileged access management and incident playbooks, because credentials outside SSO often become the fastest path to lateral movement. Controls tend to break down in environments with legacy authentication, embedded device access, or third-party systems that cannot participate in federation because the access path never enters the SSO control plane.
Common Variations and Edge Cases
Tighter SSO enforcement often increases operational overhead, requiring organisations to balance user convenience against coverage gaps and legacy constraints. There is no universal standard for this yet, so current guidance suggests treating SSO as a coverage metric, not proof of identity maturity. A team may have strong federation for employees and still need password management for vendors, contractors, service accounts, and machine-to-machine access.
The edge cases are usually the most important ones. Shared mailboxes, jump boxes, on-prem applications, industrial systems, and emergency access accounts can sit outside SSO by design. In those cases, the question is not whether SSO exists, but whether the residual authentication method is governed: are passwords vaulted, are secrets rotated, and are offboarding steps tested? The NHI risk picture is often worse than teams expect, especially when credentials are stored outside secrets managers or copied into scripts and config files.
For security leaders, the practical test is simple: if SSO were unavailable tomorrow, which credentials would still grant access, and who could revoke them? If that answer is unclear, the estate is not yet at a point where SSO coverage alone can replace password governance.
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 |
|---|---|---|
| NIST CSF 2.0 | ID.AM | Identity and asset inventory is required before judging SSO coverage. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Discovery of non-human identities is needed to find credentials outside SSO. |
| NIST AI RMF | AI governance analogously requires visibility into residual access paths and dependencies. |
Inventory federated and non-federated identities, then track residual local logons as unmanaged access.
