When should organisations require more friction for high stakes actions like account changes or payments?

Organisations should add more friction when an action is hard to reverse, carries financial loss, or affects account control. Examples include deleting data, closing accounts, increasing transfer limits, or approving a large payment. In those cases, confirmation steps and stronger authentication protect against errors, abuse, and unintended consequences.

When extra friction is the right design choice for irreversible actions

Higher-friction journeys are justified when a user action changes control, money, or trust in a way that cannot be safely undone with a simple retry. That includes account changes, payment approvals, transfer-limit increases, recovery-option edits, and administrative actions that expand privilege. The point is not to block legitimate users, but to make the action deliberate, attributable, and harder to carry out under coercion, mistake, or session compromise. For governance-heavy teams, this is where user experience becomes a security control.

For a control perspective, NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference for stronger authentication, approval, and auditability expectations around sensitive actions. In practice, many security teams discover that friction is missing only after a compromised session, workflow error, or policy exception has already created a hard-to-reverse loss.

How friction should scale with the stakes of the action

Good friction is proportional. Low-risk actions should remain fast, while high-stakes actions should add steps that improve confidence without creating so much delay that users bypass the process. The usual design pattern is to introduce extra verification at the point where the decision becomes consequential, not everywhere in the journey. That can mean step-up authentication, explicit re-entry of critical details, dual approval, out-of-band confirmation, or a waiting period for the highest-risk cases.

The key is to tie friction to the failure mode you are trying to prevent. If the main concern is accidental error, a clear review screen and confirmation prompt may be enough. If the concern is unauthorised account takeover, the control needs stronger evidence of user intent, such as a second factor, device-bound approval, or an approval from a separate trusted channel. If the concern is fraud or insider abuse, one-person approval is often too weak and the process needs segregation of duties or independent review.

Use extra friction when the action is hard to reverse or expensive to unwind.
Use stronger authentication when the action changes access, permissions, or payout destinations.
Use a second approver when the action creates material financial or privilege exposure.
Use delay or hold periods when immediate completion would defeat detection or recovery.

This guidance breaks down when the organisation cannot reliably identify which actions are truly high stakes, because inconsistent classification creates either blind spots or user fatigue.

Where friction helps, and where it becomes a bad trade-off

Tighter approval flows often reduce accidental loss and opportunistic abuse, but they also increase user effort, support load, and the temptation to route around controls. That trade-off matters because not every difficult action should be slowed in the same way. A password change after suspicious activity deserves a different treatment from a routine profile update, and a payment to a new beneficiary deserves more scrutiny than a recurring payment to an established payee.

There is also a practical distinction between friction that verifies intent and friction that merely annoys the user. Security teams should treat those as different outcomes. The right control should create a meaningful pause, proof of identity, or independent authorisation where the risk justifies it. The wrong control creates delay without improving confidence, which is why some organisations overuse generic confirmation pop-ups and still fail to stop abuse.

Industry consensus is strongest on the need for step-up controls for sensitive transactions. Less consensus exists on the exact threshold for triggering them, because the threshold depends on business model, fraud tolerance, regulatory duties, and how quickly the action can be reversed. For that reason, the threshold should be defined by risk category, not by convenience alone.

Risk and Threat Considerations

High-friction controls are most valuable where an action can transfer money, expand privilege, or change account recovery paths. Those actions are attractive because they often convert a temporary foothold into durable impact. The risk is not just fraud; it is also account takeover persistence, unauthorised privilege escalation, and operational loss from mistaken approvals.

Failure mechanism: attackers and abusers exploit low-friction flows by using stolen sessions, social engineering, or hurried approvals to complete irreversible actions before the organisation detects the compromise. Where approval paths are weak, the attacker may only need one accepted action to change payout details, weaken recovery, or lock out the real user.

Impact: the organisation can lose funds, lose control of an account, create unauthorised access paths, or face difficult recovery work after the action has already taken effect.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AA-03 — Identity Proofing and Authentication	Sensitive actions need stronger assurance that the actor is legitimate.
	PR.AA-04 — Access Permissions and Authorizations	High-friction actions often change permissions, limits, or account control.
Recommendation — Apply step-up authentication for high-stakes actions before state changes are approved. Restrict sensitive changes behind explicit authorization and role checks.
CIS Controls v8	5.3 — Manage Authentication and Session Management	Friction is often implemented through stronger re-authentication for critical actions.
	6.3 — Ensure Adequate Authentication and Authorization for Administrative Actions	Administrative or account-control changes need stronger approval than routine actions.
Recommendation — Re-authenticate users before allowing irreversible or high-value transactions. Require stronger approval for actions that alter accounts, limits, or privileged settings.
NIST SP 800-63	IAL2 — Identity Assurance Level 2	Higher-risk transactions may need stronger identity evidence than ordinary access.
Recommendation — Escalate identity assurance when the action has material financial or account-control impact.

Practitioner Guidance

What to prioritise: classify actions by reversibility and blast radius before deciding on friction. The highest priority is any action that can move money, change ownership, alter recovery options, or grant new access.

Decision rule: if an action would be painful or impossible to unwind after a mistake or compromise, require a stronger confirmation path; if it is routine and low impact, keep the journey simple so users do not learn to bypass it.

What to verify: confirm that the added step actually changes the attacker’s workload. A prompt that appears in the same compromised session may not be enough, while a distinct second factor, independent approver, or delayed execution can materially improve resistance.

What practitioners underestimate: friction is not only a fraud control. It is also an accountability control, because it creates a clearer record of who approved a consequential change and under what conditions.

Practitioner takeaway: the best friction is selective, not universal. Add it where the action changes irreversible state, and make sure each added step improves assurance rather than simply increasing delay.