Join our Newsletter — 33% off our NHI Course

Should IAM teams prioritise convenience or security when changing user behaviour?

They should do both at once, because adoption depends on perceived utility as much as control strength. A secure workflow that feels harder to use will trigger resistance, while a convenient one that visibly improves everyday tasks is far more likely to stick. The best programmes reduce friction without weakening governance.

Why convenience and security are not opposites in IAM change management

For behaviour change, the real choice is not convenience versus security, it is whether the secure path is also the easiest path to complete a task. If users must work around controls to get work done, they will. If the control reduces effort, removes repeated prompts, or fits the workflow, adoption usually improves and security outcomes become more durable.

That means IAM teams should treat convenience as a control design requirement, not a luxury. Friction is not automatically good, and strong policy is not automatically effective if it drives shadow processes, approvals fatigue, or local exceptions that quietly weaken governance.

Good behaviour change work usually starts with the tasks users perform most often: sign-in, access request, approval, privilege elevation, recovery, and recertification. If these moments are slow or confusing, people infer that the security process is a tax rather than a safeguard.

What changes user behaviour more effectively than adding more policy

Users change behaviour when the secure option is visibly better in day-to-day use. That can mean fewer steps, clearer outcomes, better defaults, stronger automation, or fewer interruptions once trust has been established. The practical goal is to make the protected path feel normal, reliable, and worth repeating.

Teams often overestimate the effect of awareness messages and underestimate the effect of workflow design. A policy reminder rarely overcomes a clumsy control, but a well-placed default, sensible approval rule, or time-saving self-service step can shift behaviour with much less resistance.

This is where identity and access design matters most. Access request flows, MFA prompts, admin elevation, and account recovery should be tuned so that the secure action is the shortest path to legitimate work. When users experience the control as helpful, compliance becomes behaviour, not just instruction.

How IAM teams should decide where to draw the line

The right question is not how much friction security can tolerate, but where friction actually improves assurance. Some controls should stay strict because the action is high impact, such as privilege elevation or recovery of a sensitive account. Other controls should become lighter because they repeat frequently and add little marginal protection.

IAM and IGA basics is useful here because it distinguishes authentication, authorisation, provisioning, and access review, which should not all be treated with the same user experience. The most effective programmes separate high-risk decisions from routine ones, rather than burdening everything with the same level of friction.

In practice, teams should look for places where a secure default can replace repeated user choice, or where a one-time approval can replace ongoing manual effort. That usually improves both governance and user acceptance, provided the control remains measurable and revocable.

Risk and Threat Considerations

When security feels harder than the work it protects, users create workarounds, reuse weak patterns, or ask for standing exceptions. That can expand access, obscure accountability, and increase the chance that sensitive actions are performed through unofficial paths that are harder to monitor.

Failure mechanism: Overly rigid IAM controls can push users toward shadow IT, shared credentials, approval bypasses, or delayed compliance with access reviews, which weakens the intended control even when the policy looks strong on paper.

Impact: The organisation gets lower adoption, weaker observability, and more exception handling, which can translate into privilege creep, missed revocations, and a larger blast radius if an account is compromised.

Standards & Framework Alignment

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

NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework Control / Reference Relevance
NIST SP 800-53 Rev 5 AC-2 — Account Management User behaviour change in IAM depends on account lifecycle and access workflow design.
IA-2 — Identification and Authentication (Organizational Users) Behaviour changes around sign-in and MFA are driven by usable authentication design.
AC-6 — Least Privilege Balancing convenience and security depends on limiting privilege without overburdening users.
Recommendation — Streamline account workflows so secure access is the default, revocable path. Use strong but low-friction user authentication for routine access. Apply least privilege while preserving efficient legitimate access paths.
CIS Controls v8 CIS-5 — Account Management Account and access controls shape user behaviour and exception pressure.
CIS-6 — Access Control Management Access control design must reduce friction without weakening enforcement.
Recommendation — Automate account governance so users do not need unsafe workarounds. Tune access controls to keep secure actions simple and routine.
ISO/IEC 27001:2022 A.5.15 — Access control Access control policy needs usable workflows to be effective in practice.
Recommendation — Design access control rules that users can follow without bypassing them.

Practitioner Guidance

What to prioritise: Fix the highest-frequency workflows first, because they shape everyday behaviour more than one-off security events do. If users repeatedly touch sign-in, request, elevation, or recovery, those journeys should be the first candidates for simplification.

Decision rule: If a control adds friction but does not materially increase assurance for that task, simplify it; if the action changes privilege, access scope, or recovery authority, keep stronger checks even if the experience is less convenient.

What to verify: Measure completion rates, exception requests, abandonment points, and whether users are circumventing the approved path. A “successful” control that users routinely work around is not actually successful.

Practitioner takeaway: The best IAM change programmes do not trade security for convenience, they design for secure convenience so the control survives contact with real work.