The main signal is a login method that appears after the app has been moved to SSO, especially when older password based access should no longer be in use. Teams should look for orphan accounts, repeated password logins to SAML integrated apps, and any new login type that differs from the expected identity provider or authentication flow.
What to look for when SSO migration is incomplete
Recently onboarded SSO apps should show one dominant login path: the identity provider redirect, assertion, or token flow that replaced the old password prompt. When password based access is still active, the clearest evidence is a second path that should have been retired but continues to succeed, especially for users who were supposed to be cut over fully.
That usually shows up in sign-in logs, help desk resets, or admin reports as a mix of SSO and legacy authentication for the same application. If the app is genuinely enforced through SSO, password logins should become rare or disappear quickly. Persistent password activity suggests a coverage gap, a misconfigured federation setting, or a subset of accounts that never moved to the new flow.
Orphan or stale accounts matter because they often bypass the clean migration story. If an account still authenticates with a local password after the app was onboarded to SSO, that account may not be tied to the expected identity lifecycle and may never have been migrated, reviewed, or decommissioned properly. Ultimate Guide to NHIs — Key Challenges and Risks is useful background on the broader visibility and lifecycle gaps that tend to create exactly this kind of leftover access.
Operational clues that password access is still live
The most practical clue is a login record that does not match the expected identity provider journey. If the app was moved to SSO, any successful direct password login, basic auth event, or legacy web session is a signal worth investigating. Repeated password logins on a SAML integrated app are especially important because they often indicate that the federation path exists, but enforcement was not completed everywhere.
Watch for account-level inconsistencies as well. One user may authenticate through SSO while another user in the same app still signs in locally. That split often means the app supports both methods and the migration only changed the default path, not the only path. A newly onboarded app can also retain a fallback password option for emergency access, which becomes a problem if the team cannot prove who uses it, when it is used, and whether it is truly restricted.
- Direct username and password success against an app that should redirect to the identity provider.
- Mixed login methods for the same application after cutover.
- Local accounts that were never linked to the expected SSO directory or identity source.
- Login activity from accounts that should have been disabled, merged, or recertified during migration.
For a broader set of real failure patterns, 52 NHI Breaches Analysis and OWASP Non-Human Identity Top 10 both reinforce the same operational lesson: lingering alternate access paths are where control assumptions break down.
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 MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secret and Credential Sprawl | Legacy password logins after SSO cutover indicate lingering credential paths. |
| NHI-02 — Identity Lifecycle and Offboarding | Orphan accounts and unmigrated users show incomplete identity lifecycle handling. | |
| Recommendation — Remove retained password paths and rotate or revoke any leftover credentials. Reconcile, disable, or federate any accounts not moved into the SSO flow. | ||
| CIS Controls v8 | 5.3 — Disable Dormant Accounts | Stale or orphan accounts can keep local password access alive after onboarding. |
| 6.3 — Access Rights Management | Mixed login methods often reveal access that was never fully re-scoped during migration. | |
| Recommendation — Disable inactive or orphaned accounts that still authenticate outside SSO. Review application access and remove any legacy local-auth entitlements. | ||
| NIST CSF 2.0 | PR.AC-1 — Identities and Credentials Issued, Managed, Verified, Revoked, and Audited | Password logins after SSO onboarding show credentials are not fully governed. |
| DE.CM-8 — Activity of External Service Providers Monitored | Unexpected login methods need monitoring to confirm the new access model is enforced. | |
| Recommendation — Verify and revoke any credentials that still bypass the expected SSO path. Monitor authentication events for legacy login patterns after SSO migration. | ||
| NIST SP 800-63 | IAL/AAL Federation Sections — Federation and Authenticator Assurance Guidance | SSO cutovers depend on federated authentication assurance and correct authenticator use. |
| Recommendation — Confirm federated authentication is the only accepted path for the onboarded app. | ||
| NIST Zero Trust (SP 800-207) | Policy Enforcement and Access Decision — Zero Trust Policy Enforcement | Multiple login paths weaken the intended access decision point after SSO rollout. |
| Recommendation — Enforce a single policy decision path for application authentication. | ||
Practitioner Guidance
What to verify: Confirm whether the application is actually enforcing SSO at the authentication boundary, not just presenting SSO as the preferred route. The key test is simple: if a password still works, the old path is still live, regardless of what the rollout documentation says.
What to prioritise: Investigate any successful password login after cutover before you spend time on edge cases. Then check whether the account is expected, whether the app has a fallback auth mode, and whether the account was meant to be deprovisioned or federated during onboarding.
What good looks like: After migration, authentication telemetry should converge on one expected flow, with legacy password success dropping to zero or to a tightly controlled exception pattern that has explicit ownership and review.
Practitioner takeaway: The strongest sign of incomplete SSO adoption is not just that password login is possible, but that it still succeeds where the organisation believes it has already been removed; treat that as a migration control failure, not a user convenience issue.
Related resources from NHI Mgmt Group
- What are the signs that password based access is no longer sufficient for distributed workforces?
- Why do shadow IT apps create identity risk even when users still have valid SSO access?
- What are the signs that password-based access is creating avoidable operational and security problems?
- What are the signs that a Keycloak based SSO setup is misconfigured in a password management environment?
