Access that relies on shared logins, individual application passwords, browser-stored credentials, or other direct secrets rather than federated single sign-on. In governance terms, it often sits outside identity provider logs, so teams must discover it through vault, browser, and application telemetry.
Expanded Definition
Non-Sso Access is access granted through direct credentials rather than federated identity. That can include shared logins, application-specific passwords, browser-saved secrets, embedded API keys, or service credentials that never pass through a central identity provider. In practice, it often exists because a system was onboarded before SSO was available, a legacy application does not support federation, or a team chose speed over governance.
For NHI security, the important distinction is not simply whether a human typed a password. The question is whether the access path is centrally observable, policy-governed, and revocable through identity controls. Compared with SSO, non-SSO access is harder to enumerate, harder to rotate, and easier to miss in audit evidence. It is one reason the OWASP Non-Human Identity Top 10 treats secret handling and lifecycle control as core risks, not peripheral hygiene. Definitions vary across vendors when browser-stored secrets or shared app passwords are described as “convenience access,” but in governance terms they remain direct secrets.
The most common misapplication is treating non-SSO access as an exception that can be ignored once the application is in production, which occurs when teams fail to inventory every direct credential path.
Examples and Use Cases
Implementing control over non-SSO access rigorously often introduces migration friction, requiring organisations to weigh faster rollout against the cost of weaker visibility and more manual revocation.
- A legacy payroll application uses a shared administrator login because it cannot integrate with federation, so access must be monitored through vault and application logs.
- A CI/CD pipeline stores deploy credentials in a browser profile or local keychain, creating a direct secret path outside the IdP audit trail.
- A third-party support portal is accessed with individual passwords because SSO is not enabled, forcing teams to track joiner-mover-leaver changes manually.
- A service account authenticates with a static token stored in a config file, which is operationally convenient but difficult to rotate safely.
- An engineering team uses a shared break-glass login for a vendor console, and the credential must be protected like any other NHI secret.
These patterns are repeatedly visible in NHIMG research on the Ultimate Guide to NHIs, especially where secret sprawl and lifecycle gaps create hidden access paths. The same governance issue appears in implementation guidance from the OWASP Non-Human Identity Top 10: if the credential is direct, it needs inventory, ownership, rotation, and revocation.
Why It Matters in NHI Security
Non-SSO access matters because it weakens the two things security teams need most for NHIs: visibility and control. A credential that bypasses the identity provider can evade normal access reviews, leave no clean authentication trail, and persist after the original owner has changed roles or left the organisation. That creates a governance gap even when the application itself appears stable.
NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, a signal that direct-credential access is commonly undercounted rather than fully managed. The risk compounds when direct secrets are stored in code, browsers, or unmanaged local files, because compromise of one endpoint can expose multiple downstream systems. For broader identity architecture, the zero-trust expectation in NIST SP 800-207 Zero Trust Architecture is especially relevant: access decisions should remain explicit and continuously assessable, even when federation is not possible.
Organisations typically encounter the full impact only after a leaked secret, stale shared login, or failed offboarding event exposes an application they assumed was already under IdP control, at which point non-SSO access becomes operationally unavoidable to address.
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 Zero Trust (SP 800-207) 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-02 | Direct secrets and hidden access paths fall under secret management and visibility risks. |
| NIST Zero Trust (SP 800-207) | AC-2 | Non-SSO access bypasses centralized identity enforcement and continuous verification expectations. |
| NIST CSF 2.0 | PR.AC-1 | Access to assets should be managed through controlled identities, not ad hoc shared secrets. |
Bring direct credential access under explicit policy, logging, and least-privilege enforcement.
