How should organisations handle users without a registered authenticator?

Why a fallback path has to prove identity, not just recognise absence

When a user has no registered authenticator, the real problem is not convenience, it is assurance. The organisation must still decide whether the person at the point of action is the rightful user, then bind that decision to a controlled step-up path. If the fallback simply bypasses authentication, it turns an enrollment gap into an account takeover opportunity.

A sound fallback path usually combines stronger identity evidence with tighter approval rules, for example verified help-desk recovery, supervised re-enrollment, or in-person or equivalent high-assurance checks. The key is that the fallback must be treated as a security control, not an exception queue. That is why the quality of recovery matters as much as the primary sign-in method, as discussed in Workforce Identity Security Guide.

Organisations also need to distinguish between temporary recovery and permanent state. A one-time exception for a lost device is very different from a user who has never completed enrollment, because the latter often exposes deeper lifecycle or governance issues. That distinction affects whether the control owner should approve access, force enrollment, or block the request until stronger evidence is produced.

How to design the recovery path so it does not become an ad hoc bypass

The safest pattern is to define a small number of approved recovery routes in advance, each with a known assurance level and an explicit escalation path. One route might require a verified manager approval plus out-of-band identity proofing, while another might require a supervised reset followed by immediate authenticator registration. This is closer to a controlled recovery workflow than a user support shortcut, and it aligns with NIST SP 800-63 Digital Identity Guidelines.

Good design also means the fallback should end in a durable fix, not repeated temporary access. If the user remains without a registered authenticator after recovery, the organisation is carrying forward the same exposure into the next request. The process should therefore force enrollment, document the reason for the gap, and require revalidation before the next privileged or sensitive action.

For higher-risk systems, the fallback should be paired with step-up controls that are materially stronger than normal access. That may include reduced entitlements, shorter session duration, transaction approval, or human review before any sensitive action is completed. The point is to preserve business continuity without normalising weak assurance.

What happens when organisations treat missing authenticators as an exception

Missing authenticators become dangerous when support teams improvise. Attackers often target recovery channels because those paths can be easier to socially engineer than the main sign-in flow. If the help desk, supervisor, or workflow approver accepts weak evidence, the fallback path becomes the easiest route into the account rather than the safest way back out of lockout.

This is especially problematic where the fallback can unlock privileged or high-impact actions. In that case, the recovery step is effectively an access grant, so weak proofing creates the same exposure as a compromised login. Organisations should expect pressure to make exceptions for VIPs, urgent work, or operational deadlines, and they should predefine what evidence is required before any exception is granted.

Recovery risk is also cumulative. A weak reset process, a long-lived temporary token, or an unreviewed manual approval can create a second control failure even when the original sign-in policy was sound. The practical lesson is to review exception rates, recovery outcomes, and enrollment backlog, not just MFA adoption metrics.

Practitioner Guidance

What to prioritise: Treat “no registered authenticator” as a recovery and assurance problem, not a support convenience problem. The first decision is whether the user can be positively re-verified at the point of action; if not, the request should stop until stronger evidence is available.

What to verify: Check that every approved fallback path has an owner, a defined evidence standard, and a mandatory end state, usually authenticator enrollment or re-enrollment. If the process allows repeated use without closing the gap, it is not a fallback control, it is an alternate bypass.

Decision rule: If the user is requesting access to sensitive data, privileged functions, or recovery of an already suspicious account, require the strongest available verification path and a shorter-lived, lower-privilege outcome. If the request is low risk, a lighter recovery route may be acceptable, but only if it still proves identity and is logged for review.

Common mistake: Allowing the help desk or application owner to invent “one-off” exceptions under pressure. That shortcut usually transfers the risk to the least constrained part of the organisation, where evidence, auditability, and approval quality are weakest.

Practitioner takeaway: The right fallback path is one that restores access while narrowing trust, limiting privilege, and forcing closure of the authenticator gap as quickly as possible.

Related resources from NHI Mgmt Group

• How should security teams handle help desk requests when users do not have a registered authenticator?
• How should organisations handle digit specific password prompts without creating extra login friction for users?
• How should organisations handle requests to correct inaccurate personal data without creating unnecessary friction for users?
• How should organisations handle identity verification when deepfakes can mimic real users?