Start by inventorying every custom authentication flow, tenant model, and application dependency tied to the legacy platform. The first goal is to identify what must move, what can be retired, and what would break if the vendor stopped changing the product entirely.
What breaks first when CIAM enters maintenance mode?
Start with the parts of the customer identity stack that are hardest to replace without visible disruption: authentication flows, tenant assumptions, profile and consent data, password reset and recovery paths, and any downstream application that depends on platform-specific hooks. The practical goal is not a full migration plan yet, but a clean map of what is coupled, what is replaceable, and what will fail if the platform stops evolving.
A maintenance-mode announcement changes the problem from feature selection to dependency control. Teams need to understand whether the platform is still adequate for steady state operations, but no longer safe to treat as a strategic foundation. That shift matters most where the CIAM layer is embedded in login, session handling, consent, federation, or fraud controls that other systems assume will continue working unchanged.
What should teams inventory before they decide anything else?
Inventory the authentication surface first, because that is usually where hidden coupling is deepest. Map sign-in methods, step-up paths, social or enterprise federation, recovery flows, MFA, passkeys, delegated access, and any custom logic around progressive enrollment. If the platform supports customer identity at scale, review how Customer IAM (CIAM) Guide frames those controls so the inventory covers both user journeys and abuse-resistant design.
Then inventory the tenant and environment model. Many CIAM migrations fail because organizations discover too late that tenants encode business units, regions, brands, or B2B customer boundaries in ways that are not portable. Include configuration exports, custom policies, email templates, branding, consent settings, and any environment-specific rules that would behave differently after migration.
Finally, inventory every application dependency, not just the CIAM product itself. Look for hard-coded endpoints, SDK versions, token validation logic, custom claims, event hooks, provisioning jobs, and downstream services that consume identity attributes or session signals. A useful comparison is the broader identity governance view in IAM and IGA Basics, because maintenance mode often exposes the gap between authentication ownership and access governance ownership.
Why does maintenance mode create operational and security risk?
Maintenance mode does not mean immediate failure, but it does mean the control plane is aging in place. That creates risk when new application work keeps depending on a platform that may no longer receive feature updates, compatibility fixes, or security improvements. If the CIAM platform also anchors fraud controls, identity proofing, or account recovery, those risks can propagate quickly into account takeover exposure.
The most common failure mechanism is drift. Applications, browsers, mobile clients, federation partners, and adjacent security tools continue to change while the CIAM layer remains static. Over time, that mismatch shows up as broken login journeys, brittle recovery flows, degraded usability, and exceptions that teams patch with custom code. For buyer-side evaluation and replacement planning, CIAM Buyer's Guide is a useful reference for the capabilities that typically need to survive a platform transition.
There is also a concentration risk. When one CIAM product holds the tenant model, the authentication policy, and the customer profile lifecycle, the business inherits a single point of change control. In maintenance mode, that concentration becomes harder to justify because the organization is effectively freezing a critical trust layer while everything around it keeps moving.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | CIAM maintenance mode affects customer account lifecycle and dependent access paths. |
| IA-2 — Identification and Authentication (Organizational Users) | Customer sign-in, federation, MFA, and recovery paths are central to CIAM continuity. | |
| IA-5 — Authenticator Management | Maintenance-mode CIAM often exposes secret, token, and authenticator lifecycle dependencies. | |
| Recommendation — Inventory affected customer accounts and dependent flows before planning migration. Verify all authentication methods and preserve equivalent assurance in the replacement platform. Review credential and token lifecycle dependencies that the legacy CIAM currently manages. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems inventory | A first-step CIAM inventory is an asset and dependency inventory problem. |
| Recommendation — Map every dependent application, tenant, and integration before deciding migration scope. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | Teams need a complete inventory of CIAM-linked assets and dependencies before transition decisions. |
| Recommendation — Document all CIAM-linked assets, dependencies, and ownership before changing platforms. | ||
Practitioner Guidance
What to prioritise: Treat the first inventory as a dependency map, not a tooling exercise. The highest-value output is a list of customer journeys, integrations, and tenant structures that cannot tolerate a platform swap without redesign.
What to verify: Confirm which authentication paths are custom, which are standard, and which applications consume CIAM-specific claims or events. If you cannot explain how a login or recovery flow would behave without the current platform, that dependency is not yet understood well enough for migration planning.
Common mistake: Teams often start with feature comparison between vendors before they know what must be preserved. That usually produces false confidence, because the real blocker is rarely authentication alone, it is the surrounding tenant model, recovery logic, and downstream application contract.
What good looks like: You can separate core journeys into move, retire, or redesign categories, and you can name the systems that would fail, degrade, or require code changes if the legacy platform stopped changing tomorrow.
Practitioner takeaway: The right first step is to expose coupling early enough that migration becomes an architecture decision rather than an emergency response.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org