Coexistence is the operating state where source and target directory environments remain live during a phased migration. Users, services, and dependencies may span both sides for weeks or months. This makes sequencing, visibility, and rollback planning essential, because failures affect only the active wave if the program is designed correctly.
Expanded Definition
Coexistence is the controlled phase in a directory migration where source and target environments remain operational at the same time. It is not a static “both on forever” state, but a deliberate transition window in which identities, group memberships, authentication paths, and dependent services may be split across two systems while the program completes wave by wave.
The boundary that matters is operational ownership. During coexistence, one directory usually remains authoritative for some records while the other begins to absorb new provisioning or synchronized state. That creates a practical need to define which side owns create, update, disable, and rollback decisions at each stage. A common misunderstanding is to treat coexistence as only a technical replication problem; in reality, it is also a governance and sequencing problem because mismatched policy, duplicate objects, or stale attributes can persist long enough to affect access decisions.
For migration planning, coexistence differs from cutover: cutover ends the overlap, while coexistence manages it safely. The better the overlap is scoped, observed, and reversible, the less likely a migration wave is to spread failure beyond the accounts or applications currently being moved.
Examples and Use Cases
- A legacy directory stays live while a cloud directory is introduced for a subset of business units, allowing users to authenticate in the old environment until their applications are ready.
- Directory synchronization runs between source and target so staged groups, attributes, or password states can be validated before final switch-over.
- Partner or contractor identities remain on the source side while internal employee accounts are migrated first, reducing operational disruption for dependent systems.
- An application team keeps one set of service dependencies on the original directory while testing the target directory against lower-risk user populations.
- A rollback plan preserves the source environment until post-migration validation confirms that sign-in, authorization, and downstream lookups behave as expected.
Coexistence is useful when the estate contains older applications, hybrid authentication paths, or dependencies that cannot all move in one window. The tradeoff is that the longer the overlap lasts, the more carefully teams must manage consistency, support boundaries, and duplicate administration.
Security Implications
Coexistence increases the chance of policy drift, inconsistent group membership, and ambiguous ownership if teams do not define which system is the source of truth for each object type. Those conditions can create unintended access, delayed deprovisioning, or failed access changes during the migration window.
Another common failure mode is incomplete visibility. If monitoring, audit trails, or admin activity are split across two directories, investigators may miss who changed a privilege, when a user was disabled, or why a login succeeded in one environment but not the other. That makes coexistence especially sensitive for privileged accounts and time-bound change windows.
The operational risk is often local rather than catastrophic, which can make it easy to underestimate. A well-designed coexistence model should therefore isolate each migration wave, validate directory sync behaviour before expanding scope, and ensure rollback does not reintroduce stale access state. For directory and identity migration work, the control question is usually not whether coexistence is needed, but whether it is bounded well enough to preserve access integrity while both sides remain active.
Security, Operational and Governance Implications
In security terms, coexistence is a temporary trust boundary problem. Two live directories mean two places where identity truth, policy enforcement, and revocation timing can diverge, so governance has to specify which system governs which decisions at each stage of the migration.
That has direct implications for least privilege, change control, recovery planning, and exception handling. If the overlap is not tightly owned, an access change can be applied in one system and missed in the other, or a rollback can restore availability while silently restoring outdated permissions. The result is usually not a dramatic outage, but a governance gap that persists until the overlap is closed.
SPIFFE workload identity specification is a useful adjacent reference when coexistence includes machine or service identities, because it highlights how identity, attestation, and trust boundaries must remain explicit during transitions. For broader control planning, NIST Cybersecurity Framework 2.0 helps teams tie coexistence to governance, protection, detection, response, and recovery rather than treating migration as a pure infrastructure exercise.
Risk and Threat Considerations
Coexistence creates a temporary exposure window because two live systems can hold overlapping identity state, access paths, and administrative control. That makes it attractive to attackers if stale accounts, duplicated privileges, or weak synchronization are left in place.
Failure mechanism: compromise or misconfiguration in one directory can persist into the other through sync errors, delayed revocation, or inconsistent policy enforcement. Attackers also benefit when defenders cannot quickly tell which side is authoritative for a given account, group, or service principal.
Impact: the practical result is unauthorized access, delayed detection of privilege abuse, and rollback paths that may restore the wrong state. In a migration, that can turn a contained issue into a broader access-control failure across both environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST Zero Trust (SP 800-207), NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | PL-2 — Security and Privacy Architecture | Coexistence changes trust boundaries and identity flows during migration. |
| Recommendation — Define the trust boundary between source and target directories before each migration wave. | ||
| NIST CSF 2.0 | GV.SC — Supply Chain Risk Management | Directory coexistence depends on controlled third-party and migration dependencies. |
| PR.AA — Identity Management, Authentication and Access Control | Coexistence directly affects how identities and access decisions remain consistent across systems. | |
| Recommendation — Assign ownership for migration dependencies and validate rollback assumptions before cutover. Keep access provisioning, revocation, and authentication decisions aligned across both directories. | ||
| CIS Controls v8 | 6 — Access Control Management | Coexistence can create duplicate or stale access paths if governance is unclear. |
| 8 — Audit Log Management | Two live directories require visibility into changes and failures across both sides. | |
| Recommendation — Review and remove duplicate access paths before moving each identity wave. Centralize logs from both directories so identity changes remain traceable during coexistence. | ||
Practitioner Guidance
Why practitioners should care: coexistence is safest when each wave has a clear owner, a defined source of truth, and a narrow rollback boundary. Without that, the migration can appear to be progressing while access state quietly diverges.
What to watch for: duplicate objects, unexpected group memberships, partial sync failures, and sign-in paths that succeed in one directory but fail in the other are early signs that the overlap is no longer tightly controlled. Treat those as migration-blocking conditions, not cosmetic issues.
Practitioner takeaway: the best coexistence plans assume that inconsistency will happen, then design sequencing, validation, and exit criteria so it stays contained to the current wave.
Related resources from NHI Mgmt Group
- What do security teams get wrong about Apple MDM and DDM coexistence?
- Why do LTE-M and 5G coexistence models complicate IoT governance?
- Why do passkey and password coexistence models create account governance risk?
- What is the difference between hybrid coexistence and retiring legacy identity systems?
