What do organisations get wrong when they try to manage tenant access and custom roles across multiple CIAM vendors?

Why This Matters for Security Teams

Multi-vendor CIAM often looks like a platform selection issue, but the real risk is identity model drift. Tenant access, custom roles, and user hierarchies tend to be implemented differently in each stack, so policy decisions fragment across products and teams. That creates inconsistent entitlements, brittle migrations, and gaps that are hard to see until access is mis-granted or revoked too late.

This problem shows up in the same way NHI governance breaks down when access logic is scattered: design choices become vendor-specific exceptions instead of a consistent control model. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is a reminder that fragmented authorization logic usually expands access rather than constrains it. NIST’s Cybersecurity Framework 2.0 treats identity governance as an ongoing capability, not a one-time configuration task.

For organisations running multiple CIAM vendors, the mistake is assuming each implementation can define “tenant” and “role” independently without downstream cost. In practice, many security teams encounter access drift only after a migration, merger, or regional rollout has already exposed the inconsistency.

How It Works in Practice

The better approach is to define a single access model first, then map each CIAM vendor to it. That means standardising the meaning of tenant scope, role scope, entitlement inheritance, and administrative boundaries before any product-specific configuration begins. Current guidance suggests treating these as policy design decisions, not UI or implementation details.

Teams usually get better results when they separate three layers:

• Business policy: what a tenant, organisation, region, or customer segment is allowed to do.

• Canonical access model: the shared schema for roles, permissions, hierarchy, and delegation.

• Vendor mapping: the translation rules that adapt the canonical model to each CIAM product’s features and limitations.

This matters because one vendor may support nested organisations, another may rely on custom claims, and a third may force role composition through scripts or external policy engines. If those differences are hidden inside local builds, the organisation ends up with multiple versions of the truth. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the Ultimate Guide to NHIs — Key Challenges and Risks both reinforce the broader lesson: lifecycle consistency matters more than isolated control points.

Operationally, this is where policy-as-code, entitlement catalogs, and versioned role definitions help. NIST SP 800-53 Rev. 5 supports this kind of control discipline through access enforcement and accountability requirements, while the OWASP Non-Human Identity Top 10 is a useful reminder that excessive privilege and poor lifecycle governance are recurring failure modes across identity types. These controls tend to break down when a vendor cannot represent hierarchy cleanly, forcing teams to encode exceptions directly into application logic.

Common Variations and Edge Cases

Tighter standardisation often increases upfront modelling work, requiring organisations to balance consistency against speed of rollout. That tradeoff becomes visible in mergers, regulated markets, and global tenant structures where one-size-fits-all role design is rarely practical.

Some teams need different access patterns for enterprise tenants, consumer tenants, and internal operators. That is not a reason to abandon a canonical model, but it is a reason to define controlled variation. Best practice is evolving here: there is no universal standard for tenant hierarchy across CIAM vendors, so the safest pattern is to standardise semantics while allowing product-specific translation at the edge.

Edge cases usually appear when one vendor supports rich hierarchy and another only supports flat roles, or when regional data residency rules require separate directories and administrative domains. In those cases, the mistake is trying to force identical configuration everywhere instead of preserving equivalent policy intent. The 2024 Non-Human Identity Security Report found that 35.6% of organisations see consistent access across hybrid and multi-cloud environments as their top NHI security challenge, which mirrors the same consistency problem in CIAM. The more fragmented the estate, the more important it is to test role resolution, tenant isolation, and administrative escalation paths before production cutovers.

When custom roles are used as a substitute for access architecture, organisations usually discover the cost during audit, tenant expansion, or vendor replacement. At that point, role cleanup becomes a redesign project rather than a configuration change.

Related resources from NHI Mgmt Group

• What do organisations get wrong about harmonising AML and CFT controls across multiple jurisdictions?
• What do organisations get wrong when they try to make BYOD compliant across different device types?
• What do security teams get wrong about using APIs to manage user roles and application licences?
• What do organisations get wrong when they treat partner enablement as a sales-only function?