They need both, but usability determines whether the control survives behaviour. A strong control that users avoid is weaker in practice than a slightly lighter control that users complete consistently. The right question is how to preserve assurance while making the secure route the least painful one.
Why customer identity programmes have to balance usability and control
A customer identity programme only works if real people can complete it under normal conditions. Assurance matters, but if the journey creates too much friction, customers route around it, abandon it, or create weaker workarounds. For that reason, the security target is not maximal friction, but a usable control path that still resists takeover, fraud, and abuse.
The practical question is which parts of the journey need the strongest assurance and which can be made lighter without materially increasing risk. In customer identity, the best design usually pairs strong default controls with targeted step-up checks so the secure path remains the easiest path most of the time.
Where the trade-off becomes visible in customer journeys
Usability and control strength are not opposites in every step. They become a trade-off where the programme asks for proof, recovery, or repeated authentication at moments customers experience as inconvenient. That includes sign-up, login, password reset, device change, profile updates, payout changes, and account recovery. If those flows are too strict, support volume rises and abandonment increases; if they are too loose, account takeover and fraud become easier.
Customer identity programmes work best when they distinguish between routine access and higher-risk actions. A fast, low-friction login can be acceptable if sensitive actions trigger stronger verification. That preserves day-to-day usability while concentrating control strength where it actually changes the blast radius of compromise.
What strong customer identity looks like in practice
Good customer identity design uses assurance proportionally. Stronger controls belong where identity proof, recovery integrity, or high-value transactions are at stake, while common access paths should stay simple enough that legitimate users will actually use them. That is why modern CIAM patterns usually combine passkeys or other phishing-resistant authentication, risk-based step-up, and carefully designed recovery.
Programme teams should also treat recovery as part of the control, not as an afterthought. The most elegant login control can be undercut by a weak reset flow, a help-desk exception, or a poorly governed delegated access path. Customer IAM (CIAM) Guide covers the operational balance across authentication, recovery, delegated access, and consent, while CIAM Buyer’s Guide helps teams compare platforms on the controls that affect both friction and assurance.
How to decide what to tighten and what to simplify
The right design choice is to make the secure route the least painful one for the common case, then reserve heavier checks for exceptions and higher-risk behaviour. That usually means reducing repeated prompts, using step-up only when risk changes, and avoiding controls that punish every user for the failures of a few. The programme should be judged by completion rate, recovery success, and abuse resistance together, not by security strictness alone.
At scale, the question becomes governance as much as experience. If one policy creates heavy support load, users will seek shortcuts, and those shortcuts become part of the real control environment. Identity Security Programme Guide is useful here because it frames customer identity decisions inside an operating model, so product, fraud, support, and security teams can align on what should be centralised, what should be delegated, and where exception handling is acceptable.
Risk and Threat Considerations
Overly strict customer controls can create security failure indirectly, because users avoid them, forget them, or work around them through weaker channels. Overly weak controls create direct exposure through credential stuffing, account takeover, recovery abuse, and unauthorised profile or payment changes. The risk is not just whether the control exists, but whether real customers can complete it consistently enough for the control to survive in production.
Failure mechanism: Friction pushes customers toward password reuse, shared devices, fallback recovery paths, or support-assisted exceptions, which attackers can then target as the weakest practical path into the account.
Impact: The programme loses assurance where it matters most, because takeover, fraud, and recovery abuse become easier even if the nominal control design looks strong on paper.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V6 — Authentication | Customer identity journeys hinge on authentication strength and friction. |
| Recommendation — Use stronger authentication where account access risk is highest and simplify routine login where possible. | ||
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | Customer identity is non-organizational user authentication and recovery. |
| IA-5 — Authenticator Management | Recovery, rotation, and lifecycle of customer authenticators shape both usability and control strength. | |
| Recommendation — Apply IA-8 to balance customer assurance with usable access flows. Manage authenticators so recovery remains secure without making normal access unusable. | ||
| CIS Controls v8 | 5 — Account Management | Customer identity programmes must govern account lifecycle, access, and recovery paths. |
| Recommendation — Harden account lifecycle controls while keeping the customer journey usable. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Customer programmes trade assurance against friction in proofing and recovery. |
| Recommendation — Set assurance levels proportionate to the customer risk and transaction sensitivity. | ||
Practitioner Guidance
What to prioritise: Put the strongest assurance on account recovery, recovery changes, payout changes, and other high-impact actions before tightening everyday login further. Those are the moments where a control failure has the highest business consequence.
What to verify: Test the journey with real users, not just security reviewers. If completion drops sharply, support tickets spike, or users migrate to weaker fallback channels, the control is too costly in practice even if it is technically sound.
Decision rule: If a control protects a high-value action, keep it strong; if it only adds friction to routine access, simplify it unless abuse data shows that step is itself a target.
Practitioner takeaway: For customer identity, the right standard is not maximum resistance, but maximum usable assurance, because only controls customers will actually complete can protect the account over time.
Related resources from NHI Mgmt Group
- Why does device identification matter for customer identity programmes?
- How should security teams handle control deficiencies in identity governance programmes?
- Why do identity programmes need customer success support as they scale?
- Who should be accountable for control monitoring in identity programmes?