Cybersecurity
Identity Security: Defending the Perimeter You Actually Have
Identity security in practice: the tiered admin model, where MFA belongs, taming service accounts, conditional access, and surviving an IdP compromise.
Executive summary
Identity security is the discipline of treating authentication and authorization systems as the primary security perimeter, because in cloud and hybrid environments the attacker's path runs through credentials, not firewalls. This article lays out the identity architecture I deploy: a tiered administration model that contains credential theft, MFA placed where it interrupts attacks rather than where it is convenient, a lifecycle for service accounts that stops them from becoming permanent skeleton keys, conditional access as the policy engine, and a clear-eyed look at what breaks — and what recovery requires — when Active Directory or the IdP itself is compromised.
The perimeter moved and most architectures didn’t
Attackers stopped breaking in years ago. They log in.
Credential phishing, token theft, password spraying, MFA fatigue, and abuse of over-privileged service accounts dominate the intrusion reports I read and the incidents I’ve been near. Yet most security budgets still buy network boxes, while the directory that every one of those boxes trusts runs on fifteen-year-old design decisions and forty Domain Admins. That is not a tooling gap. It is an architecture that no longer matches the attack.
Identity-first security is the correction: treat the identity systems — AD, the cloud IdP, the PKI — as the crown jewels they already are to your adversary, and design authentication, authorization, and administration so that a stolen credential has the smallest possible blast radius. NIST SP 800-207’s zero trust model says the same thing in formal language: the policy decision point is the perimeter now. Network segmentation remains the containment layer underneath, but the access decisions happen in identity.
The tiered administration model
The single highest-leverage identity control is the tiered model, formalized by Microsoft as the enterprise access model. The concept fits in one sentence: credentials are exposed wherever they are used, so credentials that control everything must be used nowhere except the systems that control everything.
| Tier | Scope | Examples |
|---|---|---|
| Tier 0 | Control of identity itself | Domain controllers, IdP tenant admin, PKI, backup platform, hypervisor management, privileged access workstations |
| Tier 1 | Control of servers and applications | Member servers, database admin, cloud subscription admins |
| Tier 2 | Control of user devices | Workstation support, helpdesk |
The rules that give the model teeth:
- No tier-crossing logons. A Tier 0 account never authenticates to a Tier 1 or Tier 2 system — not for convenience, not “just once.” Enforce with authentication policies, logon restrictions, and Protected Users membership, because policy documents don’t stop Mimikatz.
- Separate accounts per tier, per human. An admin holds distinct credentials for each tier they work in. Password reuse across them defeats the design.
- Privileged access workstations for Tier 0. Administering the directory from the same laptop that opens email is how one phish becomes a forest compromise. A dedicated, hardened, no-mail no-web workstation is cheap insurance against the most expensive event you can have.
- Tier 0 is bigger than you think. Anything that can push code or commands to domain controllers is Tier 0: the patch management system, the EDR console, the virtualization layer hosting DCs, the backup platform that can restore (or exfiltrate) a DC image. Most environments have a dozen unacknowledged Tier 0 systems; a security architecture review should enumerate them explicitly.
MFA placement: interrupt the attack, not the user
MFA works, but only where it actually sits in the attack path. Placement order that reflects how intrusions unfold:
- The IdP, for everyone, with legacy authentication disabled. POP, IMAP, SMTP basic auth, and other legacy protocols bypass MFA entirely; leaving them enabled while rolling out MFA is installing a lock and leaving the window open.
- Every remote entry point. VPN, VDI gateways, published apps, bastions.
- Phishing-resistant methods for privileged accounts. Push notifications lose to MFA-fatigue attacks and real-time phishing proxies. For Tier 0 and Tier 1 administration, require FIDO2 security keys or platform passkeys — the direction NIST SP 800-63B points for high-assurance authentication.
- The forgotten consoles. Backup software, out-of-band management (iLO/iDRAC), hypervisor clients, network management systems. These are exactly the consoles a ransomware operator wants, and they are the last to get MFA in most shops.
Service accounts: the permanent skeleton keys
Every mature environment carries a sediment layer of service accounts: passwords set in 2014, membership in Domain Admins “because it didn’t work otherwise,” used by four applications nobody fully remembers. Attackers love them — high privilege, no MFA, no human to notice anomalies. Kerberoasting exists almost entirely because of this sediment.
Nobody designed this. It accumulated, one reasonable exception at a time, which is how most security debt gets issued.
The lifecycle that prevents it:
- Inventory first. You cannot secure accounts you cannot list. Pull every account with a service principal name, every account with password-never-expires, and every non-human account in privileged groups.
- Prefer managed identities. Group managed service accounts (gMSA) on-prem, workload identities and managed identities in cloud platforms — anything where the platform rotates the secret and no human ever knows it.
- Long random passwords where gMSA won’t fit. 25+ characters makes Kerberoasting economically pointless; vault the credential and rotate on a schedule.
- Least privilege, verified. “It needs Domain Admin” is almost always “nobody traced what it actually needs.” Trace it once; the answer is usually three ACLs.
- Deny interactive logon for every service account. A service account in an RDP session is an incident, and your monitoring should say so.
Conditional access as the policy engine
Static group membership answers “who are you.” Conditional access adds the questions that catch real attacks: from what device, from where, at what risk level, to which application. Done well, this is the rare control that reduces uncertainty and friction at the same time — risky sign-ins face more challenges, normal ones face fewer, and the policy engine, not a human, carries the judgment. The policies I consider baseline:
- Block legacy authentication, tenant-wide, no exceptions.
- Require phishing-resistant MFA for all administrative roles.
- Require compliant or managed devices for access to admin planes and sensitive data.
- Restrict Tier 0 administration to privileged access workstations by device filter — this is where the tiered model becomes enforceable in the cloud.
- Alert-and-review on impossible travel and token anomalies; token theft is the current frontier, and session binding features are worth adopting as they mature.
Build policies in report-only mode first, exactly like a firewall ruleset in log-only mode. Locking the entire admin team out of the tenant is a rite of passage nobody needs twice.
What actually breaks when identity falls
Design for this scenario explicitly, because every other control inherits it. When AD or the IdP is compromised:
- Group policy becomes the attacker’s deployment tool. Ransomware operators routinely push encryptors by GPO — the same channel you use for configuration is a distribution network for whoever holds Tier 0.
- Kerberos trust becomes forgeable. With the krbtgt hash, golden tickets impersonate anyone, and recovery demands rotating krbtgt twice with replication in between, plus hunting forged tickets in the interim.
- Federated trust propagates the breach. SaaS applications trusting the IdP trust the attacker; every signing certificate and federation trust must be re-established.
- Your own tools go hostile. EDR, patching, and remote management consoles authenticated against the directory now belong to the adversary — a dependency worth mapping before, not during, the incident.
Two preparations change the outcome. First, keep at least one break-glass account per critical system that does not depend on the directory or IdP, with credentials sealed offline and use alarmed. Second, protect and test Tier 0 recovery: isolated DC backups predating compromise, restore drills into a clean network, and the sequencing documented — this is the identity chapter of ransomware-resilient architecture, and the first task on the board during incident response.
What to write down
- The complete Tier 0 inventory, reviewed quarterly — it grows silently.
- Which accounts may cross which boundaries, and the enforcement mechanism.
- Break-glass procedures, storage location, and the test date.
- The service account inventory with owners and rotation dates.
- The IdP-compromise runbook, written on a calm day.
Firewalls decide what can talk. Identity decides what can act.
The network perimeter was never really the point — it was an implementation detail from an era when the systems and the people stayed inside one building. The perimeter that matters is the set of decisions about who may do what, and that perimeter now deserves the design attention, the review cadence, and the budget the firewall estate has enjoyed for twenty years. Fund and review it accordingly.
Frequently asked questions
- What does identity-first security mean?
- It means designing on the assumption that the attacker will authenticate rather than break in. Controls concentrate on credentials, sessions, and authorization: strong phishing-resistant MFA, tiered privileged access, short-lived credentials for services, and continuous evaluation of sign-in context. The network still matters for containment, but identity is where access decisions are actually made.
- What is the tiered administration model?
- A structure that separates administrative control into tiers — identity systems at Tier 0, servers and applications at Tier 1, user devices at Tier 2 — with the rule that credentials never cross tiers. A Tier 0 credential is never used on a lower-tier system, so a compromised workstation or server cannot yield the keys to the directory. Microsoft formalizes this as the enterprise access model.
- Where should MFA be enforced first?
- At the identity provider for all users, on every remote-access path, and — with phishing-resistant methods like FIDO2 — on all privileged and Tier 0 accounts, including backup consoles and hypervisor management. Legacy authentication protocols that bypass MFA must be disabled at the same time, or the control is decorative.
- What happens if Active Directory itself is compromised?
- Every control that trusts AD inherits the compromise: group policy becomes a malware distribution system, Kerberos tickets can be forged, and MFA layered on top of AD-derived trust can be bypassed. Recovery requires an isolated restore from media predating the compromise, double rotation of the krbtgt account, credential resets across the estate, and re-establishing trust in every federated system — typically weeks of work.