TL;DR: 88% of organisations are using or plan to use AI agents, yet only 37% have moved beyond pilot programs and just 9% have integrated identity and data security controls for AI, according to Descope’s 2025 customer identity data. The gap is no longer theoretical: identity programmes are being asked to govern agent behaviour with controls built for users and static workloads.
NHIMG editorial — based on content published by Descope: 50+ customer auth stats to keep in mind for 2026
By the numbers:
- 88% of organizations are using or plan to use AI agents, but only 37% have progressed beyond pilot programs.
- 94% of organizations have some form of customer MFA, but only 10% offer it across all applications.
- 87% of organizations still use username/password-based authentication, but only 2% believe it effectively balances security and user experience.
Questions worth separating out
Q: How should security teams reduce password dependence without breaking customer login flows?
A: Start with the journeys that create the most account takeover and support cost, then replace passwords with stronger authentication where recovery and device binding can be controlled.
Q: Why do partial MFA deployments still leave organisations exposed?
A: Because attackers do not need universal weakness.
Q: What do security teams get wrong about developer-owned customer IAM?
A: They assume implementation skill is enough.
Practitioner guidance
- Reduce password dependence in the highest-risk journeys Prioritise customer-facing flows where password reset, recovery, and takeover risk create the largest business impact, then replace them with stronger authentication paths first.
- Measure MFA coverage by application and session path Do not rely on enterprise-wide adoption claims.
- Separate identity architecture ownership from feature teams Assign accountable owners for auth policy, recovery design, and session controls so developers are not left to make security trade-offs ad hoc.
What's in the full article
Descope's full blog post covers the operational detail this post intentionally leaves for the source:
- The full breakdown of each customer authentication statistic and its business impact context.
- The underlying survey framing behind developer ownership, MFA coverage, and passkey adoption.
- The article's per-metric comparisons across auth friction, security posture, and user behaviour.
- The AI agent adoption and trust figures that support the article's forward-looking analysis.
👉 Read Descope's customer authentication stats and AI agent risk analysis →
AI agent identity risk and customer auth: what teams need to know?
Explore further
Password-heavy authentication has become an identity tax, not an identity strategy. Organisations keep paying operational and user-experience costs for controls that the data shows they do not trust. The problem is structural: password dependence persists because the transition cost is high, even when the control itself is demonstrably weak. Practitioners should treat password reduction as a governance priority, not a UI preference.
A few things that frame the scale:
- 98% of organizations that reported an AI-related security incident lacked proper AI access controls, according to AI Agents: The New Attack Surface report.
- 80% of organizations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorized systems, inappropriately sharing sensitive data, and revealing access credentials.
A question worth separating out:
Q: How should organisations govern AI agents that touch customer data?
A: Treat each agent as a separate governed identity with explicit scope, audit requirements, and approval boundaries. If an agent can access data, invoke tools, or act on behalf of users, the control model must define what it may do, what it may not do, and how its actions are reviewed.
👉 Read our full editorial: AI agent identity risk is outpacing enterprise auth controls