How should organisations reduce fraud risk in digital identity programmes?

Why This Matters for Security Teams

Fraud risk in digital identity programmes is usually not a single control failure. It emerges when identity proofing, authentication, recovery, and transaction approval are treated as separate checkpoints instead of one assurance chain. Attackers look for the weakest step, especially where legitimate credentials, social engineering, or stolen session state can be used to look “normal” long enough to complete a transaction.

The scale of identity exposure makes this worse. NHIMG research shows that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, which is why identity abuse often starts before any obvious fraud alert fires. Guidance in the NIST Cybersecurity Framework 2.0 and NHIMG’s Ultimate Guide to NHIs both point to the same operational reality: identity controls must be tied to risk, not applied as a one-time gate.

In practice, many security teams discover fraud paths only after a recovered account is used for a payment or profile change that still appears fully authenticated.

How It Works in Practice

Reducing fraud risk means designing digital identity controls to evaluate trust continuously, not just at sign-in. Strong authentication is necessary, but it is not sufficient if the session can be hijacked, the account can be recovered through weak support workflows, or high-risk actions can proceed without additional checks. Current guidance suggests organisations should combine identity proofing, device binding, behavioural monitoring, and step-up verification at the transaction layer.

Start with assurance at onboarding and recovery. If identity proofing is weak, attackers can create synthetic identities or take over accounts through manipulated recovery channels. Then add device trust and session risk signals so the platform can detect when a known user is suddenly operating from a new device, location, or pattern of use. This is where identity fraud programs often fail: the account is valid, but the context is not.

Practitioners should also distinguish between authentication and authorisation for sensitive actions. A user may be allowed to access a dashboard, but not to change payout details, add a new beneficiary, or reset a recovery factor without additional friction. Transaction-level controls can include:

• step-up authentication for high-value actions
• out-of-band approval for account recovery or payment changes
• session scoring based on device, network, and behaviour
• limits or delays on first-time recipients and unusual transfers
• manual review queues for edge cases that exceed policy thresholds

NHIMG’s 52 NHI Breaches Analysis and the broader key risks discussion show how compromise often persists when organisations rely on static credentials or one-time verification alone. These controls tend to break down in high-volume consumer environments because aggressive friction reduction can create blind spots for sophisticated account takeover and mule-account activity.

Common Variations and Edge Cases

Tighter fraud controls often increase customer friction and operational cost, so organisations have to balance conversion against loss prevention. That tradeoff becomes especially visible in low-value consumer flows, where overly strict checks can drive abandonment, while high-risk financial flows require much stronger verification and monitoring.

Best practice is evolving, but a few patterns are consistent. First, recovery deserves the same scrutiny as primary login, because recovery abuse is a common fraud path. Second, risk scoring should use more than one signal, since device reputation alone can be spoofed and behavioural signals can be noisy. Third, static rules age badly. A fixed threshold for “unusual” activity rarely keeps pace with fraud rings that learn normal user behaviour and adapt.

There are also edge cases where step-up verification should be used carefully. For example, travellers, accessibility tools, shared devices, and business users working through VPNs can all trigger false positives. The answer is not to remove controls, but to make policy context-aware and review outcomes regularly. For governance teams, Top 10 NHI Issues reinforces a broader lesson that applies here too: identity programmes fail when visibility, revocation, and accountability lag behind real-world usage.

Organisations that want durable fraud resistance should treat identity assurance, session defence, and transaction controls as one system rather than separate security projects.

Related resources from NHI Mgmt Group

• Why do just-in-time access models reduce risk in privileged identity programmes?
• Why do silent data changes create governance risk for identity and security programmes?
• How can organisations reduce risk when changing authoritative DNS records?
• How can organisations reduce spoofing risk without overcomplicating email operations?