They break because the destination provider often cannot trust the old session token without explicit translation. Different signing keys, different issuers, and different claim rules mean the new system has no native basis for accepting the legacy login. That mismatch forces reauthentication unless the migration layer bridges the gap.
Why IdP changeovers break active sessions
Active sessions usually fail during an IdP changeover because the new provider cannot safely accept the old session state as its own. Session continuity depends on trust in the original issuer, token format, signing keys, audience rules, and claim semantics. When those differ, the legacy login is no longer portable, so the user must authenticate again.
What actually changes during the cutover
An IdP session is not just a login event, it is a trust decision anchored in a specific signing chain and set of validation rules. If the old IdP issued the session cookie, SAML assertion, or OIDC token, the new IdP must either understand that artifact or receive a deliberate translation layer. Without that bridge, the destination system treats the session as foreign state rather than a valid continuation.
The practical problem is that migration often changes more than the logo on the login page. It can change issuer identifiers, key material, token lifetimes, subject formats, group mappings, step-up policy, and which applications are allowed to trust which assertions. Even a technically successful migration can still force reauthentication if the application caches the old provider’s trust context.
Why session persistence is harder than it looks
Session persistence across IdPs is fragile because authentication is only one part of the contract. The application also depends on token validation rules, renewal behaviour, and local session assumptions. If the old and new IdPs do not align on those details, the user may look “logged in” at one layer while the app refuses the session at another.
That is why migrations often expose hidden dependencies such as hardcoded issuer checks, stale metadata, old certificates, or claims that no longer map cleanly. A clean cutover requires explicit trust transition, not just account migration. In many environments, the safest outcome is a planned reauthentication window rather than silent acceptance of ambiguous legacy sessions.
Risk and Threat Considerations
Session continuity failures are not only a usability issue. If teams try to preserve old sessions too aggressively, they can weaken issuer validation, extend token acceptance beyond the intended trust boundary, or create inconsistent behaviour across applications and browsers.
Failure mechanism: The migration layer may over-trust legacy tokens, reuse stale signing metadata, or accept claims that were valid under the source IdP but are not valid under the destination IdP’s policy. That can create broken authentication flows, session fixation-style confusion, or unintended access persistence during the changeover.
Impact: The usual consequence is forced reauthentication and user disruption, but the higher-risk outcome is partial trust overlap where some applications accept old sessions while others reject them. That inconsistency can hide access failures, complicate incident investigation, and widen the window for misuse if old sessions remain valid longer than intended. For background on the control problem, see Identity Provider and SSO Security Guide.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST SP 800-57 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | IdP changeovers directly affect how users are reauthenticated after trust changes. |
| IA-5 — Authenticator Management | Session continuity depends on rotation and handling of signing keys and related authenticators. | |
| IA-9 — Service Identification and Authentication | Applications and services must trust the new IdP’s tokens and assertions correctly. | |
| Recommendation — Require reauthentication where issuer trust or session validation changes. Rotate and validate authenticators during IdP migration. Re-establish service-to-service trust before allowing legacy sessions. | ||
| NIST SP 800-57 | Key Management | Signing key lifecycle and rotation are central when old sessions rely on prior token signing keys. |
| Recommendation — Retire old signing keys only after trust transition is complete. | ||
Practitioner Guidance
What to verify: Before cutover, confirm which applications validate issuer, audience, signing key, and claim schema locally versus through the IdP. Those differences determine whether sessions can survive the change or must be reissued.
Implementation sequence: Preserve both trust paths only as long as needed, translate where the session model is compatible, and plan a hard reauthentication boundary where it is not. Session continuity should be engineered per application, not assumed at the directory level.
Common mistake: Treating account migration and session migration as the same problem. User identity may move cleanly while session trust still breaks because the validation context did not move with it.
Practitioner takeaway: The safest IdP changeover is the one that explicitly defines which sessions are portable, which must be reissued, and where trust must be reset rather than guessed.