What should trust and safety teams review before adding more booking friction?

Why This Matters for Security Teams

Booking friction is not just a conversion decision. For trust and safety teams, it is a control decision that can either slow abuse or block legitimate demand. The main mistake is treating all bookings as equally risky, then applying blanket challenge logic that ignores context. Current guidance suggests friction should be tied to a defined risk signal, such as a payment change, device mismatch, or abnormal booking pattern, rather than applied pre-emptively across the board.

This matters because poorly targeted controls often push harm onto genuine customers while leaving organised abuse paths intact. NHI Mgmt Group notes in the Ultimate Guide to NHIs that 97% of NHIs carry excessive privileges, a reminder that over-broad permissions and over-broad controls tend to create the same failure pattern: too much reach, too little precision. Security teams should review friction as part of a risk policy, not a product habit. In practice, many teams discover the control is miscalibrated only after abandonment rates climb and abuse operators have already adapted.

How It Works in Practice

Effective booking friction starts with a simple question: what risk event justifies intervention? Teams should define the event first, then decide the minimum challenge needed to reduce abuse. That usually means moving from static rules to context-aware decisions at runtime, similar to how NIST Cybersecurity Framework 2.0 encourages organisations to align safeguards with risk outcomes rather than indiscriminate control placement.

In practice, teams review:

• Whether the friction is triggered by a meaningful change, such as a new card, account takeover signal, or suspicious velocity.
• Whether the step-up control is proportional to the risk, such as OTP, payment verification, or rate-limited review.
• Whether the same user action is being challenged repeatedly without evidence that the added friction improves abuse detection.
• Whether the control is harming high-intent customers, especially in mobile, family booking, or last-minute travel flows.

That review should also include operational evidence. If a challenge is added, teams should check whether fraud rates actually drop, whether attackers shift to another path, and whether customer support contacts increase. The Ultimate Guide to NHIs highlights how exposed and over-permissioned identity paths create systemic risk; booking systems behave similarly when every user is forced through the same barrier regardless of trust signals. The best practice is evolving, but the direction is clear: use event-based friction, measure outcomes, and remove challenges that do not change attacker behaviour. These controls tend to break down when the booking flow has many legitimate edge cases because false positives rise faster than the abuse signal.

Common Variations and Edge Cases

Tighter friction often reduces abuse, but it also increases abandonment and operational overhead, so organisations must balance protection against revenue and customer experience. That tradeoff becomes most visible in markets with thin margins, high mobile traffic, or heavy same-day booking behaviour, where even a small amount of extra friction can suppress legitimate transactions.

There is no universal standard for this yet, but current guidance suggests treating some situations differently. For example, a payment method change after account recovery deserves more scrutiny than a routine repeat booking from a known device. Likewise, high-value or high-resale inventory may justify stronger step-up controls than low-risk, low-value bookings. A useful pattern is to reserve friction for higher-risk actions and use softer signals, such as monitoring or queueing, for the rest.

Teams should also avoid confusing visibility with prevention. If a control only records suspicious behaviour but does not change the decision path, it is not booking friction, it is logging. The operational question is whether the added step changes attacker cost without materially increasing customer drop-off. In many environments, the control fails when fraud is distributed across many low-and-slow attempts, because per-event friction looks reasonable in isolation but becomes excessive at scale.

Related resources from NHI Mgmt Group

• How should security teams implement zero trust authentication without adding too much user friction?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?