When access sits outside SSO, the identity provider no longer has authority over the full lifecycle of the account. That breaks ownership, review and offboarding because the application may still accept local credentials after central policy changes. The result is a parallel access plane that security teams can neither reliably certify nor revoke.
When access sits outside SSO, what actually stops being governed?
Once an application accepts local login or other side-door access, the IdP is no longer the single place where access is created, changed, reviewed, and removed. That means policy can be updated in SSO while the application still preserves an independent way in. The security problem is not just convenience, it is that identity control has split into two authorities.
The most important break is lifecycle control. If the local account can still authenticate after central deprovisioning, the IdP can no longer guarantee joiner-mover-leaver outcomes across the whole access path. Ownership becomes ambiguous, access reviews become incomplete, and offboarding becomes a best-effort process instead of a reliable revocation event.
That is why “outside SSO” usually creates a parallel control plane rather than a simple backup login. The application is now enforcing its own access model, often with its own password store, reset flow, or recovery logic. Security teams then have to reconcile two sources of truth, and the weaker one tends to survive longer than intended.
Why local access breaks review, certification, and offboarding
When access is bound to SSO, reviewers can usually validate entitlement from the IdP, group membership, or federation policy. When local credentials exist, that evidence no longer tells the full story. A clean SSO record can coexist with an active local account, so certification becomes partial and revocation can miss the exact account that still matters.
This is also where Identity Provider and SSO Security Guide is directly relevant, because the core control boundary is the trust relationship between the IdP and the application. If the app accepts local credentials, the federation boundary is no longer the whole access boundary, and governance has to account for both paths.
The same issue shows up in offboarding. Disabling the central identity does not necessarily disable the local one, especially where the application allows password resets, break-glass logins, or stale tokens. That leaves a residual account path that may remain usable long after a person has changed role or left the organisation.
Workforce Identity Security Guide is useful here because it reflects the practical reality that joiner-mover-leaver controls only work when provisioning and deprovisioning cover the full access surface, not just the central directory. If one system can still authenticate on its own, the offboarding control is incomplete by definition.
What the residual access path means for security operations
A local access plane creates real operational drag. Security teams must inventory which systems still permit native credentials, determine whether those accounts are human or service accounts, and decide who owns resets, approvals, and periodic review. Without that mapping, the organisation cannot prove that an access removal event actually removed access.
The risk also extends beyond routine administration because a parallel login path broadens the blast radius of identity compromise. If an attacker learns or steals the local credential, central SSO policy changes may not stop them immediately. That is especially dangerous when the local path uses weaker authentication, longer-lived secrets, or weaker audit visibility than the federated path.
OpenID Connect Core 1.0 is a good reference point for the intended model, because it assumes the IdP is the issuer of trust for sign-in. If an application bypasses that model for part of its population, the trust boundary fragments and the organisation loses one of the main benefits of centralized governance.
Where local access cannot be removed immediately, the application needs compensating controls such as explicit ownership, periodic access review, strong recovery governance, and a defined retirement plan for the local path. Otherwise, the organisation is left certifying an access state it does not fully control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Local access outside SSO weakens centralized user authentication control. |
| IA-5 — Authenticator Management | Residual local credentials create lifecycle and revocation risk outside the IdP. | |
| AC-2 — Account Management | Accounts outside SSO break complete provisioning, review, and offboarding coverage. | |
| Recommendation — Centralize user authentication so deprovisioning and access reviews remain authoritative. Track, rotate, and revoke all authenticators that can still grant access. Maintain one governed account inventory and disable noncompliant local accounts. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Parallel local access paths undermine coherent access control governance. |
| A.5.16 — Identity management | The question is about losing identity authority over the full account lifecycle. | |
| A.8.5 — Secure authentication | Local credentials outside SSO expand authentication risk and weaken assurance. | |
| Recommendation — Enforce a single access-control model for each application and remove unmanaged paths. Make identity records authoritative for creation, review, and revocation. Require strong authentication only through governed sign-in paths. | ||
| CIS Controls v8 | CIS-5 — Account Management | Parallel access planes are an account governance failure with review and offboarding impact. |
| Recommendation — Inventory accounts and remove any login path that bypasses governance. | ||
| OWASP ASVS | V8 — Authorization | Non-SSO access can bypass centrally enforced authorization expectations. |
| Recommendation — Verify that every access path enforces the same authorization decision model. | ||
Practitioner Guidance
What to verify: Confirm whether the application still permits local password login, local recovery, or alternate administrator access after SSO is enabled. If it does, treat those paths as first-class access surfaces, not exceptions hidden in the implementation details.
Decision rule: If central deprovisioning does not reliably disable every authentication path, the access model is not centrally governable yet. In that case, shorten the exception window, assign an owner for the residual path, and remove the local mechanism on a defined timeline.
What good looks like: The IdP should be the authoritative control point for enrollment, review, and revocation, with no surviving local login that can outlive a central access decision. If a fallback path must exist, it should be tightly controlled, monitored, and intentionally temporary.
Practitioner takeaway: The real test is not whether SSO exists, but whether a single deprovisioning action fully removes access. If it does not, you have an access exception that must be governed as a separate risk until it is eliminated.
Related resources from NHI Mgmt Group
- What breaks when IGA software cannot govern applications outside SSO and federation?
- What breaks when AI agent access sits outside SSO and PAM coverage?
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern API keys used for generative AI access?