Should organisations treat scam prevention as part of identity governance?

Why Scam Prevention Belongs in Identity Governance

Scam prevention belongs in identity governance when the customer journey itself is the control boundary. If an attacker can steer a legitimate user through login, booking or payment steps, the organisation is not only defending a system, it is deciding how much trust to place in a session, a device, a claimant or a recovery path.

That matters because many scams do not need a software exploit. They succeed by abusing normal identity decisions: whether a login is real, whether a change request is genuine, whether a payment approval should be trusted, and whether a recovery action should be allowed to bypass the usual checks.

The practical consequence is that identity governance must cover the points where trust is converted into permission. That includes step-up verification for unusual behaviour, counterparty assurance before sensitive actions, and recovery workflows that do not let an attacker ride a compromised channel all the way to final approval.

Where Identity Governance and Scam Defence Overlap

Scam defence and identity governance overlap most clearly in flows where a verified account can still be manipulated into authorising the wrong outcome. Booking changes, payment releases, beneficiary updates, password resets and account recovery all create an opportunity for social engineering to masquerade as legitimate use.

Good governance therefore needs to treat the request path, not just the login event, as part of the control surface. A user may authenticate correctly and still be misled into approving a fraudulent action, so the governance question is whether the organisation can distinguish ordinary customer intent from a coerced or spoofed request.

That is why recovery design matters. If the fallback path is weaker than the primary path, scams often concentrate there. The safest design is to make higher-risk actions harder to complete through a single channel and to require stronger confirmation when the action changes money movement, account ownership, contact details or access recovery state.

What Organisational Controls Change When Scams Are Treated as Identity Risk

Once scam prevention is treated as identity governance, the control model shifts from one-time authentication to ongoing decision quality. The organisation needs to know which actions require additional verification, which signals should trigger step-up checks, and which recovery steps should be blocked or delayed when the risk profile changes.

This also changes incident handling. A scam is not only a fraud event, it can be a sign that a login session, recovery channel or delegated approval path has been socially engineered. The response should therefore include account review, session review and a check for any changes made through the same trust path.

For teams that manage customer journeys, this usually means aligning identity, fraud, support and operations around the same event model. If one team can override controls that another team depends on, the scammer will eventually find that seam and use it as the shortest path to an irreversible action.

Risk and Threat Considerations

Scams exploit trust relationships, not only technical weaknesses. When an organisation relies on a customer login or approval flow as proof of legitimacy, an attacker can target the person, the process or the recovery channel and still achieve a harmful business outcome without breaching the underlying system.

Failure mechanism: A legitimate user is manipulated into approving, resetting or redirecting an action that should have been challenged more strongly, so the attacker inherits trust through the normal identity process rather than breaking it.

Impact: The organisation can suffer fraudulent payments, unauthorised changes, support fraud, account takeover follow-on activity and avoidable recovery costs, especially when the same channel is used to approve both low-risk and high-risk actions.

Practitioner Guidance

What to verify: Check which customer actions are currently treated as “authenticated enough” even though they can cause irreversible harm. The important test is whether the control still holds when the user is pressured, distracted or acting through a support channel.

Decision rule: If the action changes money movement, access recovery, beneficiary details or account ownership, require a stronger approval path than the one used for ordinary sign-in. Do not let the recovery process become the easiest route to the highest-risk outcome.

What good looks like: The business can show that risky actions have explicit step-up controls, clear fraud triggers and a recovery workflow that is harder to abuse than the primary login flow. Support staff should be able to explain why a request was blocked or escalated.

Practitioner takeaway: Treat the scam as an identity problem when the attacker is exploiting trust in the channel, because the control objective is not simply to authenticate the user, but to prevent a legitimate identity from being tricked into authorising the wrong action.

Related resources from NHI Mgmt Group

• Should organisations treat browser extensions as part of identity governance?
• When should organisations treat agent intent as part of identity governance?
• Should organisations treat semantic governance as part of identity governance?
• Should organisations treat workload communication policy as part of identity governance?