Customer identity is straining under passwords, patchwork and AI agents

At a glance

What this is: This is a Descope survey of 416 CIAM decision makers showing that customer identity programmes are being strained by passwords, developer overload, and the rising use of AI agents.

Why it matters: It matters because the same governance gaps now affect customer, workforce-adjacent, NHI, and emerging agentic identity patterns, which means IAM teams have to design for scale, friction, and control boundaries together.

By the numbers:

• 82% of survey respondents citing at least some negative business impact
• 87% of organizations use password-based authentication for their customer-facing applications
• 51% of organizations task developers with minimal to no authentication experience to build and manage CIAM
• 88% of respondents are using or planning to use AI agents

👉 Read Descope's survey on customer identity, CIAM friction, and AI agents

Context

Customer identity is moving from a user login concern to a broader control-plane issue. Passwords, homegrown auth flows, and shared workforce tooling are being asked to cover customer journeys they were never designed to govern, which creates friction for users and drag for engineering teams. This is now a customer identity problem, but it is also a lifecycle and governance problem for identity programmes that increasingly span human, non-human, and agentic subjects.

The survey points to a familiar failure pattern: organisations keep extending legacy controls because they are available, not because they fit the use case. When teams use workforce IAM for customer auth, or ask developers with little authentication experience to own CIAM, the result is usually more support cost, slower delivery, and weaker governance. As AI agents and MCP servers enter the same environment, the old boundary between human access and machine access starts to blur.

Key questions

Q: How should organisations govern customer identity when they also use AI agents?

A: They should govern AI agents as non-human identities with explicit data, action, and authorization boundaries. Customer identity can no longer stop at human login if an agent can act on behalf of the user, touch customer data, or trigger downstream workflows. The governance model needs ownership, scope limits, auditability, and clear lifecycle rules for the agent itself.

Q: Why do workforce IAM tools often fail for customer identity?

A: Workforce IAM tools are usually built for employees, managed devices, and internal policy boundaries, not for high-scale customer journeys. They tend to create friction in enrolment, recovery, and step-up flows, and they rarely fit the support, fraud, and conversion constraints that CIAM must balance. Reuse can save time initially, but it often increases governance debt later.

Q: What do security teams get wrong about password-based authentication?

A: They often treat passwords as a default identity strategy rather than a control with known friction, reuse, and recovery weaknesses. In customer identity, passwords can keep systems running, but they also increase support demand and limit the organisation’s ability to build stronger, more adaptive assurance into the journey. The real issue is not passwords alone, but overdependence on them.

Q: How do organisations know if their CIAM programme is working?

A: A CIAM programme is working when it reduces support burden, shortens identity-related delivery cycles, and lowers onboarding abandonment without creating new access gaps. If developers keep delaying identity work, customers keep dropping out, and the business still depends on passwords and legacy workarounds, the programme is not operating as a governed control plane.

Technical breakdown

Why password-based customer authentication persists

Password-based authentication persists because it is universally understood, easy to deploy, and already embedded in most product stacks. The technical problem is that passwords create a shared failure domain: they are easy to reuse, hard to govern at scale, and often bolted onto customer journeys without strong step-up logic or risk-based controls. In CIAM, the challenge is not just security strength. It is how to balance recovery, fraud prevention, and conversion without forcing every user through the same brittle pattern.

Practical implication: teams should map where password flows are still doing too much work and identify the highest-friction journeys first.

Why workforce IAM is a poor stand-in for CIAM

Workforce IAM is built around employees, corporate devices, and managed lifecycle assumptions. CIAM has different scale, different recovery expectations, different UX constraints, and far less tolerance for process-heavy enrolment or support overhead. Reusing workforce tooling for customers can look efficient on paper, but it often produces a mismatch between policy design and actual user behaviour. That mismatch is why the survey finds many organisations would not choose the same architecture again if they started from scratch.

Practical implication: review where customer identity policy is inherited from workforce assumptions and separate the two control models.

What agentic identity changes in customer-facing environments

Agentic identity introduces a new class of runtime access problem because software entities can initiate actions, select tools, and access data paths as part of a live session. In customer-facing systems, that means identity is no longer only about authenticating a person. It also has to govern delegated actions, authorization scope, and data boundaries for non-human actors that may operate alongside customers or on their behalf. Without explicit guardrails, agentic access can expand the blast radius of a compromised session or an over-permissioned workflow.

Practical implication: treat AI agents and MCP-connected services as governed identities, not just application features.

Threat narrative

Attacker objective: The likely objective is to exploit weak customer identity controls to obtain unauthorized access, disrupt journeys, or widen access through over-permissioned authentication and agentic paths.

1. Entry begins when organisations expose customer identity flows through passwords, shared workforce IAM, or loosely governed agent integrations that were not designed for customer-scale trust boundaries.
2. Escalation happens when developers with limited authentication experience extend those flows, creating over-permissioned paths, inconsistent recovery logic, and unaudited access handoffs.
3. Impact follows as support costs rise, launches stall, users abandon onboarding, and AI agents expand the attack surface across customer-facing systems.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Customer identity is now a governance problem, not just an authentication problem. The survey shows that most organisations are still using passwords and patchwork CIAM patterns even though they know the user and business cost is rising. That is a sign that identity teams are being forced to optimise around legacy convenience instead of control design. Practitioners should treat customer identity as a lifecycle-managed programme, not a login feature.

Shared workforce IAM for customer journeys is a structural mismatch. Workforce controls assume employees, managed devices, and internal policy boundaries, while customer identity has higher scale, lower tolerance for friction, and different recovery needs. When organisations reuse the wrong control plane, they create hidden technical debt in support, onboarding, and authorization. The practitioner conclusion is straightforward: the model is wrong before the implementation is even discussed.

Agentic identity expands CIAM beyond human sessions into governed runtime behaviour. Once AI agents and MCP-connected services are part of the customer stack, identity programmes must account for delegated action, data access, and authorization scope at runtime. This is where classic CIAM thinking meets NHI governance, because the same session can involve a person and a non-human actor. Teams need to decide which access paths are human-owned, machine-owned, and agent-mediated before production use widens.

Customer identity sprawl creates identity blast-radius debt. As more systems depend on the same authentication and authorization patterns, every weak recovery path, overbroad privilege assignment, and inconsistent policy exception increases the damage radius of a compromise or outage. This is not just a technology issue. It is an operating-model issue that affects customer trust, delivery speed, and auditability. Practitioners should reframe CIAM around containment, not just convenience.

Access review assumptions break when developers are the de facto CIAM operators. The survey shows many organisations still task developers with authentication work despite limited experience and competing priorities. That creates a governance gap where no one owns the consistency of the control, even though everyone depends on it. The practitioner implication is to formalise ownership, review paths, and escalation criteria before the next customer identity change lands.

From our research:

• 82% of survey respondents citing at least some negative business impact, according to AI Agents: The New Attack Surface report.
• Only 44% of organisations have implemented any policies to govern AI agents, even though 92% say governing them is critical to enterprise security.
• Customer identity is now crossing into agentic governance, which is why the broader pattern in 52 NHI Breaches Analysis matters for CIAM teams as well.

What this signals

Customer identity programmes are starting to inherit NHI governance problems. Once AI agents are part of the customer journey, identity teams have to think in terms of delegated access, runtime scope, and lifecycle ownership rather than only login assurance. The practical signal is that CIAM and NHI teams can no longer work as separate disciplines if they share the same customer-facing trust boundary.

AI agent adoption is advancing faster than governance maturity. In our research, 44% of organisations have implemented policies to govern AI agents while 92% say governance is critical, which is a classic gap between intent and operating model. That gap will surface first in customer-facing environments because those journeys combine scale, support pressure, and lower tolerance for identity failure. Teams should expect CIAM backlogs to become governance backlogs.

The organisations most exposed here are the ones that treat identity as a feature rather than a programme. If onboarding, recovery, and agent access all sit in separate silos, the business will keep paying for every exception in support cost, launch delay, and audit friction. The cleaner model is a single governance view across human, machine, and agent-mediated access.

For practitioners

• Separate customer identity from workforce IAM Inventory every customer-facing application that still relies on workforce-auth patterns, then define a distinct CIAM control model for enrolment, recovery, step-up authentication, and authorization. The goal is to stop inheriting employee assumptions into customer journeys.
• Reduce password dependence on high-value journeys Map the login, recovery, and account change flows that create the most support friction or fraud exposure, then prioritise stronger methods where the business impact is highest. Use the supporting journey, not the password itself, as the design unit.
• Assign explicit ownership for agentic identity Decide which teams own AI agent access, which data paths the agents may use, and how approval is recorded when an agent acts on behalf of a user or process. Do not leave agent access embedded inside application logic without governance.
• Build CIAM review criteria around business impact Track support ticket volume, onboarding dropoff, launch delays, and unauthorised access events as governance signals, not just operational metrics. That lets IAM and product teams see where identity controls are becoming a delivery constraint.

Key takeaways

• Customer identity is reaching the point where legacy password flows and workforce IAM reuse create measurable business drag, not just technical inconvenience.
• The survey shows a clear operating-model gap: many teams know their current CIAM pattern is suboptimal, but they keep it in place because developer time and budget are already committed elsewhere.
• As AI agents enter customer-facing systems, IAM teams need to govern delegated access, lifecycle ownership, and runtime scope as one identity problem, not three separate ones.

Key terms

• Customer Identity And Access Management: Customer Identity and Access Management is the discipline that governs how external users authenticate, recover access, and are authorised across digital services. In practice it has to balance security, scale, support cost, and conversion, which is why workforce identity patterns rarely fit it cleanly.
• Agentic Identity: Agentic identity is the governance model for AI systems that can act at runtime on behalf of a user, process, or workflow. It must define who owns the agent, what data it may access, what actions it may take, and how those decisions are logged and reviewed.
• Identity Blast Radius: Identity blast radius is the amount of damage that can spread when one authentication or authorization control fails. In customer and agentic environments, it grows when recovery paths, shared privileges, and exceptions are reused across multiple journeys or systems.
• Lifecycle Ownership: Lifecycle ownership is the assignment of responsibility for creating, changing, reviewing, and retiring an identity or its access. For customer and non-human identities, weak lifecycle ownership usually shows up as orphaned access, inconsistent policy enforcement, and unclear accountability during change.

Deepen your knowledge

Customer identity governance, CIAM lifecycle design, and AI agent access controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are redesigning customer identity from a patchwork starting point, it is worth exploring.

This post draws on content published by Descope: Log In User Circle Descope Survey Shows 82% of Organizations Experience Negative Business Impact Due to Customer Identity Issues. Read the original.