How should security teams reduce fraud risk when attackers can imitate trusted people and processes?

Why This Matters for Security Teams

Fraud risk rises sharply when an attacker can sound like a trusted executive, mimic a vendor, or reproduce a process that already feels routine. The failure is rarely just technical. It is usually a process design issue: a single email thread, a callback to an exposed number, or an approval chain that rewards speed over verification. NHI Management Group’s analysis of 52 real incidents shows how often identity trust is the weakest link in these events, especially when credentials, permissions, and process memory are reused without independent proof. See the 52 NHI Breaches Analysis for the underlying patterns.

This matters because impersonation attacks are not limited to human identities. They often exploit the same trust fabric used by bots, service accounts, approvals, and delegated workflows. Once the adversary gets a foothold in a trusted channel, urgency becomes a weapon. Current guidance from the NIST Cybersecurity Framework 2.0 still applies, but the operational lesson is broader: trust should be earned at the point of action, not assumed because a message or request looks familiar. In practice, many security teams encounter fraud only after funds move or access changes, rather than through intentional challenge and verification design.

How It Works in Practice

The most reliable way to reduce imitation-based fraud is to add a second, harder-to-spoof path before any high-impact action is executed. That means the person or process making the request is not enough. The request must also prove legitimacy through a separate control plane, such as a verified callback, a signed approval, a protected workflow portal, or a policy engine that checks the request against context before release. This is especially important where the attacker can imitate tone, timing, and escalation language.

A practical control stack usually includes:

• Independent verification for payment changes, vendor banking updates, privileged access grants, and account recovery.
• Channel separation so approval, request, and confirmation do not all occur in the same inbox, chat thread, or ticket.
• Policy checks that look for unusual timing, request amount, destination, or initiator relationship before the action is approved.
• Step-up review for exceptions, especially when urgency, confidentiality, or executive authority is cited.

This is where governance for non-human identities becomes relevant. Fraud often rides on automated workflows, OAuth grants, inbox rules, and service accounts that can be abused to make a request appear authentic. The State of Non-Human Identity Security highlights how weak visibility and over-privilege remain common, which is exactly the environment attackers prefer. For broader threat context, the CISA cyber threat advisories are useful for tracking how social engineering and identity abuse evolve in parallel.

The strongest teams design the workflow so that urgency cannot bypass scrutiny, even when the request appears to come from a trusted person or an automated system. These controls tend to break down when approval paths are embedded in the same compromised tenant, chat platform, or ticketing system that the attacker already controls.

Common Variations and Edge Cases

Tighter verification often increases friction, so organisations must balance fraud resistance against operational speed. That tradeoff is real, especially in finance, incident response, and executive support functions where delays can carry business cost. Best practice is evolving, but current guidance suggests using stronger checks only for actions that can materially change money, access, or authority.

Some edge cases need tailored handling. Emergency requests may justify faster approvals, but they still need a post-action audit trail and a separate confirmer. Vendor changes are another weak spot, because attackers frequently impersonate legitimate third parties or compromise shared service channels. High-risk organisations should also treat automation as part of the attack surface, since a scripted approval path can be abused as easily as a human one. The Ultimate Guide to NHIs — Key Challenges and Risks is useful for understanding where trusted automation becomes an entry point rather than a safeguard.

For teams looking at adversarial patterns more broadly, the MITRE ATLAS adversarial AI threat matrix helps frame how attackers blend automation, persuasion, and identity abuse. In these mixed environments, a human-only fraud playbook is not enough. Security teams need separate verification for high-impact actions, plus policies that remain effective when the requester may be a person, a bot, or a compromised workflow.

Related resources from NHI Mgmt Group

• How should teams reduce the risk of exposed AI credentials being abused?
• How should teams reduce risk from malicious npm package installs?
• How should security teams reduce fraud risk in account recovery workflows?
• How should security teams reduce fraud when attackers use deepfakes and synthetic identities?