Common signs include repeated credential prompts, password-related help desk calls, inconsistent adoption, and staff asking for exceptions or shortcuts. In a public-sector identity programme, those signals usually mean the control is technically compliant but operationally fragile.
When does access control become too hard to use?
An access control model is too hard when people cannot apply it consistently in normal work. The telltale signs are not just frustration, but repeated workarounds: users re-prompted too often, teams inventing exception paths, and managers seeing the policy used unevenly across similar tasks. That usually means the model is asking humans to carry too much cognitive load.
What user behaviour shows the model is failing in practice?
Look for friction that appears at the point of work, not just in policy reviews. Frequent password or approval prompts, help desk calls about access, and users delaying tasks until someone grants a shortcut are all signals that the control is imposing too much effort for the value it adds. IAM and IGA basics help explain why entitlement design and access governance need to stay usable, not merely correct.
Another warning sign is inconsistent adoption across teams. If one group follows the model and another quietly bypasses it, the control is too dependent on perfect user discipline. A good access control model should behave predictably across roles, systems and business units, so that people do not need to remember special rules just to get their work done.
Why do cumbersome controls create security and governance problems?
When access rules are harder to live with than to circumvent, people naturally optimise for productivity. That can produce shadow approvals, shared accounts, blanket exceptions, and overbroad access grants that survive long after the original task is complete. Authorisation Models Guide is useful here because the model choice affects how often users hit edge cases, how much context the policy needs, and whether access decisions stay understandable.
The risk is not only convenience loss. Hard-to-use models tend to generate exception creep, which weakens least privilege and makes governance hard to audit. When reviewers can no longer tell whether an exception is temporary or routine, the control starts drifting away from the intent of the policy. In practice, that is when a technically sound model becomes operationally fragile.
A second failure mode is that support teams absorb the complexity. If identity operations become a constant queue of access fixes, the organization may be compensating for a design problem with manual labour. That is a poor long-term control pattern because the process becomes expensive, slow, and highly variable depending on who is on shift.
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-6 — Least Privilege | Access models must stay usable while limiting access to what work needs. |
| Recommendation — Simplify access paths while preserving least privilege so users do not need workarounds. | ||
| CIS Controls v8 | CIS-5 — Account Management | User friction often shows up as account exceptions, shared access and support tickets. |
| Recommendation — Tighten account processes where repeated access exceptions or help desk calls appear. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Usability issues often indicate access rules that are correct on paper but hard to operate. |
| Recommendation — Review access control rules for usability, consistency and operational fit. | ||
Practitioner Guidance
What to prioritise: Start with the highest-friction journeys, the ones that generate repeated prompts, tickets, or exceptions. Those are usually the best indicators that the control is out of balance with how work actually gets done.
What to verify: Check whether the people asking for shortcuts share a legitimate workflow pattern, or whether the pain is coming from one-off policy exceptions that should be redesigned out. If the same exception appears repeatedly, treat it as a model flaw rather than an end-user discipline problem.
What good looks like: Users can complete routine tasks with a small, predictable number of access decisions, and support requests are concentrated around genuine edge cases rather than normal work.
Common mistake: Treating a spike in exception requests as proof that users need more training. Often it means the control is too coarse, too verbose, or too context-insensitive for the job it is trying to govern.
Practitioner takeaway: If users keep bypassing an access control model, the design is usually misaligned with real workflows, and the safest fix is often simplification before adding more enforcement.
Related resources from NHI Mgmt Group
- What are the signs that an authorization model is too weak for tenant-aware access control?
- What are the signs that role-based access control is becoming too hard to manage?
- What are the signs that access control is being applied too loosely?
- What are the signs that an AI agent access model is becoming too permissive?