Passwordless adoption reveals a question problem, not a data one

At a glance

What this is: This is RSA Security’s argument that passwordless adoption stalls less from missing technology than from teams asking the wrong questions of identity telemetry.

Why it matters: It matters because IAM teams across human, NHI, and autonomous programmes need to turn raw identity signals into decisions that expose where trust fails in practice.

By the numbers:

• 92% of organizations are implementing passwordless.
• Only 7% have gone completely passwordless.

👉 Read RSA Security's analysis of passwordless adoption and identity telemetry

Context

Passwordless adoption is a governance and measurement problem as much as an authentication problem. The article argues that identity platforms already produce enough telemetry, but most teams stop at reporting instead of using those signals to explain where trust breaks down and why users fall back to weaker paths.

For IAM and identity architects, the operational question is not whether passwordless can be deployed, but whether it works across every workflow, exception path, and recovery journey. That makes telemetry quality, exception handling, and recovery design central to the programme, not side issues.

Key questions

Q: How should security teams improve passwordless adoption without adding more friction?

A: Start by measuring where the secure path breaks in real workflows, not just where passwordless is enabled. Focus on fallback triggers, recovery paths, device exceptions, and application-specific failures. If users repeatedly encounter blocked journeys, they will choose the easiest option, which is often the least secure one. The goal is to remove friction from the secure path, not to force users through it.

Q: Why do passwordless programmes stall even when deployment rates are high?

A: They stall when teams confuse deployment with usable coverage. A system can be enabled for most users and still fail in the edge cases, exceptions, and recovery flows that matter most. Adoption lags when the secure option is not consistently available across the environments people actually work in. That is a governance and journey-design problem, not a protocol problem.

Q: What do security teams get wrong about identity telemetry?

A: They often use telemetry to report outcomes instead of to explain failure. Authentication events, failure counts, and usage trends only become valuable when they answer a concrete question about trust, recovery, or workflow breakage. Without that interrogation, telemetry becomes a compliance artefact rather than a driver of change.

Q: How do you know if passwordless is actually working?

A: You know it is working when users can complete every common access and recovery journey without reverting to passwords. Look for consistent success across devices, locations, and applications, and check whether support tickets or fallback usage are declining. If recovery is still easier than login, passwordless is only partially working.

Background and context

Why passwordless telemetry often fails to explain adoption gaps

Passwordless programmes usually generate large volumes of authentication data, but volume is not the same as insight. Teams often track whether passwordless is enabled, while missing where users encounter fallback paths, workflow breaks, or recovery steps that reintroduce passwords. The result is a misleading picture of coverage. Identity telemetry becomes useful only when it is interrogated for failure patterns, not just consumed for audit trails. In practice, the gap is often in the questions, not the data pipeline. Practical implication: measure where secure paths break in live workflows, not just where they are configured.

Practical implication: measure where secure paths break in live workflows, not just where they are configured.

Recovery flows and helpdesk paths are where trust often collapses

The article shifts from login to recovery because attackers often bypass strong authentication by exploiting human and service workflows around it. Recovery, account reset, and helpdesk verification become alternate trust channels that can be easier to subvert than the primary sign-in flow. That is why a passwordless programme can still leak risk even when login itself is hardened. The technical issue is not only authentication strength, but whether the surrounding identity journey preserves the same assurance level. Practical implication: treat recovery and support workflows as part of the authentication control surface.

Practical implication: treat recovery and support workflows as part of the authentication control surface.

Why continuous trust depends on all-environment consistency

Passwordless fails when it is strong in one context but unreliable in another. If a user can authenticate securely in one environment yet is forced back to passwords in a different device, location, or exception case, the programme creates friction that undermines adoption. This is a design and coverage issue, not a user preference issue. The identity journey has to behave consistently across the places people actually work, or the secure path loses credibility. Practical implication: validate passwordless success rates across every environment, then close the exception paths that force fallback.

Practical implication: validate passwordless success rates across every environment, then close the exception paths that force fallback.

NHI Mgmt Group analysis

The passwordless gap is really a question-design gap. The article’s core point is that identity data already exists in most enterprises, but teams ask reporting questions instead of operational questions. That means they see deployment status, not trust failure. The practitioner lesson is that programme maturity depends on interrogating the journey, not merely counting enabled users.

Recovery is the hidden trust boundary in passwordless programmes. Login hardening does not eliminate risk if account recovery, helpdesk verification, or exception handling provide easier paths around the secure channel. That is where adversaries and frustrated users both drift. The practical conclusion is that passwordless governance must treat recovery as a first-class identity control surface.

Recovery-path integrity: the real failure mode is when secure login is strong but adjacent access recovery is weaker and easier to abuse. That concept is grounded in the article’s shift from authentication telemetry to recovery telemetry, which is where the trust model breaks in practice. Teams should stop assuming passwordless success at the point of sign-in and assess whether recovery paths preserve equivalent assurance.

Passwordless adoption is constrained by exception management, not just platform capability. The article makes clear that users retreat to passwords when the secure path fails them in real workflows. That is a governance issue because exceptions become the de facto control. Practitioners need to measure whether their exception paths are shrinking or silently becoming the dominant access route.

Identity telemetry only has value when it changes decisions. Compliance-grade reporting can show what happened, but it does not explain why a programme stalls or where users lose trust. The discipline shift is from visibility to interrogation, which is relevant well beyond passwordless. Practitioners should make telemetry answer a decision, not just generate a dashboard.

From our research:

• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• The same governance lesson applies to identity recovery paths, as covered in Top 10 NHI Issues, where exception handling and delayed revocation create lingering exposure.

What this signals

Recovery-path integrity is becoming a useful way to think about any identity programme that looks secure on paper but leaks trust through adjacent workflows. The practical test is simple: if the secure path fails, does the fallback preserve the same assurance level, or does it become the easiest way around control?

For teams managing human IAM, NHI, and autonomous access together, the lesson is to stop treating telemetry as an after-the-fact report. Identity data should show where trust degrades, which workflows create avoidance, and which exceptions have become normalised.

This is where broader identity governance matures: the programme stops asking whether controls exist and starts asking whether they still hold under real-world pressure. That shift matters most when exception paths, recovery routes, and support processes become the de facto authentication layer.

For practitioners

• Map passwordless failure points across the full identity journey Track where users are forced to fall back from passwordless into passwords, including device changes, application exceptions, browser limitations, and recovery workflows. Prioritise the points where secure access is available in theory but unavailable in practice.
• Instrument recovery and helpdesk workflows as identity controls Review account reset, verification, and support escalation paths with the same assurance expectations you apply to primary authentication. If recovery is easier than login, the programme has created a weaker trust boundary outside the main control.
• Use telemetry to answer one operational question at a time Replace generic reporting with targeted questions such as where users fail, which workflows trigger fallback, and which exceptions drive the most password reuse. This turns identity telemetry into a remediation input rather than a compliance artefact.
• Validate success rates across every environment Test passwordless in the real combinations of device, location, application, and user population that your workforce actually uses. A control that works in one environment but breaks in another will not sustain adoption.

Key takeaways

• Passwordless adoption often stalls because teams inspect identity data instead of asking better operational questions about where trust fails.
• Recovery, helpdesk, and exception workflows are part of the authentication control surface, so they must be governed with the same assurance standard as login.
• A passwordless programme is only real when users can complete every common access journey without falling back to weaker paths.

Key terms

• Passwordless adoption: Passwordless adoption is the operational process of replacing password-based sign-in with stronger authenticators such as passkeys or device-bound credentials. In practice, it is not complete when a feature is enabled. It is complete only when users can reliably use the secure path across their real workflows, environments, and recovery journeys.
• Identity telemetry: Identity telemetry is the event data generated by authentication, access, recovery, and account activity. It becomes useful when teams interrogate it for patterns that explain trust failure, workflow friction, and fallback behaviour. Raw telemetry alone does not improve security. The value comes from turning signals into decisions.
• Recovery workflow: A recovery workflow is the set of steps used to regain access when a user cannot complete primary authentication. These paths often include helpdesk checks, reset actions, and alternate verification methods. They are part of the identity control surface because attackers and users alike may prefer them when they are easier than the main login path.

Deepen your knowledge

Passwordless adoption, recovery-path assurance, and identity telemetry interrogation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to turn authentication signals into governance action, the course maps well to that challenge.

This post draws on content published by RSA Security: Passwordless You Don’t Have an Identity Data Problem. You Have a Question Problem. Read the original.