Banks should treat strong customer authentication as a multi-channel control, not a smartphone-only workflow. A resilient design supports hardware authentication devices alongside mobile methods so customers can authenticate across different needs, accessibility constraints, and failure conditions. That approach also reduces exposure to mobile malware, device compromise, and network dependence while helping institutions meet evolving European compliance expectations.
Designing strong customer authentication for more than one access path
strong customer authentication is strongest when it is treated as a capability, not as a device assumption. Banks should design for at least two usable authentication paths, so customers are not forced into a single mobile workflow when they change devices, travel, lose coverage, or need an accessibility alternative. That means planning the channel model first, then mapping the assurance level each channel can actually deliver.
The practical design question is whether the bank can still complete authentication if the smartphone is unavailable, the mobile app is compromised, or the network path fails. A robust programme allows the same customer to authenticate through a second factor or second device class without collapsing into weaker fallbacks that undermine the original control objective.
For banks building out the control, the right design choice is usually to separate the authentication policy from the customer interface. Hardware tokens, smart cards, passkeys bound to a different device, and carefully governed recovery methods can all be part of the same assurance model if they are measured against the same fraud and step-up requirements.
For implementation guidance, use the bank’s own resilience criteria to decide whether a method is acceptable: the channel should be supportable under low connectivity, recoverable after device loss, and compatible with high-risk transaction approval. The authentication design should also avoid creating a hidden dependency on one operating system, one app store, or one handset class.
How mobile dependency changes fraud, resilience, and customer access
Mobile-only authentication creates a narrow trust path. If that path is protected only by a smartphone app, then device compromise, SIM-related attack paths, push fatigue, malware, or account recovery abuse can all become single points of failure. The issue is not that mobile authentication is inherently weak, it is that over-reliance on one endpoint makes the bank’s control posture brittle.
The same dependency also creates operational risk. Customers who cannot use the phone they registered, or who cannot receive data at the time of authorization, may be pushed into manual exceptions that are slower, harder to monitor, and more likely to be abused. A multi-channel model reduces the pressure to weaken controls during service disruption.
Hardware-based methods can improve resilience because they detach authentication from a single general-purpose mobile device. A separate authentication device or physical token can preserve access when the phone is replaced, compromised, or unavailable, and it can be especially important for customers who cannot reliably use app-based workflows.
That design also supports accessibility and inclusion. If strong customer authentication is only viable through a smartphone app, the bank may create avoidable friction for customers with older devices, poor coverage, disability-related constraints, or operating environments where app installation is not practical.
Risk and Threat Considerations
Mobile-only strong customer authentication concentrates both attack surface and operational dependency in one place. If the phone becomes the sole authenticator, then compromise of that device or its recovery path can affect both availability and trust, and the bank may end up substituting convenience for assurance when users need an exception path.
Failure mechanism: Attackers target the mobile device, the notification channel, or the recovery process because a single compromised path can enable account takeover or high-risk transaction approval. Service outages, roaming limits, lost devices, and accessibility barriers create the same concentration risk even without an active attacker.
Impact: The bank can see higher fraud exposure, weaker recovery controls, more manual overrides, and greater customer abandonment when the only approved method is unavailable. If the fallback path is poorly governed, the institution may also create a weaker door than the one it was trying to protect.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the technical controls, while PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-7 — Identity Management, Authentication and Access Control | Multi-channel SCA depends on strong authentication and access control choices. |
| Recommendation — Design authentication paths so customers can prove identity without relying on one device class. | ||
| CIS Controls v8 | 6 — Access Control Management | Banks need governed access methods, least privilege and controlled fallback authentication. |
| Recommendation — Standardise approved authentication methods and restrict weaker recovery paths. | ||
| NIST SP 800-63 | 3 — Digital Identity Assurance | Customer authentication strength depends on assurance, authenticator binding and recovery design. |
| Recommendation — Select authenticators and recovery flows that preserve the required assurance level across channels. | ||
| NIST Zero Trust (SP 800-207) | 3 — ZTA Policy Engine and Policy Decision Point | Strong authentication should support policy-based decisions independent of a single mobile endpoint. |
| Recommendation — Enforce step-up decisions through policy, not through one mandatory user device. | ||
| PCI DSS v4.0 | 8 — Identify Users and Authenticate Access | Payment-sector authentication must support strong identity verification and controlled access. |
| Recommendation — Use approved authenticators that meet payment authentication requirements without device lock-in. | ||
Practitioner Guidance
What to prioritise: Treat channel diversity as part of the assurance design, not as an optional convenience layer. Banks should explicitly define which authentication methods are primary, which are backup, and which are only acceptable for lower-risk actions or recovery.
What to verify: Test that every approved method can support the same risk-based policy decisions, especially for step-up authentication and transaction confirmation. If a non-mobile option cannot meet the bank’s security threshold, it should not be promoted as an equivalent path.
Common mistake: Using the mobile app as the universal control and then adding a weak recovery workaround after the fact. That pattern often shifts risk into onboarding, reset, or help-desk processes rather than removing it.
Practitioner takeaway: The strongest customer authentication models are the ones that preserve assurance while removing single-device dependency, because resilience and security need to be designed together from the start.
Related resources from NHI Mgmt Group
- How should organisations design customer authentication so security adapts to risk instead of adding more steps for every login or transaction?
- How should banks adapt customer experience and authentication flows as 5G makes mobile banking more continuous and device-rich?
- Why does device identity matter when organisations use passwordless authentication for customer apps?
- How should security teams distinguish identification from authentication in IAM design?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
