An SSO gap is any application or workflow that still requires direct credentials even though the organisation has deployed single sign-on elsewhere. These gaps matter because they create unmanaged access paths that must still be governed, audited, and revoked.
Expanded Definition
An SSO gap is not just a missed login convenience, but a separate authentication path that bypasses the organisation’s primary identity plane. In NHI and IAM programs, this usually means an application, script, batch job, legacy portal, or partner workflow still depends on direct usernames, passwords, API keys, or certificates even after single sign-on has been rolled out elsewhere. That distinction matters because SSO centralises control only for the systems that are actually integrated.
Definitions vary across vendors when SSO is extended into machine access, federated identity, or passwordless login, but the operational meaning is stable: if a workflow still needs direct credentials, it remains outside the SSO governance boundary. For identity teams, that boundary should be explicit and mapped to lifecycle controls, revocation, and audit logging. The control lens here aligns well with the NIST Cybersecurity Framework 2.0, especially where access control and asset visibility intersect.
The most common misapplication is treating “SSO deployed” as proof that all access is federated, which occurs when legacy applications, service accounts, or break-glass workflows are excluded from the rollout scope.
Examples and Use Cases
Implementing SSO rigorously often introduces migration overhead and dependency cleanup, requiring organisations to weigh user simplicity against the cost of refactoring older workflows and federating every access path.
- A finance application still uses a shared local password because its vendor does not support federation, creating a direct-credential exception that must be tracked separately.
- A CI/CD pipeline authenticates to cloud services with a long-lived API key, even though employees access the pipeline console through SSO, leaving the machine path outside the identity provider.
- A legacy administrative console allows only username and password login, so administrators must manage a parallel credential store and revocation process.
- A partner portal supports SSO for employees but not for external contractors, forcing a mixed access model that requires explicit governance and periodic review.
NHI governance guidance in the Ultimate Guide to NHIs is especially relevant here because SSO gaps often conceal service accounts and API keys that teams forget to inventory. For identity federation patterns, the NIST Cybersecurity Framework 2.0 remains a practical anchor for visibility and access oversight.
Why It Matters in NHI Security
SSO gaps are high-risk because they create alternate control planes for secrets, access reviews, and revocation. Once a direct credential exists, it becomes another object that can leak, persist, or be over-privileged outside the main identity governance process. That is especially dangerous in NHI environments, where access often belongs to machines, jobs, automations, and agents rather than employees.
NHI Mgmt Group reports that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, and that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. Those numbers show why an SSO rollout cannot be treated as complete until the direct-credential tail is identified and governed. The same issue is amplified in environments where SSO coverage exists for people but not for tools, pipelines, or embedded applications, leaving revocation and audit trails fragmented. The broader risk picture is documented in the Ultimate Guide to NHIs.
Organisations typically encounter the consequences only after a credential leak, account compromise, or failed offboarding event, at which point the SSO gap 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 CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Direct credentials outside SSO are secret-management risk under NHI guidance. |
| NIST CSF 2.0 | PR.AC-1 | Access is only controlled when all authentication paths are governed. |
| NIST Zero Trust (SP 800-207) | Zero Trust assumes every access path is explicitly authenticated and authorized. | |
| NIST SP 800-63 | IAL2 | Identity assurance breaks when alternate credentials bypass centralized identity proofing. |
Inventory every non-SSO credential path and move it into governed secret lifecycle control.
