They should treat them as linked controls rather than a trade-off. Fast journeys still need reliable proofing, but assurance should be designed so customers are not forced through unnecessary friction. The goal is to keep verification strong while making the process consistent, reusable, and understandable across channels.
Why customer experience and identity assurance should be designed together
Digital journeys work best when the assurance model is matched to the risk in the step the customer is completing. A low-friction experience is not the opposite of strong identity assurance, it is often the result of better design, clearer proofing rules, and fewer repeated checks. Organisations should therefore design identity controls to support completion, not to interrupt it unnecessarily.
The practical question is not whether to be strict or convenient, but where assurance must be strong enough to protect the transaction or account. That often means using reusable identity evidence, step-up checks only when needed, and consistent rules across channels so customers are not forced to re-prove the same facts in different ways.
Where the trade-off appears in real journeys
The friction problem usually shows up when teams treat each channel, product, or business unit as a separate verification event. That creates duplicate document capture, repeated biometric checks, inconsistent recovery rules, and avoidable abandonment. It also weakens trust because customers learn that the process is arbitrary rather than risk-based.
A better model is to separate NIST SP 800-63 Digital Identity Guidelines-style assurance decisions from presentation decisions. The journey can remain fast if the underlying proofing, authenticator strength, and step-up logic are calibrated to the action being taken, rather than applied as a blanket hurdle to every interaction.
For customer-facing identity programs, reusable identity evidence and federated or wallet-based approaches can reduce repeat collection while keeping assurance intact. That matters most where onboarding, account recovery, and high-risk changes all touch the same customer record but happen in different journeys or channels.
What makes the balance break down
The balance fails when assurance is treated as a one-time compliance checkbox, or when user experience is treated as the only success metric. In both cases, teams miss the real control objective: the organisation must know enough about the customer, at the right point, to trust the action without creating a brittle or confusing journey.
Customer journeys are also exposed when authentication, recovery, and proofing are designed separately. An elegant login flow can still leave weak account recovery, and a strong onboarding flow can still allow later takeover if step-up, reuse, and recovery paths are inconsistent. The result is either too much friction for legitimate users or too little resistance for attackers.
That is why journey design should align with proofing strength, fraud risk, and the consequences of failure. Where the action has financial, legal, or privacy impact, assurance should increase; where the action is routine and low impact, the experience should stay lightweight and predictable.
Customer identity programs are easier to operate when they use a coherent control set across onboarding, login, recovery, and sensitive transaction approval. Customer IAM guidance is useful here because it ties authentication, recovery, delegated access, and fraud resistance back to one operating model rather than a series of disconnected fixes.
How to optimise both assurance and journey quality
Good practice is to design identity assurance as a tiered system. Start with baseline verification for routine activity, then add step-up proofing only for higher-risk events such as profile changes, payment setup, credential reset, or account recovery. This keeps the common path short while preserving stronger controls where the business impact is real.
What to verify: the customer should not have to repeat the same proofing outcome if the organisation already holds strong and current evidence. What to measure: abandonment, recovery success, false rejects, and fraud or takeover rates should be reviewed together, because a better journey that increases abuse is not actually better.
When the organisation is evaluating proofing standards, the right question is whether the control can be reused safely across channels without weakening assurance. Identity proofing and KYC guidance helps practitioners judge where document checks, liveness, and assurance levels should sit in the flow, rather than bolting them on at the end.
Risk and Threat Considerations
Weakly balanced digital journeys create two kinds of exposure: excessive friction that drives customers away, and insufficient assurance that lets attackers through account recovery, onboarding, or step-up gaps. The more channels and recovery options an organisation offers, the more important it becomes to keep verification rules consistent and defensible.
Failure mechanism: The control breaks when different teams implement different proofing thresholds, reuse rules, or recovery steps, so an attacker can target the least resistant path while legitimate users face repeated checks.
Impact: Organisations can see higher abandonment, weaker trust, account takeover risk, and inconsistent customer treatment across channels, especially where one flow is easier to abuse than another.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IA-5 — Authenticator Management | Identity assurance depends on strong, usable authenticators and recovery controls. |
| IA-12 — Identity Proofing | Customer onboarding and proofing strength drive the friction-versus-assurance balance. | |
| Recommendation — Align authenticators and recovery with the assurance level required for each journey step. Set proofing requirements to match the risk of onboarding and account recovery. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | The question centres on authentication strength versus user friction in digital access flows. |
| Recommendation — Apply identity verification controls proportionally to the sensitivity of the action. | ||
| OWASP ASVS | V6 — Authentication | The answer addresses authentication strength, reuse, and step-up in customer journeys. |
| V10 — OAuth and OIDC | Reusable identity journeys often rely on federated sign-in and cross-channel trust. | |
| Recommendation — Specify stronger authentication for high-risk actions and keep low-risk paths lightweight. Use federated identity flows to reduce repeat verification without weakening assurance. | ||
Practitioner Guidance
What to prioritise: Put the strongest assurance on the highest-impact actions, not on every touchpoint. If a step changes credentials, payout details, or recovery paths, treat it as a control decision rather than a UX preference.
What good looks like: The customer experience feels simple because the proofing model is consistent, reusable, and risk-based, not because the organisation removed verification.
Common mistake: Teams often optimise the login screen while leaving recovery and exception handling inconsistent. That is where attackers and frustrated customers usually find the gap.
Practitioner takeaway: The best digital journeys do not choose between convenience and assurance, they make assurance proportional, reusable, and visible enough that legitimate users move quickly and attackers do not.
Related resources from NHI Mgmt Group
- How do organisations keep digital identity systems inclusive without weakening assurance?
- How should organisations design digital identity programs for AI-driven customer journeys?
- Who should organisations trust to handle digital identity services when designing citizen or customer journeys?
- What should organisations do when customer conversations may involve synthetic identity?