Verifying users without pre-registration changes help desk identity risk

At a glance

What this is: This is a blog post about verifying users without pre-registration, and its key finding is that help desk identity checks fail when they depend on an earlier enrollment step.

Why it matters: It matters because IAM teams need a verification path for first-time users, contractors, alumni, and lockout cases where the enrolled factor is missing, stolen, or unusable.

By the numbers:

• The ratio of non-human to human identities now exceeds 100:1 in enterprise environments.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Trusona's blog on verifying users without pre-registration

Context

Most identity verification workflows assume the user enrolled something first, whether that is a registered device, an authenticator app, a phone number, or a biometric template. That assumption is comfortable for normal access but it breaks down when the person needing verification is locked out, newly hired, or outside the organisation’s standard onboarding path. In IAM terms, the problem is not authentication strength alone but whether proofing can work when no prior corporate factor exists.

That gap matters because help desk and recovery flows are often where attackers concentrate their social engineering. If a process only verifies people who already enrolled, it leaves a standing population of users who can be claimed by voice, urgency, and exception handling. In practice, identity assurance must cover both the enrolled population and the never-enrolled population, or recovery becomes the weakest point in the access lifecycle.

Key questions

Q: What breaks when identity verification still depends on pre-registration?

A: Recovery fails for the users who need help most, because the system has nothing current to compare against. Help desks then fall back to subjective judgment, which creates an opening for social engineering. The control fails at the exact moment the user cannot present the enrolled factor, so the verification design must account for absent or lost credentials, not just normal login.

Q: Why do organisations need a separate process for never-enrolled users?

A: Because the absence of an enrolled factor is not temporary noise, it is a recurring operational state. New hires, contractors, alumni, and users who never accepted a corporate app all arrive without the same proofing history. A separate process keeps recovery from becoming a guess and gives the service desk a defensible way to verify identity without relying on memory or urgency.

Q: How can security teams verify a caller who has no factor on file?

A: They should use an external authority that already holds a record of the person, such as an issuing agency or carrier validation, rather than trying to inspect a user-managed secret that does not exist. The key is to confirm the record behind the identity claim, then use the result as the basis for recovery or denial.

Q: What should help desk teams do when a caller pressures them for an immediate reset?

A: They should follow a scripted proofing path and refuse to downgrade assurance because the caller is urgent. If the caller cannot satisfy the live verification step, the request should pause and escalate. Speed is not a substitute for identity confidence, especially when the account is being recovered rather than newly authenticated.

Technical breakdown

Why pre-enrolled factors fail in recovery flows

Pre-enrolled factors work because the organisation already holds a secret, a device binding, or a stored biometric to compare against. That design is strong only when the factor still exists and still belongs to the legitimate user. In recovery scenarios, the factor is often missing, replaced, or unreachable, so the verification step becomes a lookup against stale state rather than a live proof of identity. Help desk teams then inherit the burden of deciding who someone is without a reliable reference point, which is exactly when attackers imitate lockout behaviour.

Practical implication: Treat recovery as a distinct assurance workflow, not a retry of normal login controls.

External authority checks and identity proofing

Verification without pre-registration shifts the comparison away from your own directory and toward an authoritative source that already knows the person, such as a government issuing authority or carrier record. The point is not merely to inspect a document, because document inspection can be faked. The stronger check queries a live authority and confirms that the claimed identity has a matching record, while also using session and network signals to detect relay or replay attempts. This changes the trust basis from internal enrollment history to independent record validation.

Practical implication: Use external authority queries when the user has no trustworthy internal factor to present.

Why first interaction is the real test

A true no-pre-registration flow must work on the person’s first interaction, with no app installed, no device registered, and no hidden enrollment artifact already in place. Many products claim to avoid apps while still depending on a previously created factor, which only hides the enrollment step instead of removing it. The operational question is whether the process can verify a user who has never touched your system before, because that is where onboarding, contractor access, alumni support, and emergency recovery converge.

Practical implication: Validate the first-use path explicitly before treating a verification method as enrollment-free.

Threat narrative

Attacker objective: The attacker wants to use social engineering at the recovery layer to regain or reset access without authenticating through the normal enrolled factor path.

1. Entry occurs when the attacker calls the help desk and poses as a locked-out user who lacks access to a registered factor.
2. Credential harvesting follows when the agent is pressured into resetting access or disclosing recovery details without strong proofing.
3. Impact arrives when the attacker obtains account access through the recovery channel and bypasses the intended authentication boundary.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Pre-registration is a hidden assumption in most identity assurance designs. Verification programmes are usually built around an earlier enrollment step, whether that is a device, a passkey, or a stored biometric. That assumption holds for ordinary access but fails when the user has no prior factor, which is common in help desk recovery, contractor onboarding, and legacy user populations. The implication is that identity assurance must be designed around the full lifecycle, not just the happy path.

Never-enrolled users are not an edge case, they are a governance class. Organisations often treat missing enrollment as an exception, but the article correctly shows that the exception is persistent and predictable. First-day employees, alumni, short-term staff, and people who refuse corporate apps all create a standing queue that conventional verification cannot serve. The implication is that access recovery policy should explicitly account for unenrolled identities instead of routing them through brittle workarounds.

External authority verification is a better trust anchor than internal enrollment history. If the organisation does not already hold a reliable factor, the stronger approach is to query an issuing authority that already has an authoritative record. That changes identity proofing from a local memory check into a live assertion about the person’s real-world identity. The implication is that IAM teams should separate proofing authority from internal account state when designing recovery flows.

Recovery is where identity assurance and fraud control converge. The same pressure, urgency, and impersonation tactics that affect service desks in human IAM will later appear in broader identity recovery across contractors, alumni, and other external populations. The lesson is not limited to one vendor or one flow: if the process cannot verify a never-enrolled person, the attacker has already found the control boundary. The implication is that help desk policy, fraud checks, and identity governance need one shared recovery model.

From our research:

• The ratio of non-human to human identities now exceeds 100:1 in enterprise environments, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how often identity programmes still lose track of non-human actors.
• That visibility gap is why teams should pair recovery governance with 52 NHI Breaches Analysis when they want to understand how identity failures compound under pressure.

What this signals

Never-enrolled identity recovery is a governance problem, not a convenience feature. When a recovery path depends on prior enrollment, the organisation has implicitly decided who is easy to verify and who is not. That distinction becomes operational debt as the workforce changes, especially where contractors, alumni, and transient staff sit outside standard onboarding rhythm. Teams should map those populations explicitly before they turn into recurring exception queues.

Pre-registration assumptions create hidden blast radius in service desk operations. A caller who cannot satisfy the normal proofing flow often ends up in a manual exception lane, and that is where social engineering pressure concentrates. The identity programme needs a separate control plane for those calls, with defined authority sources and clear escalation thresholds. For broader context on where identity failure patterns repeat, see Ultimate Guide to NHIs.

Recovery design should be tested against the first interaction, not the tenth. A process that only works after a user has already enrolled something is not solving the never-enrolled problem. The practical signal to watch is whether frontline teams can verify a person who has no prior record in the system and no app on a managed device. That is the boundary that separates real identity proofing from a brittle workflow.

For practitioners

• Define a never-enrolled recovery path Separate first-time verification from routine MFA recovery so the help desk does not improvise under pressure. Document which populations can arrive without a registered device, app, or biometric and route them into a distinct assurance workflow.
• Require live external authority checks Use an issuing authority or carrier validation when no trustworthy internal factor exists. Avoid relying on document inspection alone, because visual document checks do not prove the record behind the credential.
• Remove hidden enrollment dependencies Review every no-app or no-download claim for a concealed prerequisite such as a stored phone number, prior session, or registered factor. If the first interaction still depends on something the user created earlier, the flow is not truly enrollment-free.
• Tighten help desk verification scripts Give agents a short, non-negotiable script for lockout calls so urgency does not collapse the proofing standard. Include escalation thresholds for callers who cannot produce a live authority match or whose story depends on immediate reset pressure.

Key takeaways

• Most identity recovery processes still assume a prior enrollment step, and that assumption fails for the users who arrive with nothing on file.
• The real risk is not only friction but social engineering, because attackers exploit the same lockout narrative that legitimate users use.
• IAM teams need a distinct never-enrolled verification path based on authoritative external checks, not improvised help desk judgment.

Key terms

• Pre-Registration Verification: A verification method that confirms a person’s identity without requiring them to have enrolled a device, app, biometric, or security question in advance. The check depends on an authoritative external source rather than on a factor the organisation previously issued.
• Identity proofing: The process of verifying that a person is who they claim to be before granting or restoring access. In higher-risk recovery paths, proofing can include stronger evidence checks such as government ID validation or liveness-based facial verification so the assurance level matches the sensitivity of the request.
• Never-Enrolled User: A user who can legitimately need access but has no usable pre-existing factor in the organisation’s environment. This includes first-day employees, contractors, alumni, and people whose device or number changed, making standard recovery workflows insufficient.
• Authority-Based Verification: A verification approach that checks a person against the institution that issued the underlying identity record, such as a state agency or carrier. It is stronger than visual document inspection because it validates the record behind the credential, not just the credential’s appearance.

What's in the full article

Trusona's full blog covers the operational detail this post intentionally leaves for the source:

• The live call flow for verifying a person with no pre-registered factor, including how the session begins and ends.
• The distinction between document inspection and authoritative record verification, including what the agent actually sees.
• Operational handling for cases where the user has no smartphone, no app, or no internal record at all.
• The retention and deletion model for session data after verification completes.

👉 The full Trusona post covers the live verification flow, authority checks, and recovery edge cases.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.