Who should own the balance between customer experience and authentication assurance?

Ownership should sit jointly with identity, application, and security teams, but accountability should remain with the identity programme. If the business treats login as only a product issue, security gaps get hidden. If it treats login as only a security issue, customer friction grows. Governance has to cover both outcomes.

Why This Matters for Security Teams

The ownership question is really about preventing two common failure modes: product teams optimising for lower login friction without enough assurance, and security teams tightening controls without enough context for customer impact. That tension is especially visible when customers use passwords, MFA, step-up authentication, and recovery flows that affect conversion, support load, and fraud exposure. The right governance model makes those tradeoffs explicit, not accidental.

Authentication policy is not just an engineering choice. It sits at the intersection of identity assurance, fraud management, application design, and customer experience. Current guidance from NIST SP 800-63 Digital Identity Guidelines is useful here because it frames assurance as a risk decision, not a pure usability exercise. NHI Management Group’s Ultimate Guide to NHIs makes a similar point for machine identities: when governance is unclear, weak controls persist until an incident forces the issue. The same pattern appears in customer authentication when no single owner is accountable for both outcomes.

In practice, many security teams encounter login abuse, account takeover, or abandoned recovery controls only after customer friction has already been normalised as a product compromise rather than a governance failure.

How It Works in Practice

The most effective model is shared execution with clear accountability. Identity teams usually own the authentication standard, assurance levels, and lifecycle controls. Application teams own how those controls are implemented in the product journey. Security owns the threat model, risk thresholds, and control validation. Customer experience, product, and support should feed requirements into the design so the authentication journey reflects real user behaviour rather than internal assumptions.

In practice, this means separating policy from presentation. The policy defines when step-up authentication is required, which recovery methods are acceptable, and what assurance level is needed for sensitive actions. The application then implements those rules in a way that is clear to users. This is where NIST SP 800-63 Digital Identity Guidelines helps with assurance concepts, while Ultimate Guide to NHIs is a reminder that identity controls fail when ownership is fragmented.

• Set one accountable owner for the policy, usually the identity programme.
• Use risk-based step-up rules for sensitive transactions, not for every sign-in.
• Review drop-off, lockout, recovery abuse, and support tickets together.
• Measure both assurance and customer effort so tradeoffs are visible.

Strong programmes also use telemetry to detect when users are pushed into insecure workarounds, such as repeated password resets or weak recovery paths. Those signals matter because they often reveal that the authentication journey is too strict, too vague, or poorly aligned with user behaviour. These controls tend to break down in high-volume consumer environments where rapid experimentation changes the login journey faster than governance can keep up.

Common Variations and Edge Cases

Tighter authentication often increases support load and abandonment risk, requiring organisations to balance fraud resistance against growth and usability. That tradeoff is real, and current guidance suggests there is no universal standard for the exact threshold where friction becomes excessive. The right answer depends on transaction value, threat level, regulatory exposure, and whether the account protects payments, personal data, or privileged functions.

Edge cases usually appear in passwordless rollouts, delegated admin models, customer recovery flows, and step-up prompts for low-frequency actions. In these cases, ownership should remain with the identity programme, but the final design decision needs input from product analytics and customer support. Security should not dictate every control equally; it should define minimum assurance outcomes and acceptable exceptions. For broader identity assurance governance, NIST’s risk-based framing remains useful, while NHIMG research on NHI governance shows how quickly ambiguous ownership leads to weak lifecycle discipline. That lesson applies equally to human login journeys.

Where there is no universal standard yet, the best practice is to document the decision criteria: which risk signals trigger extra verification, who approves exceptions, and how customer impact is reviewed after release. Organisations that skip this discipline often discover misalignment only when fraud rises or abandonment spikes, not during design reviews.

Related resources from NHI Mgmt Group

• How should financial institutions balance DORA compliance with customer authentication experience?
• Who should own the move from NTLM to certificate-based authentication?
• Who should own security evidence for authentication and recovery workflows?
• Why does fragmented identity data weaken customer experience and governance?