Friction Budget

The amount of challenge an organisation can introduce before legitimate users start abandoning the journey. In fraud-heavy environments, it becomes a governance constraint, not just a UX preference, because every extra step has both security value and conversion cost.

Expanded Definition

Friction Budget is the practical ceiling on how much challenge an organisation can add before legitimate users stop completing a journey. In NHI security, the concept matters because authentication, approvals, rotation prompts, and step-up checks all create measurable resistance that can either reduce abuse or block legitimate operations. The term is not a formal standard, and usage in the industry is still evolving, so teams should treat it as a governance lens rather than a fixed metric.

In practice, friction budget sits at the intersection of security design and operational adoption. A control can be technically sound and still fail if it adds too many steps for developers, operators, or automated workflows. That is why it is useful to compare it with guidance from the NIST Cybersecurity Framework 2.0, which emphasises risk-based control selection rather than blanket burden. NHI teams also use this lens when deciding whether a control belongs in the default path, a high-risk exception path, or a back-office review process. The most common misapplication is treating all friction as beneficial, which occurs when organisations add approval steps to every secret or agent action without considering task frequency, urgency, and failure impact.

Examples and Use Cases

Implementing friction budget rigorously often introduces a tradeoff between stronger verification and higher abandonment, requiring organisations to weigh abuse resistance against user and operator delay.

• A developer rotating a service account token may accept a one-click approval in a low-risk environment, but abandon a workflow that requires multiple ticket handoffs for every rotation.
• An AI agent with tool access may need step-up confirmation before moving funds or changing production access, while routine read-only retrieval stays seamless.
• A security team may tolerate extra challenge for privileged secrets checkout, but not for every build pipeline execution, where delay would break delivery cadence.
• After repeated secret leakage, an organisation may raise friction by forcing vault access and expiring local credentials, while documenting the exception path in the Ultimate Guide to NHIs.
• Teams designing passwordless or token-based access often study the same balance in NIST Cybersecurity Framework 2.0 terms by mapping the control to the risk level of the workflow.

In mature environments, friction budget is reviewed per journey, not as a single enterprise-wide value. A privileged admin flow can absorb more challenge than a service-to-service call, and a remediation workflow can absorb more delay than a monitoring heartbeat. The same pattern applies to NHI offboarding, where a slightly slower but auditable path may be acceptable if it prevents orphaned access.

Why It Matters in NHI Security

Framing challenge as a budget helps organisations stop overcorrecting after an incident. NHI environments are particularly sensitive because non-human credentials are numerous, persistent, and often embedded in automation. NHIMG research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 79% have experienced secrets leaks, with 77% of those incidents causing tangible damage, according to the Ultimate Guide to NHIs. That reality makes it tempting to add controls everywhere, but poorly calibrated friction can push teams toward workarounds such as credential copying, bypass paths, or shadow automation.

Used well, the concept helps security leaders place the strongest friction where blast radius is highest: secret issuance, privilege elevation, production writes, and agentic actions with external side effects. It also forces clearer governance decisions about which workflows must remain smooth to preserve adoption. The right balance is not about making access easy; it is about making the risky path costly while keeping legitimate operations viable. Organisations typically encounter the cost of bad friction only after a breach investigation reveals that users circumvented controls, at which point friction budget becomes operationally unavoidable to address.

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?