How should security teams handle fraud and identity abuse in eCommerce journeys?

Why This Matters for Security Teams

eCommerce fraud is often treated as a payments problem, but the operational reality is closer to identity governance across the full customer journey. Synthetic registrations, credential stuffing, automated account recovery, and bot-driven checkout abuse all exploit weak assurance at different points. Security teams need to distinguish legitimate customers from adversarial automation without forcing every interaction through the same high-friction path.

That shift matters because abuse rarely starts at transaction time. It begins with account creation, device enrolment, password reset, and session handoff, where static rules and generic step-up controls are easiest to predict. NIST’s Cybersecurity Framework 2.0 is useful here because it frames identity as a continuous risk function, not a one-time login event. NHIMG’s Ultimate Guide to NHIs shows why this mindset matters: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a reminder that weak identity controls scale quickly once automation is involved.

In practice, many security teams encounter fraud only after chargebacks, account takeovers, or loyalty abuse have already become measurable losses, rather than through intentional design of the customer identity lifecycle.

How It Works in Practice

The most effective approach is to treat every eCommerce step as a policy decision that can change based on risk, context, and observed behaviour. Authentication confidence should be combined with device reputation, velocity, behavioural signals, and session continuity so the system can decide whether to allow, challenge, delay, or block. This is not just about stronger passwords or MFA. Current guidance suggests building a layered control plane that adapts to the specific action being attempted.

That usually means:

• Applying lower-friction controls for low-risk browsing, then escalating only when the journey becomes sensitive.
• Using step-up verification for account recovery, shipping changes, payout changes, and first-time high-value checkout.
• Correlating device and session signals across login, cart, and payment flows to spot automation and account takeover.
• Separating customer identity assurance from payment authorization so fraud rules do not become overly broad.

This is where NHI thinking becomes useful even for customer journeys. Fraud tooling increasingly depends on machine identities, API keys, bot detection services, and backend workflows that make real-time decisions. Those workloads should be governed with the same discipline outlined in Top 10 NHI Issues, especially when secrets, service accounts, or internal APIs are used to enrich customer risk scoring. The practical lesson is that identity abuse is rarely isolated to the front end; it often depends on compromised or over-privileged automation behind the scenes. Best practice is evolving toward policy-as-code, runtime evaluation, and short-lived credentials for the systems that score and act on fraud signals. These controls tend to break down when legacy commerce stacks require fixed trust between storefronts, payment services, and fraud engines because static integrations leave too much room for replay and privilege abuse.

Common Variations and Edge Cases

Tighter fraud controls often increase customer friction and operational overhead, requiring organisations to balance conversion rates against abuse reduction. That tradeoff becomes harder in subscriptions, marketplaces, and high-volume flash-sale environments where legitimate behaviour can look suspicious at peak traffic. There is no universal standard for this yet, so teams should expect to tune controls by channel, product value, and fraud tolerance.

One common edge case is account recovery. Even strong login controls can fail if recovery relies on weak email links, SMS-only verification, or knowledge-based checks. Another is guest checkout, where the absence of a durable customer profile reduces visibility and makes device and payment intelligence more important. A third is agent-assisted commerce, where customer service workflows can unintentionally bypass normal assurance steps and create a privileged path for fraud.

NHIMG’s 52 NHI Breaches Analysis is useful as a reminder that hidden trust paths are where abuse often concentrates, while The State of Non-Human Identity Security shows how confidence gaps persist when organisations rely on incomplete visibility and weak rotation discipline. For fraud teams, the analogue is clear: if the policy engine cannot see the full journey, it will overreact to noise and underreact to coordinated abuse.

Related resources from NHI Mgmt Group

• How should security teams handle identity risk when legacy infrastructure and AI threats collide?
• How should security teams handle control deficiencies in identity governance programmes?
• How should security teams reduce synthetic identity fraud in customer onboarding?
• How should security teams handle risks from AI browser extensions?