How should organisations approach identity management when moving Office 365 to the cloud without keeping Active Directory?

Treat the migration as a redesign, not a lift and shift. Start by deciding which identities, devices, and applications need centralized control, then map them to cloud-native authentication, provisioning, and access policies. The key move is to make identity the new perimeter and choose a directory model that supports modern workflows instead of preserving on-premises assumptions.

Rebuild identity as a cloud control plane, not a server dependency

When Office 365 moves to the cloud without retaining Active Directory, identity stops being something anchored to a local directory and becomes the control plane for authentication, provisioning, and policy enforcement. The practical question is not whether to preserve the old model, but which identity source, trust boundary, and lifecycle process will replace it cleanly. That decision should be made before mailbox, device, or app migration work begins.

A cloud-first approach usually means separating the functions that were historically bundled together in Active Directory. Authentication may move to cloud directory services, app access may shift to federation or modern sign-in, and device trust may need a separate enrollment and compliance layer. The main failure mode is leaving legacy assumptions in place, where the business has already moved to cloud services but still expects on-premises directory behavior to govern access.

For that reason, organisations should define the target identity architecture as a redesign exercise. If the new model cannot support passwordless authentication, conditional access, mobile device management, and application-specific authorization without an on-prem directory, it is probably not a valid replacement. A useful reference point for the broader identity lifecycle is NHI Lifecycle Management Guide, which is particularly helpful when teams need to think through provisioning, rotation, and deprovisioning as a lifecycle rather than a one-time migration task.

What has to be decided before the first tenant cutover

The first decision is which identities must remain centrally governed, and at what level. Most organisations need a deliberate split between human users, devices, applications, and automated services, because each class has different authentication, access, and governance requirements. That is especially important when the old directory was doing too much work, such as holding legacy group logic, workstation trust, and application credentials in one place.

The second decision is whether the cloud directory will be the authoritative source for users, whether identity will be synchronized from another system, or whether a hybrid trust model will exist for a transition period. The answer affects provisioning workflows, account recovery, access reviews, and the way applications consume identity claims. Modern identity design also means choosing whether conditional access, multifactor authentication, and device posture checks will be mandatory for critical workflows rather than treated as optional add-ons.

The third decision is how application access will be remediated. Office 365 may be the immediate target, but many surrounding applications still depend on directory assumptions such as LDAP lookups, group-based authorization, or shared service credentials. If those dependencies are not inventoried, the cloud migration can succeed technically while creating hidden access failures, especially for line-of-business systems, automation, and remote users.

For teams that need an identity model anchored in cloud controls, the Ultimate Guide to NHIs is a useful broader reference because it shows how identities, access governance, and credential hygiene fit together across users, services, and machines.

What “no Active Directory” changes operationally

Without Active Directory, organisations lose the convenience of relying on a local domain controller for authentication, device join, and many forms of access inheritance. That does not remove the need for identity control; it increases the need for explicit design. Provisioning, offboarding, group management, certificate handling, and privileged access must all be intentional instead of incidental.

The operational shift is that identity administration becomes policy-driven rather than infrastructure-driven. That means cloud directory governance, access policies, and administrative separation become the normal control points. It also means that recovery planning matters more, because a mistake in cloud identity configuration can disrupt access to email, collaboration, and administrative portals at the same time.

Organisations should also expect greater sensitivity to third-party and external identity integration. If partners, contractors, or remote staff need access, the cloud model should define exactly how external identities are authenticated, how access expires, and how exceptions are approved. The old habit of “just sync the directory and sort out exceptions later” is what turns a migration into a long-lived access sprawl problem.

For cloud identity architecture, SPIFFE workload identity specification is a useful adjacent model for understanding how identity can be represented and trusted without depending on a traditional directory hierarchy.

Risk and Threat Considerations

The main risk in this kind of migration is not loss of functionality, but misplaced trust in legacy directory assumptions. If identities, devices, and apps are moved without a new control model, organisations can end up with overprivileged accounts, unmanaged access paths, stale credentials, and brittle federation dependencies that are harder to see than the original on-prem setup.

Failure mechanism: Teams preserve old authentication and group logic while moving only the mailbox and collaboration layer, which creates hidden access dependencies, weak lifecycle control, and a larger blast radius when cloud sign-in or provisioning fails.

Impact: The result can be account sprawl, delayed offboarding, overbroad access, and outages that affect both users and administrators, especially when recovery depends on a directory service that no longer exists on site.

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, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	Cloud identity design centers on user authentication after AD removal.
	IA-5 — Authenticator Management	Migration success depends on lifecycle control for passwords, tokens, and recovery factors.
	IA-9 — Service Identification and Authentication	Without AD, apps and services still need explicit non-human authentication paths.
Recommendation — Use IA-2 to require strong cloud authentication for organizational users. Use IA-5 to govern authenticator issuance, rotation, and revocation. Use IA-9 to authenticate services and workloads separately from users.
NIST Zero Trust (SP 800-207)	ZT — Zero Trust Architecture	The question asks how to replace perimeter-era directory trust with cloud policy and verification.
Recommendation — Apply Zero Trust principles to make identity and device posture the new trust anchor.
CIS Controls v8	CIS-5 — Account Management	Cloud migration without AD requires tighter account lifecycle control and cleanup.
Recommendation — Implement CIS-5 to inventory, provision, and remove accounts consistently.

Practitioner Guidance

What to verify: Before migration, verify which system is authoritative for user creation, access removal, device trust, and admin elevation. If those four functions are not separately defined, the cloud cutover will inherit ambiguity that shows up later as either broken access or excessive access.

Decision rule: If an identity-dependent workflow cannot be cleanly expressed with cloud-native authentication and policy, redesign the workflow before migration rather than carrying the old dependency forward. If the application truly requires directory-era behavior, isolate that requirement and treat it as an exception with an expiration date.

Practitioner takeaway: The safest migration path is the one that treats identity as the new operating model, not as a compatibility layer for legacy infrastructure.