Identity-Centric vs Network-Centric Zero Trust: Which Pillar to Fund First

Zero trust programmes stall when the identity team and the network team each believe their pillar is the real zero trust and the other is a supporting act, so money goes to two half-built architectures that cannot enforce policy together. NIST SP 800-207 describes both approaches as legitimate variations: one makes identity the key input to every policy decision, the other places resources behind gateways on their own segments. This guide sets out which attack paths each approach closes, the dependency order between them, how workload identity changes the answer, and the failure modes that appear when one is built without the other. It is for security architects, CISOs and programme leads deciding what to fund first. Mechanics of individual controls are covered elsewhere: see the Conditional Access vs ZTNA guide for where sign-in policy ends and brokered access begins, and the Zero Trust Identity Guide for the identity controls themselves.

Key takeaways

• Identity comes first because every network policy needs it. NIST SP 800-207 states that the micro-segmentation approach "requires an identity governance program (IGP) to fully function". A segment rule that cannot name who or what is connecting falls back to IP addresses, which is the implicit trust zero trust is meant to remove.
• Identity alone leaves the network open for reconnaissance. The same publication notes the identity-led approach has a downside: granting basic connectivity means attackers "could still attempt network reconnaissance". Network controls close what identity cannot see: lateral movement, exploitation of exposed services and protocols that never call an identity provider.
• The order is identity foundation, then network shrinkage, then convergence. Fund central identity, phishing-resistant authentication and device identity first; use them to remove broad network access with brokered access and macro segmentation; then add micro-segmentation keyed to workload identity.
• Workload identity is where the two pillars merge. NIST SP 800-207A moves cloud-native access policy from network parameters to application and service identities. Service to service traffic is the case where network-centric segmentation is weakest and identity-based policy is strongest.
• The worst outcome is a strong network gate behind a weak identity. ZTNA or micro-segmentation that trusts a password-only sign-in, a shared service account or a long session turns every policy into a single credential away from bypass.

The short answer

For almost every organisation, start with identity. Centralise identities, require phishing-resistant authentication for people, give devices and workloads verifiable identities, and put policy at the identity provider. That work is a precondition for any meaningful network policy, and it closes the largest single attack path, the use of valid accounts (MITRE ATT&CK T1078). Start network work in parallel only where the exposure is urgent and identity cannot reach it: internet-facing remote access, flat networks hosting legacy systems, and OT or medical device estates where devices cannot authenticate at all. Then converge, so that network enforcement points make decisions using the identities you built.

The US federal strategy in OMB M-22-09 captures the intended end state in one line: "Users should log into applications, rather than networks." It also requires agencies to "break down their perimeters into isolated environments". Both halves are required. The question is only sequencing.

What each approach means

The NSA network and environment pillar guidance groups the network side into four capabilities: data flow mapping, macro segmentation, micro segmentation and software defined networking. It also says plainly that the pillars "are not independent", and suggests that micro-segmentation security levels be defined "based on identity and application access". The CISA Zero Trust Maturity Model Guide covers how maturity is staged across Identity, Devices, Networks, Applications and Workloads, and Data.

Threat paths each approach closes

The clearest way to decide is to list the paths attackers use and ask which pillar actually breaks each one.

Read down the last column. Identity closes the paths that start the most incidents (credential theft and remote access abuse). Network closes the paths that turn a foothold into a breach (scanning, exploitation and lateral movement). NIST SP 800-207 Section 5.3 makes the identity point directly: a contextual trust algorithm is "more likely to detect and respond quickly" to stolen credentials than static rules. Section 5.4 makes the network point: some traffic is opaque to network analysis, so visibility has to come from other signals too.

Dependency order

The two pillars are not parallel tracks. Several network capabilities consume identity outputs, so building them first means rebuilding them later.

1. Inventory and flows. Know users, devices, services and their communication paths. The NCSC's first two principles are "Know your architecture" and "Know your User, Service and Device identities". Data flow mapping is also the first NSA network capability. This step serves both pillars and is where most programmes underinvest.
2. Authoritative identity. One identity provider for workforce users, with joiner, mover and leaver processes and phishing-resistant authentication. OMB M-22-09 requires "centralized identity management systems" and phishing-resistant MFA for staff, contractors and partners.
3. Device identity and posture. Managed devices with certificates or attested identity, so policy can distinguish a managed laptop from a stolen password on an unknown machine.
4. Remove broad network access. Replace network-level remote access with per-application brokered access that federates to the identity provider. Apply macro segmentation: separate user, server, management and OT networks, and block administrative protocols between them.
5. Workload identity. Give services verifiable identities (cloud workload identity, SPIFFE IDs, managed identities) and retire static keys and shared service accounts.
6. Micro-segmentation keyed to identity. Write segment policies in terms of workload and user identities, not IP ranges, and enforce them at host agents, gateways or service mesh proxies.
7. Continuous evaluation. Feed device, identity and network signals into policy decisions that can revoke sessions mid-flight.

Steps 4 and 6 are the network pillar. Both depend on step 2 or step 5. That is the practical meaning of NIST's statement that micro-segmentation needs an identity governance programme, and of its warning that, without advanced gateways, administration cost and slow adaptation make it "a very poor choice".

Workload identity: where the pillars meet

Most zero trust debate is about people. In modern estates, most connections are machine to machine, and here the network-centric model struggles. Container and serverless workloads change addresses constantly, so IP-based rules either become too broad or break deployments. NIST SP 800-207A, published in September 2023, describes the response: policies based on "application and service identities", enforced through "API gateways, sidecar proxies, and application identity infrastructures", applied "irrespective of the location of the services or applications". It describes this as a move away from "segmentation and isolation using network parameters".

That does not make the network irrelevant. A service mesh proxy is a network enforcement point; it simply decides using a workload identity rather than an address. The practical sequence is:

• Issue identities: cloud-native workload identity or SPIFFE IDs for every service, with short-lived credentials. See the SPIFFE and SPIRE Guide and the Workload Identity Federation Guide.
• Authenticate every call: mutual TLS between services, with the identity in the certificate.
• Authorise by identity: allow service A to call service B's specific API, not "the payments subnet can reach the database subnet".
• Keep a coarse network floor: macro segmentation still blocks whole classes of traffic if the mesh is misconfigured or bypassed.

See the NIST SP 800-207A Zero Trust for Cloud-Native Applications Guide for the architecture.

When to start with the network

Identity first is the default, not a rule. Network work should lead, or run alongside from day one, where:

• Devices cannot authenticate: OT controllers, medical devices, building systems and printers have no identity provider integration. Segmentation is the only control available. See Zero Trust for OT and ICS Guide.
• The network is flat and ransomware is the main risk: blocking SMB, RDP and remote management between user subnets and from users to servers cuts lateral movement in weeks, while an identity programme takes quarters.
• Exposed remote access is unpatched or hard to patch: removing an internet-facing VPN concentrator in favour of brokered access removes the surface even before identity is mature.
• Legacy protocols dominate: estates built on Kerberos, NTLM and directory-bound applications gain more from limiting who can reach domain controllers and file servers. See Zero Trust in Hybrid Active Directory Environments.

Even in these cases, the network controls should be designed to accept identity input later: choose enforcement points that can consume user, device and workload identity rather than only addresses.

Failure modes

Network controls on top of weak identity

• ZTNA with password-only sign-in: the broker makes applications invisible to the internet, then admits anyone with a phished password. The brokered path becomes a high-value target.
• Segments that trust a shared service account: a micro-segmentation rule that allows "the backup account" everywhere is a network-wide credential.
• Long sessions: access granted once and never re-evaluated outlives the device posture or user status that justified it.

Identity controls with an open network

• Flat internal network: strong sign-in to SaaS, but any foothold can reach every server, domain controller and backup system.
• Legacy protocols ignored: conditional access protects modern sign-ins while SMB, RDP and database logins bypass the identity provider entirely.
• Exploit paths left open: an unauthenticated vulnerability in an internal service needs no identity at all.

Both pillars, no convergence

• Two policy engines that disagree: the identity team disables a user, the network team's rules still allow the device, and nobody owns time to revoke.
• Segment rules written in IP ranges forever: rules never move to identity, so cloud migration breaks them or forces broad allowances.

The Top 10 Zero Trust Mistakes covers programme-level mistakes beyond this choice.

Worked scenario: a 4,000-person firm with a hybrid estate

The firm runs a hybrid Active Directory estate, a mix of SaaS and on-premises applications, a remote access VPN, and a flat data centre network. The board has funded zero trust for three years.

Year one, identity foundation plus urgent network work. Consolidate to one identity provider, enforce phishing-resistant MFA for administrators then all staff, enrol devices, and apply conditional access. In parallel, the network team blocks SMB, RDP and WinRM between user subnets and restricts administrative protocols to a management segment, because ransomware lateral movement is the top risk in the risk register.

Year two, shrink the network using identity. Replace the VPN with brokered per-application access federated to the identity provider, with a device requirement. Macro-segment the data centre into tiers. Start issuing workload identities in the cloud estate and retire static keys.

Year three, converge. Rewrite data centre micro-segmentation in terms of workload identities. Connect identity risk signals to session revocation across the broker and SaaS. Measure time to revoke across all layers.

The firm funded identity first, but it did not wait for identity to finish before cutting the paths ransomware uses. That is the typical shape.

Decision criteria

• Mostly SaaS, few private applications: identity first and mostly identity; network work is limited to device posture and egress.
• Hybrid with legacy protocols: identity first, with early macro segmentation of admin protocols.
• Heavy cloud-native and microservices: workload identity is the priority; segmentation is enforced through identity-aware proxies.
• OT, medical or IoT heavy: network first for devices, identity first for the people and vendors who reach them.
• Small organisation: buy identity (single identity provider, MFA, device management) before any segmentation product; use built-in host firewalls for basic segmentation. See Zero Trust for Small Organisations.
• Large organisation with separate teams: fund both, but make the network roadmap consume identity milestones as dependencies, and appoint one owner for policy decisions.

Detection and measurement

Log identity provider sign-ins and token issuance, broker connection decisions, segmentation allow and deny events, and workload authentication failures, and join them on user, device and workload identity. Metrics that show both pillars are working:

• Percentage of sign-ins using phishing-resistant authentication.
• Percentage of applications reachable only through an identity-aware path (broker, proxy or federated sign-in).
• Percentage of east-west traffic covered by a default-deny policy.
• Percentage of segmentation rules written in terms of identity rather than IP ranges.
• Percentage of workloads authenticating with short-lived identity rather than static keys.
• Median time from disabling an account to loss of access in every layer.

Framework mapping

Practitioner checklist

• Map users, devices, workloads and their communication flows before choosing tools.
• Consolidate to one authoritative identity provider and enforce phishing-resistant MFA, starting with administrators.
• Give managed devices verifiable identities and use their state in access policy.
• Block administrative protocols between user networks and restrict them to a management segment early.
• Replace network-level remote access with per-application brokered access that federates to the identity provider.
• Issue workload identities and retire static keys and shared service accounts.
• Write new segmentation rules in terms of identity and plan to migrate old IP-based rules.
• Assign one owner for policy decisions across identity and network, and measure time to revoke.

Standards and references

• NIST: SP 800-207 Zero Trust Architecture
• NIST: SP 800-207A A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments
• OMB: M-22-09 Moving the U.S. Government Toward Zero Trust Cybersecurity Principles
• NSA: Advancing Zero Trust Maturity Throughout the Network and Environment Pillar
• NCSC: Zero trust architecture design principles
• MITRE ATT&CK: T1078 Valid Accounts
• MITRE ATT&CK: T1021 Remote Services

Related NHI Mgmt Group resources: Zero Trust Identity Guide · Conditional Access vs ZTNA · CISA Zero Trust Maturity Model Guide · Network Segmentation Guide · ZTNA Guide