They fail because PSD3 is addressing a fraud environment where attackers can socially engineer users, spoof devices, and exploit weak recovery steps. Legacy MFA often proves phishable or easy to bypass, while weak recovery creates a second authentication path that is easier to abuse than the first.
Why Legacy MFA and Recovery Journeys Break Under PSD3
PSD3 raises the bar because modern payment fraud is no longer limited to password guessing or one-time-code theft. Attackers now combine social engineering, device spoofing, account takeover, and recovery abuse to defeat controls that were designed for a simpler threat model. Legacy MFA often assumes the second factor is enough, but phishable prompts, SIM swap exposure, and push fatigue make that assumption weak in practice. Recovery flows are even riskier because they often become a parallel authentication path with looser checks than the primary login.
That mismatch is familiar across identity abuse cases, including the patterns described in the Microsoft Midnight Blizzard breach and the DeepSeek breach, where weak trust boundaries and exposed credentials created paths around intended controls. The broader lesson aligns with the NIST Cybersecurity Framework 2.0: authentication is only defensible when the recovery path is as strong as the primary path, and ideally stronger for high-risk events.
In practice, many security teams discover recovery weaknesses only after an attacker has already used them to bypass MFA, rather than through intentional testing of the full identity journey.
How PSD3 Changes the Design Problem
PSD3 does not simply ask whether MFA exists. It pushes organisations to prove that authentication and recovery resist real fraud tactics, including adversary-in-the-middle interception, impersonation of support staff, and compromise of alternate channels. The practical issue is that many legacy journeys rely on knowledge-based checks, SMS codes, email links, or call-centre verification. Those controls may pass a basic policy check, yet still fail under coordinated fraud.
Effective design starts by mapping every step where an account can be re-bound to a new device, factor, or contact method. Current guidance suggests treating recovery as a privileged action, not an administrative convenience. That means stronger verification for factor reset, step-up controls for unusual behaviour, and explicit limits on how much a single channel can prove. Where possible, organisations should prefer phishing-resistant methods and reduce dependency on shared or replayable secrets.
- Use phishing-resistant MFA for primary access where the risk profile justifies it.
- Make recovery require stronger assurance than routine login, not weaker.
- Instrument behavioural signals such as device change, geovelocity, and channel switch.
- Review call-centre and help-desk scripts as part of the authentication surface.
This is consistent with identity hardening principles in The State of Secrets in AppSec, where fragmented controls and weak operational practices undermine security even when policy looks sound. In environments that still depend on SMS, email-based resets, or manual support overrides, these controls tend to break down because the recovery path becomes the easiest target in the whole trust chain.
Common Failure Modes and Practical Tradeoffs
Tighter authentication and recovery often increases friction, so organisations have to balance fraud resistance against abandonment, support load, and regulatory expectations. There is no universal standard for every customer journey, but PSD3-oriented design should assume that attackers will test the path of least resistance and that users will forget, lose, or replace devices.
Common failures include overly permissive self-service resets, recovery questions that are easy to research, and support teams that can override policy without strong evidence. Another gap is overreliance on a single factor type. If one channel is compromised, the entire journey can collapse. Best practice is evolving toward layered verification, better step-up logic, and tighter monitoring of recovery events as security events, not just service events.
For organisations with high fraud pressure, the operational question is not whether recovery should exist, but whether it can be made harder to abuse than direct login. That usually means limiting high-risk resets, validating changes through independent signals, and continuously testing the journey with fraud scenarios instead of assuming the workflow is safe because it is convenient.
Where customers are frequently changing devices or support teams have broad exception authority, PSD3-aligned controls can become fragile unless fraud operations and IAM governance are tightly coordinated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-7 | Supports stronger authentication and session control against spoofing and account takeover. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Recovery flows often rely on weak or reusable secrets, which this control helps govern. |
| NIST AI RMF | Useful for risk mapping when automated fraud detection and identity decisions are being tuned. |
Reduce reliance on reusable secrets and require tighter lifecycle controls for reset-related credentials.
Related resources from NHI Mgmt Group
- Why do strong MFA controls still leave organisations exposed to session hijacking?
- Why do identity fraud controls fail when they rely on one strong signal?
- What breaks when a remote access portal does not require MFA?
- What breaks when stolen cloud credentials are allowed to authenticate without strong MFA?
