Because the attacker paths are different. Web login can rely on browser-bound cryptographic authentication, while voice and shared-device workflows face call interception, helpdesk social engineering, and shared endpoint abuse. Each channel needs its own proof method and fallback design, otherwise a strong web control gives a false sense of coverage.
Why browser login and voice or shared-device channels are not the same control problem
Web login is usually a single-user, browser-bound interaction with stronger assumptions about device possession, session continuity, and cryptographic proof. Voice and shared-device paths are more exposed to channel transfer, human-mediated verification, and ambiguity about who is actually present. That means the control objective shifts from “authenticate the browser session” to “verify the caller or user in a higher-friction, higher-uncertainty context.”
A control that works well in one channel can fail badly in another. Browser-based authentication can lean on device binding, phishing-resistant factors, and session state. Voice and shared-device workflows often need additional proof steps, step-up checks, or constrained fallback options because the channel itself is easier to intercept, imitate, or share.
What changes in the identity proof method and fallback design
The main design difference is that each channel needs its own trust assumptions. In a web flow, the browser and authenticated session can carry much of the assurance. In voice or shared-device workflows, the system often has to decide whether to trust a spoken claim, a call-back, a one-time code, an agent interaction, or a device that may be used by multiple people.
That is why fallback design matters so much. If the fallback path is weaker than the primary web flow, attackers will seek it out. Strong controls only remain strong when account recovery, helpdesk verification, and alternate access paths are designed to the same assurance level as the main login flow.
- Use channel-specific proof methods instead of reusing the web login pattern everywhere.
- Prefer stronger evidence for recovery than for ordinary access, because fallback paths are common abuse targets.
- Treat shared devices as ambiguous environments unless the application can reliably re-establish the user context.
Why voice and shared-device paths create different failure modes
Voice channels add risk because the security decision depends on call handling, speaker context, and the possibility of social engineering. Shared-device channels add risk because the device may retain state, expose sessions to the next user, or blur accountability between people. Both patterns weaken the simple assumption that “the person at the endpoint is the legitimate user.”
For practitioners, the important point is that authentication strength is not just about factor quality. It is also about channel integrity, human process exposure, and whether the device or conversation can be influenced by someone other than the intended user. The answer to “can this user sign in?” may be different from “can this caller or device safely recover access?”
For a broader view of how identity controls need to match the actual access path, NHIMG’s Ultimate Guide to NHIs, What are Non-Human Identities is useful for understanding how proof, access, and lifecycle design change when the access path is not a normal browser session. For lifecycle and offboarding issues that often surface in shared or reused access paths, the NHI Lifecycle Management Guide is a relevant internal reference.
Risk and Threat Considerations
When organisations assume a web login control automatically protects every channel, they create a blind spot. Attackers do not need to break the strongest path if a weaker recovery or voice workflow can be used to bypass it. Shared devices also increase the chance of session confusion, unauthorized continuation, and accidental disclosure through leftover state.
Failure mechanism: The control fails when channel-specific threats, such as call interception, helpdesk impersonation, or shared-session reuse, are treated as equivalent to browser-based authentication. The attacker then targets the weakest alternate path rather than the main login.
Impact: Users may be authenticated in the wrong context, account recovery may become the easiest compromise path, and a single compromised recovery workflow can negate otherwise strong web-login controls.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Covers channel-specific authenticator assurance and phishing-resistant login design. |
| Recommendation — Map each channel to an appropriate assurance level and require stronger proof for fallback access. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Applies to lifecycle and protection of credentials used across web, voice, and fallback channels. |
| IA-2 — Identification and Authentication (Organizational Users) | Relevant because the question is about how users are authenticated differently by access channel. | |
| IA-8 — Identification and Authentication (Non-Organizational Users) | Supports external or customer-facing recovery and access flows that may use voice or shared devices. | |
| Recommendation — Restrict and rotate authenticators used in alternate access paths. Use channel-appropriate user authentication controls instead of one-size-fits-all login logic. Apply stronger proofing for external-user recovery and alternate access paths. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Supports defining access rules that vary by channel and assurance level. |
| A.5.17 — Authentication information | Applies to protecting secrets and verification material used in alternate identity proofing. | |
| Recommendation — Document separate access rules for web, voice, and shared-device channels. Protect recovery secrets and authentication data with tighter handling than ordinary access data. | ||
| OWASP ASVS | V6 — Authentication | Covers authentication design choices that differ by interaction channel and session model. |
| Recommendation — Verify that each login and recovery flow uses an authentication method suited to its channel. | ||
Practitioner Guidance
What to verify: Confirm that each access channel has its own assurance level, recovery method, and escalation path. If voice, SMS, helpdesk, kiosk, or shared-device access can reach the same privileges as the browser flow, the design is too loose.
Decision rule: If the channel cannot reliably bind the user to the session, require stronger step-up verification or restrict what that channel can do. Do not allow a weaker fallback to perform stronger actions than the primary web path.
Common mistake: Reusing the same identity policy everywhere and assuming “MFA” means the same thing in a browser, over the phone, and on a shared endpoint. The channel and the threat model matter as much as the factor.
Practitioner takeaway: The right question is not whether the user was authenticated somewhere, but whether the specific channel can prove the right person or device is acting in the right context.
Related resources from NHI Mgmt Group
- Why do AI-powered browsers require the same identity controls as other web access channels?
- Why do device code flows still need non-human identity controls?
- Why do login-only controls fail for healthcare identity governance?
- Why do browser-based applications need different identity controls than legacy SAML websites?