Selective friction is a control strategy that adds verification or delay only where risk signals justify it. In returns, it preserves a smooth experience for low-risk customers while using tighter checks, evidence demands, or manual review for claims with stronger abuse indicators.
Expanded Definition
Selective friction is a risk-based control pattern that inserts verification, delay, evidence collection, or human review only when a request, claim, or action crosses a defined risk threshold. In cyber and identity-heavy workflows, it sits between fully seamless automation and blanket step-up control, allowing low-risk paths to stay fast while high-risk paths receive additional scrutiny.
Definitions vary across vendors because selective friction is a design pattern rather than a formal standard. In practice, it is used to reduce abuse without degrading legitimate throughput, especially where signal quality is uneven and false positives are costly. It aligns closely with NIST Cybersecurity Framework 2.0 concepts for adaptive risk management, even though the framework does not name the pattern directly. For identity and NHI governance, the control logic often evaluates entitlements, request context, device posture, reputation, and history before deciding whether to slow or block an action.
The most common misapplication is treating selective friction as a universal slowdown, which occurs when organisations apply the same verification step to every user or request instead of only to elevated-risk cases.
Examples and Use Cases
Implementing selective friction rigorously often introduces an experience tradeoff, requiring organisations to weigh fraud reduction and assurance against abandonment, support volume, and operational latency.
- A returns portal allows instant refunds for low-value, low-risk customers, but asks for photo evidence and manual review when the claim pattern matches known abuse indicators.
- An identity workflow permits routine access changes without interruption, yet adds step-up verification when an Ultimate Guide to NHIs-style service account suddenly requests broader permissions or unusual API activity.
- A cloud admin console introduces a short delay and explicit confirmation before deleting a production secret, mirroring the kind of guardrail commonly recommended in NIST Cybersecurity Framework 2.0 governance workflows.
- A fraud operations team requires additional evidence only when shipment addresses, device fingerprints, or prior dispute history indicate a likely abuse ring.
- An agentic AI platform pauses a high-impact tool action until a policy check confirms that the requested operation matches the agent’s assigned scope.
NHIMG research shows that 97% of NHIs carry excessive privileges, which helps explain why selective friction is often paired with privilege review and contextual approval gates. In other words, the control is most useful where normal-looking requests hide disproportionate risk.
Why It Matters for Security Teams
Selective friction matters because most security teams cannot afford to treat every action as equally suspicious. If friction is too light, abuse slips through on the strength of speed and convenience. If it is too heavy, legitimate users and operators find ways around controls, weakening both governance and visibility. The strongest implementations reserve delay or proof for moments where the expected loss justifies the cost, which is why the pattern is relevant across fraud prevention, identity assurance, and NHI oversight.
For NHI governance, the same principle helps protect service accounts, API keys, and agent tool access when their behavior changes in ways that normal monitoring can detect but automatic blocking should not always trigger. NHIMG reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and that 91.6% of secrets remain valid five days after notification, underscoring how slowly abuse can be contained when controls are too coarse. Selective friction creates a middle path: enough resistance to expose misuse, not so much that routine work stalls.
Organisations typically encounter the consequence only after a fraud spike, privilege abuse incident, or compromised automation event, at which point selective friction becomes operationally unavoidable to address.
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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | Risk decisions should be proportionate to business impact and threat context. |
| NIST AI RMF | GOV-4 | Governance requires defining accountability for risk-based controls in AI-enabled decisions. |
| OWASP Non-Human Identity Top 10 | NHI governance emphasizes contextual controls around service accounts and secret use. | |
| OWASP Agentic AI Top 10 | Agentic systems need policy gates before high-impact tool actions are executed. | |
| NIST SP 800-63 | AAL2 | Assurance levels support step-up verification when risk exceeds baseline authentication. |
Tune friction thresholds to risk appetite so extra checks trigger only where loss potential warrants delay.
Related resources from NHI Mgmt Group
- 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?
- How should security teams replace traditional MFA without creating new access friction?
