What happens when a passwordless authentication request expires before it is approved?

When a request expires, the login attempt cannot complete through that request record and the user must start again. The short 15 minute lifetime limits exposure if a request is left unattended, but it also means users need a timely approval path. Expiration is a safety control, not a permanent failure condition.

What changes when a passwordless request expires

Once the request times out, the relying login flow no longer has a valid approval record to complete against. That means the user cannot be authenticated through that expired request, even if someone approves it later. The practical effect is simple: the login has to be restarted, and the user must generate a new request.

The expiry window is doing real security work. It limits how long an unattended approval prompt or token can sit open, which reduces the chance that a stale request is approved too late or abused out of context. The trade-off is operational: the shorter the lifetime, the more important timely human or automated approval becomes.

A short-lived request also helps prevent ambiguous state. If the user has already moved on, switched devices, or changed context, the expired record ensures the system does not treat an old challenge as still trustworthy. In passwordless flows, that expiration boundary is part of the control, not a failure of the technology.

Why expiration matters for approval and user experience

Expiration is most useful when the approval path is predictable and fast. If the approver, authenticator, or notification channel is delayed, the user experiences a retry even though the underlying identity is valid. In other words, the control protects the login session, but it also imposes a timing requirement on the surrounding workflow.

That timing requirement becomes more visible in high-friction environments, such as when users depend on a second device, a push notification, or a manual approval step. If the approval arrives after the record expires, the system should fail closed and force a fresh attempt rather than keep a long-open challenge alive.

For practitioners, the important distinction is between rejected and expired. A rejected request can often be diagnosed as an explicit denial. An expired request usually means the window closed before the approval path completed, so the next action is to reinitiate the login, not to investigate a permanent account problem.

Risk and Threat Considerations

Short request lifetimes reduce the chance that a stale authentication challenge remains usable, which is a meaningful safety property in passwordless systems. The main risk is not that expiration breaks security, but that poor timing or notification delays turn a control into user friction or repeated retries.

Failure mechanism: The request times out before approval, so the authentication server discards that transaction and refuses to complete the login on an expired record. If approvals are habitually delayed, users may start compensating by retrying too often or treating the control as unreliable.

Impact: The session cannot be established from that request, the user must start a new login, and the organisation may see more abandoned attempts, help desk contacts, or pressure to lengthen the timeout. A longer timeout can improve usability, but it also increases the exposure window for an unattended prompt.

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 address the attack and risk surface, while NIST SP 800-63 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	Passwordless request expiry governs short-lived authentication material and stale approval exposure.
	NHI-03 — Lifecycle and Rotation	The question is about expiry and re-initiation of a login request lifecycle.
Recommendation — Enforce short-lived, tightly scoped credentials and expire unused authentication requests quickly. Define clear lifetimes and require a fresh request once the original authentication window closes.
NIST SP 800-63	AAL — Authenticator Assurance Level	Passwordless approval flows depend on authenticated, time-bound authenticator use and transaction validity.
Recommendation — Set authenticator requirements so expired authentication transactions cannot be reused.
CIS Controls v8	6 — Access Control Management	Timed login requests are an access-control condition that should fail closed when they expire.
Recommendation — Configure access workflows to invalidate expired authentication requests and force reauthentication.

Practitioner Guidance

What to verify: Confirm that the timeout is long enough for normal approval latency but short enough to close stale requests promptly. If a significant share of users regularly hit expiry, the issue is usually workflow latency or notification reliability, not the authentication method itself.

Decision rule: If the request has expired, treat the login as invalid and start a fresh challenge rather than trying to salvage the old one. If approvals routinely arrive late, fix the approval path first, then revisit the timeout only if the workflow cannot be made reliably faster.

Common mistake: Extending the lifetime too far to reduce user complaints. That can weaken the control by leaving more time for unattended prompts, delayed approvals, or stale context to persist.

Practitioner takeaway: The right balance is a request window that is short enough to limit exposure, but long enough that normal users can complete approval without forcing constant retries.