Join our Newsletter — 33% off our NHI Course

Who should own customer identity strategy in an organisation, and why does that matter?

Customer identity should have a dedicated executive owner who sits across security, fraud, compliance, authentication, and customer experience. When ownership is fragmented, teams assume someone else is handling proofing and confidence checks, which creates gaps. A clear owner can align people, process, and technology, define the target level of identity confidence, and keep leadership accountable for fraud, onboarding, and trust outcomes.

Who should own customer identity strategy?

customer identity strategy should sit with one accountable executive owner, usually a leader who can balance security, fraud, onboarding, compliance, and customer experience. The important point is not the title itself, but that one person can make cross-functional trade-offs, set confidence standards, and prevent identity decisions from being diluted across teams with conflicting priorities.

That owner should be able to align the identity roadmap with business outcomes such as conversion, account recovery, fraud loss, and support burden. If the strategy is treated as a purely technical implementation, teams optimize their own slice and leave gaps in proofing, authentication, and governance that only appear later in production.

Why fragmented ownership creates real operational risk

When customer identity is split across product, security, fraud, legal, and operations, no one owns the full decision chain. One team may approve a smoother onboarding flow, another may tighten authentication, and a third may tune fraud rules, but without a single strategy those choices can conflict and create inconsistent trust levels across the customer journey.

Fragmentation also makes accountability disappear at the exact point where identity decisions need escalation. If no executive owns the risk posture, issues such as weak proofing, inconsistent recovery, or unclear step-up rules tend to become local exceptions rather than enterprise decisions, which makes them harder to measure and harder to fix.

Customer identity is especially sensitive because it sits at the intersection of access, trust, and revenue. A weak strategy can increase account takeover exposure, block legitimate customers, or force manual reviews that do not scale. A strong owner can decide where friction is justified, where it is excessive, and what evidence should support that choice.

What the owner must be able to decide

The owner needs authority over the target level of identity confidence, not just the tooling. That includes deciding how strong proofing should be at enrollment, when step-up authentication is required, how account recovery is handled, and what conditions trigger human review. Without that decision power, the organisation can buy controls without defining the operating standard they are meant to enforce.

The role should also define the boundaries between customer trust, fraud tolerance, and user experience. For example, a consumer platform may accept a different level of recovery friction than a regulated financial service, but the decision has to be explicit. If the threshold is not set centrally, teams will default to convenience until an incident forces a stricter posture.

For identity-heavy programmes, it is useful to connect the strategy to a broader identity baseline such as IAM and IGA Basics and the deeper lifecycle and governance issues in Ultimate Guide to NHIs. Even when the primary focus is customers, the governance lesson is the same: identity cannot be managed well when ownership is split from lifecycle and access decisions.

Risk and Threat Considerations

Fragmented customer identity ownership creates a control gap that attackers and fraudsters can exploit. If proofing, authentication, recovery, and support flows are owned by different teams, the weakest path often becomes the path of least resistance, especially when manual exceptions or inconsistent escalation rules are allowed to accumulate.

Failure mechanism: separate owners make contradictory decisions about trust, recovery, and access, which leads to inconsistent identity assurance and exploitable gaps between onboarding, login, and account recovery.

Impact: the organisation can see higher account takeover risk, more false accepts or false rejects, weaker auditability, and a strategy that is hard to defend when leadership asks who accepted the risk and why.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework Control / Reference Relevance
NIST SP 800-53 Rev 5 PM-1 — Information Security Program Plan Customer identity strategy needs an accountable program owner and decision structure.
IA-2 — Identification and Authentication (Organizational Users) Customer identity strategy centers on authenticating users and setting assurance expectations.
IA-8 — Identification and Authentication (Non-Organizational Users) Customer identity is about external user authentication and lifecycle assurance.
Recommendation — Assign program ownership and formalize identity decision rights in the security program plan. Define the required authentication assurance level for customer access paths. Establish proofing and authentication controls for external customer identities.
ISO/IEC 27001:2022 A.5.2 — Information security roles and responsibilities The question is fundamentally about clear ownership and accountability for identity strategy.
A.5.15 — Access control Customer identity strategy must set rules for access, recovery, and confidence checks.
Recommendation — Assign a single accountable owner for customer identity strategy and related risk decisions. Define access and recovery rules that reflect the chosen identity assurance level.

Practitioner Guidance

What to prioritise: name one executive owner first, then define the decision rights for proofing, authentication, recovery, fraud escalation, and customer support. The ownership model matters more than the first tool choice because tool decisions without governance usually inherit the wrong thresholds.

What to verify: confirm that the owner can answer three questions without escalation, what level of identity confidence is required, who approves exceptions, and how the organisation measures drift between intended and actual identity assurance. If those answers live in different departments, the strategy is not truly owned.

Practitioner takeaway: customer identity is a governance problem before it is a technology problem, and the organisation will only get consistent trust outcomes when one executive is accountable for the trade-offs across security, fraud, compliance, and experience.