When one phone both starts a payment and holds an authentication factor, the PSD2 technical standards still require the factors to be independent. A breach of one must not compromise the others. Providers must add mitigations such as separated secure execution environments and checks that the device or software has not been altered.
The independence rule
Article 9 of Delegated Regulation (EU) 2018/389 says elements from the knowledge, possession and inherence categories must be independent. The text puts it this way: "the breach of one of the elements does not compromise the reliability of the other elements."
On paper that is simple. In practice, a customer's phone holds the banking app, the biometric sensor, the device key and often the SMS inbox. One piece of malware on that phone can touch several of those.
What the text asks for on multi-purpose devices
Where a multi-purpose device carries the elements, providers must apply mitigations. The regulation names these:
- Separated secure execution environments on the device.
- Mechanisms to ensure the software or device has not been altered by the payer or a third party.
- Where alteration has occurred, mechanisms to reduce the consequences.
In app terms, think of hardware-backed key storage, platform attestation, and rooted or jailbroken device checks. The regulation does not prescribe a specific technology, so your design record matters.
Design questions to answer
- Where does the key live? A key in the secure hardware of the device is harder to extract than one in app storage.
- What proves the device is intact? Decide what you do with a device that fails an integrity check: block, step up, or lower limits.
- What if the factor is a code sent to the same phone? If the same compromised device receives and approves, the factors are less independent than they look.
- How do you recover a lost device? Recovery is where independence usually collapses, because support staff reset factors by phone or email.
Common mistakes
- Treating a screen unlock and an in-app tap as two factors when both are controlled by the same on-device code.
- Skipping device integrity checks to avoid false positives, with no compensating control.
- Logging factor events without recording which device they came from.
Document the reasoning
Auditors and regulators will ask why you consider your factors independent. Keep a short design note: what the factors are, where each is stored, what an attacker with full control of the app process can and cannot do, and what you monitor. Update it when the app changes.
Quick check
Can one phone ever hold two SCA factors?
The text allows multi-purpose devices, provided the factors stay independent and mitigations such as separated secure execution environments and integrity checks are in place.
Is the biometric alone enough?
Inherence is one category. Strong customer authentication needs two elements from different categories, so the biometric must pair with a possession or knowledge element.
Sources
Last reviewed: 19 October 2026.
