Identity-Aware Network Segmentation

Most segmentation programs still write rules in terms of location: this subnet may reach that subnet on this port. The rule is easy to read and easy to audit. It also grants access to anything that happens to sit in the source range, including an attacker who has just taken over a server there.

Identity-aware segmentation changes what the rule refers to. Instead of “the reporting subnet may reach the finance database”, the policy says which user, device or workload identity may reach which resource, under which conditions. The network still enforces it. The decision no longer depends on an address.

That sounds like a small change. In practice it moves the hard work from firewall engineering to identity data quality, dependency mapping and policy operations. This article covers what the term does and does not mean, where programs fail, and the order of work that holds up.

Why address-based segmentation leaves the path open

Zero trust architecture guidance from NIST is direct on the underlying problem. It describes a shift away from network location as the main basis for trust, and treats authentication and authorization of the subject and the device as separate steps completed before a session to a resource is established. A segment is a location. Under that model it cannot be the thing that earns access.

Consider a hypothetical case. A reporting server runs under a service account that is allowed to query a finance database. The network rule allows the reporting subnet to reach the database zone. An attacker who gains code execution on any other host in that subnet now has the same network path, and often the same ability to try the same credentials. The segmentation exists on paper and on the diagram. Against this intrusion it does very little.

This is why flat trust inside a zone is the central weakness. Zones reduce what an intruder can reach from outside. Inside the zone, address-based rules cannot tell a legitimate request from a hijacked one.

What “identity-aware” means, and what it does not

Three terms get used as if they were one. They are not.

• Segmentation is the act of dividing an environment and controlling traffic between the parts.

• Microsegmentation is about granularity: smaller zones with tighter rules. CISA’s guidance describes it as limiting connections to a zone or segment with more granular access rules. You can do it entirely with addresses and ports.

• Identity-aware describes what the policy references. The rule keys on a user, a device state, or a workload or service identity rather than only an IP address.

A program can be fine-grained and still address-based. It can also be identity-aware and coarse. The two properties are independent, and the architecture decision is which of them each part of the estate needs.

The identity can come from different places depending on the layer where the rule is enforced.

NIST’s guidance on zero trust for cloud-native applications describes the last row. It calls for authentication and authorization policy based on application and service identities, enforced by components such as gateways and sidecar proxies, so that policy holds whether the service runs on-premises or across several clouds. CISA’s microsegmentation guidance lists the same range of enforcement points: network devices, endpoints, containers, hypervisors and cloud-native controls.

Where identity-aware programs go wrong

Identity data becomes the new dependency

A policy that says “Finance-Analysts may reach the ledger” is only as accurate as the group. Stale memberships, nested groups nobody understands and service accounts with no owner all carry straight into the rule. Identity-aware segmentation does not remove the problem of poor entitlement hygiene. It enforces it faster.

Policy written before dependencies are known

CISA’s guidance sets out a sequence: identify candidate resources, identify what depends on them and what they depend on, decide the policy, then deploy it starting in a permissive mode that flags violations. It also recommends pilot user groups, monitoring and rollback. Teams that skip the dependency step find out about the batch job, the monitoring probe and the disaster recovery path when something stops working on a Monday morning.

Most east-west traffic is not a person

User-centred access tools handle human sessions well. A large share of internal traffic is one service calling another. If the design only covers users, the machine traffic stays on address-based rules, and that is where an intruder moving between servers tends to operate.

Assets that cannot take part

CISA is open about this limit. Operational technology, IoT and legacy devices often cannot run agents and have limited built-in protection. These stay behind network-level controls. The honest design records them as an accepted limitation with a named owner, rather than pretending the identity model reaches them.

Valid identity is still the weak point

If an attacker steals a session token or a privileged credential, identity-aware policy sees a legitimate subject. Segmentation limits how far that subject can travel and what it can reach. It does not detect the theft. The design needs session protection, device posture checks, continuous re-evaluation and identity threat detection alongside it.

The decision point is now critical infrastructure

Once access depends on a policy engine and an identity provider, an outage or compromise of either has an immediate effect on the business. Teams should decide deliberately what happens when the policy decision cannot be reached. Fail-open protects availability and quietly removes the control. Fail-closed protects the control and can stop operations. The choice differs by system, and it should be made by the system owner with the architect, not discovered in an incident.

An order of work that holds up

1. Start with the paths that matter most. Administrative access to identity infrastructure, hypervisors, backup systems and the management interfaces of security tools gives an intruder the widest reach. Protect those paths before the general application estate.

2. Map real flows before writing rules. Use flow data and application owners together. Flow data shows what talks to what; owners explain why, and which flows are rare but essential.

3. Express each rule in identity terms where identity exists. Fall back to address-based rules where it does not, and record each fallback as a known gap with an owner and a review point.

4. Run in observe mode, then enforce in stages. Review violations, fix the dependency list, then enforce one application or environment at a time with a tested rollback.

5. Test the segmentation, not just the configuration. From a representative compromised workload, try to reach the protected resources the policy says are closed. A rule that has never been tested against an attempt to bypass it is an assumption.

6. Decide failure behavior and ownership of the policy. Document fail-open or fail-closed per system, and put policy changes under the same change control as any other production security control.

How this relates to firewalls and zero trust programs

Identity-aware segmentation does not replace the firewall estate. Network devices remain enforcement points, and next-generation firewalls are one of the layers CISA lists. What changes is how much of the rule base should stay address-based, and that should shape any firewall refresh. Migrating an address-based rule set unchanged into new hardware, while access is being moved to identity-aware controls elsewhere, produces two overlapping policy sets and no clear owner for either.

It also does not equal a zero trust program. It is one control family within one. A zero trust architecture still needs strong identity, device assurance, data protection and detection around it.

A QUESTION FOR THE NEXT ARCHITECTURE REVIEW For each of your most critical applications, can you state who or what may reach it, from where, under what device or workload condition, and how you would know if that changed? Where the honest answer is "anything in this subnet", the segmentation is describing a location, not an authority.

What to do next

Pick one high-value path, such as administrative access to the identity platform or the finance database, and walk it through the six steps above. The exercise is small enough to finish and will show quickly how reliable your identity data is, how many dependencies are undocumented, and which enforcement layers you can rely on. If you want an outside view on scope, enforcement point selection or how to sequence the work against a firewall refresh, a security architecture review is the logical place to start.

Sources

1. NIST SP 800-207, Zero Trust Architecture. National Institute of Standards and Technology

2. NIST SP 800-207A, A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments. National Institute of Standards and Technology

3. Microsegmentation in Zero Trust, Part One: Introduction and Planning. Cybersecurity and Infrastructure Security Agency. Source for the planning sequence, enforcement points and the limits for OT, IoT and legacy devices