MFA and passkeys verify access, but they do not prove a payment request is legitimate. Invoice fraud often succeeds because the attacker manipulates trust, timing, and workflow, then redirects payment details to a new account. Security teams need behavioural controls that flag new sender domains, unusual request patterns, and abnormal financial correspondence before payment is approved.
Why MFA and passkeys do not solve invoice fraud
MFA and passkeys are strong access controls, but invoice fraud usually abuses a different part of the process: the moment a person is persuaded to approve a payment or change payee details. The attacker does not need to defeat the login ceremony if they can impersonate a trusted supplier, exploit urgency, or inject a false account-change request into a legitimate workflow.
That is why the control boundary matters. Authentication answers, “Is this user allowed into the system?” Invoice fraud asks, “Should this payment be made, to this beneficiary, right now?” Those are related but not the same decision. When teams treat authentication as a proxy for payment legitimacy, they leave the business process itself outside the protection model.
Two common failure modes show up repeatedly. First, the attacker compromises email or chat and then waits for a natural invoice cycle, so the request looks routine. Second, the attacker sends a convincing “bank account update” or “urgent remittance” message from a lookalike domain, then relies on the recipient to skip callback verification or maker-checker review. MailChimp breach and Uber Breach are useful reminders that social engineering often succeeds by abusing trust and process, not by breaking authentication alone.
Where social engineering bypasses the control you thought you had
Passkeys reduce phishing for login credentials, and MFA reduces simple account takeover, but neither one can validate the meaning of a request once the user is already inside a mailbox, ERP, AP portal, or collaboration channel. If the attacker has obtained a session, compromised a sender, or simply persuaded a legitimate user to take an action, the authentication layer has already done its job. The weakness is now in human judgment, workflow design, and exception handling.
Invoice fraud succeeds when the environment makes fraudulent requests look operationally normal. That includes new supplier domains that resemble existing ones, late-day payment changes, rushed approvals, and “updated bank details” that arrive just before settlement. The right response is to treat those as behavioural signals, not as secondary nuisances. Review should be triggered by context, for example first-time beneficiary changes, mismatch between prior correspondence and payment destination, or requests that break the established communication pattern.
For a broader attack-path view, social engineering often creates the first foothold and then pivots into financial abuse. A compromised account can be used to observe approval workflows, spoof internal correspondence, or learn when payment staff are most likely to bypass scrutiny. Microsoft Midnight Blizzard breach and MGM Resorts Breach 2023, Scattered Spider both illustrate how social engineering can move from access to wider operational impact once trust is established.
What actually reduces invoice fraud in practice
The effective controls are mostly procedural and behavioural, supported by monitoring. Payment teams need a rule that any new beneficiary, changed bank detail, or out-of-band request is verified through an independent channel, not replied to in the same thread. Security and finance should also tune alerts for sender-domain anomalies, email thread spoofing, unusual payment timing, high-pressure language, and correspondence that diverges from the supplier’s historical pattern.
If you want one practical test, ask whether your process would still be safe if the sender had a valid login and a believable voice, but the payment instruction was false. If the answer is no, then the control gap is in approval design, supplier verification, and exception management, not in MFA enrollment or passkey rollout. Authentication is still worth having, but it is only one layer in a larger fraud-control stack.
Practitioner Guidance: Treat invoice fraud as a business-process abuse problem with security consequences. The highest-value control is not stronger login friction, it is a payment-verification path that is independent of the channel used to deliver the request, plus clear escalation when a request changes beneficiary data or departs from normal correspondence.
Practitioner takeaway: If a control only proves who opened the account, it cannot prove the payment instruction is genuine; fraud prevention must verify the request itself, not just the login that preceded it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 — Identity Management, Authentication and Access Control | Authentication secures access, but not the legitimacy of payment instructions. |
| DE.CM-8 — Vulnerability Management | Behavioural and domain anomalies help detect fraudulent correspondence before payment. | |
| Recommendation — Separate access authentication from payment approval and verify beneficiary changes independently. Monitor for anomalous sender domains, request patterns, and payment-detail changes. | ||
| CIS Controls v8 | 14 — Security Awareness and Skills Training | Invoice fraud relies on human trust, urgency, and workflow manipulation. |
| 6 — Access Control Management | Approval paths and exception handling need enforced limits beyond account login. | |
| 8 — Audit Log Management | Fraud patterns are often visible in correspondence and approval trail anomalies. | |
| Recommendation — Train approvers to use out-of-band verification for any changed banking details. Require maker-checker review and restrict payment changes to approved workflows. Retain and review payment-change audit trails for suspicious request sequences. | ||
| MITRE ATT&CK | T1566 — Phishing | Invoice fraud commonly begins with deceptive messages that impersonate trusted senders. |
| Recommendation — Hunt for spoofed domains, impersonation, and fraudulent follow-up requests. | ||
Related resources from NHI Mgmt Group
- Why do MFA and SSO not stop Salesforce data theft in social-engineering attacks?
- Why do social engineering attacks still bypass strong MFA programs?
- Why do social engineering attacks bypass many traditional fraud controls?
- What breaks when organisations rely only on endpoint controls to stop browser-based social engineering attacks?
