What do organisations get wrong about access friction and identity security?

Why This Matters for Security Teams

Access friction is often discussed as a usability problem, but for identity security it is usually a signal that the control design is wrong. When approvals are slow, credentials are over-scoped, or authentication steps do not fit the workflow, people and automation create workarounds that weaken traceability. That is how shadow access, shared secrets, and informal exceptions enter the environment.

The issue is especially visible in non-human identity programs, where long-lived tokens and brittle approval paths create pressure to bypass the intended process. NHIMG research shows that 97% of NHIs carry excessive privileges and 79% of organisations have experienced secrets leaks, which makes “minor” friction a direct exposure path rather than a comfort issue. The patterns documented in the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 both point to the same operational lesson: if access is painful, policy will be bypassed.

In practice, many security teams encounter credential sharing and exception sprawl only after an incident review, rather than through intentional control testing.

How It Works in Practice

Effective identity security reduces friction by making the secure path the easiest path. That means replacing coarse, standing permissions with context-aware access, shorter-lived credentials, and tighter alignment between request, approval, and actual task. In human workflows, this often means stronger federation, better single sign-on, and fewer manual re-authentication loops. For NHIs, it usually means workload identity, short TTL secrets, and automated issuance and revocation instead of static secrets stored in code or tickets.

Practitioners should distinguish between necessary friction and accidental friction. Necessary friction is a deliberate control such as step-up authentication for privileged actions or JIT access for production changes. Accidental friction is a broken process, such as waiting on a ticket queue for routine secret rotation or forcing operators to reuse an old token because renewal is too complex. Current guidance suggests that the latter creates far more risk than it removes, because it pushes users toward bypasses that are invisible to audit logs.

• Use policy-driven access decisions so approval depends on context, not just role membership.
• Issue credentials just in time and revoke them automatically when the task ends.
• Prefer workload identity and federated trust over static shared secrets.
• Log the request, the decision, and the duration of access so exceptions remain accountable.

The operational goal is not zero friction, but low-friction controls that preserve security intent. NHIMG’s research on the 52 NHI Breaches Analysis shows how poorly governed credentials repeatedly turn process shortcuts into exposure, while the NHI management patterns in the Key Challenges and Risks section reinforce why manual handling does not scale.

These controls tend to break down when access is embedded in legacy batch jobs, shared admin accounts, or tool chains that cannot support short-lived federation because revocation and attestation are not natively available.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance reduced exposure against change-management speed. That tradeoff is real, especially in environments with legacy applications, incident-response break-glass paths, or third-party integrations that were never built for JIT access. Best practice is evolving, and there is no universal standard for every edge case.

One common mistake is assuming all friction should be removed equally. Break-glass access should remain possible, but it should be exceptional, time-bound, and heavily logged. Likewise, not every workflow should be fully automated if the system cannot reliably prove workload identity or support revocation. In those cases, the safer answer may be to reduce privilege scope before reducing friction.

Another edge case is agentic and machine-driven access, where the problem is not just convenience but unpredictability. When software can chain tools, escalate requests, or act at machine speed, static IAM assumptions fail quickly. Current guidance from NHI and agentic AI security frameworks is to evaluate access at runtime and bind credentials to the workload, not to a generic service label.

Security teams often get this wrong by treating frustration as evidence of maturity. In reality, excessive friction usually means the control is misaligned with how people and systems actually operate.

Related resources from NHI Mgmt Group

• What do organisations get wrong about identity recovery and helpdesk support?
• What do security teams get wrong about persona-based identity reporting?
• What do organisations get wrong about temporary access in SaaS platforms?
• What do security teams get wrong about third-party access in CJIS environments?