Pending sessions mean the user has authenticated but still owes a required step such as MFA setup, password reset, or organisation selection. Expired sessions mean the authentication state is gone and the user must re-establish it. Treating those conditions the same creates broken redirects, lost context, and avoidable support friction.
How pending sessions differ from expired sessions in mobile flows
Pending sessions are not finished yet, so the app should preserve the authenticated state while guiding the user to complete the missing step. Expired sessions are finished from the server’s point of view, so the app must stop assuming continuity and force a clean re-authentication path. The handling difference is really about state management, not just user messaging.
That distinction matters because a pending session still has context worth preserving, such as the original destination, chosen tenant, or partially completed enrollment flow. If the app discards that context too early, users end up repeating steps they already completed. If the app preserves context after expiry, it may send users into screens that no longer have a valid security context.
Where mobile apps usually get the session boundary wrong
The most common mistake is treating both states as a generic “not usable” outcome. That collapses two different recovery paths into one and creates brittle navigation logic. A pending session should usually continue the flow that created it, while an expired session should typically restart login and then restore only the safe, still-relevant context.
This is especially important when the app can return the user to a specific app state after authentication. The redirect target, selected organisation, or partially completed setup should be restored only when the app still has a valid authenticated context to attach it to. Otherwise, the app can create loops, confusing error states, or a false sense that access was granted when it was not.
For broader mobile hardening, teams often combine session handling with testing for state transitions, token storage, and redirect behaviour in a Mobile App Security Testing Guide. That matters because the bug is usually not the login screen itself, but the transition between login, recovery, and return-to-app states.
Why state preservation and re-authentication need different rules
A pending session usually indicates an in-progress but still meaningful identity transaction. The user has already proven something, and the app is waiting for completion of a required control such as MFA setup, password reset, or tenancy selection. The app should therefore preserve enough context to let the user finish, while still enforcing the missing step before granting full access.
An expired session is different because the authentication state is no longer reliable. At that point, the app should assume the prior session cannot be resumed and should require the user to establish a new one. That protects against stale state, replayed navigation, and accidental access to content that was only intended for the prior authenticated window.
Session handling is also closely tied to secure storage and token lifecycle decisions in mobile environments. The Mobile App Security Guide is useful where teams need to think through how app state, token handling, and platform storage choices affect whether a user can be safely resumed or must sign in again.
How to design the user journey so failures stay understandable
The clean design pattern is to separate “resumeable” from “expired” at the routing layer, not only in the UI text. A pending session should route the user back into the same control point that is waiting for completion. An expired session should route the user to authentication first, then to the original destination only after the new session is established.
That separation also reduces support friction because users can tell whether they need to complete a step or re-enter credentials. It is a small difference in implementation, but it has a large effect on perceived reliability. The app feels coherent when each state has a distinct next action instead of a catch-all error page.
Where teams want to validate that the app can handle redirect, token, and state transitions safely, they often pair this work with the Mobile App Security Guide and Mobile App Security Testing Guide. Both support the practical question of whether the app can recover state without accidentally treating an invalid session as still active.
Risk and Threat Considerations
When pending and expired sessions are conflated, the main risk is not only user frustration but also state confusion that can weaken access control assumptions. A stale or misrouted session can produce broken redirects, repeated login loops, or an incorrect continuation path after authentication has actually lapsed.
Failure mechanism: The application reuses the same recovery logic for two different security states, so it either preserves too much context after expiry or discards too much context during an in-progress session. That can lead to invalid navigation, session confusion, and accidental exposure of pre-authenticated workflow state.
Impact: Users lose trust in the app flow, support volume rises, and the product becomes more likely to mishandle authentication boundaries in edge cases. In security terms, the bigger problem is that the app may continue to make assumptions about identity state after that state has already changed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V7 — Session Management | Pending vs expired session handling is a session-management boundary question. |
| V10 — OAuth and OIDC | Mobile redirect and resume flows often depend on federated authentication state and return handling. | |
| Recommendation — Separate resumable session state from expired state and enforce re-authentication when the session is no longer valid. Validate return-flow handling so an expired authentication state cannot be mistaken for a valid continuation. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The answer hinges on session continuity, expiration, and re-establishing authentication state. |
| AC-12 — Session Termination | Expired sessions must stop being treated as active and must require a fresh login path. | |
| Recommendation — Manage authenticator and session lifecycle so expired authentication cannot be reused. Terminate stale sessions and require a new authentication process before restoring access. | ||
Practitioner Guidance
What to verify: Test the exact transition points where a user can be mid-flow, then leave and return after the session expires. Confirm that the app preserves only the context that is still safe to reuse, and that it never resumes access without a fresh authentication event when the session is expired.
Decision rule: If the user still has a valid pending state, keep the flow and prompt for the missing completion step; if the authentication state is gone, discard the session continuation and force a clean sign-in path. That decision should be explicit in the app logic, not inferred from generic error handling.
Practitioner takeaway: Treat pending sessions as incomplete journeys and expired sessions as dead sessions, because good mobile UX depends on preserving the right context for the former and refusing to trust any of it for the latter.
Related resources from NHI Mgmt Group
- Why do mobile apps create different trust problems than standard web applications?
- Why do mobile apps create different security assumptions than server-side systems?
- Why do native mobile apps need a different OAuth approach than server rendered applications?
- Why do native mobile apps need stricter redirect URI handling than web apps?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org