They often treat friction as a user experience issue only. In practice, unnecessary password resets, mobile-hostile forms, and repeated challenge steps drive measurable abandonment, so friction should be managed as an access and retention risk inside CIAM governance.
Why This Matters for Security Teams
Frictions in customer authentication are often treated as a conversion-only problem, but they are also a control design problem. When login journeys force repeated challenges, brittle device checks, or password reset loops, users do not just complain. They abandon flows, call support, reuse weak recovery paths, or bypass approved channels entirely. That creates risk for both access governance and retention. Current guidance from the NIST Cybersecurity Framework 2.0 reinforces that access decisions should support business outcomes, not sit apart from them. NHI Management Group sees the same pattern in identity programs: when friction is added without measuring abandonment, support load, and fraud exposure together, teams optimise the wrong metric. The result is often more exceptions, more reset traffic, and weaker assurance at the exact moment the customer is most likely to disengage. The broader identity lesson is consistent with Ultimate Guide to NHIs: unmanaged identity sprawl creates hidden operational cost, even when the control was meant to reduce risk. In practice, many security teams discover authentication friction only after abandonment, fraud escalation, or support overload has already become visible in the business metrics.Authentication should therefore be governed as a shared security and revenue control, not as a narrow UX preference. That means tracking where users fail, why they fail, and which controls are actually reducing trust signals versus merely adding steps.
How It Works in Practice
Teams usually get this wrong by adding more gates whenever they feel uncertain. Extra MFA prompts, forced password changes, or mobile-hostile recovery screens may appear safer, but they can also create predictable failure points. A better model is to separate high-risk events from routine access, then apply stronger checks only when the context justifies them. The NIST Cybersecurity Framework 2.0 supports this kind of risk-based design, and the identity guidance in Ultimate Guide to NHIs shows why governance fails when control decisions are not tied to lifecycle and operational reality.In practice, effective CIAM teams usually look at four things together:
- Step-up only when the transaction, device, or behaviour changes meaningfully.
- Use passwordless or low-friction recovery paths where recovery is the main abandonment source.
- Measure challenge completion, reset frequency, and drop-off as security signals, not just product analytics.
- Review whether SMS, email, or app-based prompts are creating accessibility or channel-lockout issues.
Where possible, authentication policy should be driven by risk context rather than static rules. That includes considering session history, device reputation, account age, and transaction sensitivity before forcing another challenge. The key is not to eliminate friction, but to place it where it actually raises assurance. Teams that ignore this usually end up with more support tickets, more reset-based attacks, and more users finding unofficial ways around the designed flow. These controls tend to break down in high-volume consumer environments where peak traffic, fragmented device ecosystems, and limited support capacity make every extra step visible to the customer.
Common Variations and Edge Cases
Tighter authentication often increases operational overhead, so organisations have to balance assurance against abandonment, support cost, and accessibility. That tradeoff becomes sharper in regulated sectors, shared-device environments, and markets with low smartphone reliability. There is no universal standard for the exact number of challenge steps that is acceptable; current guidance suggests tuning by risk and measuring outcomes rather than assuming more prompts are always safer. NIST’s risk-based approach in NIST Cybersecurity Framework 2.0 is useful here because it encourages continuous adjustment instead of fixed ceremony.Edge cases often expose the weaknesses in rigid authentication design:
- High-value accounts may justify stronger verification, but only for sensitive actions, not every login.
- Legacy systems sometimes force password resets because they cannot support better recovery options, even though the reset itself is the friction source.
- Mobile-only or mobile-first experiences can fail when the second factor depends on the same device the user is trying to replace or recover.
For identity teams, the practical lesson from Ultimate Guide to NHIs carries over: governance is strongest when it accounts for real operational conditions, not idealised flows. In customer authentication, that means preserving strong assurance while removing avoidable steps that push users into insecure workarounds or outright abandonment.
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 NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Access control should be risk-based, not driven by friction alone. |
| NIST SP 800-63 | Digital identity guidance informs assurance without unnecessary burden. | |
| OWASP Non-Human Identity Top 10 | NHI-05 | Lifecycle and access governance reduce brittle identity workflows. |
Tune authentication to account risk and user context instead of adding blanket challenge steps.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
