Subscribe to the Non-Human & AI Identity Journal

How should teams reduce friction in customer identity journeys without weakening security?

Start by removing avoidable reauthentication, broken reset flows, and unnecessary account creation steps from high-value journeys. Then add adaptive verification only where context changes, such as a new device or location. The goal is not zero friction, but friction that tracks risk rather than blocking ordinary customers.

Why This Matters for Security Teams

Customer identity journeys shape conversion, trust, and fraud exposure at the same time. When sign-in, recovery, step-up verification, and device trust are too rigid, legitimate users abandon the journey. When they are too loose, attackers exploit password reset, account takeovers, and session hijacking. Current guidance suggests that the right balance comes from risk-based decisions, not blanket friction.

The challenge is that most organisations still treat every customer like a high-risk exception or a low-risk default. NIST Cybersecurity Framework 2.0 emphasises continuous governance and adaptive protection, while NHIMG research shows how identity controls fail when teams do not understand where exposure actually lives. In the Ultimate Guide to NHIs, NHIMG reports that 79% of organisations have experienced secrets leaks, which is a reminder that weak identity controls create real operational damage, not just theoretical risk. In practice, many security teams encounter conversion loss only after a reset flow, MFA challenge, or account creation step has already frustrated customers.

How It Works in Practice

Reducing friction without weakening security means moving from static rules to contextual decisioning across the journey. Start by mapping the highest-friction customer moments: password resets, first-time device use, new session login, profile changes, payment actions, and account recovery. Then remove redundant prompts where the risk is already low, while preserving step-up controls when context changes materially.

Security teams should treat identity signals as inputs to a runtime decision, not as a single yes-or-no gate. Common signals include device reputation, location change, velocity, session age, failed attempts, and recovery channel trust. If the context is normal, allow the customer through with minimal interruption. If the context is unusual, add verification that is proportionate to the risk.

  • Use passwordless or passkey-enabled paths where possible to eliminate repeated credential entry.
  • Keep recovery flows short, but require stronger proof when the user requests a reset from an unfamiliar device.
  • Limit account creation to cases where the customer truly needs a persistent profile, not every first transaction.
  • Apply step-up verification only at sensitive actions, such as payout changes or account recovery.

This aligns with the NIST Cybersecurity Framework 2.0 approach to risk-informed protection, and with NHIMG guidance in the Top 10 NHI Issues, which highlights how overexposed identity controls create avoidable attack paths. The operational goal is to make security invisible during normal use and visible only when the context justifies it. These controls tend to break down when legacy IAM systems cannot consume real-time risk signals or when every channel uses a different identity policy engine.

Common Variations and Edge Cases

Tighter authentication often increases support load and abandonment risk, so teams have to balance fraud reduction against customer effort. There is no universal standard for this yet, especially across regulated industries, high-risk transactions, and multi-device households.

One common edge case is account recovery. It is tempting to simplify recovery to reduce drop-off, but recovery is also a top takeover path. Best practice is evolving toward layered recovery: allow low-friction options for routine cases, but require stronger proof when the request comes from a new device, a high-risk geography, or a recent session change. Another edge case is shared devices, where device trust may be less reliable and session persistence should be shorter.

Teams should also avoid assuming that more MFA always means more security. If the second factor is easy to social-engineer or too disruptive, attackers and customers both adapt around it. The safer pattern is adaptive verification tied to the specific action, not to the user’s entire relationship with the brand. NHIMG’s 52 NHI Breaches Analysis is a useful reminder that identity failures usually compound when controls are either too weak or applied too broadly.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 PR.AA Adaptive customer verification supports identity assurance and access decisions.
OWASP Non-Human Identity Top 10 NHI-01 Overly broad identity flows can mirror excessive privilege and weak lifecycle controls.
NIST AI RMF GOVERN Risk-based identity journeys need governance for consistent, accountable decisions.

Reduce standing access in customer flows and step up only when risk context changes.