Customers abandon when verification is poorly timed, repetitive, or unexplained. In consumer journeys, any extra step can feel like suspicion rather than protection, especially when the user is trying to complete a time-sensitive purchase. Clear trust signals and proportionate controls reduce that drop-off.
Why This Matters for Security Teams
Booking abandonment is often treated as a conversion problem, but for identity teams it is also a trust design problem. Verification is meant to reduce fraud, bot activity, and account takeover risk, yet it can create friction if it appears at the wrong moment or asks for more data than the user expects. The security issue is not the existence of the check, but whether it is proportionate, explainable, and aligned to the risk being managed. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports using controls that are appropriate to the asset and the threat, rather than applying the same burden to every transaction.
In practice, teams often discover the damage only after checkout metrics fall, chargebacks rise, or support complaints reveal that customers felt blocked rather than protected. The real failure is usually not weak verification, but poor orchestration between fraud, compliance, product, and UX owners. In practice, many security teams encounter abandonment only after a revenue or trust decline has already occurred, rather than through intentional journey testing.
How It Works in Practice
identity verification causes abandonment when it interrupts momentum, creates doubt, or asks the user to solve a problem the business has not explained. A user who has already selected dates, entered payment details, and reached final confirmation expects the next action to be fast and familiar. If the system suddenly demands document upload, repeated selfies, or multiple challenge rounds, the customer may interpret the step as a warning sign rather than a safeguard.
Operationally, the best approach is to match assurance to risk. Lower-risk bookings may only need lightweight email or phone verification, while higher-risk paths may justify step-up checks, fraud scoring, or document validation. The control should be visible enough to feel legitimate, but not so intrusive that it breaks the journey. Identity governance also matters when personal data is collected, retained, or shared across vendors. For regulated environments, frameworks such as eIDAS 2.0 and FATF Recommendations reinforce the need for proportionate identity assurance and documented customer due diligence.
- Place verification before the user invests too much effort, or explain clearly why it appears later.
- Use one strong check where possible instead of several smaller, repetitive prompts.
- Re-use trusted signals across the journey so customers are not re-authenticated unnecessarily.
- Reserve higher-friction checks for higher-risk bookings, suspicious patterns, or policy triggers.
- Provide concise language that explains what is being verified and why it protects the customer.
These controls tend to break down when booking flows depend on multiple vendors, because inconsistent handoffs make the experience feel duplicated and unreliable.
Common Variations and Edge Cases
Tighter identity verification often increases fraud resistance and compliance confidence, but it also raises abandonment risk, so organisations must balance assurance against completion rate. That tradeoff is especially sharp in travel, ticketing, hospitality, and high-demand retail, where users expect speed and may compare one provider against another in seconds. Best practice is evolving, and there is no universal standard for how much friction is acceptable in every journey.
Some bookings justify stronger checks because the downstream risk is higher. High-value purchases, refunds to alternative payment methods, cross-border activity, or repeated failed attempts may warrant stronger challenge steps. Conversely, first-time users in a trusted network, returning customers with verified profiles, or low-value transactions may only need a light confirmation. The key is to avoid treating verification as a fixed gate; it should behave like a risk signal that adapts to context.
Edge cases usually appear when legal, fraud, and product teams optimise for different outcomes. Compliance may prefer more evidence, fraud teams may prefer stricter gating, and product teams may prefer fewer interruptions. The best designs use transparent copy, progressive verification, and clear fallback paths when automated checks fail. That becomes especially important where identity data must satisfy both user trust and regulatory accountability.
In practical terms, the most effective journeys make verification feel like part of the service promise, not an obstacle to it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | Identity checks should be risk-based and proportionate to the transaction context. |
| NIST SP 800-53 Rev 5 | IA-1 | Identity proofing and authentication need clear policy and ownership across the journey. |
| NIST SP 800-63 | IAL | Identity assurance levels help calibrate how much evidence is actually needed. |
Use risk-based access and verification steps that match booking sensitivity instead of applying one fixed gate.
Related resources from NHI Mgmt Group
- How should organisations handle identity verification when deepfakes can mimic real users?
- What is the difference between probabilistic and deterministic identity verification?
- Why do identity issues cause more downtime in manufacturing than teams expect?
- Why do hybrid identity architectures matter for cross-border verification?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
