Because they often survive outside normal identity provider logs and review cycles. Shared credentials, individually owned app passwords, and browser-saved logins can remain active after a role change or departure, which creates revocation gaps and audit blind spots. The risk is not only exposure, but the inability to prove who had access when.
Why This Matters for Security Teams
Non-SSO logins are a governance problem because they sit outside the control plane that most teams rely on for access review, revocation, and audit evidence. When users authenticate directly to applications with local accounts, shared passwords, or stored browser credentials, identity teams lose the normal signals that support joiner, mover, and leaver workflows. That creates a gap between policy on paper and actual access in production.
The issue is not limited to exposure. It is the inability to answer basic questions during an investigation or audit: who authenticated, when access changed, and whether it was revoked promptly. NHI Management Group’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives frames this as a lifecycle and evidence problem, not just a password problem. The NIST Cybersecurity Framework 2.0 also emphasises identity governance, logging, and recovery as operational controls rather than one-time configuration choices.
In practice, many security teams encounter non-SSO access only after a departure, privilege review, or incident has already exposed how incomplete their records were.
How It Works in Practice
Teams reduce this risk by treating every non-SSO exception as a governed identity path, not as a convenience account. That starts with inventory: find every app, API, admin console, and partner portal that authenticates outside the enterprise IdP. Then classify each access path by business owner, credential type, and revocation method. NHI Management Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because the same lifecycle logic applies to human exceptions and to machine identities.
From there, governance usually needs three controls:
- Replace shared credentials with named access wherever the platform supports it.
- Require JIT approval or time-bound access for privileged non-SSO paths.
- Log authentication events centrally, including local logins, password resets, and manual overrides.
For higher-risk systems, best practice is evolving toward forcing non-SSO apps behind brokers, PAM workflows, or federation adapters so access can be reviewed against a single record. That is especially important where the application has its own user store and bypasses enterprise conditional access. The Top 10 NHI Issues research reinforces the broader pattern: the biggest failures are rarely about a single password, but about weak lifecycle control, incomplete visibility, and poor rotation discipline.
Current guidance suggests that non-SSO exceptions should be time-boxed, formally approved, and periodically revalidated against business need. These controls tend to break down in legacy applications with embedded local directories or in partner-facing portals where the application owner cannot export usable audit logs.
Common Variations and Edge Cases
Tighter control over non-SSO access often increases operational overhead, so organisations must balance governance strength against support burden and application constraints.
Legacy systems are the most common exception, especially where federation is impossible or where local accounts are hard-coded into operational workflows. In those environments, current guidance suggests compensating controls rather than pretending the risk does not exist: stricter password policy, separate admin accounts, session recording where possible, and shorter review cycles. Shared vendor logins are another edge case, but they should be treated as temporary exceptions with explicit ownership and expiry.
There is no universal standard for when a non-SSO app must be retired versus wrapped in compensating controls, but the decision should be driven by auditability and revocation speed. NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks and Ultimate Guide to NHIs — Why NHI Security Matters Now both point to the same operational truth: unmanaged credentials persist because nobody owns the cleanup. The strongest programmes shrink the exception set over time, document every remaining bypass, and make non-SSO access visible enough to review like any other privileged path.
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 CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Local and shared logins need rotation and revocation discipline. |
| NIST CSF 2.0 | PR.AC-1 | Non-SSO access paths weaken access enforcement and accountability. |
| NIST CSF 2.0 | DE.CM-8 | Hidden logins create monitoring blind spots and missing audit evidence. |
Inventory non-SSO accounts, shorten credential lifetimes, and automate rotation and deprovisioning.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
