How should security teams authenticate retail customers without slowing checkout?

Why This Matters for Security Teams

Retail checkout is a pressure test for identity design: customers expect instant flow, while attackers exploit every extra prompt to push abandonment, account takeover, and fraud. For returning users, the right control is usually not “more MFA everywhere” but the right assurance at the right moment. That means low-friction authentication for routine purchase steps, then step-up verification only when risk changes, consistent with NIST Cybersecurity Framework 2.0 and the practical lessons in NHIMG’s State of Secrets in AppSec.

The biggest mistake is forcing the same assurance level on every action. A customer adding an item to cart does not need the same controls as someone changing a delivery address, redeeming stored value, or recovering an account. Passkeys help because they reduce password reuse and phishing exposure, but the checkout flow still needs risk signals, device continuity, and clear fallback paths. In practice, many security teams encounter checkout friction only after conversion drops or abuse spikes rather than through intentional authentication design.

How It Works in Practice

The most effective pattern is to separate authentication from transaction risk. Returning customers can authenticate with passkeys at sign-in or re-authenticate silently with an existing session, then complete normal checkout without repeated challenges. When the action involves higher value or higher abuse likelihood, the system can ask for step-up verification, such as a passkey re-prompt, one-time code, or account recovery check. The decision should be based on context at runtime, not just a static role or a single login event.

Teams usually combine several signals:

• Device and browser continuity, including whether the session matches a known device.
• Transaction context, such as new shipping addresses, unusual redemption volumes, or gift card use.
• Behavioural risk, including velocity, bot-like navigation, and repeated failed attempts.
• Account history, such as recent password resets, support interactions, or prior fraud flags.

This is where modern guidance is evolving toward risk-based and context-aware authentication, as reflected in NIST CSF 2.0. Passkeys are especially useful because they remove password reuse from the equation and make phishing much harder, but they do not eliminate the need for session controls or anomaly detection. For teams measuring operational exposure, NHIMG’s LLMjacking report is a reminder that compromised identities can be abused extremely quickly once credentials are exposed.

In practice, the checkout stack should treat authentication as a graduated process: browse, buy, and recover are not equal trust states. These controls tend to break down when legacy commerce platforms cannot share risk state across web, mobile, and call-center channels because the customer is forced to prove the same identity multiple times.

Common Variations and Edge Cases

Tighter authentication often increases friction, so organisations must balance fraud reduction against conversion loss. That tradeoff is especially sharp for guest checkout, first-time buyers, and cross-border customers, where there may be no durable device history to lean on.

There is no universal standard for this yet, but current guidance suggests a few practical exceptions. High-risk account recovery should always be stronger than ordinary checkout, because recovery is where attackers often take control. Merchants selling digital goods or loyalty value may also need stricter step-up rules than physical-goods retailers, since the payout can be immediate and hard to reverse. For repeated low-value purchases from the same device, heavy prompts usually add little security and create avoidable abandonment.

Teams should also avoid confusing authentication with customer identification. A verified return customer can still behave fraudulently, and a new customer can still be legitimate. The best practice is evolving toward adaptive controls, supported by strong device binding, fraud analytics, and clear escalation paths when a transaction crosses a risk threshold. NHIMG’s DeepSeek breach underscores how quickly exposed identities and secrets can become an operational incident once trust assumptions fail.

Related resources from NHI Mgmt Group

• How should security teams authenticate AI agents in enterprise environments?
• How should SaaS teams authenticate users, partners, and workloads without mixing trust boundaries?
• How should security teams implement Client ID Metadata Documents?
• How should security teams reduce secrets leakage without slowing developers down?