How should security teams reduce risky user behavior without making controls harder to use?

Why friction-heavy controls fail to change behavior

People rarely choose the risky option because they believe it is safe. More often, they choose it because the secure path is slower, harder to find, or interrupts urgent work. When a control adds extra steps without reducing uncertainty or effort, users learn to bypass it, defer it, or invent workarounds that preserve speed but weaken security.

That is why “more enforcement” is not the same as “better control.” If the control path conflicts with how people actually work, the organisation is left with policy compliance on paper and inconsistent behavior in practice. The real design goal is to lower the effort cost of the secure action until it competes with the risky shortcut.

What makes the secure choice easier to follow

Reducing risky behavior usually means removing unnecessary decision points, not adding more reminders. Teams should prefer controls that are obvious, consistent, and available at the moment of action, because users are least tolerant of friction when they are busy, under time pressure, or trying to recover from an exception.

Effective controls also reduce ambiguity. Clear defaults, safe pre-configuration, and just-in-time prompts work better than broad warnings because they tell the user exactly what to do next. Education helps when it is tied to the specific risky action, but education alone rarely survives a workflow that keeps rewarding speed over caution.

Where possible, the secure path should be the shortest path. That can mean fewer approvals, cleaner interfaces, safer defaults, or automation that handles routine decisions while still preserving review for genuinely high-risk cases.

How to balance usability and control strength

The right question is not whether a control is strict enough, but whether it changes behavior without creating a shadow process. A control that users can predict, understand, and complete quickly is more likely to be followed consistently than one that is technically strong but operationally brittle.

Teams should segment controls by risk level. Low-risk activities should be low-friction; high-risk actions should trigger stronger checks only where the extra effort is justified by the blast radius of the action. This keeps controls proportionate and avoids training users to treat every safeguard as an obstacle.

Good programs also test controls with real users before broad rollout. If people routinely fail a step, delay it, or ask peers to do it for them, that is a usability defect as much as a policy issue. The design should be revised before the pattern becomes normalised.

Risk and Threat Considerations

Friction-heavy controls often create the exact behavior they are meant to prevent: users route around them, reuse weaker alternatives, or postpone secure steps until after the risky action has already happened. That creates exposure in both insider and external threat scenarios, because attackers often benefit when people normalise shortcuts and exception handling.

Failure mechanism: The secure workflow becomes slower than the insecure workaround, so users choose convenience under pressure and the organisation loses control over where risky actions happen.

Impact: Control adoption drops, shadow processes grow, and security teams get weaker visibility into real user behavior, which makes both prevention and detection less reliable.

Practitioner Guidance

What to prioritise: Remove the top one or two workflow frictions that most often push users toward shortcuts. The highest-value fixes are usually the ones that reduce repeated interruptions, unclear prompts, or unnecessary manual approvals.

What to verify: Check whether users can complete the secure path in the same context where the risky action occurs, without having to open a separate process, wait for another team, or remember an exception procedure. If they cannot, the control is likely to be bypassed.

Common mistake: Treating education as a substitute for design. Training helps people understand the risk, but it does not compensate for a control that is slower or harder than the unsafe alternative.

Practitioner takeaway: The best controls change the default behavior of the workflow, not just the tone of the policy, so security teams should optimise for adoption and repeatability as much as for restriction.

Related resources from NHI Mgmt Group

• How should security teams use human risk data to reduce risky behaviour without relying on blanket controls?
• How should security teams use user activity monitoring to detect risky behavior without creating an unmanageable review burden?
• How should security teams reduce account recovery risk without making sign-in harder?
• How should security teams secure telehealth access without making care harder to use?