TL;DR: Gartner’s Innovation Insight for Customer and Partner IAM argues that more than half of organisations still rely on homegrown CIAM or no solution at all, according to Descope’s reading of the report, while external identity demands are becoming more dynamic and security-sensitive. The governance problem is no longer authentication alone but whether identity architecture can support transient users, partner ecosystems, and modern protocols without overloading workforce IAM assumptions.
At a glance
What this is: Descope’s reflection on Gartner’s 2025 customer and partner IAM insight argues that external identity has outgrown workforce IAM assumptions and now needs its own governance model.
Why it matters: IAM teams managing customer, partner, and workforce identities need to separate external identity requirements from employee-centric control patterns, or they will misfit security, UX, and lifecycle controls.
By the numbers:
- Over 50% of organizations are using either homegrown CIAM solutions or no solution at all.
- Gartner published its Innovation Insight for Customer and Partner Identity and Access Management on 28 April 2025.
Context
Customer and partner IAM, often called CIAM and PIAM, governs access for people and organisations outside the workforce. The core problem is not authentication alone, but whether identity architecture can support transient external users, partner relationships, and modern protocol expectations without inheriting employee-centric assumptions.
Descope’s reflection on Gartner’s Innovation Insight frames this as a structural split between workforce IAM and external identity. As customer-facing applications, partner portals, and multi-party ecosystems mature, the governance model has to follow the stakeholder, not the org chart.
Key questions
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 customer and partner IAM programmes need different governance than employee IAM?
A: Because external identities are governed by relationship and usage context, not by employment status. Customers, partners, and business users can arrive, shift roles, and disappear on timelines that do not match joiner-mover-leaver models built for employees. That means lifecycle, consent, and access scope have to be designed around the external stakeholder, not copied from workforce processes.
Q: How should teams decide whether to build or buy CIAM and PIAM capabilities?
A: Teams should evaluate whether they can sustain modern protocol support, external identity journey design, and security updates without pulling core engineering away from product work. If the answer is no, the governance burden of an in-house build will usually exceed the value of custom control. The deciding factor is operational fit, not internal preference.
Q: What is the difference between B2C and B2B in mature external IAM?
A: In mature external IAM, B2C and B2B are not hard programme boundaries. They are collections of identity functionality for individuals and organisations that often coexist in the same customer, partner, or vendor ecosystem. The practical difference is that identity architecture must support both constituency types without forcing one rigid model across every external relationship.
Technical breakdown
Why workforce IAM patterns break for external identities
Workforce IAM is optimised for stable employee populations, fixed joiner-mover-leaver processes, and predictable administrative boundaries. External identities behave differently: customers, partners, distributors, and vendors can be transient, multi-tenant, and embedded in product journeys rather than internal directories. That changes how authentication, profile capture, consent, session design, and delegation need to work. When teams reuse workforce IAM assumptions, they usually inherit rigid flows, limited branding, weak protocol flexibility, and poor support for business-specific identity data. The result is not just poor user experience. It is an identity control plane that cannot keep up with how external stakeholders actually interact with the organisation.
Practical implication: Separate external identity requirements from employee IAM requirements before selecting controls, flows, or platform architecture.
Why modern protocols matter in CIAM and PIAM
The article points to modern identity protocols and evolving user needs as a reason in-house builds struggle. In practice, external IAM now has to support federated login, adaptive journeys, customer-specific context, and integration with surrounding business systems without forcing developers to hand-code every path. That is an architecture question as much as an access question. If the identity layer cannot interoperate cleanly with product, risk, support, and partner systems, the organisation ends up extending ad hoc logic into the application tier. That increases maintenance cost and makes governance harder because the identity decision is no longer centralised.
Practical implication: Design external IAM so protocol handling and policy decisions stay in the identity layer, not inside application code.
How transient stakeholder populations change governance
External identities are governed by usage context, not employment status. A customer may appear once, a partner may need delegated access across several organisations, and a business user may move between constituencies over time. That makes lifecycle, consent, and access scope more dynamic than workforce provisioning. The article’s point about B2C and B2B converging is important because it shows that external identity programmes cannot be built around one fixed user class. They need flexible schemas, conditional journeys, and role-aware administration that can adapt as relationships change.
Practical implication: Treat external identity lifecycle as a dynamic governance problem and model it around stakeholder context, not static user categories.
NHI Mgmt Group analysis
External IAM is no longer a subset of workforce IAM. The article’s central argument is that customer and partner identity has different operating assumptions, different security expectations, and different lifecycle realities. Workforce IAM can authenticate an employee, but it does not automatically govern a transient customer, a partner admin, or a multi-tenant business relationship. Practitioners should stop treating external identity as an extension of employee access and start treating it as its own governance domain.
The real control gap is architectural, not cosmetic. External identity fails when organisations bolt customer and partner flows onto employee-centric platforms and then try to compensate with configuration. That creates brittle identity journeys, limited protocol flexibility, and poor support for business-context decisions such as personalised login paths or tenant-aware administration. The implication is that external IAM requires its own control plane, not a branded wrapper around workforce tooling.
Customer and partner IAM exposes identity decisioning as a product capability. The article shows that external identity is tied to user experience, developer productivity, and security at the same time. That means IAM is no longer just a back-office access function for external users; it is part of the product operating model. Organisations that recognise this will govern external identity as a shared platform capability rather than as scattered application logic.
Unified external identity does not mean uniform identity. The piece correctly notes that B2C and B2B are not cleanly separate in mature organisations. External IAM must therefore support multiple stakeholder types, different trust expectations, and different administration patterns within one programme. The governing assumption to retire is that one external identity template can serve all constituencies. Practitioners need an identity model that flexes by relationship, not by department.
External identity friction is now a governance signal, not just a UX issue. When login, consent, or delegated access flows become hard to maintain, the platform is usually telling you that the underlying identity model is too workforce-shaped for the business it serves. That is where architecture, governance, and developer experience converge. Teams should read friction as evidence that external identity has outgrown the controls built for employees.
What this signals
External identity programmes need their own control model, not a workforce IAM retrofit. As organisations add partner portals, customer communities, and multi-party application journeys, the identity layer has to express relationship-specific rules instead of employee assumptions. That shift affects how teams design admin scope, authentication paths, and lifecycle handling across the programme.
External user friction is often a sign of architectural mismatch. If organisations keep compensating for CIAM complexity inside application logic, they end up with duplicated policy decisions and brittle maintenance. The more the business depends on transient or partner access, the more important it becomes to keep the identity decision centrally governed.
For practitioners
- Separate external identity from workforce IAM Define CIAM and PIAM as distinct programme scopes with different lifecycle rules, UX expectations, and risk controls instead of folding them into employee IAM workstreams.
- Model stakeholder types explicitly Map customers, partners, vendors, and tenant admins as separate identity constituencies so journey design, consent handling, and administrative privileges reflect real relationships.
- Keep protocol logic in the identity layer Centralise federation, adaptive authentication, and session decisions in the identity control plane rather than embedding them in application code.
- Design for transient and multi-tenant access Build flows that can adapt as users move between constituencies, tenants, and partner contexts without forcing a workforce-style provisioning model.
Key takeaways
- Customer and partner IAM has different lifecycle and trust assumptions from workforce IAM, so employee-centric controls are a poor default fit.
- The main risk is architectural mismatch: external identity journeys become brittle when teams force CIAM and PIAM into workforce-shaped platforms.
- Practitioners should treat external identity as a distinct governance domain with its own control plane, protocol handling, and stakeholder modelling.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | External identity requires distinct permission and entitlement governance. |
| Recommendation — Define separate entitlements for customer and partner identities under PR.AA-05. | ||
| NIST SP 800-63 | SP 800-63C — Federation | The article centres on external identity, partner access, and federated trust boundaries. |
| Recommendation — Use federation controls to separate external trust relationships from workforce identity flows. | ||
| OWASP API Security Top 10 | API10 — Unsafe Consumption of APIs | External identity platforms must integrate safely with surrounding business systems and identity APIs. |
| Recommendation — Review identity-to-application integrations for unsafe API consumption paths and hidden trust assumptions. | ||
| CIS Controls v8 | CIS-5 — Account Management | CIAM and PIAM still require disciplined account lifecycle governance. |
| Recommendation — Apply account management controls to external identities instead of reusing employee lifecycle defaults. | ||
Key terms
- Customer Identity And Access Management: Customer Identity and Access Management is the discipline of governing how external users sign in, recover access, and move through digital services. It combines authentication, profile management, and lifecycle control so organisations can deliver secure, low-friction experiences at scale.
- Partner Identity And Access Management: PIAM governs access for business partners, suppliers, and other external organisations that need controlled entry into apps or portals. It usually involves more delegated administration, federation, and lifecycle complexity than customer identity because access often reflects commercial relationships and shared business processes.
- External Identity: An external identity is an account or access path owned outside the organisation but trusted inside it, such as a partner, vendor, contractor, or temporary worker. These identities enlarge the attack surface because they are harder to govern consistently and often fall outside standard employee lifecycle processes.
- Federated Identity: Federated identity lets one organisation trust an external identity provider so a user can access another service without creating a separate account. It simplifies access, but it also expands the trust relationship that must be monitored. Weak federation settings can turn a single compromise into cross-domain access.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 16, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org