Identity Fraud Prevention Guide

Identity fraud is what happens when someone gets an account, a transaction or a benefit by pretending to be someone else, or someone who does not exist. It spans the whole customer lifecycle: synthetic and stolen identities at account opening, credential stuffing and phishing to take over existing accounts, bots that create fake accounts at scale, and mule accounts that move the proceeds. Fraud teams and identity teams often work separately, with different tools and data, and attackers exploit the gap between them. This guide explains the main types of identity fraud, the signals that reveal it, and how to combine identity, device and behavioural controls across onboarding, sign-in, recovery and transactions. It is written for fraud, customer identity and security teams, and for product owners who set friction.

Key takeaways

• Four points of attack: identity fraud happens at account opening, sign-in, account recovery and high-risk actions such as payments and payout changes. Controls are needed at each, and the weakest one sets the real level of protection.
• Synthetic identities are found by links, not single checks. They have no real victim to complain, so they surface through shared devices, phones, addresses and documents across applications.
• Account takeover is mostly an authentication problem. Phishing-resistant options such as passkeys, breached-password screening, rate limiting and bot defence remove most of it; recovery flows remove the rest or reopen the door.
• Device and behavioural signals add context that identity data alone cannot, but they are personal data. NIST SP 800-63A-4 requires a privacy risk assessment of fraud checks before they go live.
• Shared signals and shared ownership: fraud, identity and security teams need one view of the account, a named owner for account takeover, and a feedback loop from confirmed fraud into onboarding and authentication rules.

Types of identity fraud

The fraud types below differ in who the victim is, when the loss appears and which team is best placed to stop it. Naming them consistently matters: the Federal Reserve convened an industry focus group precisely because inconsistent definitions of synthetic identity fraud made it harder to identify and report. Its recommended definition is "the use of a combination of personally identifiable information (PII) to fabricate a person or entity in order to commit a dishonest act for personal or financial gain".

Each type has a dedicated NHI Mgmt Group guide. See the Synthetic Identity Fraud Guide, the Account Takeover Prevention Guide, the Money Mule Detection Guide and the Deepfake and AI Impersonation Guide.

Controls across the lifecycle

Place controls where each fraud type first becomes visible, and pass what each stage learns to the next.

Account opening

• Proof identity to a level that matches the product's risk. NIST SP 800-63A-4 describes resolution, validation and verification, with identity resolution as "the starting point in the overall identity proofing process, including the initial detection of potential fraud". See the Identity Proofing and KYC Guide.
• Look for linked attributes across applications: the same device, phone, email pattern, address or document image appearing under different names.
• Check the age and history of the email address and phone number supplied, and whether the number was recently ported (a SIM swap indicator). See the SIM Swap Fraud Guide.
• Use bot defence and rate limits on registration.
• For businesses, verify the entity and its beneficial owners. See the KYB Guide.

Sign-in

• Offer and encourage passkeys. NIST SP 800-63B-4 requires verifiers to offer at least one phishing-resistant option at AAL2 and states plainly that OTP and out-of-band methods are not phishing-resistant. See the Passwordless and Passkeys Guide and the MFA Guide.
• Screen new and changed passwords against a blocklist of commonly used, expected or compromised values, as SP 800-63B-4 requires, and throttle credential stuffing. See the Password Spraying and Credential Stuffing Guide. The 23andMe Breach 2023 showed the cost: more than 18,000 accounts were accessed with passwords reused from other sites, and the DNA Relatives feature exposed data on almost 7 million people.
• Detect impossible travel, new devices and anonymising infrastructure; step up rather than block when unsure.
• Revoke active sessions when credentials or recovery details change.

Recovery and profile changes

• Treat changes to email, phone, password, MFA and payout details as high risk, with step-up and cooling-off periods before money can move.
• Notify the customer independently. SP 800-63B-4 says account recovery "SHALL cause a notification to be sent to the subscriber", and that binding a new authenticator also requires notice, because these notifications help subscribers detect fraud.
• Do not let support staff or chatbots change recovery details without verification. In the Meta AI Instagram Account Takeover 2026, attackers asked an AI support assistant to link a new email address to target accounts; Meta said the system "did not properly verify" that the address matched the account, and its filing lists 20,225 people affected. See the Account Recovery and Help Desk Security Guide.

Transactions and high-risk actions

• Use transaction signing or dynamic linking for payments, so approval is tied to the amount and payee and a stolen session cannot redirect funds.
• Score behaviour during the session and add friction at the moment of risk, such as a new payee.
• Watch for mule patterns: dormant accounts that suddenly receive and forward funds, or many new accounts paying one beneficiary. See the Payment Fraud Guide and the Authorised Push Payment (APP) Fraud Guide.

What NIST expects of a fraud programme

SP 800-63A-4 added a fraud management section that is a useful template even outside US federal services. It requires credential service providers to run a documented fraud management programme, assess the privacy risk of every fraud check before implementation, give people a way to report suspected fraud, monitor how well fraud checks perform, and communicate suspected and confirmed fraud to relying parties. It lists recommended checks:

The same section makes a death records check mandatory for identity proofing processes under the guideline, noting it can help prevent synthetic identity fraud, the use of stolen identity information and exploitation by a close associate or relative. It also requires redress for applicants who fail fraud checks.

Signals that reveal fraud

No single signal is reliable alone. Combine weak signals into a score, remembering that each one also describes some genuine customers.

Device signals need a lawful basis. In the UK, the ICO's guidance on storage and access technologies says the consent rule in regulation 6 of PECR applies where fingerprinting stores or accesses information on a device, and gives fraud detection at account creation and sign-in as an example where it applies. The same guidance lists "preventing or detecting fraud" among activities likely to meet the strictly necessary exception, but only if the technology is used for that purpose alone. Document the purpose, keep fraud data out of marketing, and record the assessment. See the Device Intelligence and Fingerprinting Guide and the Identity Data Privacy and Consent Guide.

Bots and automation

Automated attacks drive credential stuffing, fake account creation, card testing and scraping. The OWASP Automated Threats to Web Applications project gives them stable names, including OAT-008 Credential Stuffing ("mass log in attempts used to verify the validity of stolen username/password pairs"), OAT-019 Account Creation, OAT-001 Carding, OAT-009 CAPTCHA Defeat and OAT-012 Cashing Out.

Defences work in layers:

• Rate limits by account, IP range, device and session, over both short bursts and long periods. OWASP's cheat sheet warns that proxy networks can keep per-address volume low even in large attacks.
• Bot detection that checks browser integrity, headless automation and behaviour, recognising that client-side checks "may be spoofed or bypassed" and need other layers behind them.
• Proportionate challenges that are accessible; OWASP notes CAPTCHAs can be broken by tools and services, and suggests watching solve rates for abnormal patterns.
• Breached credential response: MITRE ATT&CK lists proactively resetting accounts known to be in breached credential sets as a mitigation for T1110.004 Credential Stuffing.

See the Bot Management Guide.

AI agents and non-human actors in customer journeys

Customers are starting to send AI agents to shop, book and manage accounts for them, so some automation now acts with the customer's permission. Fraud controls need to tell declared agents, benign automation and abusive bots apart.

• Agent identification: the IETF Web Bot Auth working group is chartered to standardise ways of cryptographically authenticating automated clients, including "AI agents retrieving or interacting with content on behalf of end users". Its charter notes that IP allowlisting, User-Agent strings and shared API keys "have significant limitations". Authenticating the end user stays out of its scope, so the customer's delegation still has to be checked separately.
• Delegated authority: give agents scoped, revocable permission (for example, a spending limit and a payee list) rather than the customer's password. See the Agentic Commerce Identity Guide.
• Your own support agents: an AI assistant that can reset credentials or change recovery channels is a privileged workflow. The verification must be enforced in code, not left to the model, as the Meta case showed.
• Synthetic media: generative AI lowers the cost of forged documents, face-swap video and voice cloning. SP 800-63B-4 asks verifiers to check the integrity of biometric sensors to detect injection attacks and emulators, and SP 800-63A-4 requires manual review before declining an enrolment on a 1:N biometric match. See the Biometrics Guide.

Bringing fraud and identity together

SP 800-63A-4 recommends "close coordination of identity proofing and CSP functions with cybersecurity, privacy, threat intelligence, and program integrity teams", giving the example of payment fraud data revealing compromised accounts and weaknesses in proofing. In practice:

• Share signals in both directions: identity events such as MFA changes, recovery and new device bindings feed fraud scoring, and fraud decisions feed step-up and account restrictions.
• Agree who owns account takeover: identity, fraud or security. Unowned problems persist.
• Use common case management covering sign-in, device and transaction history.
• Feed confirmed fraud back into onboarding rules and models, and tell partners. SP 800-63A-4 asks relying parties to report fraud outcomes, positive and negative, back to their identity providers.

The Customer IAM (CIAM) Guide covers the identity platform side, and the Fraud and Cyber Convergence Guide covers operating models for joint teams.

Detection and monitoring

Most identity fraud shows in identity logs before it shows in losses.

• Credential stuffing: many failed sign-ins with distinct username and password pairs from one source, or low-volume failures spread across many sources and accounts. MITRE ATT&CK's detection strategy for T1110.004 describes sign-in failures using combinations "leaked from unrelated domains".
• Successful compromise: a correct password followed by a failed MFA challenge. OWASP recommends notifying the user in that case so they can change their password.
• Recovery abuse: recovery requests from new devices, several resets from different addresses, or a recovery channel change followed quickly by a payout change.
• Onboarding rings: clusters of applications sharing devices, phones, addresses or document images.
• Mule behaviour: rapid in-and-out flows, new payees added soon after account opening, and dormant accounts waking up.
• Defence health: OWASP advises that each defence should produce volume metrics for detected and mitigated attacks, so a silent failure of one layer is noticed.

Measuring fraud controls

Measure fraud outcomes and genuine customer friction together.

See the Identity Security Metrics Guide for how to report these alongside other identity measures.

Framework mapping

This table is an indicative NHI Mgmt Group alignment, not an official crosswalk. Control IDs were checked against NIST CSF 2.0, the NIST SP 800-53 Rev. 5 catalogue, the CIS Controls (control level, with safeguard text from the CIS Controls Assessment Specification) and the OWASP Automated Threats list. ISO/IEC 27001:2022 Annex A names come from a published Annex A index, as the standard itself is paywalled.

Common failure patterns

• Strong front door, weak back door: rigorous onboarding and MFA, but a recovery flow, help desk or chatbot that changes the email address on request. The Meta AI Instagram Account Takeover 2026 is the clearest recent example.
• Checking applications one at a time: each synthetic identity passes on its own; only the shared phone, device or address across dozens of applications gives it away.
• Passwords without breached-credential screening: reused passwords let attackers in at scale, as in the 23andMe Breach 2023, where the ICO later fined the company £2.31 million.
• OTP treated as strong: SMS and app codes are relayed by phishing kits and intercepted after SIM swaps; NIST does not count them as phishing-resistant.
• Signals collected without a lawful basis: device and behavioural data gathered for "fraud" and reused for marketing, which removes the exemption and creates regulatory exposure.
• No feedback loop: confirmed fraud cases stay in the fraud team's tool and never update onboarding rules, models or authentication policy.
• All automation treated as hostile: blanket bot blocking that breaks legitimate customer agents and pushes customers to share passwords with tools.

Implementation roadmap

Practitioner checklist

• Map fraud types to the lifecycle stage where each can be stopped, and name an owner for each.
• Proof identity by risk at onboarding and look for linked attributes across applications.
• Offer passkeys, enforce MFA for sensitive actions and screen passwords against breached lists.
• Protect recovery and profile changes with step-up, independent notification and cooling-off periods.
• Hold chatbots and help desk staff to the same verification rules as self-service, enforced in code.
• Layer bot defence, device intelligence and adaptive rate limiting, with a documented privacy basis.
• Monitor accounts after opening for mule and early-life fraud patterns.
• Share signals and case data between fraud, identity and security teams, and feed confirmed fraud back into rules.
• Distinguish declared customer agents from abusive bots and give agents scoped, revocable permissions.
• Offer redress for genuine customers who fail fraud checks.
• Measure both fraud outcomes and genuine customer friction.

Standards and references

• NIST: SP 800-63A-4, Identity Proofing and Enrollment
• NIST: SP 800-63B-4, Authentication and Authenticator Management
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• NIST: The NIST Cybersecurity Framework (CSF) 2.0
• CIS: The 18 CIS Critical Security Controls
• OWASP: Automated Threats to Web Applications
• OWASP: Credential Stuffing Prevention Cheat Sheet
• MITRE ATT&CK: Brute Force, Credential Stuffing (T1110.004)
• Federal Reserve FedPayments Improvement: Synthetic Identity Fraud
• ICO: Guidance on the use of storage and access technologies, What are the exceptions?
• IETF: Web Bot Auth (webbotauth) Working Group charter
• ISMS.online: ISO 27001:2022 Annex A Explained

Related NHI Mgmt Group resources: Customer IAM (CIAM) Guide · Identity Proofing and KYC Guide · Synthetic Identity Fraud Guide · Biometrics Guide · Financial Services Identity Security Guide