Targeted Friction

Expanded Definition

Targeted friction is a risk-based security pattern that inserts extra verification, rate limits, step-up authentication, or temporary restrictions only when behaviour, device context, or session signals indicate elevated risk. The goal is to make attack paths harder without turning ordinary use into a constant obstacle. In mobile and web environments, this approach is often paired with anomaly detection, fraud controls, and identity signals so that the control is proportionate to the level of concern.

Definitions vary across vendors, because some teams use the phrase to describe customer experience tuning while others use it for security controls that adapt in real time. In NHI and agentic AI contexts, the same concept can apply to service accounts, API clients, and autonomous agents when their actions deviate from expected baselines. That distinction matters because friction aimed at a human user may look very different from friction applied to a token, workflow, or delegated automation. NIST Cybersecurity Framework 2.0 is useful here because its risk management approach supports proportionate, outcome-driven safeguards rather than blanket interruption.

The most common misapplication is treating targeted friction as a generic login slowdown, which occurs when teams add challenges to all users instead of reserving them for high-risk events.

Examples and Use Cases

Implementing targeted friction rigorously often introduces design and operations overhead, requiring organisations to balance abuse resistance against the cost of false positives and user drop-off.

• Prompting for step-up authentication when a sign-in originates from an unfamiliar device, unusual geography, or impossible travel pattern, rather than challenging every login.
• Requiring re-verification before a payment, profile change, or privilege escalation when the session carries a higher fraud or compromise score.
• Slowing or temporarily constraining repeated API calls from a service account that exceeds normal behaviour, while leaving routine machine traffic untouched.
• Adding challenge-response checks to suspected bot traffic in a mobile app without disrupting legitimate users who pass device and behaviour checks.
• Using policy-driven NIST Cybersecurity Framework 2.0-aligned controls to decide when additional friction is justified by risk signals.

In identity-heavy environments, targeted friction can also protect delegated access. A privileged session that suddenly requests secrets, modifies roles, or exports data may trigger extra review before the action completes. For autonomous tools and AI agents, that same pattern can pause a workflow until the system confirms intent, scope, or policy fit. Used carefully, it supports security without forcing every legitimate interaction through the same hurdle.

Why It Matters for Security Teams

Security teams need targeted friction because broad, untuned controls often create predictable workarounds, frustrated users, and hidden exceptions. When every action is treated as suspicious, people and systems eventually adapt by reducing compliance or seeking bypasses, which weakens control effectiveness. Proportionate friction helps preserve both security outcomes and operational continuity, especially where identity assurance, fraud prevention, and behavioural analytics must work together.

The identity connection is especially important for NHI governance. A token, API key, or agent credential can be legitimate yet still dangerous if it is abused from an unexpected context or begins acting outside its approved envelope. That is where targeted friction becomes a control strategy for humans and machines alike. It can force a fresh approval, token rotation, or session revalidation only when the risk signal justifies it, instead of interrupting every workflow. The concept aligns with the risk-based direction of NIST Cybersecurity Framework 2.0, where safeguards should be outcome-driven and responsive to changing conditions.

Organisations typically encounter the consequences of weak friction design only after fraud, account takeover, or automation abuse has already progressed, at which point targeted friction becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should fraud teams implement targeted friction without hurting conversion?
• When does zero trust IAM create more friction than risk reduction?
• How should organisations implement PSD2 controls without adding too much checkout friction?
• How should security teams implement zero trust authentication without adding too much user friction?