Why does using the same device for both authentication factors increase risk in Strong Customer Authentication?

Using the same device or communication channel for both factors weakens the protection that multi-factor authentication is meant to provide. If a phone or channel is compromised, both the authentication prompt and the verification code can be exposed to the attacker. Strong authentication depends on independence between factors, so teams should avoid designs where one compromised channel can satisfy both checks.

Why shared-device authentication breaks factor independence

strong customer authentication is not just about having two checks, it is about keeping those checks meaningfully separate. When the same phone, browser session, or message channel can deliver both factors, the design collapses into a single point of compromise. A stolen or hijacked device can then satisfy both steps, which removes much of the resistance MFA is supposed to add.

The practical problem is factor correlation. If one device receives the prompt and also receives the code, push approval, or one-time password, the attacker only needs control of that one endpoint or channel. That weakens the “something you have” test because the possession factor and the verification flow are no longer independently protected.

This is why phishing-resistant approaches and separated recovery paths matter. A stronger design keeps the authenticator, the approval channel, and the protected session from all depending on the same compromised endpoint, so the loss of one device does not automatically expose every factor involved in the login.

How attackers turn one compromised device into a full bypass

When the same device handles both factors, attackers can exploit malware, SIM swap, session hijacking, notification interception, or relay attacks to capture both the request and the response. That is especially dangerous when the code or approval is presented on the same screen where the user is expected to trust the sign-in flow.

In practice, this means a single successful compromise can defeat the intended layered defense. For example, an attacker who controls the phone may read SMS codes, intercept push prompts, approve a fraudulent request, or redirect a login flow through a cloned browser session. The risk is not just code theft, it is the collapse of separation between authentication steps.

For a broader control perspective, NIST guidance on digital identity places weight on authenticators that resist phishing and channel interception, and on assurance that the authentication event is not vulnerable to replay or relay. The same principle is reflected in NIST SP 800-63 Digital Identity Guidelines, which is why device-bound or phishing-resistant methods are preferred over shared-channel OTP patterns.

Practitioners can also see the attack pattern in real breach reporting, where MFA is bypassed through fatigue, theft, or channel abuse rather than brute-force guessing. The key lesson is that “having MFA” is not enough if both factors can be satisfied through the same compromised control point.

What good Strong Customer Authentication looks like in practice

Good SCA separates the factors in a way that survives one device compromise. That can mean using a phishing-resistant authenticator, binding the login to a trusted hardware-backed credential, or ensuring the approval path cannot be used to approve the same session from which it was initiated. The point is to preserve independence, not merely to increase the number of prompts.

In customer environments, the strongest designs also reduce recovery abuse. If account recovery, reset, or fallback channels all route through the same phone or email inbox, an attacker who gains that channel can often pivot into the primary account. So the control has to cover the full authentication journey, not only the first login screen.

For teams standardising customer authentication, Customer IAM (CIAM) Guide is useful for understanding step-up authentication, recovery abuse, and account takeover patterns, while Passwordless and Passkeys Guide explains why phishing-resistant, device-bound sign-in changes the risk profile compared with SMS and OTP-based flows.

Where regulated financial or payment contexts are involved, the independence requirement becomes even more important because Strong Customer Authentication is expected to withstand realistic interception and social-engineering paths. Financial Services Identity Security Guide is a practical reference for those sector-specific expectations.

Risk and Threat Considerations

Shared-device designs concentrate risk into one endpoint, one channel, and one recovery path. If that endpoint is lost, cloned, or remotely controlled, the attacker often gets both the initial factor and the second factor at once, which turns MFA into a single-compromise event rather than layered protection.

Failure mechanism: The authentication factors are not independent, so compromise of the device, browser session, or messaging channel exposes both the challenge and the response. That enables phishing, relay, session theft, or SIM-based takeover to satisfy the login without defeating two separate controls.

Impact: Account takeover becomes materially easier, and downstream abuse can include payments fraud, profile changes, recovery takeover, or unauthorized transactions. In customer systems, the blast radius is often larger than the login itself because the compromised device can be reused to approve future actions.

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 PCI DSS v4.0 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-63	Digital Identity Guidelines	SCA depends on phishing-resistant, independent authenticators and assurance levels.
Recommendation — Prefer phishing-resistant authenticators and separate the challenge path from the approved factor.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Shared-device MFA risk centers on authenticator lifecycle and compromise resistance.
	IA-2 — Identification and Authentication (Organizational Users)	The question is about authentication design and factor independence.
Recommendation — Manage authenticators so one device compromise cannot expose both factors. Require stronger authentication methods that do not collapse into a single compromised channel.
PCI DSS v4.0	8.6 — System and Application Accounts with Interactive Login	Payment-sector SCA and shared-channel login risk directly affect account authentication.
Recommendation — Ensure interactive authentication does not rely on a single compromised device or channel.
OWASP ASVS	V6 — Authentication	Factor independence and phishing resistance are core authentication requirements.
Recommendation — Verify that authentication factors remain independent under device or channel compromise.

Practitioner Guidance

What to verify: Check whether each factor is actually independent in the failure case, not just different on paper. If the same phone, same browser profile, or same messaging route can satisfy both steps, treat the design as correlated rather than strongly independent.

Decision rule: If compromise of one device lets an attacker receive, approve, or replay both factors, move to a phishing-resistant or device-bound design and tighten recovery controls before relying on the current flow for high-risk transactions.

Practitioner takeaway: Strong Customer Authentication is only strong when the factors fail separately; once one compromised device can deliver both, the control stops behaving like true multi-factor protection.