VPN MFA Request Rejected: What the Client Should Do

A rejected MFA prompt looks like a network problem and is not one. The server asked for a second factor, the factor came back negative or never arrived, and the session was refused before any tunnel existed. What happens next is a client behaviour question: surface the failure and let the user start a clean attempt, or retry in ways that generate more prompts and eventually trip account protection. The second path is how one mistyped code becomes a locked account.

Check which request failed

Start by identifying which request failed. A push notification, a TOTP code, a FIDO assertion and a SAML flow each fail differently, and the client usually knows which one it asked for. A denial, an expired challenge and a delivery failure that never reached the device all end in the same generic error, so the client's own state is often the only place the difference survives.

That state is worth logging precisely. Record the challenge identifier or transaction reference, the factor type, the timestamp and the outcome, but never the code or the assertion. A challenge identifier is what lets an administrator find the event on the identity provider's side; without it, the support conversation starts with "sometime in the last hour" and usually ends there. Treat it as diagnostic metadata, not as a secret.

Retry once, deliberately, with a new challenge

A retry should be a new attempt with a new challenge, not a replay of the old one. When the client reuses the previous challenge, the identity provider either rejects it as stale or, worse, accepts an approval that was meant for the earlier attempt. Request a fresh challenge, show it, and let the user act on the one currently on screen.

Two attempts with a short pause between them is a reasonable default; an unbounded loop is not. If the second attempt fails the same way, stop and report rather than continuing.

What the client must not do

The client must not do several things that look helpful and are not. It must not keep re-sending push notifications until someone taps approve, because that trains users to approve prompts they did not initiate and is exactly the behaviour phishing kits rely on. It must not fall back to a weaker factor because the strong one failed, and it must not disable the server-identity check to get past a certificate complaint that appeared at the same time. Those three shortcuts each turn an authentication failure into a security incident.

It also must not silently swallow the failure. A client that closes the connection and shows a spinner leaves the user with no idea whether to retry, wait or call support. Surface the failure with the factor type and a short code, keep the message free of secrets, and make the retry action explicit rather than automatic.

If the request was not initiated by the person at the keyboard, the correct action is to leave it rejected and report it through the verified support path. Approving a prompt to stop the noise is the failure mode, not the fix.

What to record for support

For support, the useful record is small. The approximate time with the time zone, the account, the client and version, the factor type, and the non-secret status of each attempt: asked, denied, timed out, approved but rejected by policy.

Keep the client and server clocks in view as well. TOTP is a time-window check, so a device whose clock has drifted produces valid-looking codes that fail every time, and a client that reports an invalid code without noting the drift sends people to reset credentials that were never wrong. A user whose login fails repeatedly should check the supported client version, the enrollment state and the documented recovery flow before generating more prompts.

The recovery path deserves the same care as the login path. A lost-device workflow exists precisely so that a rejection does not become permission to bypass authentication, and a client should link to the organisation's documented process rather than improvising one.

The rule to build against is that rejection is a result, not an obstacle. Report it once, clearly, with enough context to act on, and let the next attempt be a new one. CISA's guidance on phishing-resistant MFA explains why the prompt-until-approval pattern is dangerous in the first place, and it is the reference worth citing when someone proposes a retry loop. Everything the client adds after a rejection should make the next decision easier for a human, not remove the decision from them.