Microsoft has officially deprecated the formal ESAE guidance, replaced by the broader "Privileged Access" security model. The framework name changed; the architecture pattern that most regulated enterprises run did not. Tier-0/1/2 separation, dedicated administrative forest, Privileged Access Workstations, just-in-time elevation — calling the result PAS or ESAE does not change what running it costs.

What follows is what owning that architecture actually looks like on day 400 — the operational reality after the project sponsor moved on, the documentation drifted, and the team now has to live with the model.

Staffing reality

ESAE — and its Privileged Access successor — is not a project. It needs at least two dedicated AD engineers who do nothing else but the admin forest. In smaller orgs that often becomes one person, which is the fragile pattern. The on-call rotation has to extend to tier-0 changes; tier-0 changes cannot happen quickly because the design intentionally puts process between intent and effect.

The honest staffing math is: 2 FTE for admin forest operations, plus 0.5 FTE for governance and access reviews, plus on-call coverage from a senior engineer who can authoritatively make tier-0 changes at 2am. That is 2.5 FTE minimum. Most regulated enterprises understaff this by half on the assumption that "we don't change tier-0 often." They do. Identity changes are the most frequent infrastructure changes; they are just usually invisible because they do not touch user-visible systems.

Tier-0 discipline

The hardest cultural shift. Tier-0 means: identity systems, identity infrastructure, anything that can grant identity. PKI. ADFS. Entra Connect. SCEP. The DC inventory is the obvious part; the rest of tier-0 is what gets cut from the model in year two when the team is tired.

People resist the expansion because it puts a queue between them and quick fixes. The discipline is enforced by ACLs and workstation segmentation, not by goodwill. If a tier-1 engineer can RDP to ADFS from their daily-driver laptop, ADFS is no longer tier-0 — regardless of what the diagram says.

JIT / JEA workflow

The promise: just-in-time elevation. The reality: most orgs end up with a mix of MIM PAM, third-party tooling (CyberArk, Delinea), and PowerShell JEA. Each has friction patterns that get exploited.

PAM workflows require ticket numbers — engineers create empty tickets when the queue is too slow. The ticket then exists but documents nothing.

CyberArk is great until the PSM proxy is down. The failure mode is "everyone has admin again" — the break-glass account becomes the daily-use account, and the audit of break-glass usage becomes meaningless.

JEA endpoints work but are brittle. Module loading often gets blocked, scripts get rejected silently because of constrained-language-mode parsing rules. The engineer falls back to "just RDP to the DC and run it directly" — defeating the workflow.

The cost of these workflows is invisible until it isn't. The first audit that asks "show me the privileged actions taken in the last 90 days" exposes whether the workflow was actually used or routinely bypassed.

Common drift patterns

Where ESAE quietly degrades over time:

  • Tier-0 admins grant themselves "temporary" tier-1 to debug — and never remove it. Quarterly access reviews catch this if the reviews are run; usually they aren't.
  • Service accounts get promoted to Domain Admins for an emergency change and stay there. The change ticket gets approved, the demotion gets forgotten.
  • PAWs get used for non-admin tasks (reading email) because the dual-workstation workflow is too slow. The PAW becomes a regular workstation that happens to have a stricter security baseline.
  • Audit logging on the admin forest fills up disk; someone disables it instead of expanding storage. The audit-disabled period is usually months, not days.
  • Backup operators get added to a tier-0 group because someone confused backup privilege with restore privilege. Backup of NTDS.dit is restore of identity, but the access-control implications are rarely understood at the helpdesk level.

Where teams cut corners

And the audit consequences:

  • Sharing PAW devices between admins. Single-user enforcement is rarely enforced; most PAWs end up as shared kiosks for the admin team. Auditors flag this as "no individual accountability for privileged actions."
  • Not enforcing SmartCard for tier-0. "MFA is good enough." It isn't, against credential-replay attacks; the audit finding is specific to NIST 800-53 IA-2(11) and is rarely waivable.
  • Letting tier-0 admins log into tier-1 systems "just to grab a log" — which voids the tier separation. The fix is to instrument tier-1 logs so they push to a tier-0-readable location, not to relax the access rule.
  • Skipping the credential-theft detection tooling because it's expensive — and then not noticing when something goes wrong. Microsoft Defender for Identity, Defender for Endpoint, and equivalents from third parties are not optional in a real ESAE deployment.

What it actually costs (Day 400)

At the operational level:

  • 2 FTE minimum for admin forest operations, plus 0.5 FTE for governance.
  • 4 to 8 hours per week per admin in workflow overhead — JIT requests, PAW usage, ticket-bound changes. That is a 10-20% productivity tax on the senior engineering team.
  • 1 to 2 days per quarter for tier-0 access reviews. Done well, with stakeholder sign-off. Done poorly, the access review becomes a rubber stamp and the value of the architecture decays.
  • 1 process-engineering FTE part-time keeping documentation current. The hardest part to fund and the first thing cut.

Why it's worth it anyway

Microsoft deprecated the formal ESAE guidance because the model became too rigid for the cloud-and-hybrid reality most enterprises now run. But the underlying problem — keeping privileged identity separate from production identity — did not go away. The pattern most enterprises end up with is ESAE-shaped, even if no one calls it that.

Knowing what running it costs is more valuable than knowing what to call it. The cost is real, the discipline is real, and the architecture works only as well as the team operating it.