How should security teams handle users who never enrolled a verification app?

They should test whether the recovery flow can authenticate a user with no prior registration at all. If the product still depends on a pre-enrolled passkey, authenticator, or device, those users will fall back to the help desk. The control is only useful when it covers the unenrolled population, not just the easy majority.

Why This Matters for Security Teams

Users who never enrolled a verification app expose a simple but important test: whether recovery is truly identity proofing, or just a shortcut for people already inside the happy path. If the flow assumes a pre-enrolled authenticator, it will fail exactly when a user has lost access, changed devices, or never completed setup. That is when help desk pressure rises and attackers look for social engineering opportunities. NIST Cybersecurity Framework 2.0 frames this as a governance and recovery issue, not just an authentication issue.

For non-human identity programs, the same pattern appears in a different form. NHI Mgmt Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which shows how often identity recovery and lifecycle control are treated as edge cases rather than core controls. The practical lesson is that every access path must be designed for the unenrolled, the unregistered, and the recently disrupted user. In practice, many security teams discover this only after the help desk has already become the de facto identity authority.

How It Works in Practice

The right approach is to separate account recovery from device recovery. A user who never enrolled a verification app should be able to prove identity through an alternative, policy-approved method that does not depend on a prior app registration. That often means a layered process: knowledge-independent checks, verified email or phone channels where appropriate, document-based proofing, help-desk escalation with strong controls, or supervised re-enrollment after step-up validation. The key is that the recovery path must start from the user’s current state, not from a prior assumption that a verifier already exists.

Security teams should define recovery as a risk-based workflow with clear thresholds. Stronger flows are needed for high-value accounts, privileged users, and admin identities. Current guidance suggests avoiding single-channel recovery for sensitive populations because SIM swap, mailbox compromise, and help-desk impersonation are all well-established attack paths. The NIST identity guidance is useful here, because it distinguishes proofing, authentication, and account recovery as separate controls rather than one merged process. For teams managing machine identities, the same principle shows up in lifecycle control: Ultimate Guide to NHIs highlights how weak revocation and rotation create persistent access problems long after an identity should have been retired.

• Offer at least one recovery path that does not depend on a previously enrolled verification app.
• Use step-up verification for higher-risk accounts instead of a one-size-fits-all reset flow.
• Log every recovery action, including who approved it, what evidence was used, and what was restored.
• Re-enroll the user into stronger authentication after recovery, not as a substitute for recovery.

For implementation details, teams can align the workflow with the NIST Cybersecurity Framework 2.0 and treat recovery as an access control decision with monitoring, escalation, and audit trails. These controls tend to break down in outsourced or high-volume service-desk environments because the pressure to restore access quickly can override proofing discipline.

Common Variations and Edge Cases

Tighter recovery controls often increase friction and support cost, so organisations must balance user experience against account takeover risk. That tradeoff is unavoidable, especially where workforce turnover is high or device churn is frequent. Best practice is evolving, but there is no universal standard for this yet, which means the control set should be calibrated to account sensitivity rather than applied uniformly.

Some environments require special handling. Contractors may never have enrolled an internal authenticator because they were issued a limited-access account. Executives may need an alternate path that is fast but heavily supervised. Shared service accounts should not use human-style recovery at all; they need formal owner-based reset and revocation procedures. For identity programs with significant NHI overlap, the same operational lesson applies: lifecycle completeness matters as much as enrollment completeness, and unmanaged exceptions become permanent exposure. The broader risk picture is consistent with NHI Mgmt Group research showing that 96% of organisations store secrets outside of secrets managers in vulnerable locations, which demonstrates how often controls fail when the secure path is optional rather than mandatory.

Related resources from NHI Mgmt Group

• How should security teams decide whether JIT access is safe for non-human identities?
• How should security teams handle SaaS offboarding when users also use AI tools?
• How should security teams handle identity verification when background checks are automated with AI?
• How should security teams handle identity verification in high-risk video calls?