How should security teams overcome employee resistance when introducing new identity and access controls?

Start with the operational change, not the control itself. Security teams should explain why the new policy exists, involve affected users early, and train people on the specific behaviors expected of them. Resistance falls when the process is clear, responsibilities are explicit, and leaders treat adoption as part of business continuity rather than a one-time technical rollout.

Why adoption fails when identity controls are treated as a technical rollout

Employee resistance usually comes from the change in workflow, not from the underlying security objective. If people experience the new control as friction, ambiguity, or a hidden productivity tax, they will route around it. The practical answer is to frame the change as a business process update, explain the reason in plain language, and make the expected behavior obvious in the moment of use.

Resistance also increases when teams introduce controls before they have clarified who owns exceptions, how long enforcement will take, and what “good” looks like after rollout. Identity change is easier to absorb when users can see the operational boundary of the new rule, the reason it exists, and the path for escalation when the control blocks legitimate work.

Security teams should also recognize that adoption is partly a trust exercise. If employees believe the control was designed without their input, they often treat it as arbitrary. If they see that the policy maps to a real operational need, and that the rollout was shaped with affected groups, they are more likely to comply consistently instead of looking for workarounds.

How to reduce resistance through communication, involvement, and training

The most effective sequence is to explain the operational impact first, then the rule, then the behavior change. That means starting with the business case, using examples from the actual user journey, and training people on the exact decisions they must make, such as when to reauthenticate, when to request access, or when to use an approved workflow instead of a shortcut.

Early involvement matters because it exposes friction before it becomes widespread pushback. Pilot the process with representatives from the affected teams, collect objections while the design is still flexible, and use that feedback to remove unnecessary steps. The goal is not to remove every safeguard; it is to keep the control understandable, enforceable, and aligned with how work really happens.

Training should be specific and operational, not policy-heavy. Users need to know what changed, what the new default behavior is, and what happens when they are blocked. A short, role-based explanation usually works better than a generic awareness campaign because it gives people a concrete action to take rather than a broad message to remember.

Risk and Threat Considerations

Resistance becomes a security issue when users respond by bypassing the new control, reusing shared access, delaying enrollment, or requesting exceptions that quietly expand privilege. In identity and access programs, poor adoption often turns a well-designed control into a paper policy, which leaves the organisation exposed to unauthorized access and weak accountability.

Failure mechanism: The control is introduced without enough context, so users keep using old methods, create shadow workarounds, or pressure managers for standing exceptions. That weakens enforcement, reduces visibility, and can undermine the access model the control was meant to strengthen.

Impact: The result is not just lower compliance, but a larger attack surface, more inconsistent access decisions, and weaker evidence that the organisation can trust its identity processes during audits, incidents, or business disruptions.

Standards & Framework Alignment

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

OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	User resistance often drives workarounds that expose secrets and weaken identity controls.
	NHI-02 — Identity Lifecycle and Ownership	Successful adoption depends on clear ownership, onboarding, and exception handling for access changes.
Recommendation — Explain the workflow change clearly and remove shortcuts that encourage secret reuse or bypasses. Assign ownership for rollout, exceptions, and user communication before enforcement begins.
CIS Controls v8	6 — Access Control Management	Access control changes fail when users circumvent or resist new access decisions.
	5 — Account Management	Identity-control adoption depends on clear account responsibilities and predictable user-facing changes.
Recommendation — Document access changes in business terms and validate that users can follow the new process. Align account change communications and approvals with the actual roles affected by the rollout.
NIST CSF 2.0	PR.AC — Access Control	The topic centers on implementing and operationalising access control in a way users will follow.
	GV.OV — Oversight	Leadership support and adoption oversight are essential when new controls affect business continuity.
	PR.AT — Awareness and Training	The question explicitly requires changing user behaviour through training and explanation.
Recommendation — Implement access rules with user-impact communication and exception handling built into the rollout. Track adoption as an operational control objective, not just a technical deployment milestone. Train users on the specific behaviours and decisions the new identity control requires.
NIST SP 800-63	IAL — Identity Assurance Level	Identity control changes often alter assurance expectations and user enrollment burden.
	AAL — Authenticator Assurance Level	Authenticator changes can trigger resistance if the new authentication method is not explained and supported.
	FAL — Federation Assurance Level	Federated access changes require users to understand new trust boundaries and login behavior.
Recommendation — Match the assurance requirement to the minimum user friction needed for the risk being addressed. Roll out authenticator changes with role-based guidance and clear recovery paths. Communicate federation changes in terms of where users authenticate and what they can expect.

Practitioner Guidance

What to prioritise: Make the user journey clear before you enforce the new control. If the change adds a step, a prompt, or an approval, explain what problem it prevents and what people should do when it blocks legitimate work.

What to verify: Check whether affected users can complete their normal tasks without resorting to exceptions, informal approvals, or shared credentials. If they cannot, the rollout is too abstract or too disruptive, and adoption will degrade quickly.

Common mistake: Treating resistance as a messaging problem only. In practice, resistance often signals that the process design still contains avoidable friction, unclear ownership, or a poor fit with the actual operating model.

Practitioner takeaway: The best adoption strategy is to remove uncertainty before you add enforcement, because people are far more willing to follow a control they understand, can explain, and can actually use.