What should organisations do when their CIAM platform no longer fits their authentication needs?

They should separate the identity system of record from the authentication experience, then decide which controls belong in each layer. That usually means keeping account and access governance in the CIAM platform while moving passkeys, step-up, and risk-based decisions into a dedicated authentication service when needed.

Why This Matters for Security Teams

When a CIAM platform stops fitting authentication requirements, the risk is usually not the login page itself. The real problem is that identity, assurance, and authorization controls have been collapsed into one layer for too long. As organisations add passkeys, step-up challenges, fraud signals, and adaptive policy, the CIAM system can become a bottleneck for customer experience, resilience, and governance at the same time.

That is why NHI Management Group recommends separating the identity system of record from the authentication experience. It aligns with the control logic in NIST SP 800-53 Rev 5 Security and Privacy Controls, where authentication strength and account governance are related but not identical concerns. It also reflects the practical lesson seen in the Ultimate Guide to NHIs — The NHI Market: identity sprawl and control misalignment create operational debt long before they create a visible incident.

In practice, many security teams discover the mismatch only after onboarding friction, failed step-up journeys, or risky workarounds have already spread across product and engineering teams.

How It Works in Practice

The cleanest pattern is to keep CIAM as the system of record for accounts, profiles, consent, and lifecycle events, while moving authentication into a dedicated service that can handle modern requirements without forcing a platform migration. That service may manage passkeys, MFA orchestration, device signals, step-up flows, and risk-based decisions in real time. The key is that authentication becomes a capability, not a property locked inside one product.

This division of labour is especially important when assurance needs vary by journey. A low-risk account lookup should not trigger the same challenge as a payment change or admin action. Current guidance suggests using policy-driven authentication so the decision is made at runtime, based on context such as device posture, location, transaction sensitivity, and session history. In other words, the organisation should decide what the user is trying to do, then authenticate to that risk.

Implementation usually works best when the CIAM platform issues the canonical identity and the authentication layer returns trust signals or session assertions. That lets downstream applications consume a consistent identity while still enforcing stronger checks where needed. It also avoids turning the CIAM vendor into a monolith that must solve every assurance problem at once. For governance and control design, teams can map these responsibilities against ISO/IEC 27001:2022 Information Security Management and the account lifecycle guidance in NHI Management Group’s Ultimate Guide to NHIs.

• Keep the CIAM platform as the source of truth for identity, consent, and account status.
• Move adaptive authentication, passkeys, and step-up policy into a separate service when requirements outgrow the platform.
• Use risk signals and transaction context to choose the right assurance level at runtime.
• Ensure downstream apps consume signed assertions or session state, not bespoke local logic.

These controls tend to break down in tightly coupled legacy environments because application code, session handling, and account governance all depend on the same vendor-specific authentication stack.

Common Variations and Edge Cases

Tighter authentication control often increases integration and operational overhead, requiring organisations to balance stronger assurance against release speed, vendor complexity, and user friction. That tradeoff is why there is no universal standard for when to split CIAM from authentication; the decision depends on scale, risk appetite, and how much custom policy the business now needs.

One common edge case is a CIAM platform that already supports some adaptive features, but only through limited rules or rigid workflows. In that situation, best practice is evolving rather than settled: some organisations can extend the platform safely, while others need an external authentication layer once policy logic becomes too granular or too dynamic. Another edge case is regulated or high-friction journeys such as financial operations, healthcare portals, and admin consoles, where stronger step-up may need to be isolated from consumer login flows.

The most useful signal is not whether the platform is “old” or “new,” but whether it can separate identity governance from assurance decisions without creating workarounds. If teams are embedding custom auth code into every app, or if product teams are bypassing the platform to get the UX they need, the architecture has already outgrown a single CIAM dependency. That pattern is visible in breach and secrets research such as TruffleNet BEC Attack — Stolen AWS Credentials, where weak control boundaries amplified access risk, and in the NHI management data showing that many organisations still struggle with access consistency across modern environments.

Related resources from NHI Mgmt Group

• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?
• Should organisations prioritise external exposure or internal credential governance first?