By NHI Mgmt Group Editorial TeamPublished 2025-09-16Domain: Best PracticesSource: Axiad

TL;DR: Frictionless authentication only works when security design accounts for the full mix of users, administrators, and executives, because friction at any point drives workarounds and weakens MFA adoption, according to Axiad. The deeper issue is programme design: controls that ignore population differences and staffing constraints fail in practice, not theory.


At a glance

What this is: This is a practitioner take on why frictionless MFA fails when identity programmes treat every population the same.

Why it matters: It matters because IAM teams have to design for adoption, administration, and governance at the same time, or users will route around controls and security outcomes will degrade.

By the numbers:

👉 Read Axiad's blog post on frictionless MFA and enterprise adoption


Context

Frictionless MFA is not just a user experience question. In practice, it is an identity programme design problem: if a control is hard to adopt, hard to support, or hard to explain, people work around it and the control loses value.

The article argues that this applies across the organisation, not only at the end user layer. That makes the topic relevant to human identity, IAM operations, and governance decisions about how security controls are introduced, supported, and sustained.


Key questions

Q: How should IAM teams reduce friction without weakening MFA controls?

A: Start by removing unnecessary steps, clarifying enrollment and recovery, and making the secure path the easiest path for each user population. Good MFA design reduces effort without reducing assurance. Teams should also measure support tickets, bypass requests, and fallback usage because those signals show whether the control is usable enough to survive in production.

Q: Why do identity controls fail when they create too much friction?

A: They fail because users optimise for speed and continuity of work. If the secure process is disruptive, people look for shortcuts, fall back to passwords, or avoid enrollment altogether. That turns a policy into an exception pattern. The real test is whether the control can be followed consistently by the people who must use it every day.

Q: How do security teams know if frictionless MFA is actually working?

A: Look for lower help desk load, fewer recovery events, fewer bypass requests, and steady completion rates across user populations. If adoption looks high but support demand stays elevated, the control may be technically deployed but operationally fragile. A usable MFA programme should reduce exceptions, not simply shift them into the service desk.

Q: Who is accountable when MFA design fails across the enterprise?

A: Accountability sits with the identity and security owners who choose the control design, but it also extends to operations leaders who must sustain it. If auditability, support capacity, and user experience were not built into the programme, the failure is architectural, not just procedural. Governance must cover deployment, operation, and evidence generation together.


Technical breakdown

Why friction breaks MFA adoption

Multi-factor authentication depends on sustained user compliance, and compliance drops when the control interrupts normal work. Friction can come from extra steps, unreliable devices, inconsistent enrollment, or support processes that make the secure path feel harder than the insecure one. When that happens, users revert to passwords or find unofficial shortcuts. The technical issue is not that MFA is weak. It is that the surrounding operational model fails to make the secure action the default action.

Practical implication: measure MFA not only by rollout coverage, but by whether users complete it without recurring exceptions or workarounds.

Why IT operations determine whether identity controls hold

Identity controls are only as strong as the operations model behind them. The article highlights the load placed on IT teams when they must maintain, support, and evolve MFA without extra budget, training, or staffing. That creates dependency on a small number of skilled administrators and makes fragmented security tooling harder to sustain. In identity programmes, operational friction becomes a control-risk multiplier because support gaps, knowledge gaps, and tool sprawl all reduce the reliability of authentication and auditing processes.

Practical implication: assess whether your MFA operating model can survive staff turnover, support demand, and fragmented tooling before expanding scope.

How auditability changes the case for frictionless authentication

For security leaders, frictionless does not mean permissive. It means the authentication process must be easy enough to adopt while still producing evidence for audits, assurance, and policy enforcement. The article points to reporting, third-party certifications, and higher-assurance environments as part of the value proposition. That is an important distinction: a control that cannot be evidenced cleanly will struggle in regulated or customer-audited environments even if it works technically.

Practical implication: build reporting and assurance requirements into the authentication design, not after deployment.


NHI Mgmt Group analysis

Friction is a governance failure, not a user complaint. Identity programmes often describe adoption problems as change-management issues, but the deeper issue is control design. If the secure path is slower than the insecure path, users will optimise for work completion, not policy compliance. The implication is that authentication design has to be judged by behaviour under pressure, not by policy intent alone.

The IT operating model is part of the control surface. The article correctly shows that MFA success depends on support capacity, staff continuity, and the ability to manage a patchwork of technologies. That is an identity governance issue, because the control does not exist in isolation from the team that must keep it working. Practitioners should treat operational fragility as a security risk, not a back-office inconvenience.

Assurance must be frictionless enough to survive audit scrutiny. The article links user experience with compliance reporting and higher-assurance environments, which is the right frame. Security leaders do not just need adoption, they need evidence that the control can be maintained, audited, and trusted across populations with different needs. The practical conclusion is that assurance design belongs in the identity architecture, not as an afterthought.

One-size-fits-all identity design fails because populations are not identical. End users, IT staff, and executives do not interact with security controls in the same way, and a programme that ignores those differences creates avoidable resistance. That is why frictionless design is really about role-sensitive governance. Practitioners should map authentication journeys by population before standardising controls across the enterprise.

From our research:

  • 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
  • Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
  • Top 10 NHI Issues shows why visibility and lifecycle discipline matter before friction turns into control failure.

What this signals

Frictionless identity design is becoming a governance differentiator. As programmes expand across users, administrators, and executives, teams need to understand where control usability breaks down before they declare a deployment successful. The operational question is no longer whether MFA exists, but whether it can be supported, audited, and used consistently without creating hidden exceptions.

A useful way to frame this is as an authentication experience gap: the more a control depends on staff expertise and manual intervention, the less repeatable it becomes across the enterprise. That is a risk for any identity programme trying to scale security assurance while keeping support overhead under control.


For practitioners

  • Map authentication friction by population Track enrollment failures, help desk escalations, bypass requests, and recovery events separately for end users, IT teams, and executives so you can see where friction is driving workarounds.
  • Test the support burden before rollout Validate whether the security team can maintain the control with current staffing, training, and tooling, especially if the environment already has a disconnected patchwork of products.
  • Build audit evidence into the design Require reporting, certification, and assurance outputs as part of the control baseline so that compliance can be demonstrated without manual reconstruction after the fact.
  • Treat user bypasses as control defects If users revert to passwords or alternate paths, document the reason as an authentication design issue and fix the process rather than blaming the user group.

Key takeaways

  • Friction in MFA is not a minor usability issue, because it directly affects whether users comply with the control or route around it.
  • Operational capacity, staff continuity, and audit reporting are part of the identity control surface, not separate concerns.
  • Identity leaders should design authentication for adoption and evidence at the same time, or the programme will look stronger on paper than it is in practice.

Standards & Framework Alignment

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

NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AC-1Authentication usability affects whether access controls are consistently used.
NIST SP 800-63Digital identity assurance depends on enrollment and authentication that people will actually complete.
NIST Zero Trust (SP 800-207)AC-4Zero trust relies on continuous access decisions that fail if users bypass authentication.

Treat authentication adoption as part of zero-trust enforcement, not a separate UX concern.


Key terms

  • Frictionless authentication: An authentication approach that reduces unnecessary user effort while preserving security assurance. The goal is not to remove controls, but to make the secure path simple enough that people actually use it instead of inventing shortcuts or reverting to weaker methods.
  • Authentication adoption: The degree to which a user population consistently completes the intended sign-in or verification flow. In identity programmes, adoption is a security outcome because a control that users avoid or bypass may exist technically but fail operationally.
  • Assurance evidence: The reports, logs, certifications, and operational artefacts that show an identity control is working as intended. For practitioners, assurance evidence matters because audits and customer reviews depend on demonstrable control performance, not policy statements alone.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or lifecycle governance, it is worth exploring.

This post draws on content published by Axiad: What’s All the Hype about Frictionless? Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2025-09-16.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org