Just-in-time migration moves a user’s identity into the target system at the moment they log in, rather than in one bulk transfer. It reduces disruption, but it requires both systems to operate in parallel and demands reliable synchronisation, clear cutover rules, and strong monitoring.
Expanded Definition
Just-in-time migration is a cutover pattern that creates or updates a user identity in the target system only when the user first authenticates there, rather than preloading every account in advance. In identity and NHI programs, the term is often used during directory modernisation, application consolidation, or cloud tenant transitions where NIST Cybersecurity Framework 2.0 principles of resilience and controlled change are relevant.
Unlike bulk migration, JIT migration depends on a live trust relationship between the source and target systems, plus reliable attribute mapping, provisioning rules, and deprovisioning logic. Guidance varies across vendors on whether the identity is truly “migrated” or merely “materialised” at sign-in, so practitioners should treat the term as an operational pattern rather than a single standardised mechanism. In NHI-adjacent environments, the same design logic can appear when service principals, workload identities, or agent accounts are introduced only when needed and constrained by policy. NHIMG’s Ultimate Guide to NHI is a useful reference for the governance context around lifecycle control and visibility. The most common misapplication is assuming JIT migration eliminates source-system dependency, which occurs when cutover teams fail to account for parallel authentication and rollback paths.
Examples and Use Cases
Implementing just-in-time migration rigorously often introduces temporary dual-running complexity, requiring organisations to weigh user continuity against the cost of synchronising two identity estates at once.
- A workforce app moves from an on-prem directory to a cloud identity provider, and each user is created in the target tenant the first time they log in after the cutover window.
- A merger requires staged migration of thousands of users, so only active accounts are instantiated in the new directory, reducing up-front data movement and clean-up effort.
- A SaaS platform supports delegated identity creation through NIST Cybersecurity Framework 2.0-aligned access control and logging, allowing migration events to be tracked as they occur.
- An engineering organisation uses the same approach to transition privileged service accounts, but only after validating token mapping and secret handling against the lessons in Guide to NHI Rotation Challenges.
- A regional rollout uses JIT migration to onboard users in waves, keeping legacy and target directories live until authentication success rates stabilise.
JIT migration is especially useful when identity stores cannot be frozen for a long batch window, but it demands careful reconciliation rules so duplicate or orphaned identities do not emerge during first sign-in.
Why It Matters in NHI Security
In NHI security, just-in-time migration matters because migration logic often touches the same controls that govern service accounts, API keys, and credential lifecycles. If the target system creates identities on demand without strong monitoring, teams can accidentally preserve excessive privileges or reintroduce stale entitlements. NHIMG notes that only 5.7% of organisations have full visibility into their service accounts, which illustrates how easily migration work can hide unmanaged identities when inventory is incomplete.
The risk is not just technical failure, but governance drift: source and target systems may disagree on who is authorised, which attributes are authoritative, or when an identity should be disabled. That is why JIT migration should be paired with logging, reconciliation, and explicit cutover criteria, especially in environments where machine identities are already overexposed. Organ organisations typically encounter the consequences only after users are locked out, duplicate identities appear, or a rollback exposes unexpected privilege paths, at which point just-in-time migration becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 | Identity proofing and authentication assurance affect JIT-created identities at first sign-in. |
| NIST Zero Trust (SP 800-207) | IA-3 | Zero Trust requires continuous validation when identities are materialised during migration. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity lifecycle gaps and hidden accounts are core NHI governance risks during migration. |
Ensure on-demand identity creation still inherits verified authentication and access controls.
Related resources from NHI Mgmt Group
- What is Just-in-Time (JIT) access and why is it important for NHI security?
- When do NHI access reviews create more value than a one-time cleanup?
- When does just-in-time access reduce risk for agentic AI, and when does it fall short?
- How do organisations reduce the dwell time of exposed credentials at scale?
