PSD2 uses two independent factors so a single compromise does not let an attacker complete a payment or account action. Independence matters more than the label of MFA. If one device, channel, or recovery path can satisfy both factors, the assurance model weakens and fraud resistance drops.
Why two factors have to be independent
PSD2 is trying to stop one stolen secret from unlocking a payment flow on its own. Independence means the factors must fail separately, so a compromised password, device, or recovery channel does not automatically satisfy the second check. That is why the rule is about assurance, not just counting factors.
In practice, the bank or payment provider has to avoid designs where the same underlying event can satisfy both checks. If both factors are bound to one phone, one inbox, or one recovery process, the attacker only needs a single break in that chain. That is weaker than true two-factor authentication.
PSD2 also reflects the reality that payment fraud often starts with credential theft, session theft, or account takeover. A second factor only adds real protection when it resists the same compromise path as the first. That is the difference between step-up security and a box-ticking MFA flow.
What counts as independence in PSD2-style authentication
Independence is a design property, not a product label. The factors should come from different categories, such as knowledge, possession, and inherence, but the deeper requirement is that compromise of one should not make compromise of the other likely. For example, an SMS code and a recovered phone number can be too closely linked to deliver strong separation.
This is why implementation details matter. Shared recovery routes, synced credentials, fallback codes, and help desk resets can collapse separation even when the login screen still says “two-factor.” The assurance level drops whenever an attacker can pivot from one factor to the other through the same trusted path.
For payment security, the practical question is not whether MFA exists, but whether the authentication chain still holds when the primary account secret, device, or support process is already exposed. PSD2 pushes firms to think about failure correlation, not just factor count.
How attackers exploit weak factor independence
When factors are not truly independent, attackers look for the shared weak point. That may be password reuse, SIM swap, push fatigue, token theft, session hijacking, or a recovery workflow that resets both factors at once. A “second factor” that can be re-established through the same compromised channel does not stop account takeover.
For a good practitioner view of those bypass paths, see MFA Guide, which breaks down common MFA bypass patterns and phishing-resistant alternatives. The same lesson appears in payment and banking incidents where valid credentials, legacy access, or stolen sessions were enough once the second control was weak or absent.
That is also why Financial Services Identity Security Guide is relevant for PSD2 readers: it ties payment-sector identity controls to strong customer authentication, dynamic linking, and fraud-resistant access design.
Risk and Threat Considerations
Weak factor independence creates a single point of failure across the whole payment journey. If the same device, recovery channel, or support process can satisfy both factors, an attacker who steals one credential path can often complete the transaction without needing a second distinct compromise.
Failure mechanism: The attacker abuses correlated controls such as password reset, SIM swap, token theft, or help desk recovery to turn one compromise into full authentication bypass.
Impact: The result is higher account takeover risk, fraudulent payment approval, and reduced confidence that step-up authentication will stop unauthorized action.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST SP 800-63 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | PSD2-style factor independence depends on strong user authentication design. |
| IA-5 — Authenticator Management | Factor independence is undermined by weak lifecycle control over passwords, tokens, and recovery authenticators. | |
| Recommendation — Enforce separate authenticators and break shared recovery paths for user logins. Manage authenticator issuance, replacement, and revocation so one compromise cannot reset both factors. | ||
| NIST SP 800-63 | AAL2 — Authenticator Assurance Level 2 | PSD2’s two-factor requirement is about assurance strength, not just MFA presence. |
| AAL3 — Authenticator Assurance Level 3 | Higher-assurance authentication emphasizes phishing resistance and stronger factor separation. | |
| Recommendation — Map payment authentication to assurance targets and reject factor designs that collapse into one compromise path. Use phishing-resistant authenticators when payment risk warrants stronger factor independence. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | PSD2 factor independence is an access-control design issue for financial transactions. |
| Recommendation — Define access rules that require truly independent authentication before payment actions. | ||
| OWASP ASVS | V6 — Authentication | The question concerns authentication strength and factor independence. |
| Recommendation — Verify that authentication cannot be satisfied by a single compromised channel or shared recovery path. | ||
| PCI DSS v4.0 | 8.6 — System and application accounts and authentication credentials | Payment-sector authentication controls are directly relevant to preventing account compromise in payment flows. |
| Recommendation — Restrict and manage authentication credentials so account actions require distinct, well-controlled factors. | ||
Practitioner Guidance
What to verify: Test whether the two factors fail independently in the real recovery and support flow, not just at primary login. If the reset process, fallback code, or new-device enrollment can satisfy both factors, the control is materially weaker than PSD2 intent.
Decision rule: Treat any shared dependency, especially a single mobile number, email inbox, or help desk reset path, as a design defect until proven otherwise. Independence should survive compromise of one factor and compromise of the most likely recovery path.
Practitioner takeaway: PSD2 is really demanding correlated-failure resistance, so the right question is whether one compromised path can ever be reused to satisfy both factors.
Related resources from NHI Mgmt Group
- Why is it crucial to adopt new authentication methods in MCP usage?
- What breaks when strong customer authentication does not use independent factors?
- What do organisations get wrong when they treat two-factor authentication as automatically compliant with PSD2-style requirements?
- Why does PCI require MFA factors to be independent in payment card environments?