1. Zen IT Technologies
  2. Technical notes
  3. The login path that survived the migration

The login path that survived the migration

Jonny Flaks, Founder & Principal Architect

Technical note in Identity & Access Management

An application was moved to SSO eighteen months ago. Everyone now signs in through the identity provider, the project closed successfully, and the documentation says authentication is centralized.

Then somebody discovers a second login URL that still accepts a password.

The SSO migration worked. It just did not necessarily remove what existed before it.

What federation actually changes

Connecting an application to Okta, Entra ID, JumpCloud or another identity provider usually adds a new authentication path and makes it the normal one. That is not the same as removing every other path.

Local passwords may still exist. Administrator login URLs may bypass the normal SSO screen. API tokens, service accounts and integration credentials may never touch the browser login at all.

The distinction is important: hiding a login path is a usability change. Disabling it is a security change.

A migration can deliver the first while everyone assumes it delivered the second.

What tends to survive

The exact list depends on the application, but the patterns are familiar.

Alternate login URLs. Some platforms keep a separate login page for administrators or emergency access.

Local passwords. Accounts that existed before federation may still have usable credentials unless they were deliberately disabled.

API and personal access tokens. These often continue working independently of browser authentication and may remain valid until explicitly revoked.

Service accounts. They are commonly excluded from SSO for legitimate reasons, then forgotten once the integration is working.

Legacy authentication. Older protocols or clients may authenticate against a credential store that sits outside the SSO flow.

Break-glass accounts. These should exist in some environments, but they should also be controlled, monitored and periodically tested.

None of these is automatically wrong. The problem is not knowing they are there.

Why ordinary access reviews miss this

Access reviews usually answer: Who has access to this application, and what can they do?

They rarely answer: How can this person authenticate?

Two users can have exactly the same role while one is forced through the identity provider and the other still has a working local password.

The identity provider's logs will not tell you about a login path that bypasses the identity provider. If nobody has used that path recently, there may be no obvious evidence that it still exists.

Silence in the SSO logs does not prove the other door is locked.

Exceptions should stay visible

Some alternate authentication is deliberate.

External partners may not belong in your corporate identity provider. A service account may genuinely need non-interactive authentication. A break-glass administrator may need to work when the identity provider is unavailable.

Those are valid exceptions when they are treated as exceptions.

Record who owns them, why they exist and what controls apply. Make sure MFA protects alternate human login paths where the platform supports it. Review the population periodically instead of rediscovering it during an incident.

Test what should no longer work

SSO migration testing usually proves that the new login works. The equally important test is whether the old one still does.

Open a private browser window and try the alternate login page. Test a local credential on an older account. Check whether an old API token still returns data. Verify the break-glass path deliberately rather than assuming it works or does not.

If an alternate path remains available, make a decision: disable it, revoke it, or document it as an intentional exception.

The check worth running

Choose one important application that was federated more than a year ago. Without signing in to the identity provider, try to reach it another way.

Anything that still works is part of your authentication surface until it has been deliberately disabled, revoked or accepted as a controlled exception.

Explore this expertise: Identity & Access Management

All technical notes