Banks can create a false trust boundary if they treat device possession as a permanent proof of customer legitimacy. Possession may help at the moment of authentication, but it does not address number changes, device swaps, or social engineering. The result is a control that feels strong while slowly drifting away from the real assurance requirement.
What breaks when banks treat device possession as proof of customer legitimacy?
PSD2 SCA is strongest when it is treated as a momentary authentication signal, not as a permanent claim that a customer is trustworthy. If possession becomes the whole model, the bank can miss account changes, device replacement, number recycling, SIM swaps, and low-friction social engineering that preserve “possession” while changing who actually controls the channel.
Why possession stops being enough after the first login
Possession is a weak basis for long-lived trust because it can be transferred, replicated, or preserved while the customer’s relationship to the device changes. A phone may still be in the customer’s hands, yet the associated number, recovery route, push channel, or registration state can drift away from the original assurance event.
That is why device possession works best as one factor inside a broader assurance model, not as a standing entitlement to sensitive actions. Banks need to distinguish between authenticating the device at a point in time and trusting every future action from that device without re-evaluating risk.
Where the false trust boundary shows up in banking journeys
The failure usually appears in recovery and change workflows, not in the initial SCA challenge. If a bank treats a known device as enough to approve reset, enrolment, number change, or high-risk payment events, an attacker only needs to inherit or redirect the customer’s channel once to keep using the same “trusted” path.
Mobile possession also becomes fragile when the bank assumes the same device, same number, and same person remain bound together. In practice, those bindings change independently, so the bank may still see an authenticated device while the real control point has shifted to a new handset, a recycled number, or a manipulated support interaction.
For the banking context, the strongest interpretation of SCA is closer to a Financial Services Identity Security Guide than to a device-only shortcut, because the control has to survive number changes, step-up events, and channel reassignment. Strong possession evidence at one moment does not justify permanent trust in later transactions.
Risk and Threat Considerations
When possession is over-trusted, the bank creates a durable trust boundary around something that is inherently mutable. That opens the door to takeover by number reassignment, device migration abuse, account recovery fraud, and social engineering that preserves the device factor while bypassing the customer’s true control of the account.
Failure mechanism: The institution conflates point-in-time possession with ongoing legitimacy, then uses that stale assumption to approve recovery, enrolment, or high-value actions after the underlying binding has changed.
Impact: Attackers can retain access long after the original SCA event, while legitimate customers are locked into a control that looks strong on paper but no longer reflects actual assurance.
How to design SCA so it still means something later
Banks should treat possession as one ingredient in a living trust model that can expire, rotate, or be invalidated by downstream changes. That means tying authentication strength to the action being requested, not to a permanent device flag, and making sure the assurance level falls whenever the binding between customer, number, and device becomes uncertain.
Where mobile apps support step-up or approval flows, banks should be careful not to let convenience features become de facto recovery authority. A device that can approve low-risk access today should not automatically be allowed to authorise identity changes, credential resets, or new transaction patterns without fresh checks.
For organisations that want to align their control model with established authentication guidance, NIST SP 800-63 Digital Identity Guidelines is useful because it separates authenticator use from assurance level. Sender-constrained approaches such as RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) also help show why possession should be tied to a specific token or session, not treated as universal legitimacy.
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 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | PSD2 SCA depends on authenticator assurance and reproofing after binding changes. |
| Recommendation — Map each mobile banking action to the required assurance level and re-verify when risk or bindings change. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Banks need authentication that proves the actor for the current session, not permanent device trust. |
| IA-5 — Authenticator Management | Number changes, device swaps, and resets are authenticator lifecycle events that affect trust. | |
| AC-6 — Least Privilege | Device trust should not grant broad standing permission for high-risk banking actions. | |
| Recommendation — Require current authentication strength before allowing account actions that change access or recovery paths. Govern authenticator enrollment, rotation, revocation, and replacement as controlled lifecycle events. Limit what a trusted device can authorise and separate routine access from privileged changes. | ||
Practitioner Guidance
What to verify: Verify which events should force re-assurance, especially number change, device rebind, SIM change, recovery channel change, and new-payee or payee-amendment flows. If those events do not trigger stronger checks, the bank is probably overusing possession as a standing trust anchor.
Decision rule: If the device can still authenticate but the customer’s recovery path has changed, treat the situation as a change in assurance state, not as a routine continuation of trust. Step up verification before allowing enrolment, reset, or payments that materially expand blast radius.
Common mistake: Treating “known device” as a substitute for current customer control. That shortcut is especially dangerous in mobile banking because the control path, not just the handset, is what attackers try to redirect.
Practitioner takeaway: The right question is not whether the device was once possessed, but whether the bank can still prove the same customer controls the same trust path at the moment the action is approved.
Related resources from NHI Mgmt Group
- What breaks when mobile banking apps treat device integrity as a binary control?
- What breaks when organisations treat agent visibility as enough governance?
- What breaks when organisations treat a business continuity plan as enough for breach readiness?
- What breaks when banks treat valid credentials as proof of trust?