What do organisations get wrong when they treat two-factor authentication as automatically compliant with PSD2-style requirements?

Why This Matters for Security Teams

PSD2-style strong customer authentication is easy to misunderstand because “two factors” sounds like a binary checkbox. It is not. The operational test is whether the authentication method resists compromise, keeps factors independent, and binds approval to the exact transaction being authorised. Security and compliance teams often over-focus on factor count while under-weighting factor separation, phishing resistance, and transaction integrity.

That gap matters because weak implementations can still look compliant in demos and policy documents. Current guidance suggests that authentication strength depends on the full control design, not just on whether a second prompt appears. NHI Mgmt Group’s Top 10 NHI Issues is a useful reminder that identity failures usually come from lifecycle and control design, not from labels. The same pattern shows up in payment authentication: teams assume the mechanism is strong until a fraud path or replay path proves otherwise.

In practice, many security teams discover the weakness only after a payment flow, approval workflow, or API transaction has already been abused, rather than through intentional control testing.

How It Works in Practice

PSD2-style requirements are about more than multi-factor authentication. The control expectation is that the authentication event is resistant to reuse, linkage, and interception. In practice, that means the factors should be independent, the authentication data should be protected, and the approval should be dynamically linked to the specific amount, recipient, or transaction context. A code, push, or token challenge that does not bind to transaction details can still be bypassed or redirected.

Practitioners should think in terms of control evidence, not marketing terms. Useful questions include: does the second factor prove possession in a way that cannot be trivially replayed, is the factor resistant to phishing or proxying, and is the approval cryptographically or procedurally tied to the payment event? For governance teams, auditability matters as much as user experience. Alignment with NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls helps translate that expectation into repeatable control assessment.

• Validate that factors are independent in practice, not just different in name.
• Confirm that approval is dynamically linked to the transaction being approved.
• Test for relay, phishing, push fatigue, and session hijacking weaknesses.
• Require evidence that authentication data is protected against reuse and disclosure.

For deeper operational context, NHI Mgmt Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and Ultimate Guide to NHIs — Regulatory and Audit Perspectives show the same principle in adjacent identity domains: controls fail when lifecycle handling and evidence collection are weak. These controls tend to break down when legacy banking channels, third-party payment journeys, or poorly integrated mobile approvals cannot enforce transaction-specific binding.

Common Variations and Edge Cases

Tighter authentication often increases friction, so organisations have to balance customer usability against fraud resistance and regulatory defensibility. That tradeoff becomes more visible in high-volume consumer flows, where teams are tempted to accept any second factor that reduces drop-off.

Best practice is evolving around stronger phishing-resistant methods, but there is no universal standard for every payment channel yet. Some schemes rely on hardware-backed authenticators, while others use app-based confirmation with transaction signing or secure device binding. The key is whether the method can prove the user approved that exact action. In regulated environments, control owners should document why a specific implementation meets the “independent factors” and “dynamic linking” expectations rather than assuming generic MFA language is sufficient.

Another edge case is delegated or corporate payments, where the user may be authenticating as an operator rather than a consumer. In those scenarios, role assignment, step-up checks, and transaction policy all matter. Compliance teams should also avoid assuming that password plus SMS is equivalent to stronger methods simply because two steps are present. That assumption breaks down fastest when attackers can intercept the second factor, manipulate the session, or alter transaction details after initial login.

Where payment journeys are fragmented across web, mobile, and third-party redirect flows, the authentication control often fails because the approval context is lost between steps.

Related resources from NHI Mgmt Group

• What do organisations get wrong when they treat access requests as a one-time approval instead of an ongoing control?
• What do organisations get wrong when they treat biometric authentication as stronger than all other controls?
• What do MSP teams get wrong when they treat quarterly updates as purely marketing content?
• What do security teams get wrong when they treat conferences as vendor showcases?