Microsoft releases an Active Directory Tier Model on GitHub. To many, this sounds like just another tool. For us, it’s official proof of something we’ve been saying for years: if you don’t strictly isolate your privileged identities, you’re playing with complete system outage.

A few years ago, it sounded as if the classic ESAE or tiering model was on its way out. Cloud, Zero Trust, modern identity platforms, new security architectures. Everything was supposed to become more modern, flexible, and less “legacy.”

And yes, the cloud has changed a lot. Entra ID, Conditional Access, modern authentication, Privileged Identity Management, and Zero Trust are essential building blocks of a modern security architecture. But the core question remains the same:

Who is actually allowed to access what, and what happens if that exact identity is compromised?

That is precisely why the new Active Directory Tier Model from Microsoft (published on GitHub) is so exciting. Microsoft provides a declarative PowerShell framework designed to deploy and audit an Active Directory tiering model for Tier 0, Tier 1, and Tier 2. The repository describes OUs, groups, users, ACL delegations, GPOs, ADMX, Managed Service Accounts, Windows LAPS permissions, idempotent re-runs, drift detection, and reproducible builds via a versioned JSON configuration.

Or in less technical terms: Microsoft is bringing tiering prominently back onto the stage.

And that is no minor side note. It’s a very clear statement.

Tiering Was Never Really Gone

When looking at the discussions around ESAE, Red Forest, and tiering, a lot has been mixed up over recent years. In our earlier article ESAE is dead – Long live SAE, or do the dead live longer?, we put this confusion into perspective: Microsoft re-evaluated ESAE within the context of the Red Forest model, but the underlying security principles remained fully relevant. From TEAL’s perspective, securing Tier-0 systems, privileged identities, and administrative access paths remains absolutely paramount.

The new Microsoft project re-emphasizes this point very clearly. Tiering is not a nostalgic on-premise idea from old Active Directory days—tiering is a fundamental security principle.

It’s about separating critical systems, identities, and administrative privileges in a way that prevents a compromised client from automatically becoming the first step toward Domain Admin.

Typical examples:

• • A Tier-0 admin does not log in to a standard client machine.
  • Highly privileged credentials are not left behind on unsecure systems.
  • Critical identity systems receive maximum protection.
  • Permissions are deliberately modeled rather than grown historically.
  • Attack paths between tiers are exposed and minimized.

We described this exact core concept in our article Data Security Through Tiering – Protection at Every Level: Microsoft Tiering divides IT systems into different levels to separate highly critical systems from less critical resources and make it harder for attackers to move through the environment.

The Problem: Excessive Rights, Lack of Structure

In theory, tiering sounds logical… in practice, reality often looks very different. Many organizations have Active Directory structures that grew organically over years, legacy groups, old service accounts, local administrator privileges, special permissions, and “temporary” exceptions that were never revoked. The result is rarely a clean tiering model, but rather a tangled carpet of permissions. And that is precisely what attackers love.

An attack doesn’t need to start directly on the Domain Controller. Often, a single compromised client, an overly powerful local admin, a poorly secured server, or an account with access where it shouldn’t have it is enough. A small problem quickly becomes an attack path.

And in the worst case, an attack path leads to a full compromise of the entire environment.

The danger rarely lies in a single misconfiguration alone. It becomes dangerous when multiple seemingly minor weaknesses combine into a chain. This exact perspective plays a central role in Attack Path Management, as we previously highlighted in the context of BloodHound OpenGraph: The crucial question is not just whether an individual system is secure, but which chain of identities, permissions, and trust relationships leads to critical systems.

What Microsoft Is Actually Delivering

With the new Active Directory Tier Model, Microsoft isn’t delivering a magical “one-click and everything is secure” product.

However, Microsoft is providing a framework that makes many technical tasks surrounding the design, deployment, and auditing of a tiering model far more structured and repeatable.

According to the repository, it is a PowerShell framework that can deploy and audit an Active Directory Tier Model from a versioned JSON configuration. It supports repeatable deployments, drift auditing, structured findings, and modular tests.

This is particularly interesting for organizations looking to systematically build a tiering model according to Microsoft guidelines or benchmark existing structures against it.

What’s especially exciting is not just the deployment, but the auditing function.

Microsoft documents drift detection for the framework via Audit-TierModel.ps1. This script analyzes the current Active Directory state against the declarative tier model configuration, identifying missing objects, configuration drifts, and structured drift findings for further remediation.

Drift Detection Is Great – But It Doesn’t Replace Attack Path Management

Drift detection has a major limitation… it checks against the model you defined.

If you strictly follow Microsoft guidelines, it will help make deviations visible. However, if your environment is heavily customized, featuring custom processes, special roles, tailored delegations, or historically grown structures, a simple comparison against a standard model won’t cut it.

When custom configurations enter the picture, you quickly arrive at Attack Path Management—because it reveals actual attack vectors, regardless of where they originate.

Drift detection can show you whether specific OUs, groups, ACLs, or GPOs deviate from the intended state. For this purpose, Microsoft documentation highlights audit results with summaries, warnings, errors, and drift findings, alongside outputs as JSON, HTML, or NUnit XML.

Attack Path Management goes a step further by evaluating which actual combinations of permissions, identities, and trust relationships present a real danger. This view is essential when environments are not cleanly standardized or when AD, Entra ID, cloud, SaaS, and other platforms need to be considered holistically.

Microsoft Is Visibly Taking Tiering Seriously Again

Microsoft is once again visibly documenting, automating, and auditing tiering. The repository outlines the goal of deploying and auditing an Active Directory Tier Model structure across Tier 0, Tier 1, and Tier 2. Furthermore, it references documentation on deployment, drift detection, logging, GPO management, ADMX management, conditional principals, CI/CD integration, test coverage, and Sentinel monitoring.

This makes one thing crystal clear: Tiering is not a relic of the past. Tiering remains state of the art.

Tools have evolved, and the cloud has undeniably gained importance. Entra ID, Privileged Access, Conditional Access, Zero Trust, and modern identity security must all be factored in.

Yet the underlying principles remain the same:

• • Privileged identities require maximum protection.
  • Administrative access must be strictly isolated.
  • Tier-0 systems must not be compromiseable via lower tiers.
  • Login and admin paths must be designed intentionally.
  • Implementation must be audited on a regular basis.

What This Means for Organizations

For organizations, this new Microsoft framework serves above all as a great opportunity to review their own tiering strategy. Not eventually. NOW!

Tiering is not a project you complete once and check off your list. Tiering is an operating model.

The TEAL approach outlined in our Tiering Article remains as valid as ever: analyze attack paths, classify systems and users, implement protective controls, migrate permissions cleanly, and continuously validate the environment. The article breaks this approach down into four phases: preparation with attack path analysis and classification, implementation of protective controls, migration and re-assignment of permissions, and ongoing validation and control.

If you want to use the new Microsoft Tiering Framework as an occasion to evaluate your environment, don’t start with scripts right away.

Start with the right questions:

• • Which systems in your environment are truly Tier 0?
  • Which accounts have direct or indirect impact on these systems?
  • Where do privileged users actually log in?
  • Which legacy admin accounts still exist?
  • Which service accounts possess overly broad permissions?
  • Which groups have been nested over years and never cleaned up?
  • Are technical logon restrictions between tiers strictly enforced?
  • Is there regular auditing to check whether new attack paths have emerged?
  • Do you have a target baseline state to measure deviations against?
  • Are you leveraging Attack Path Management to expose real attack vectors?

Only when these questions are answered does a framework provide real value. Because tools can only automate what has been understood beforehand.

Our Opinion & Conclusion

From TEAL’s perspective, the release of the Active Directory Tier Model is a strong positive signal.

Not because everything is suddenly brand new, but because Microsoft is bringing a foundational security principle back into focus—one that too many organizations dismissed for too long as an “old AD topic.”

“Rumors of its death were greatly exaggerated—I told you so!” – Fabian Böhm (CEO & Security Architect at TEAL Consulting) following Microsoft’s release.

With these new scripts and documentation, Microsoft has certainly lowered the barrier to adopting tiering, which we explicitly welcome. At the same time, the fundamental roadmap remains unchanged: classify, segregate, implement technical protections, migrate permissions cleanly, and validate regularly.

Tiering is not dead. Tiering is mandatory.