User Friction

Expanded Definition

User friction is the measurable effort required for a person to complete an access, approval, or security workflow. In NHI governance, it includes repeated logins, manual approvals, extra context switching, password resets, exception handling, and policy prompts that slow legitimate work. Friction is not inherently bad, but when it is poorly designed it becomes a leading indicator of workarounds, shadow processes, and inconsistent enforcement.

Definitions vary across vendors when friction is treated as a pure usability metric, but in security operations it is better understood as an operational cost attached to control execution. That distinction matters because the same control can be effective and still create unnecessary friction if it forces users to repeat actions that could be automated or delegated safely. NIST frames secure operations around outcomes, governance, and continuous improvement in the NIST Cybersecurity Framework 2.0, which is useful when judging whether a process is deliberately strict or simply poorly implemented. In identity-heavy environments, friction should be assessed alongside risk, not after the fact.

The most common misapplication is treating all friction as evidence of stronger security, which occurs when teams measure resistance instead of whether the workflow actually reduces exposure.

Examples and Use Cases

Implementing user friction rigorously often introduces a real tradeoff: stronger controls can reduce convenience, so organisations must weigh adoption and speed against assurance and auditability.

• A developer must request manual approval every time a short-lived token is needed, causing delays that encourage token sharing instead of proper issuance.
• An operator must copy secrets between tools because the secrets manager is not integrated into the CI/CD flow, increasing step count and error risk.
• A service owner must open a ticket for every routine privilege change, even when the request is low risk and could be handled through policy-based automation.
• A security team notices repeated MFA prompts for the same trusted workflow, which signals control fatigue rather than meaningful risk reduction.
• An identity program tracks whether friction is driving bypass behaviour, using findings from the Ultimate Guide to NHIs to compare control design against common NHI failure patterns.

These examples align with identity and access guidance in the NIST Cybersecurity Framework 2.0 and with NHI operating patterns described in the Ultimate Guide to NHIs. The practical question is not whether a process feels hard, but whether the added effort blocks abuse or merely slows legitimate execution.

Why It Matters in NHI Security

User friction becomes a security issue when people bypass controls to keep systems running. In NHI environments, that usually means hardcoding secrets, reusing tokens, disabling approval steps, or creating overbroad exception paths. The result is often more dangerous than the original convenience problem, because friction pushes sensitive activity into channels that are harder to monitor, rotate, or revoke. This is especially relevant where humans provision, approve, or troubleshoot NHIs even though the identities themselves are machine-run.

The Ultimate Guide to NHIs notes that 96% of organisations store secrets outside of secrets managers in vulnerable locations, and friction is one of the reasons those unsafe patterns persist. The same governance logic applies to NIST Cybersecurity Framework 2.0 priorities around reducing operational weaknesses while preserving control effectiveness. For NHI security leaders, friction should be treated as a design signal: if a workflow is painful enough, users will find a shorter path around it.

Organisations typically encounter the consequences only after a breach, an outage, or an audit finding exposes the workaround, at which point user friction becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams implement zero trust authentication without adding too much user friction?
• How should security teams reduce phishing risk in MFA without creating more user friction?
• How should security teams implement stronger authentication without creating more user friction?
• Why do withheld password hashes create both user friction and security risk?