TL;DR: Gartner’s 2025 Magic Quadrant for Access Management says CIAM is now the main driver of access management growth, with demand rising for modern replacements to homegrown platforms and stronger support for passwordless, orchestration, and machine IAM, according to Gartner. The practical message is that access management programmes now have to account for customer, workforce, and agentic identities together, not as separate design problems.
At a glance
What this is: This is Descope’s interpretation of Gartner’s 2025 Access Management report, which says CIAM is driving category growth and modern access stacks must support passwordless, orchestration, and machine IAM.
Why it matters: It matters because IAM teams are being pushed to rethink CIAM, workforce IAM, and non-human access as one operational surface, not three disconnected programmes.
By the numbers:
- 51% of respondents used workforce-oriented solutions for CIAM, while only 8% said they would choose that path again.
- 50% of open-source CIAM buyers agreed that organisations lost revenue after implementing stricter access control.
- 51% of open-source CIAM buyers agreed that organisations suffered security incidents after implementing low-friction access control.
👉 Read Descope’s analysis of Gartner’s 2025 Access Management report
Context
CIAM has moved from a niche customer authentication problem to a core access management decision, because modern organisations now need user journeys that can support customers, partners, service accounts, and AI-enabled systems without constant rework. The article argues that homegrown and workforce-centric stacks struggle when identity scope expands faster than the underlying architecture.
For IAM programmes, the real issue is not whether authentication is modern enough. It is whether the access layer can handle changing user journeys, orchestration, API-driven integrations, and machine access without forcing teams into brittle customisation or fragmented governance.
Key questions
Q: How should teams decide whether CIAM belongs in the same IAM programme as workforce access?
A: Treat CIAM as a distinct access domain with shared governance principles but different operating requirements. Workforce IAM optimises employee lifecycle control, while CIAM must support self-service, fast-changing journeys, and high-volume external users. If a platform cannot handle those differences without heavy customisation, the programme will struggle to stay both secure and adaptable.
Q: What breaks when organisations use workforce IAM for customer identity journeys?
A: The usual failure mode is rigidity. Workforce IAM tends to assume stable populations, administrative provisioning, and slower policy change, while customer journeys require rapid experience updates, flexible authentication, and lower-friction recovery. The result is often poor user experience, more engineering dependency, and a governance model that cannot keep pace with business needs.
Q: Why do machine identities need to be part of access management decisions?
A: Because machine identities now sit on the same trust paths as people. OAuth tokens, API keys, MCP servers, and AI agents all depend on access scope, policy, and revocation discipline. If teams exclude them from IAM design, they create parallel controls that are harder to audit, harder to govern, and easier to fragment over time.
Q: How can security teams tell whether their CIAM stack is becoming too expensive to govern?
A: Look for repeated engineering involvement in basic identity changes, growing reliance on custom flows, and delayed delivery whenever authentication or recovery logic shifts. Those are signs that the platform is operationally brittle. When routine identity work becomes a software project, the governance burden has overtaken the access benefit.
Technical breakdown
Why CIAM and workforce IAM break down under growth
Workforce IAM platforms are built around employee lifecycles, policy structures, and administrative assumptions that do not map cleanly to customer-facing journeys. CIAM adds self-service onboarding, flexible authentication paths, and product-led experiences that have to change quickly without code-heavy rewrites. When organisations try to stretch workforce tools into CIAM, they usually inherit poor flexibility, weak journey control, and higher maintenance overhead. Open-source stacks can create a different problem: they give teams freedom, but that freedom often turns into a permanent custom-build burden. The architecture may function, but the operating model becomes fragile.
Practical implication: separate CIAM requirements from workforce IAM assumptions before choosing or extending an access platform.
Passwordless, orchestration, and adaptive access are now baseline requirements
The report frames passwordless authentication, adaptive and risk-based access controls, and identity orchestration as core access management themes rather than optional enhancements. That matters because user experience and security are no longer competing add-ons in CIAM. Journey-time orchestration lets teams change flows without rewriting application logic, while adaptive controls let access decisions respond to device, location, and risk signals. For modern identity stacks, the challenge is not simply whether a method exists. It is whether the platform can combine methods, policy, and context across channels and applications without creating operational drag.
Practical implication: validate whether your access stack can adapt journeys and risk rules without code changes or long release cycles.
Machine IAM is now part of access management, not a side channel
The article’s machine IAM section is a reminder that access management now includes OAuth tokens, API keys, MCP server access, and AI agents acting on behalf of users. That changes the identity boundary. Non-human systems need scoped access, token handling, and role-aware restrictions, but they also need governance that fits machine-to-machine and agent-mediated interactions. If teams treat these as separate from CIAM and workforce access, they create inconsistent policy and blind spots in audit, entitlement, and revocation. The access platform is now being asked to govern both human journeys and machine workflows in one control plane.
Practical implication: include machine IAM requirements in access architecture decisions, not as a later extension.
Threat narrative
Attacker objective: The objective is not a single breach event but operational weakness: forcing identity systems into fragile patterns that undermine both conversion and control.
- Entry: Organisations enter the risk surface by extending workforce IAM or open-source CIAM into customer-facing journeys that were never designed for that use case.
- Credential access: Access control friction, custom workflows, and fragmented identity stores increase the chance that users or systems rely on brittle authentication and secret-handling patterns.
- Impact: The result is higher maintenance burden, weaker agility, and in some cases lost revenue or security incidents when access controls and user experience are poorly balanced.
Breaches seen in the wild
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
- ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
CIAM is no longer a peripheral identity use case. Gartner’s framing makes CIAM a growth engine for access management because customer and partner journeys now drive more architectural decisions than traditional workforce-only assumptions. That shifts the centre of gravity from admin efficiency to runtime flexibility, journey design, and control consistency across channels. Practitioners should treat CIAM as a first-class IAM domain, not a bolt-on to employee access.
The build-versus-buy decision for CIAM has become a governance decision. The article shows that homegrown CIAM can become an identity maintenance programme disguised as an engineering choice. Once business teams expect rapid changes, self-service, and omnichannel support, custom stacks often become fragile and expensive to govern. The implication is that access governance now has to account for product velocity, not just entitlement correctness.
Workforce IAM assumptions do not survive customer identity scale. Tools shaped around employee access tend to over-emphasise administrative structure and under-emphasise journey adaptability. That mismatch is why workforce-oriented solutions can look viable at procurement time and feel like a dead end later. Practitioners should assume that CIAM requires a different operating model, even when the underlying authentication principles overlap.
Machine IAM belongs in access management architecture, not in a separate innovation lane. The article explicitly links machine IAM, MCP servers, OAuth, API keys, and AI agents to the same access layer that governs people. That is where the market is heading: a converged identity surface where humans, services, and agents all depend on the same policy, token, and orchestration logic. Teams that keep machine access outside the main IAM programme will accumulate governance gaps.
Journey-time orchestration is becoming the control point that identity programmes were missing. Static policy enforcement is not enough when access experiences have to change in response to context, channel, and user state. Orchestration turns access management into a programmable decision layer rather than a fixed login screen. The practical conclusion is that future-ready IAM programmes will be judged by how quickly they can change flows without compromising governance.
From our research:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities.
- That confidence gap is a warning sign for CIAM and machine IAM convergence, which is why Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is the right next read for governance teams.
What this signals
The market signal is that identity programmes can no longer treat customer access, workforce access, and machine access as separate buying motions. The programme that wins will be the one that can change journeys quickly without losing policy control, and that starts with clearly separating CIAM requirements from workforce assumptions.
Access orchestration debt: the hidden cost is not just integration complexity, but the accumulation of identity decisions that can only be changed by engineers. As identity flows become more dynamic, teams should expect procurement pressure to shift toward platforms that expose policy and journey controls cleanly, rather than forcing brittle custom code.
With 88.5% of organisations saying their non-human IAM practices lag behind or merely match human IAM, the convergence of CIAM and machine IAM is a governance test, not a feature list. Teams should prepare for access models that span humans, services, and AI-enabled systems while keeping lifecycle control coherent.
For practitioners
- Separate CIAM from workforce IAM requirements Define customer, partner, and workforce identity requirements independently before platform selection. Map the differences in onboarding, self-service, recovery, and policy change so you do not inherit employee-centric assumptions where they do not fit.
- Test for journey-time orchestration before committing Validate whether authentication flows can be modified without code rewrites, especially for passwordless adoption, adaptive MFA, and omnichannel journeys. The platform should support policy changes at runtime, not just admin-console edits.
- Bring machine IAM into the access architecture review Include OAuth tokens, API keys, MCP server access, and AI agent access in the same architecture workshop as customer login and workforce access. Separate controls often create inconsistent revocation, audit, and entitlement handling.
- Measure the maintenance burden of custom CIAM paths Track how many identity changes require engineering work, how often customer journeys are delayed by access updates, and how much code is needed to support common authentication variations. High customisation is a governance risk, not just a delivery cost.
Key takeaways
- CIAM has become a core access management problem, not a niche customer-authentication issue.
- The strongest warning sign is when access changes depend on engineering effort instead of policy and orchestration.
- Machine IAM is now part of the same governance surface as customer and workforce identity, so programmes must be designed accordingly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | CIAM and machine access both depend on controlled identification and authentication. |
| NIST Zero Trust (SP 800-207) | AC-2 | Dynamic journeys and machine access need identity-driven access decisions. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Machine IAM, API keys, and tokens are non-human identities covered by NHI governance. |
Treat CIAM and machine IAM as zero-trust access problems and enforce continuous verification at every step.
Key terms
- Ciam: Customer Identity and Access Management is the part of identity that governs external users, such as customers, partners, and prospects. It must support self-service, high-scale authentication, and changing journeys while still enforcing policy, recovery, and auditability.
- Journey-time orchestration: Journey-time orchestration is the ability to change authentication and access flows while the user session is in motion, without rewriting application code. It lets identity teams adjust methods, risk checks, and branch logic based on context, which is especially useful in CIAM environments.
- Machine Iam: Machine IAM is the governance of non-human access paths used by services, workloads, APIs, and AI agents. It covers tokens, secrets, certificates, scope, ownership, and revocation, and it requires lifecycle discipline just like human access, but applied to software identities.
- Access orchestration debt: Access orchestration debt is the growing operational burden created when identity changes can only be delivered through custom code or repeated engineering effort. It signals that access management has become brittle, slower to govern, and harder to adapt as requirements change.
Deepen your knowledge
CIAM, machine IAM, and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your identity programme is expanding beyond workforce access, it is worth exploring.
This post draws on content published by Descope: Descope gets Honorable Mention in 2025 Gartner® Magic Quadrant™ for Access Management. Read the original.
Published by the NHIMG editorial team on 2025-11-19.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org