Identity Segmentation vs Network Segmentation: Containing Lateral Movement by Who and Where

Network segmentation decides which machines can talk to each other, but most lateral movement in modern intrusions travels over connections the network is supposed to allow, using credentials the attacker has stolen. Identity segmentation decides which accounts, human or non-human, can authenticate where and to what. One contains movement by location, the other by identity, and each misses what the other catches. This guide compares the two as enforcement models: where each enforces, the credential-based movement that network controls miss, tiering for Active Directory and for non-human identities, and how to run both as one design. It is for security architects, identity and infrastructure leads and red team assessors reviewing containment. For the programme-level funding question, see Identity-Centric vs Network-Centric Zero Trust; this page goes into the enforcement mechanics.

Key takeaways

• Network segmentation stops reachability; identity segmentation stops reuse. A firewall rule blocks a host that should never connect. It cannot tell a legitimate administrator's RDP session from an attacker using that administrator's stolen hash over the same allowed path.
• Credential-based movement is the gap. Pass the hash (T1550.002), pass the ticket (T1550.003) and Kerberoasting (T1558.003) all ride over ports that segmentation has to leave open for the business to work.
• Tiering is identity segmentation for administrators. The rule is simple: a credential from a higher tier is never exposed on a lower-tier host. Microsoft's enterprise access model extends the old Tier 0, 1 and 2 split to control, management, workload, user and app access planes.
• Non-human identities need tiers too. Service accounts, sync accounts, backup agents and CI runners often hold Tier 0 rights while running on Tier 1 or Tier 2 hosts. They are the most common hole in an otherwise tiered estate.
• Combine them so each covers the other's blind spot. Use network segmentation for things that cannot authenticate and for exploit paths; use identity segmentation for everything that logs on; and write segment rules that consume identity wherever the enforcement point allows it.

The short answer

Use network segmentation to limit what can be reached, and identity segmentation to limit what a stolen credential can do once it reaches something. Neither replaces the other. If your estate runs Active Directory and your main risk is ransomware, identity segmentation of administrative and service accounts usually returns more per unit of effort than additional network zones, because ransomware operators typically move with harvested domain credentials. If your estate includes OT, medical devices or legacy systems that cannot authenticate to a directory, network segmentation is the only containment available for those devices.

NIST SP 800-207 describes zero trust as moving defences "from static, network-based perimeters to focus on users, assets, and resources". Identity segmentation is the containment half of that move. Network segmentation remains the floor beneath it.

How each model enforces

The Network Segmentation Guide covers zones, east-west policy and enforcement options in depth. This page treats network segmentation as one side of the comparison.

Lateral movement that network controls miss

Read each row as: the network path is allowed because the business needs it, so the only place to stop the movement is identity.

The Storm-0501 Hybrid Cloud Attacks 2024 page shows the pattern end to end. Microsoft Threat Intelligence reported that the group reached Domain Admin on premises, located the directory synchronisation servers and extracted the sync accounts' credentials, then moved into the cloud tenant. Every hop used a legitimate path. The lesson recorded on that page is identity segmentation: protect sync servers and sync accounts as Tier 0 and keep cloud admin accounts cloud-only.

Identity segmentation mechanisms in Active Directory

These are the Windows controls that turn a tier model from a document into enforcement. All are customer-side settings.

• Authentication policy silos and authentication policies: silos group high-privilege user, computer and service accounts, and policies limit which devices those accounts can authenticate from. Microsoft's own example is a Forest Administrators silo where password and smart card sign-in from anything other than domain controllers and admin consoles fails. Policies are enforced during the Kerberos AS or TGS exchange, run in audit mode by default until enforced, and require Kerberos armoring on clients. Audit events 305 and 306, and enforced denials 105 and 106, are written to Applications and Services Logs, Microsoft, Windows, Authentication.
• Protected Users group: members cannot authenticate with NTLM, cannot use DES or RC4 in Kerberos pre-authentication, cannot be delegated, and have a 4-hour non-renewable TGT. On devices, plaintext credentials and NT hashes are not cached. Microsoft warns never to add service or computer accounts, and to test before adding all Domain Admins and Enterprise Admins, because accounts without AES keys can be locked out.
• User rights assignment: "Deny access to this computer from the network" (SeDenyNetworkLogonRight), "Deny log on through Remote Desktop Services", "Deny log on locally", "Deny log on as a batch job" and "Deny log on as a service" applied by GPO per tier, so Tier 0 accounts cannot log on to Tier 1 and Tier 2 hosts at all. Microsoft recommends assigning the network deny right to the built-in local Administrator, Guest and service accounts that do not need network logon. The deny right supersedes the corresponding allow right.
• Unique local administrator passwords: Windows LAPS rotates each device's local administrator password and stores it in Active Directory or Microsoft Entra ID; Microsoft lists protection against pass-the-hash and lateral traversal among its benefits.
• Managed service accounts: gMSAs have passwords computed by domain controllers and retrievable only by authorised hosts. Microsoft notes a gMSA password, once retrieved, can be used from any host for initial authentication; an authentication policy access condition closes that gap.
• Privileged access workstations: dedicated devices that are the only permitted source for Tier 0 sign-in, enforced through authentication policy device restrictions and network rules together.

See the Tiered Administration and Enterprise Access Model Guide for the tier design and the Active Directory Tiering vs Red Forest guide for the forest-level options.

Tiering non-human identities

Microsoft's enterprise access model requires policy on "all access methods including users, admins, APIs, service accounts" and hierarchy enforcement "to prevent control of higher planes from lower planes". Service accounts are where that hierarchy most often breaks, because their tier is set by what they can do, not where they run.

The common mistake is a single "svc-backup" or "svc-scan" account used across all tiers. Splitting it into one credential per tier is unglamorous and highly effective. See the Group Managed Service Accounts (gMSA) Guide, How to find service accounts with Domain Admin rights and How to detect interactive logons by service accounts.

Identity segmentation in cloud and workloads

In cloud estates the IAM policy engine is the main enforcement point, and the network is often secondary. The same idea applies without vendor-specific features:

• Account, subscription or project boundaries: separate production, non-production, security tooling and identity infrastructure into separate top-level containers, with organisation-wide guardrail policies that no account administrator can override.
• Conditions on credential use: where the platform supports it, restrict a workload's credentials to its expected network source or runtime, so a stolen token fails elsewhere.
• Workload identity instead of keys: short-lived federated credentials bound to a specific workload, repository or namespace replace static keys that work from anywhere. See the Cloud Workload Identity Guide.
• Kubernetes: one service account per workload, token automounting disabled where not needed, RBAC scoped to namespace, and network policies as the network floor. See How to find pods that automount service account tokens.
• Service mesh: mutual TLS with workload identities in certificates and authorisation rules written as "service A may call service B", which is identity segmentation enforced in the network path.

Each model in depth

Network segmentation

• Threat model: an attacker on one host scanning for and exploiting others, worms, and access to devices that cannot authenticate.
• Architecture in words: zones (user, server, management, OT, identity infrastructure) separated by firewalls or cloud security groups; host firewalls or agents for east-west rules inside zones; default deny with explicit flows.
• Failure modes: any-to-any rules added during incidents and never removed; management protocols open from user networks; identity infrastructure placed in a general server zone; segments documented but never tested.
• Controls that make it work: flow mapping before rules, change review, periodic segmentation testing (see the Network Segmentation Testing Guide) and a dedicated zone for domain controllers, sync servers and PAM.

Identity segmentation

• Threat model: an attacker with a foothold harvesting credentials and reusing them over permitted paths to climb tiers.
• Architecture in words: accounts classified by tier; each tier's accounts permitted to log on only to that tier's hosts; privileged sign-in only from privileged access workstations; service accounts managed, host-bound and single-tier; cloud and on-premises admin identities separate.
• Failure modes: exceptions for "just one" service account; help desk accounts with rights over Tier 0 groups; policies left in audit mode indefinitely; tier rules that ignore cloud roles with directory write access.
• Controls that make it work: attack path analysis to find tier violations (see the Identity Attack Paths Guide), GPO-enforced logon restrictions, authentication policies enforced after an audit period, and regular review of Tier 0 membership.

Worked scenario: containing a ransomware foothold

An attacker phishes a finance user and gains code execution on the user's workstation.

With network segmentation only. The workstation cannot reach servers on SMB or RDP, so direct movement stalls. But the help desk engineer who signed in to fix the workstation last week used an account with local admin on all servers, and the server management zone accepts RDP from the help desk subnet. The attacker dumps cached material, moves to a help desk machine using the user's own allowed paths, and uses the engineer's credential to reach servers over a permitted connection.

With identity segmentation only. The help desk engineer's workstation account cannot sign in to servers; server admins sign in only from privileged access workstations. The attacker finds no reusable privileged credential. However, the flat network lets the attacker scan and exploit an unpatched internal service that needs no authentication.

With both. The workstation cannot reach servers (network), the only credentials exposed on it are Tier 2 (identity), local admin passwords are unique (LAPS), and the exploit path is closed by default-deny east-west rules. The incident stays on one workstation.

When to prioritise each

• Active Directory estate, ransomware as top risk: lead with identity segmentation of Tier 0, then admin protocol blocks between user networks.
• OT, medical or IoT devices: network segmentation for the devices; identity segmentation for the engineers and vendors who reach them.
• Cloud-native estate: identity segmentation through IAM, workload identity and account boundaries leads; network policies are the floor.
• Small organisation: separate admin accounts from daily accounts, deploy LAPS, block inbound SMB and RDP on workstations with the host firewall. That covers most of both models at little cost.
• Large organisation: run both with one tier model that the network zones mirror, and one owner for tier exceptions.

Combining both: a phased approach

1. Classify. Identify Tier 0 assets (domain controllers, sync and federation servers, PKI, PAM, identity provider admin roles) and every account, human or non-human, with control over them.
2. Network floor. Place Tier 0 assets in their own zone; block SMB, RDP and WinRM between workstations and from workstations to servers except from management sources.
3. Logon restrictions by GPO. Apply deny logon rights so Tier 0 accounts cannot log on to Tier 1 and Tier 2 hosts. Pilot on one OU and watch for broken scheduled tasks and services; roll back by removing the GPO link.
4. LAPS everywhere. Unique local admin passwords on all workstations and member servers.
5. Service accounts. Split cross-tier service accounts, move to gMSAs, remove interactive logon, and bind to hosts.
6. Authentication policies in audit. Create silos for Tier 0 accounts, run in audit mode, review events 305 and 306 for a full business cycle, then enforce.
7. Protected Users for human admins. Add Tier 0 humans in small groups after confirming AES keys exist; keep break-glass accounts out and monitored.
8. Converge. Make microsegmentation and ZTNA policies consume identity groups, and re-test with attack path analysis after every change.

Detection and measurement

Log Kerberos and NTLM authentication on domain controllers (events 4768, 4769 and 4776), successful and failed logons with logon type on servers (4624 and 4625), authentication policy events (101, 105, 106, 305, 306) and firewall deny events, and join them by account and host. Alert on Tier 0 account logons to non-Tier 0 hosts, NTLM use by privileged accounts and RC4 service ticket requests for accounts with SPNs. Metrics:

• Number of tier violations found by attack path analysis, trending to zero.
• Percentage of Tier 0 accounts covered by enforced authentication policies.
• Percentage of service accounts that are gMSAs or workload identities, and number of cross-tier service accounts.
• Percentage of devices with unique, rotated local administrator passwords.
• Percentage of east-west traffic covered by default-deny rules.
• Number of Tier 0 logons from sources other than privileged access workstations per month.

Common failure patterns

• Segments without tiers. A perfectly zoned network where domain admins sign in to workstations; every allowed admin path is a credential theft opportunity.
• Service account exceptions. One backup or scanning account with rights on every tier undoes the tier model.
• Sync infrastructure outside Tier 0. Directory sync and federation servers managed as ordinary servers become the bridge into the cloud, as in Storm-0501.
• Audit mode forever. Authentication policies created, events reviewed once, enforcement never switched on.
• Shared local admin passwords. One image password across thousands of machines turns a single hash into estate-wide access.
• Cloud roles ignored. Cloud administrator roles with rights over hybrid identities are not classified as Tier 0, or are held by synchronised on-premises accounts.

Framework mapping

Related ATT&CK techniques also include T1046 Network Service Discovery and T1210 Exploitation of Remote Services, which network segmentation addresses and identity segmentation does not.

Practitioner checklist

• List Tier 0 assets, including sync, federation, PKI, PAM and cloud identity admin roles, and every account that controls them.
• Place Tier 0 assets in a dedicated network zone reachable only from privileged access workstations.
• Apply deny logon rights by GPO so higher-tier accounts cannot log on to lower-tier hosts.
• Deploy Windows LAPS to every workstation and member server.
• Split cross-tier service accounts, convert to gMSAs and remove interactive logon rights.
• Run authentication policy silos in audit mode, then enforce for Tier 0 accounts.
• Keep cloud administrator accounts cloud-only with phishing-resistant MFA.
• Re-run attack path analysis after each change and track tier violations to zero.

Standards and references

• NIST: SP 800-207 Zero Trust Architecture
• Microsoft Learn: Enterprise access model
• Microsoft Learn: Authentication policies and authentication policy silos
• Microsoft Learn: Protected Users security group
• Microsoft Learn: Deny access to this computer from the network
• Microsoft Learn: Windows LAPS overview
• MITRE ATT&CK: T1550.002 Pass the Hash
• MITRE ATT&CK: T1558.003 Kerberoasting

Related NHI Mgmt Group resources: Identity-Centric vs Network-Centric Zero Trust · Tiered Administration and Enterprise Access Model Guide · Network Segmentation Guide · Lateral Movement Guide · Group Managed Service Accounts (gMSA) Guide