How should organisations reduce identity friction in customer-facing services?

Why This Matters for Security Teams

Identity friction is often mistaken for a pure UX problem, but in customer-facing services it quickly becomes a security and operational risk. Every extra login, recovery step, or duplicate profile increases abandonment, support load, and the chance that teams create unsafe workarounds such as shared accounts or weak fallback paths. That is where customer trust erodes. The better lens is identity journey design, not just authentication hardening. Current guidance from NIST Cybersecurity Framework 2.0 reinforces that access controls should support business outcomes while preserving accountability.

For customer services, the practical challenge is to reduce steps without reducing assurance. That means choosing where to streamline, where to step up verification, and where to preserve evidence for auditability. It also means understanding that identity controls behave differently across web, mobile, call centre, partner, and API channels. The risk is not just failed sign-in. It is inconsistent identity handling across systems, which breaks records accuracy and complicates incident response. Research from the Ultimate Guide to NHIs shows that 80% of identity breaches involved compromised non-human identities, a reminder that machine-mediated customer journeys need the same discipline as human logins. In practice, many security teams encounter identity friction only after customer abandonment, fraud spikes, or support escalations have already occurred, rather than through intentional service design.

How It Works in Practice

Start by mapping the highest-volume journeys and identifying every identity checkpoint that does not materially reduce risk. For some flows, a passwordless sign-in or federated identity handoff will remove unnecessary friction. For others, step-up verification should only appear at sensitive moments such as profile changes, payout actions, or address updates. The goal is to use friction surgically, not universally.

Operationally, this works best when identity, fraud, support, and application teams share the same journey map. Use strong primary identity proofing up front, then persist a consistent account link across channels so customers do not have to re-establish identity on every device. If the service already has trustworthy signals, such as device binding, session history, or verified contact points, those can support NIST Cybersecurity Framework 2.0 aligned access decisions without forcing full reauthentication.

• Remove duplicate registration, duplicate profile creation, and redundant recovery prompts.
• Use step-up checks only when the action or risk level changes.
• Keep identity records synchronised so support and service channels see the same source of truth.
• Design recovery paths that verify identity without creating a permanent bypass.

Where long-lived credentials or brittle recovery logic are in play, identity friction often returns through the back door. The Top 10 NHI Issues research highlights how weak lifecycle controls and poor visibility create repeat exposure patterns. In parallel, the 52 NHI Breaches Analysis shows how identity shortcuts can become durable failure points once they are embedded in production. These controls tend to break down when legacy customer platforms, call-centre tooling, and partner integrations all maintain separate identity records because reconciliation becomes manual and errors multiply.

Common Variations and Edge Cases

Tighter identity controls often increase support cost and implementation overhead, requiring organisations to balance conversion rates against fraud risk and audit needs. That tradeoff is especially visible in regulated services, high-value transactions, and multi-brand environments where one account can span several front ends. There is no universal standard for when to use passwordless, federation, or step-up verification, so best practice is evolving toward risk-based orchestration rather than a single mandatory pattern.

Some edge cases need special treatment. Vulnerable customers may require assisted recovery that does not depend on device access. Cross-border services may need different identity evidence rules because local regulations affect what can be stored, verified, or reused. Mergers and acquisitions create another common problem: duplicated identities and conflicting customer profiles that must be merged without exposing one person’s data to another. The Cisco DevHub NHI breach and JetBrains GitHub plugin token exposure are not customer-service case studies, but they illustrate the same underlying issue: when identities and credentials are over-permissioned or poorly governed, convenience quickly turns into exposure.

For teams modernising customer-facing identity, the safest path is to reduce repeated proofing while preserving traceability. That usually means fewer logins, more contextual checks, and stronger lifecycle discipline behind the scenes, not blanket relaxation of controls.

Related resources from NHI Mgmt Group

• How can organisations reduce the blast radius of compromised agent identities?
• How do organisations reduce the dwell time of exposed credentials at scale?
• When should organisations treat machine access as a high-risk identity problem?
• When should organisations treat an identity as high risk?