Choose bulk import when password hashes can be exported and verified in the target system, because it preserves login continuity and limits user disruption. Choose just-in-time migration when hashes are unavailable but the old platform can remain active long enough to move users at login. The decision should be driven by credential portability, parallel-run capacity, and the support burden each path creates.
Why This Matters for Security Teams
ciam migration is usually sold as a technical cutover, but the real decision is operational: how to preserve login continuity without creating a credential handling problem that outlives the migration itself. Bulk import reduces user friction when password hashes can be exported and validated, while just-in-time migration avoids forcing a pre-cutover password reset when that is not possible. The tradeoff is not abstract. It affects support volume, parallel-run duration, and the blast radius of any import or sync mistake.
This is also where identity hygiene becomes visible. NHIMG research shows that 71% of NHIs are not rotated within recommended time frames, and 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, which is a reminder that migration projects often expose weak identity handling that was already present. For broader control mapping, the NIST Cybersecurity Framework 2.0 is useful for tying migration choices to recovery, access control, and operational resilience. In practice, many security teams discover import constraints only after a failed cutover or a flood of login tickets has already begun.
How It Works in Practice
Bulk import works best when the source CIAM can export password hashes in a format the destination supports, and when the target platform can verify those hashes without exposing plaintext passwords. That makes the transition largely invisible to users. The practical checklist is simple but strict: confirm hash algorithm compatibility, validate salt and iteration handling, test failed-login paths, and define a rollback point before any production switch. If the migration includes MFA, remember that password portability does not automatically mean factor portability.
Just-in-time migration is different. The old CIAM stays live, and users are migrated at login: they authenticate against the legacy system, then the new platform creates the account and stores the credential state for future use. This pattern is useful when hashes are unavailable, but it depends on a parallel-run window and a stable legacy environment. Current guidance suggests treating the old platform as a temporary dependency that must remain monitored, patched, and capacity tested until the migration finishes.
For teams choosing between these paths, the decision usually turns on three factors:
Can password hashes be exported, trusted, and verified in the destination CIAM?
Can the legacy system stay available long enough to support first-login migration?
Which option creates less support burden if users forget passwords, lose MFA factors, or collide with profile mismatches?
Where identity teams need a deeper operational baseline, NHIMG’s Ultimate Guide to NHIs is a useful reference for understanding how lifecycle mistakes and weak secret handling accumulate across identity programs. These controls tend to break down when the legacy CIAM cannot remain online long enough to absorb first-logins because the cutover schedule is fixed by business dates rather than authentication readiness.
Common Variations and Edge Cases
Tighter migration control often increases the time and coordination required, so teams have to balance login continuity against the cost of running two identity stacks at once. That tradeoff becomes especially sharp when the old CIAM has undocumented hash schemes, inconsistent MFA enrollment, or user profiles that do not map cleanly to the new schema.
There is no universal standard for this yet, but best practice is evolving toward a risk-based split: use bulk import for populations with portable hashes and stable account data, and reserve just-in-time migration for the remainder. Hybrid approaches are common, especially in large estates where one customer segment may support import while another requires first-login migration. The key is to document which populations use which path so support teams know what to expect.
Two edge cases deserve special attention. First, if the source system cannot safely remain active, just-in-time migration becomes a bad fit because the user must be able to authenticate somewhere during the transition. Second, if bulk import requires password rehashing or transformation that the source cannot provide reliably, the risk shifts from user friction to credential integrity. For background on secret handling failures that often surface during identity changes, see NHIMG’s Guide to NHI Rotation Challenges and the analysis of Azure Key Vault privilege escalation exposure. In practice, the wrong choice usually shows up as either mass password resets or an extended parallel-run that nobody staffed for.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | CIAM migration choice hinges on secure identity proofing and access continuity. |
| NIST CSF 2.0 | PR.AC-4 | Bulk import and JIT migration both require least-privilege access handling. |
| NIST CSF 2.0 | RC.RP-1 | Parallel-run and rollback planning are core to low-disruption identity migration. |
Map migration steps to PR.AC-1 and verify users can authenticate without weakening access assurance.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
