Treat them as part of the identity programme, not as informal exceptions. Build an inventory of direct-login apps, shared accounts, and browser-observed usage, then attach ownership, rotation, and offboarding rules to each one. If an account cannot be discovered, assigned, and revoked, it is not governable and should be treated as a control gap.
Why This Matters for Security Teams
Credentials that sit outside SSO are not a minor usability issue. They are usually the places where discovery breaks, ownership becomes unclear, and offboarding falls back to manual memory. That is exactly why they belong in the identity programme, with the same attention given to lifecycle, monitoring, and revocation. NHI Management Group research has repeatedly highlighted how secret sprawl turns routine exceptions into persistent exposure, especially when teams lose track of where credentials live and who can still use them through direct-login paths, shared accounts, or embedded tokens.
The risk is amplified when those credentials are used by scripts, integrations, service accounts, or browser-accessed tools that never pass through the corporate SSO layer. In those cases, the control question is not whether a login is convenient, but whether the credential can be discovered, attributed, rotated, and revoked with confidence. Current guidance from the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both point toward governance, visibility, and lifecycle control rather than treating these accounts as one-off exceptions. In practice, many security teams encounter stale direct-login access only after an audit, incident, or offboarding failure has already exposed the gap.
How It Works in Practice
Governance starts by inventorying every credential path that bypasses SSO, then classifying each one by business owner, technical owner, system type, privilege level, and rotation requirement. That inventory should include shared admin logins, legacy SaaS accounts, partner portals, machine-created credentials, and browser-observed usage where the system is accessed interactively but not federated. The goal is not just to know that a credential exists, but to know whether it can be tied to an accountable owner and a defined lifecycle.
Once discovered, each credential should be assigned one of a few enforcement patterns:
- Federate it into SSO where possible.
- Wrap it with Privileged Access Management where direct login cannot yet be removed.
- Issue short-lived access or just-in-time credentials where the platform supports it.
- Rotate and revoke on a defined schedule where federation is impossible.
The main operational shift is to treat these credentials as governed identity objects, not as static configuration items. That means ownership must be explicit, access reviews must be scheduled, and offboarding must include direct-login systems, not only SSO directories. For machine and application credentials, the preferred direction is dynamic or ephemeral secret delivery, because static secrets create a long-lived blast radius when they are copied into scripts or shared across teams. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets and Guide to the Secret Sprawl Challenge are useful references for understanding why secret visibility and rotation discipline matter more than naming conventions.
For organisations with mature controls, this also means aligning the inventory to policy-as-code checks, ticketed exceptions, and automated revocation triggers tied to termination, role change, or inactivity. These controls tend to break down in legacy environments where shared credentials are embedded in operational tooling, because no single team owns the full path from discovery to revocation.
Common Variations and Edge Cases
Tighter governance often increases operational friction, requiring organisations to balance faster access for teams against the overhead of maintaining clean ownership and rotation. That tradeoff is real, especially in older platforms, third-party portals, and customer-managed systems where federation is not available and vendor support for modern identity controls is limited.
Best practice is evolving, but there is no universal standard for handling every non-SSO credential pattern yet. Some environments can move directly to federation, while others need a phased approach that starts with discovery, then adds monitoring, then enforces rotation, and finally removes the credential altogether. This is where the strongest programmes distinguish between acceptable temporary exceptions and permanent blind spots. A credential that cannot be discovered, attributed, or revoked should be treated as a control gap, not a tolerated workaround.
In high-risk environments, prioritise the credentials that can touch production systems, data exports, CI/CD, or admin consoles. The threat pattern is often not the login itself, but what that login can reach once it is used. NHIMG’s Top 10 NHI Issues shows why over-privileged and poorly governed identities remain recurring failure points, while the State of Non-Human Identity Security report underscores the visibility gap that makes this problem hard to contain. In short, the exception is not the credential outside SSO; the exception is assuming it will manage itself.
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 and CSA MAESTRO address the attack and risk surface, while 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 | Direct-login and shared credentials need rotation and lifecycle control. |
| NIST CSF 2.0 | PR.AC-1 | Credentials outside SSO still require access management and accountability. |
| CSA MAESTRO | MAESTRO supports governing agent and workload credentials across lifecycle stages. |
Apply lifecycle governance to all non-SSO identities, including service and agent credentials.
