Enterprise Access Model (EAM) – part of Red tenant story

Table of Contents

The third part. I now assume that you have read the previous post which was about ESAE – Enhanced Security Administative Environment.

In the on-premises Active Directory world, Microsoft used to recommend the Enhanced Security Administrative Environment , a dedicated, hardened AD forest used only for administering your production forest. It was widely nicknamed the “Red Forest.” Microsoft has since retired ESAE as a general recommendation, replacing it with a modern, identity-centric strategy. The “red” in “red tenant” is a descendant of this terminology.

 

The Enterprise Access Model and privileged-access strategy

This is Microsoft’s current guidance and the real substance. Its core principles are:

  • Treating identity as the security perimeter rather than the network.
  • Tiering/segmenting access by sensitivity (the classic Tier 0 / Tier 1 / Tier 2, now expressed as control plane / management plane / data-and-workload planes, with security levels of Privileged, Specialized, and Enterprise).
  • Using dedicated hardened devices: Privileged Access Workstations (PAWs) for admin work, so privileged accounts never touch a normal, internet-browsing endpoint.
  • Just-in-time elevation via Privileged Identity Management (PIM), strong Conditional Access, and Zero Trust throughout.

The EAM tiering model

The Enterprise Access Model (EAM) is Microsoft’s modern successor to the older Active Directory “tier model” (Tier 0 / Tier 1 / Tier 2). The original tiering idea was about containing credential theft: assets were sorted by the control they exert, with
 
Tier 0 holding the identity infrastructure that everything else depends on (domain controllers, AD, ADFS, PKI),
Tier 1 holding servers and business-critical applications, and
Tier 2 holding user workstations and the helpdesk that supports them.
 
The governing rule was that a higher-tier credential must never be exposed on a lower-tier system. You never sign a Tier 0 admin account into a Tier 2 laptop, because a compromise of that laptop would then hand the attacker the keys to the identity fabric.
 
EAM keeps that containment principle but reframes it for a hybrid and cloud world where AD is no longer the center of gravity. Instead of tiers tied to on-prem domains, it organizes around access planes:
 
a control plane (the modern equivalent of Tier 0 — identity systems and privileged access),
a management plane, and
the data/workload plane where the actual apps and data live,
plus separate user-access and app-access paths.
 
The point of the reframing is to bring Entra ID, SaaS, and just-in-time privileged access in as first-class concerns rather than bolting them onto an AD-centric picture.
Copyright of image Jussi Metso - Click to enlarge

What a "red tenant" actually is in Entra ID and M365/Azure terms

The cloud-era version of the Red Forest idea is a separate, dedicated Entra ID tenant used exclusively for privileged identities and their administrative endpoints, isolated from the production/user tenant. In practice that means:
  • Entra ID: admin accounts live in this isolated tenant rather than alongside regular users. They reach the production tenant(s) through controlled cross-tenant access (B2B), and the isolation limits lateral movement and privilege escalation if a normal user endpoint is compromised. Access is governed by Conditional Access, PIM, and often Global Secure Access (Entra Private Access / Internet Access) to restrict where those identities can connect.
  • M365/Azure: the admin infrastructure including PAWs (or virtual equivalents), policy baselines, and access rules are provisioned cloud-natively in M365/Azure, frequently deployed and maintained “as code” so the whole hardened configuration is version-controlled and repeatable.

Two tenant model:

Isolated red admin tenant and cross-tenant access to Blue tenant

An isolated admin tenant is a separate Entra ID tenant that houses only privileged administrative identities, kept apart from the production tenant where users and workloads live.
 
The motivation is blast-radius reduction: the admin identities get their own Conditional Access, their own security baselines, and their own lifecycle, so a compromise of the production tenant doesn’t automatically expose the accounts that administer it (and vice versa).
 
It’s the tenant-level expression of the same “don’t put your most powerful credentials where the most exposure is” idea. The obvious question that creates is if the admins live in tenant A, how do they administer resources in tenant B? That’s what cross-tenant access mechanisms handle.
 
Entra ID’s cross-tenant access settings let the production tenant trust MFA and device-compliance claims coming from the admin tenant, so an admin arriving as an external/B2B identity doesn’t have to re-satisfy MFA and importantly you can require that the access originates from a compliant, hardened device.

 

Copyright of image Jussi Metso - Click to enlarge

The Bridge controls: PIM and Conditional Access

Privileged Identity Management (PIM) attacks the problem of standing privilege. Rather than an account permanently holding an admin role, the role is made eligible and must be activated just-in-time for a limited window, typically requiring justification, MFA, and sometimes approval, with everything logged. That shrinks the amount of always-on privilege an attacker could steal. 
 
Conditional Access is the policy engine that ties it together by gating access on signals:
*device compliance,
*user or sign-in risk,
*location,
*role,
so you can enforce, for example, that a privileged role can only be activated from a compliant PAW using phishing-resistant MFA.
 
Putting together, the pattern is:
*just-in-time privilege (PIM),
*exercised from a hardened origin device (PAW) and
*gated by policy (Conditional Access).
 

Summary

Here was Enterprise Access Model explained shortly. The next post is about PAW, PIM and Condition access. 

What does they mean, why the setup is secure and why it could be also insecure if some of the component(s) is/are missing.

Links:

Enterprise Access Model (MS Learn)

Design and Enterprise access architecture (MS Learn)

Design a privileged access architecture (MS Learn)

 

Picture of Jussi Metso
Jussi Metso

Author is a lifelong IT enthusiast, Microsoft Security MVP and interested in Cloud Security, XDR, SIEM and AI. Motto: Learning is the key for your future.

Discover more from Jussi Metso

Subscribe to get the latest posts sent to your email.

IDENTITY_ACCESS RED

Related Posts

RED

Red Tenant intro

a “Red Tenant” usually means an isolated admin control plane. The common components are: a dedicated Entra tenant for admin identities, separate admin accounts from normal user accounts, hardened admin devices/PAWs, strict Conditional Access, just-in-time role…

Read More