Because the first implementation choice often becomes the long-term operating pattern. When authentication or onboarding is cumbersome, teams create exceptions that may survive long after the original delivery pressure has passed. Those exceptions can weaken traceability, increase manual access handling, and make later audits harder because the real process no longer matches the documented one.
How Friction Becomes a Governance Problem, Not Just a Delivery Problem
Developer friction changes identity governance because teams optimise for shipment speed, not control quality, when the access path feels slow. The first workaround often becomes the production pattern. Once that happens, exceptions start to look normal, and the organisation inherits a control model that was never deliberately approved or reviewed.
That is why access design is a governance issue from day one. If the easiest path is a shared account, broad entitlement, or manual approval bypass, the system drifts toward informal control. IAM and IGA Basics is a useful starting point for understanding how authentication, authorization and lifecycle controls should work together rather than as separate shortcuts.
Friction also changes who owns the decision. When requests are hard to fulfil, engineers and project leads tend to create local exceptions, which can move access decisions away from the normal governance process. Over time, that weakens accountability because the real approval path is no longer the documented one.
Why Shortcuts Reduce Traceability and Raise Review Cost Later
The governance risk is not only that exceptions exist, but that they become hard to reconstruct. Manual approvals, temporary admin grants and one-off onboarding paths create access history that is scattered across tickets, chat, scripts and tribal knowledge. Later reviews become slower because auditors and control owners must reverse-engineer what actually happened.
This is where lifecycle discipline matters. A system that is painful to provision is often also painful to deprovision, recertify and classify. Joiner-Mover-Leaver (JML) Guide helps frame the issue as a lifecycle problem, not a one-time onboarding inconvenience, while Access Reviews and Certification Guide shows why stale exceptions become expensive to certify once they have been allowed to accumulate.
Friction also encourages teams to stop documenting edge cases properly. The result is a mismatch between policy and practice, where the policy says access should be reviewed and constrained, but the operational reality is a set of tolerated bypasses. That mismatch is itself a governance failure because it hides true entitlement exposure.
What Good Friction Looks Like in Identity Governance
Not all friction is bad. Some delay is appropriate when it prevents privilege creep, role explosion or unreviewed access. The practical question is whether the control path is annoying because it is thoughtfully governed, or annoying because it is poorly designed. Well-governed friction is predictable, time-bound and visible.
Useful design choices are the ones that make the secure path easier than the exception path. Role-based access, clear ownership, automated approvals for low-risk access and structured review for higher-risk access all reduce the temptation to create informal workarounds. Role Mining and Role Design Guide is relevant here because good role design reduces the pressure to invent ad hoc access patterns.
At the same time, governance should preserve visibility into exceptions rather than trying to eliminate every exception up front. If an exception is necessary, it should have a clear owner, expiry, and review point. That makes the exception measurable, which is the difference between controlled deviation and unmanaged drift.
Risk and Threat Considerations
When developer friction is high, organisations tend to normalise standing access, broad permissions, and hidden workarounds. That creates exposure because the access model becomes less reviewable, less attributable, and more attractive as a persistence path if an account or secret is later abused.
Failure mechanism: Slow onboarding or cumbersome auth pushes teams toward shared accounts, manual overrides, and long-lived exceptions that bypass ordinary lifecycle and approval controls.
Impact: The organisation accumulates undocumented privilege, weaker audit evidence, and larger blast radius when credentials or accounts are misused, lost, or left unrevoked.
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 sets 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 | Developer-created exceptions often bypass account lifecycle controls. |
| IA-5 — Authenticator Management | Workarounds often lengthen secret and credential lifetimes. | |
| AU-2 — Event Logging | Hidden exceptions weaken traceability unless access events are logged. | |
| Recommendation — Enforce accountable account lifecycle and revoke informal access paths promptly. Control authenticator issuance, rotation and retirement to limit exception drift. Log access changes and exception use so reviews can reconstruct actual practice. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access decisions need governed, reviewable control rather than ad hoc shortcuts. |
| A.5.18 — Access rights | Exception-heavy processes complicate granting, review and removal of rights. | |
| Recommendation — Define and enforce a consistent access control policy for exceptions and standard paths. Review access rights on a schedule and remove unmanaged exceptions. | ||
Practitioner Guidance
What to prioritise: Reduce the cost of the compliant path before you try to police exceptions. If the secure route takes too many handoffs, teams will keep creating informal ones that are harder to govern later.
What to verify: Check whether every exception has an owner, an expiry, and a review record that matches the actual implementation. If you cannot reconstruct the real approval path, the control is already weaker than the policy says.
Common mistake: Treating friction as a user-experience issue only. In identity governance, repeated friction is often a signal that the control model is poorly aligned to how teams actually build and release work.
Practitioner takeaway: The governance risk is not inconvenience itself, but the durable exceptions that inconvenience creates, because those exceptions become the hidden operating model unless they are deliberately designed to expire.
Related resources from NHI Mgmt Group
- Why does centralized identity verification create governance risk as well as developer efficiency?
- Who should own non-human identity governance when developer machines, cloud services, and automation all create secrets risk?
- Why do non-human identities create more audit risk than human accounts?
- Why do non-human identities create audit risk in modern environments?