Modern identity architecture still works AD-first for many

For many organizations, especially those in highly regulated industries, identity architecture runs on Active Directory (AD) at its core. AD authenticates users, enforces access policies, and underpins the applications the business runs on. This is different from how vendors frame the issue: identity and access management (IAM) is cloud-first, with AD repositioned as a legacy connector. One that's temporary and obsolete, or at the very least one to deprecate over time.

There's a mismatch between the reality on the ground and, to some extent, vendor-driven perception. The market presents ditching on-premise Active Directory (AD) in favor of cloud identity systems such as Entra ID is inevitable.

Until recently, anyone arguing against this view would risk being branded as eccentric at best. Today, there's a growing acceptance that the cloud vs on-premise debate is less black and white. The real world is simply more complicated than the marketing brochures imply. You can adopt the cloud without migrating everything to it. The idea of keeping on-premises AD running as a long-term plan is no longer seen as such a wild idea.

For IT, this mismatch is a problem.

• First, it's operational, because they're asked to run a migration that may take years.

• It's also a security problem. When you treat a primary authentication system like a temporary stop-gap, you stop investing in securing it properly. The bad news is that attackers don't wait for the migration to finish.

Nearly every company today has hybrid identity, whether it uses that term or not. And what it means in practice varies, a lot. Some companies have shifted to Entra ID or other cloud IdPs, synchronizing this with their legacy AD. Others do the opposite, maintaining in-house AD as their main identity system.

Those who do shift to cloud identity platforms tend to share two main similarities:

• Minimal legacy infrastructure and a SaaS-forward application stack,

• An IT team with the capacity to run a multi-year migration.

This is particularly true for organizations in highly regulated industries. Manufacturing companies run AD-integrated systems on plant floors that can't go offline during a migration project. Healthcare organisations operate in environments where an identity transition that goes wrong can breach HIPAA and disrupt patient care. Government bodies manage AD environments carrying decades of OUs, GPOs, service accounts, and permission structures that represent not just technical complexity but legal and cybersecurity compliance record-keeping. Financial institutions face the same regulatory reality, compounded by PCI DSS, SOX, and audit cycles that make architectural disruption an active risk.

For these organisations, "just migrate to the cloud" isn't a technical recommendation, it's a risk transfer. Most IT teams managing these environments already know it.

Migrating from AD to a cloud identity platform has been compared to servicing a plane's engines mid-flight. You wouldn't want to do it unless someone makes you. Usually, it's an ambitious executive on the shifting CapEx to OpEx warpath.

Organizations that already have AD have a working authentication system. Now, IT is expected to migrate key functions to a second and completely different platform that not everyone understands, usually controlled by a third-party.

But AD isn't just an identity and authentication system. It's also a database of permissions, relationships, and associations built up over years of real operations. Getting under the hood is closer to digital archeology than computer science.

Migrating or bridging to the cloud means digging up these layers, working out which bits in AD are important enough to keep, and replicating their design and intention in a completely different system.

It's like trying to connect gears that can't physically mesh. For example, many AD structures, such as Organizational Units (OUs) and Group Policy objects (GPOs), have no direct equivalent in Entra ID.

Elsewhere, AD also has many dependencies such as AD-integrated DNS, certificate infrastructure, service accounts, legacy protocols, and a morass of permissions built up over time. All of this must be uncovered, documented, analyzed, and, where necessary, replicated on the cloud side.

This isn't an argument for staying static. We all know that many organizations can and should move to Entra ID. It's more about not letting an arbitrary migration decision drive security decisions for an environment that isn't going away anytime soon. Especially when the core of that environment is operationally low risk and low cost compared to a migration project undertaken before the environment is ready.

In practice, virtually all organizations still run AD somewhere. A good number continue to use it as their primary identity store. These mainly fall into two groups:

• Smaller organizations: Generalizing is difficult, but many small organizations don't have the resources or need for an expensive cloud migration project.

• Larger organizations: Many mid-market and enterprise-level orgs stick with AD to support vital applications. This is especially true in sectors such as manufacturing, energy, healthcare, government, and finance. There, keeping the identity layer in-house offers clear security and compliance advantages.

What they all have in common: a lot of AD infrastructure. Perfectly replicating what it does in a cloud IdP is not going to be quick or simple.

And yet, it's possible to have both without moving identity at all. Adopting cloud and SaaS doesn't need to mean that the identity system must move with it.

Cloud adoption can be done pragmatically.

Organizations don't rip out and replace their AD so much as extend what they already have into a new environment very gradually, firing up SaaS and cloud to complement existing applications. Instead of replacing every on-premise system with a cloud equivalent, the two are run side-by-side for different purposes, an approach that offers a new take on the idea of "hybrid."

Calling it "hybrid" doesn't mean it's not complex and potentially stressful. Running two completely different environments, each built using different technologies and assumptions, is a challenge that can take time to get to grips with.

On-premise and cloud can work independently of each other to some extent, but not completely so. Somewhere in the network, how users access each through the identity layer must be unified and secured without leaving gaps.

When AD is framed as a temporary connector on the road to a cloud migration, prioritising proper security for it conflicts with the vendor agenda. Investment flows toward the migration, not toward hardening the system that's still doing the work. That creates an exposure window that can last years.

The problem is partly visibility. In hybrid environments, IT teams can monitor each environment separately, but rarely how they interact. Dedicated tools capable of spanning both AD and cloud environments remain scarce.

This risks creating an unmanaged attack surface. When you connect AD to a cloud environment, with or without Entra ID, this creates a visibility problem. You can see each environment but not always how they interact with and expose one another.

An example of how this can play out is Microsoft's analysis of the Storm-0501 ransomware group's attack on an unnamed customer. In a complex chain of events, attackers were able to exploit weaknesses in the on-premises AD environment, using the Entra Connect Sync bridge server to obtain privileges to let them jump to Azure. AD was where the attackers got in but they ended up targeting Entra ID by the back door.

Microsoft doesn't make it clear how AD was being used in this instance but in a way it doesn't matter. AD can be a security risk regardless of whether it is the primary authentication system or not.