They should treat the issue as a programme-design problem, not a single-tool problem. That means tightening verification on high-risk requests, testing real trust paths, and reviewing whether current controls still match attacker behaviour. The goal is to reduce the chance that one deceptive message becomes a financial or identity incident.
Why rising phishing losses usually mean the control design is off
When losses keep rising, the problem is rarely just user awareness or message filtering. It usually means the organisation is still allowing a small number of deceptive requests to reach high-value actions without enough verification, friction, or blast-radius reduction. The practical question is which trust paths still let one convincing message become money movement, credential compromise, or account takeover.
A useful way to think about it is to separate detection from decisioning. Filtering can reduce volume, but if a fraudulent email, text, or chat message can still trigger payment approval, inbox change, MFA reset, vendor-bank detail updates, or help desk recovery, the loss path remains open. The stronger response is to redesign the request path so the action itself is harder to abuse.
That usually means adding explicit verification to the steps most attractive to attackers: high-risk payment changes, identity recovery, login resets, external contact updates, and any request that creates an authentication or funds-transfer exception. Teams should also review whether existing controls depend too heavily on the channel being genuine, rather than on independent proof that the request is authorized.
Which controls actually break the phishing-to-loss chain
The most effective controls are the ones that interrupt the attacker’s ability to convert trust into action. That includes phishing-resistant authentication for sensitive workflows, out-of-band confirmation for unusual requests, step-up review for first-time or changed beneficiaries, and tighter approval rules around support functions that can reset access or redirect payments.
Security teams should test the real workflow, not the policy wording. If an attacker can still succeed by compromising one mailbox, one help desk queue, or one approver, the organisation has a process control gap. Current guidance from NIST SP 800-63 Digital Identity Guidelines is especially relevant where phishing-resistant authenticators can reduce the chance that a stolen credential becomes a durable login path.
For operational control design, it helps to map the full path from message receipt to value movement. In many cases, the weak point is not authentication alone but authorization, delegation, or recovery. Controls should therefore be tuned to the request type: what can be changed, who can approve it, and what independent evidence is required before the change is accepted.
For teams that need a broader control baseline, NIST Cybersecurity Framework 2.0 is a useful organising model because rising phishing losses touch govern, protect, detect, respond, and recover at the same time.
How to tell whether phishing losses are a trust-path problem or a credential problem
Not every increase in loss has the same root cause. If the losses concentrate in payment redirection, supplier bank changes, invoice fraud, or executive impersonation, the issue is often weak request verification and poor exception handling. If they cluster around account takeover, mailbox takeover, or help desk resets, the issue is more likely authentication and recovery design.
That distinction matters because the remediation differs. A credential problem calls for stronger authentication, better recovery controls, and tighter session protection. A trust-path problem calls for policy changes, dual approval, callback verification, and stricter handling of unusual instructions. Organisations that treat every phishing loss as the same kind of incident usually buy tools that do not touch the actual failure mode.
Loss trends also reveal where the attack surface is expanding. If attackers are now abusing chat, collaboration platforms, vendor portals, or shared inboxes, the organisation should update its trust assumptions, not just its email gateway. The right response is to review where humans are still asked to decide based on message content alone, then insert a second, independent signal before action is allowed.
Risk and Threat Considerations
Rising phishing losses indicate that attackers are finding a dependable path from social engineering to business action. The risk is not limited to stolen credentials, because the same deceptive message can also drive payment fraud, unauthorized account changes, or recovery abuse even when the original login remains intact.
Failure mechanism: A trusted channel, such as email, chat, or help desk interaction, is used to trigger an exception, and the defender has no independent verification step strong enough to stop the fraudulent request before it is executed.
Impact: The organisation sees recurring financial loss, identity compromise, and control erosion, because the same trust path can be reused until the underlying approval, recovery, or authorization design is changed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IAL — Identity Assurance Levels | Phishing losses often hinge on weak proofing and recovery assurance. |
| Recommendation — Use phishing-resistant assurance and stronger recovery checks for high-risk actions. | ||
| NIST CSF 2.0 | PR.AA-05 — Authentication Strengthening | Losses rise when sensitive actions remain reachable through weak auth paths. |
| PR.AT-01 — Awareness and Training | Social engineering still matters when requests rely on human judgement. | |
| GV.RM-01 — Risk Management Strategy | Rising losses need programme-level control redesign, not isolated fixes. | |
| Recommendation — Apply stronger authentication for the workflows attackers exploit most. Train staff to verify high-risk requests through independent channels. Treat recurring phishing losses as a control design risk requiring governance action. | ||
Practitioner Guidance
What to prioritise: Start with the top three loss scenarios, not the top three phish types. If the money loss comes from payment redirection, secure the payment-change workflow first; if it comes from account takeover, harden recovery and step-up verification first.
What to verify: Test whether a real attacker can still complete the full path from message to loss using only one compromised inbox, one approval lane, or one support interaction. If yes, the control set is still too trusting.
Decision rule: If the action can create a financial, identity, or privileged-access incident, require an independent verification step that does not rely on the same channel the attacker is already using.
Practitioner takeaway: Rising phishing losses are usually a signal to redesign trust decisions, not to add another detector; reduce the number of requests that can succeed on persuasion alone.
Related resources from NHI Mgmt Group
- How should security teams respond when identity-related incidents keep rising but leadership still treats identity as a technical issue only after a breach?
- How should security teams respond to voice phishing that targets Okta accounts?
- How should security teams respond to AI-assisted phishing and social engineering?
- How should security teams respond to AI-generated phishing campaigns?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org