Non-Sso Access

What Non-Sso Access Means in Practice

Non-Sso access is any direct login path that bypasses federated single sign-on, which means the user or application authenticates with a shared password, individual app password, stored browser credential, or another direct secret. That makes the access path more fragmented, less visible to central identity controls, and harder to govern consistently.

Because these access paths often live outside the normal SSO control plane, they can persist even when the main identity system is well managed. The practical question is not just whether users can sign in, but whether the organisation can inventory, monitor, and retire every direct secret that still grants access.

Why Non-Sso Access Exists

Non-Sso access usually appears where older applications cannot federate, where service workflows still depend on static credentials, or where teams have chosen convenience over integration. It is common in legacy systems, small SaaS tools, shared admin portals, build tooling, and emergency access paths that were never fully migrated into SSO.

It can also emerge as a workaround. A browser-saved password, a shared application account, or a vendor login that sits outside the primary identity provider may feel operationally harmless until no one can answer who owns it, who last used it, or whether it still needs to exist.

How Non-Sso Access Becomes Hard to Govern

Non-Sso access fragments policy enforcement because the identity provider is no longer the only place where authentication happens. That creates blind spots in logging, recertification, and offboarding, especially when access depends on passwords or tokens that are never centrally inventoried.

It also weakens accountability. When several people share one login, or when an application stores a reusable secret locally, the organisation loses clean linkage between a person, a session, and an action. In practice, that makes access review, incident investigation, and privilege reduction much harder to do with confidence.

A useful governance lens is to treat non-federated access as a separate population of credentials and sessions that must be explicitly discovered, reviewed, and retired. NHIMG’s Access Control Policy Template helps structure that ownership and review model, while the IAM and Identity Provider Buyer’s Guide frames how SSO, lifecycle, and access management choices fit together.

What Good Coverage Looks Like

Good coverage starts with knowing where non-Sso access exists. That means combining application inventory with evidence from vaults, browser-stored secrets, login telemetry, and admin portals so the team can distinguish intentional exceptions from accidental sprawl.

It also means deciding which direct logins are truly justified. Some systems may need temporary exceptions, but long-term reliance on direct secrets should be the exception rather than the default. Where possible, replace shared logins with federated authentication, shorten secret lifetime, and make ownership explicit.

For teams securing the surrounding identity layer, NHIMG’s Identity Provider and SSO Security Guide explains the controls that reduce the need for direct access paths, and the Workforce Identity Security Guide covers the adjacent controls that often fail when direct logins remain in use.

Detection and Response Considerations

Detection is harder for non-Sso access because the relevant events may be scattered across app logs, browser telemetry, vault audit trails, and help-desk records rather than concentrated in one identity platform. That means an organisation can miss reuse, shadow admin access, or stale credentials even when its central SSO monitoring looks healthy.

Response should focus on what the access path actually depends on. If a shared login or application password is suspected to be exposed, the priority is to invalidate the secret, review recent use, and identify every account, session, and downstream application that relied on it. This is especially important when the secret was used for federation-adjacent access, because token theft or credential reuse can let an attacker bypass the normal front door entirely.

For a broader view of token and federated-access compromise patterns, NHIMG’s Salesloft OAuth token breach and Klue OAuth Supply Chain Breach show how access material can be abused outside the main SSO experience.

Risk and Threat Considerations

Non-Sso access raises the likelihood of secret sprawl, weak ownership, and hidden privilege because the access path is often invisible to the systems that centralise sign-in control. Shared credentials and browser-saved secrets are especially attractive to attackers because they can be reused, copied, or quietly persisted after a user leaves.

Failure mechanism: A direct secret is reused, stolen, shared, or left active after offboarding, allowing access that does not pass through the main identity provider and may escape normal logging or conditional controls.

Impact: Attackers can gain durable access to applications, data, or admin functions, while defenders lose the clean audit trail needed for investigation, containment, and accountability.

Practitioner Guidance

Why practitioners should care: Treat non-Sso access as a governance gap, not just a legacy inconvenience. If an application or team still depends on direct secrets, it needs explicit ownership, review cadence, and retirement criteria so the exception does not become permanent by default.

What to watch for: Pay special attention to shared logins, browser-stored passwords, long-lived app secrets, and systems that are absent from identity-provider reporting. Those are the places where access tends to survive beyond user changes, role changes, and offboarding.

Practitioner takeaway: The objective is not to eliminate every exception immediately, but to make every non-federated access path visible, attributable, and time-bounded until it can be replaced.

Related resources from NHI Mgmt Group

• Why does non-SSO access create a governance gap for identity teams?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• How should security teams decide whether JIT access is safe for non-human identities?