How should this help desk workflow start?

Start with a narrow set of recurring requests, approved answers, named ownership, and a review sample.

What should stay with an owner?

Keep identity, money, security, policy, and unusual technical decisions with named owners until the controls are proven.

Philippines staffing blog · Published October 27, 2026

Triage an SSO Login Loop Without Breaking the Account

A login loop is an identity symptom, not a password problem. Separate the safe checks from the changes only an identity owner may make.

Direct answer

Operational guidance

Recognize the loop before resetting anything

A user who authenticates successfully and is then returned to the sign-in page has usually passed the identity check. The failure sits in the session, the application assignment, the conditional access rule, or a browser state that keeps replaying an old token. Resetting the password is the wrong first move because it changes a credential that was never the problem and adds another variable to the investigation.

Collect the evidence the identity owner needs

Ask for the exact timestamp, the application, the browser or device, whether the loop happens in a private window, and any error code shown after the redirect. Do not ask for the password or a one-time code. A screenshot of the error page is useful if it contains no token or personal data. Record whether the user can reach a different application with the same identity, because that narrows the fault to one app or to the whole session.

Run only the safe local checks

Clearing the site's cookies and cached session for the affected application is a reasonable first step, and it is reversible. Trying a private window tests whether an extension or stale profile is involved. Checking the system clock matters because a skewed device clock can invalidate tokens. Do not ask the user to disable security software, install a certificate, or change a device policy to make the loop stop.

Stop at the assignment boundary

The agent can confirm that the user has an active account and that the application is listed in the catalog. Changing an application assignment, editing a conditional access policy, or bypassing multifactor authentication belongs to the identity owner. Route those requests with the evidence collected, the impact, and the time the user has been blocked. A clear stop is faster than an unauthorized workaround that later has to be undone.

Handle the shared-device case separately

Loops on a shared or loaner device often come from a stale profile or a session that belongs to the previous user. Do not sign the new user into the old profile to save time. Use the approved device reset or a fresh profile, and record the asset. If the device is unmanaged, the identity owner decides whether access is allowed at all.

Close with a verification the user can perform

Ask the user to open the application in the normal browser and complete one ordinary action, then report the result. A successful sign-in is not the same as a working session. Record the verification time and the exact application. If the loop returns, the ticket reopens with the new timestamp rather than starting from the beginning.

Review loops as a pattern

Group login-loop tickets by application, browser, and error code. A cluster after a policy change points to the change owner. A cluster on one application points to its integration. A cluster on one team's devices points to a device or network condition. The review should produce one owner and one next check, not a general reminder to clear cookies.