Why do old fraud tactics still work in modern enterprises?

Why This Matters for Security Teams

Old fraud tactics still succeed because they exploit process gaps that modern controls often leave untouched. A convincing email, phone call, or chat message can still trigger payment release, credential reset, or vendor change if the workflow trusts familiarity more than proof. That is why fraud prevention is not only a security problem but also an identity and business-process problem. NHI Management Group’s Ultimate Guide to NHIs — Why NHI Security Matters Now shows how identity sprawl, excessive privilege, and weak visibility create lasting exposure across modern enterprises. The same pattern appears in fraud: the attacker does not need to defeat every control, only the one step where a human is allowed to approve on trust. This is also consistent with the broader threat logic described in the MITRE ATLAS adversarial AI threat matrix, where manipulation and operational misuse often succeed through workflow weakness rather than technical break-in. In practice, many security teams encounter fraud only after a payment, access grant, or account change has already been completed, rather than through intentional verification failure.

How It Works in Practice

Fraud tactics persist because they map to real enterprise behaviour: urgency, delegation, and exception handling. An attacker may impersonate an executive, supplier, help desk analyst, or internal system, then route the request through a channel that already carries business legitimacy. If the organisation relies on static approval rules, the request can look normal even when the intent is malicious. Current guidance suggests treating fraud controls as identity verification plus workflow resistance. That means adding friction at the exact points where abuse is most likely:

• Verify high-risk requests through a second channel, not the same inbox or ticket path.
• Require step-up approval for bank detail changes, password resets, and privilege grants.
• Use call-backs or out-of-band confirmation for payment and vendor changes.
• Log and correlate requests across email, ticketing, chat, and IAM systems to detect repetition or impersonation.
• Restrict who can override controls, and make overrides visible for review.

NHI Management Group’s Ultimate Guide to NHIs — Why NHI Security Matters Now is relevant here because the same governance failures that affect secrets and service accounts also affect fraud response: weak ownership, poor visibility, and delayed revocation. Security teams should also align with identity-first assurance principles from MITRE ATLAS adversarial AI threat matrix when building detection around manipulated requests and tool-assisted social engineering. These controls tend to break down when approval chains are informal, exceptions are frequent, or high-volume operations pressure staff to bypass verification.

Common Variations and Edge Cases

Tighter verification often increases operational friction, requiring organisations to balance fraud reduction against speed, customer service, and internal productivity. That tradeoff is real, especially in finance, procurement, and IT support where delays can affect business continuity. Current guidance suggests risk-tiering rather than applying the same control to every request. Common edge cases include:

• Executive requests that are time-sensitive but still require out-of-band verification.
• Supplier changes that originate from a legitimate contact but use a compromised mailbox.
• Help desk resets where the attacker knows enough context to sound credible.
• Automated workflows where a human review is assumed but not actually enforced.

The important nuance is that familiarity is not proof. A known logo, a real name, or a request that matches past work does not establish legitimacy. Best practice is evolving toward policy-based verification thresholds, where the required checks depend on the impact of the request rather than the tone of the message. NHI Management Group’s research on NHIs reinforces that governance failures usually show up in the exception path first, not the normal path. Fraud controls fail most often when high-trust teams are allowed to skip verification because the request feels routine or urgent.

Related resources from NHI Mgmt Group

• Why do targeted phishing campaigns still work against mature organisations?
• Why do social engineering campaigns still succeed in mature enterprises?
• Why do higher education environments face more email fraud risk than many enterprises?
• Why do layered security controls still fail against modern attackers?