Social engineering remains the present and future fraud threat

At a glance

What this is: A recorded Vision 2023 session examines how social engineering drives modern fraud and impersonation attacks.

Why it matters: It matters because IAM, PAM, and security leaders still need controls that reduce human susceptibility, strengthen verification, and limit the blast radius when deception succeeds.

👉 Watch Abnormal AI's Vision 2023 session on social engineering and fraud

Context

Social engineering is a manipulation problem, not a malware problem. Attackers use impersonation, urgency, and trust to steer people into approving transfers, revealing credentials, or sharing information that looks harmless in isolation.

For identity and access programmes, that means the weak point is often the human decision embedded in the process, not the login mechanism itself. The session is a useful reminder that fraud defence, identity governance, and user verification need to be designed together rather than as separate control domains.

Key questions

Q: How should security teams reduce social engineering risk in identity workflows?

A: Start by identifying where a message, call, or chat can trigger a privileged action without a second verification step. Then add independent approval paths for resets, bank changes, and access requests. The goal is to break the attacker’s ability to convert trust into action through a single conversation.

Q: Why do social engineering attacks still succeed in mature security programmes?

A: They succeed because many controls verify systems and identities, but not intent. A mature stack can still fail if an employee is persuaded to approve the wrong action, reveal sensitive data, or bypass process discipline. Human decision-making remains part of the attack surface.

Q: What is the biggest weakness in help desk recovery workflows?

A: The biggest weakness is that recovery often grants more power than front-door authentication. If an attacker can impersonate a user convincingly enough, they may be able to reset credentials, unlock accounts, or escalate privileges before the deception is detected.

Q: Who should own social engineering defence across the organisation?

A: Ownership should be shared across IAM, security awareness, fraud prevention, finance, and help desk operations. Social engineering crosses these domains, so controls fail when each team assumes another one is responsible for the final verification step.

Background and context

Why social engineering bypasses technical controls

Social engineering works because the attacker targets the decision layer between identity and action. The payload is often a request, not code: a convincing caller, a realistic email thread, or a fabricated business context that leads a user to authorise access or payment. Technical controls can verify a session, but they cannot by themselves verify the intent behind the request. That is why impersonation succeeds even in organisations with strong perimeter controls and mature tooling. The real failure mode is trust being granted too early in the workflow.

Practical implication: add verification steps that trigger before approval, transfer, or reset actions are completed.

How invoice fraud turns identity trust into financial loss

Invoice fraud is a downstream identity failure. The attacker first collects enough context to impersonate a supplier, executive, or internal approver, then inserts a fraudulent payment path into an otherwise normal business process. The security issue is not only message authenticity, but also authority validation and change control around payment requests. Once the request sits inside an expected workflow, it can move faster than manual review. Controls that only watch for malware or account takeover miss the business process abuse that makes this attack effective.

Practical implication: require out-of-band verification for bank detail changes and payment exceptions.

What modern vishing reveals about human access governance

Vishing shows that human identity controls still rely heavily on memory, confidence, and procedural discipline. Attackers exploit that by creating urgency, authority, or fear, then using the call to bypass normal caution. This is not just awareness training territory. It is also about limiting what a single call can unlock, how quickly sensitive changes can be made, and whether recovery paths are as strong as primary authentication paths. When a phone call can trigger account recovery or privileged action, the governance model is too permissive.

Practical implication: treat recovery and support workflows as privileged access paths with their own controls.

NHI Mgmt Group analysis

Human trust is the first control boundary, and attackers know it. This session reinforces that social engineering succeeds when organisations treat the human as the least predictable part of the identity chain. Technical authentication can be intact while the person still authorises the wrong action. The implication is that fraud and identity programmes must be measured against decision quality, not just authentication strength.

Identity verification fails when authority is inferred from tone, urgency, or context. The article’s core lesson is that impersonation attacks exploit the social layer of identity, where people are conditioned to respond quickly to apparently legitimate requests. That means policy must assume the attacker already sounds credible. Practitioners should redesign approval paths so credibility alone never substitutes for verification.

Recovery workflows are privileged workflows, not administrative afterthoughts. Vishing and email-based impersonation often succeed by attacking reset, support, or escalation processes that were designed for convenience. Those paths usually have weaker scrutiny than frontline authentication, which makes them attractive entry points. Security teams should treat the recovery layer as a controlled privilege boundary, not a help desk convenience.

Social engineering is a fraud control problem as much as an IAM problem. The article connects identity, payment, and deception in one chain, which is exactly where many programmes are weakest. If a request can move from inbox to approval to payment without a second, independent trust check, the control design is incomplete. Practitioners need cross-functional ownership across IAM, finance, and security operations.

Named concept: trust-to-action bypass. This is the failure mode where a convincing human interaction short-circuits the controls that should separate identity proofing from business action. It matters because attackers do not need to defeat every control, only the one that turns trust into executable authority. Teams should map where that bypass exists in their own approval and support flows.

From our research:

• Average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• From our research: Only 44% of developers are reported to follow security best practices for secrets management, according to The State of Secrets in AppSec.
• From our research: Review the Ultimate Guide to NHIs , Key Challenges and Risks for the governance patterns that turn trust failures into identity exposure.

What this signals

Social engineering programmes need to be treated as identity governance work, not just awareness work. When a request can move from persuasion to approval without a second independent check, the organisation has built a trust shortcut that attackers will exploit. The control question is not whether people know the policy, but whether the workflow still allows a convincing impostor to win. See also the 52 NHI Breaches Report for how trust shortcuts become recurring failure patterns across identity types.

Trust-to-action bypass: this is the point where identity assurance is converted into an operational decision without a durable verification step. That concept matters because it explains why fraud, account recovery abuse, and impersonation often succeed even when authentication systems themselves are sound. Teams should map that bypass path across help desk, finance, and privileged workflows, then close the places where authority is inferred instead of verified.

Human identity controls increasingly intersect with machine and workflow trust as organisations automate more of the approval chain. That makes social engineering more dangerous, not less, because attackers only need one weak handoff between people, systems, and downstream execution. The practical signal is simple: if your approval process cannot survive impersonation, your governance model is still too dependent on user judgement.

For practitioners

• Harden approval paths for sensitive requests Require a second verifier for bank detail changes, payment exceptions, password resets, and privileged access requests. The goal is to stop a single persuasive interaction from becoming an authorised business action.
• Treat support and recovery as privileged access Apply step-up verification, call-back rules, and tighter logging to help desk resets, identity recovery, and account unlocks. These workflows are often the easiest place for an attacker to impersonate authority.
• Train staff on manipulation patterns, not slogans Use scenario-based exercises that cover urgency, authority, pretexting, and supplier impersonation. Measure whether people challenge unusual requests, not whether they can recite policy language.
• Separate payment control from message authenticity Validate any change to payee data through an independent channel and record the approval chain. Email authenticity alone is not a sufficient control for financial transfer decisions.

Key takeaways

• Social engineering succeeds because it attacks human decision points that technical controls do not fully verify.
• The evidence problem is not awareness alone, but the ability to turn deception into approval, payment, or access.
• Security teams should harden recovery, approval, and payment workflows so no single persuasive interaction can complete the action.

Key terms

• Social Engineering: Social engineering is the use of deception, urgency, or authority to persuade a person to take an action that benefits the attacker. It targets human judgement rather than software weaknesses, which makes it effective even when technical controls are otherwise well configured.
• Vishing: Vishing is voice-based phishing, where an attacker uses phone calls or voice messages to impersonate a trusted person or support function. It is especially dangerous in identity workflows because callers can pressure victims into resets, approvals, or disclosure without leaving the usual email trail.
• Recovery Workflow: A recovery workflow is the process used to restore access after a user loses credentials or cannot complete authentication. It is a high-risk identity boundary because it often grants privileged recovery powers, and attackers regularly target it as a shortcut around stronger front-door authentication.
• Trust-To-Action Bypass: Trust-to-action bypass is the failure mode where a person’s apparent credibility is allowed to trigger a business or access decision without an independent verification step. In practice, it is the gap between believing the request and validating that the request should be executed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Abnormal AI: a Vision 2023 session on social engineering with Rachel Tobac and James Linton. Read the original.