What breaks when access sits outside SSO and the IdP cannot govern it?

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.

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?