Should social engineering be treated as an IAM problem or an awareness problem?

Why social engineering belongs to both awareness and IAM

social engineering starts as a behavioural deception, but the security impact is often an identity event. If a user approves an MFA prompt, resets a password, shares a one-time code, or grants an attacker access through help desk flows, the outcome is no longer just “bad judgement”, it is an access decision that changes who can act in the environment.

That is why the right framing is shared ownership. Awareness programs reduce susceptibility, while IAM defines what happens after a manipulation attempt reaches a control point. The practical question is not which team “owns” social engineering, but which verification path, recovery path, and escalation path will stop a convinced human from becoming an access pathway.

In mature environments, social engineering is treated as a control bypass problem as much as a training problem. The control weakness usually appears where human confirmation is accepted as proof of identity, especially in reset, recovery, delegation, consent, and exception handling.

Where the IAM failure actually appears

The IAM-relevant failure is usually not the initial phishing email or phone call. It is the downstream action: a password reset, MFA reset, session approval, privileged grant, or secret disclosure that the attacker can use immediately. That is why recovery design matters as much as login design. Account Recovery and Help Desk Security Guide is a useful reference for the exact point where social engineering crosses into identity compromise.

Help desk workflows are especially sensitive because they often sit outside strong interactive authentication. If caller verification, callback rules, escalation rules, and step-up checks are weak, the attacker does not need to defeat the primary MFA mechanism, they only need to persuade someone else to bypass it. The same pattern appears in third-party impersonation and help desk abuse, where the “attack” is really a trusted identity process being manipulated. Co-op cyber attack 2025 and Marks and Spencer cyberattack 2025 both illustrate how impersonation can be the entry point to broader compromise.

When social engineering reaches credential issuance, secret disclosure, or recovery approval, the question becomes whether IAM controls make the action observable, attributable, and reversible. If they do not, awareness alone cannot contain the incident.

How to split responsibility without splitting control

Awareness teams should own behaviour change, simulation design, and reporting habits. IAM teams should own the guardrails that make one mistaken action insufficient to create lasting access. Those guardrails include phishing-resistant authentication where possible, strong recovery verification, reduced help desk discretion, privileged step-up for reset actions, and audit trails for every exception.

A good operating model treats social engineering as a cross-functional escalation problem. Training should teach users what to refuse, but IAM should define what a reset agent, approver, or support analyst is allowed to do without secondary verification. Where access is high impact, a single human confirmation should rarely be enough.

• Use awareness to improve detection and refusal of suspicious requests.
• Use IAM to constrain resets, approvals, and secret exposure so one compromised conversation cannot become persistent access.
• Use monitoring to identify abnormal recovery spikes, repeated MFA resets, or unusual approval patterns.

For organisations with significant workforce identity exposure, the strongest control design usually combines recovery hardening and user education. Workforce Identity Security Guide and Identity Provider and SSO Security Guide both support the idea that identity controls and end-user resistance need to reinforce each other.

Risk and Threat Considerations

Social engineering becomes a higher-severity risk when it can trigger identity recovery, MFA reset, or secret disclosure. The attacker does not need technical exploitation if the environment allows a trusted human decision to mint new access or bypass a prior control.

Failure mechanism: The manipulated user, help desk analyst, or approver authenticates the attacker indirectly by resetting credentials, approving a session, or revealing a secret, which turns deception into real access.

Impact: The result can be account takeover, privilege escalation, lateral movement, data exposure, and in some cases destructive activity if the compromised identity reaches admin or device-management scope.

Practitioner Guidance

What to prioritise: Put the strictest controls around password reset, MFA reset, account recovery, delegated approval, and any process that can re-issue trust. Those are the points where a social engineering event becomes an IAM event.

What to verify: Verify that recovery actions require more than the same communication channel the attacker can already manipulate. If your team can approve a reset from the same email thread or phone call being abused, the control is too weak.

Common mistake: Treating awareness metrics, such as click rates or training completion, as proof that the identity layer is safe. A user can fail a simulation and still be protected by strong IAM, or pass a simulation and still be vulnerable if recovery is loosely governed.

Practitioner takeaway: The right security boundary is not “was the user fooled?”, it is “did the fooled user have the ability to create or extend access?” If yes, IAM must be in the control design, not just in the post-incident review.

Related resources from NHI Mgmt Group

• What breaks when social engineering testing is treated as a one-off awareness exercise?
• When does a machine identity become a compliance problem?
• What is the difference between human IAM controls and NHI governance?
• What problem does ownership attribution solve for service accounts and API keys?