Zero Trust's hardest problem is identity

"Never trust, always verify" quietly assumes you can answer one question reliably: who or what is this? In a real enterprise, you often can't, and that gap, not the technology, is where Zero Trust programs stall.

Zero Trust gets sold as an architecture problem: buy the microsegmentation, the policy engine, the software-defined perimeter, then verify every request. But the whole model rests on one assumption the slideware never examines, that you can reliably establish who or what is making a request. "Never trust, always verify" is only as good as your ability to verify. In a real enterprise, that ability breaks down at identity.

The model rests on an identity you may not have

Every Zero Trust decision (allow this flow, grant this access, permit this workload to talk to that one) is a function of identity. Not IP address; identity. The whole point is to stop trusting network location and start trusting a verified principal: this user, this device, this service, with this posture.

That works cleanly in the reference architecture, where every actor has a strong, unique, current identity. It works far less cleanly in an environment that grew over twenty years, where a meaningful fraction of what's on the wire has an identity that is shared, stale, machine-issued, or effectively anonymous. You can buy a policy engine in an afternoon. You cannot buy a clean identity for every principal in your estate, that has to be built, and it's the part nobody budgets for.

Human identity is the easy 20%

Federated SSO, MFA, conditional access, the human-identity story is genuinely mature. If Zero Trust were only about employees opening laptops, it would mostly be a solved problem. The trouble is that human logins are a small share of what actually needs authorizing, and the rest is where it gets hard.

Service accounts: the identities that verify nothing

Service accounts are where the model quietly breaks. They're shared by design, their credentials rarely rotate, they're frequently over-permissioned because nobody dared to scope them tightly, and their actual owner is often unknown, created years ago for an integration by someone who has since left.

You can't apply "verify every request" to a principal that is, functionally, a shared password with standing privilege. There's no MFA on it, no device posture behind it, and often no one who can tell you what it's supposed to do, so you can't tell an anomaly from normal operation. Every Zero Trust program eventually collides with a wall of service accounts it can neither retire nor confidently constrain, and that collision is where timelines slip.

Machine and workload identity: strong in the cloud, murky everywhere else

Modern platforms have real answers here, SPIFFE/SPIRE, cloud workload identity, mTLS with short-lived certificates, per-pod identity in Kubernetes. Where you have them, workload identity is arguably stronger than human identity.

The catch is coverage. Your greenfield cloud estate gets cryptographic workload identity. Your twenty-year-old on-prem estate does not, the VMs, appliances, embedded systems, and OT/IoT that can't run an agent or hold a certificate still get identified by IP address, which is the exact thing Zero Trust told you to stop trusting. You end up with a split model: rigorous identity for the newer 30%, and network-location trust dressed up as segmentation for the older 70%. Honest Zero Trust means naming that gap instead of hiding it behind a diagram.

The directory is the source of truth, and it's wrong

Underneath identity sits the directory (Active Directory, your IdP, the CMDB) and Zero Trust inherits every flaw in it. This is the same problem microsegmentation hits from the network side: policy quality is a function of identity-data quality, and the identity data is stale.

• Orphaned accounts — user accounts usually get disabled when someone leaves, but the service accounts they requested or created rarely do. Nobody owns retiring them, and disabling one risks breaking whatever it quietly runs, so they persist: still enabled, still entitled, long after their purpose is gone.
• Group sprawl — nested groups granting access nobody can trace, where "verify the request" runs into "against what authoritative entitlement?"
• Privilege accumulation — the person who's been here twenty years, changed roles five times, and kept every entitlement from every one of them. Some was added informally, a favor to a colleague, access granted on a friendly ask. These entitlements do get reviewed, but reviewing is not revoking: the access shows up in the certification, the reviewer can't be sure what breaks if it's removed, the owner approves it to be safe, and it survives another cycle. They're a current, legitimate employee, so nothing forces the question of whether the access still matches what the job needs today.
• Stale attributes — the department, role, owner, and device bindings that conditional-access policy keys on, quietly out of date.
• No single source of truth — AD says one thing, the HR system another, the CMDB a third, and reconciling them is the actual project.

Point a Zero Trust policy engine at a directory that's 70% accurate and you get 70%-correct authorization, and the wrong 30% is either a blocked legitimate access or a permitted illegitimate one. Neither is the outcome the program promised.

Standing privilege is the opposite of Zero Trust

Even with clean identities, the entitlement model usually contradicts the philosophy. Zero Trust wants least privilege, verified continuously. Most enterprises run on standing privilege: access granted once and held forever, admin rights that persist between the rare moments they're used, service accounts with permanent broad scope. The goal is just-in-time access, elevate per session, re-verify continuously. Getting there means unwinding years of accumulated grants, and that's an organizational fight (who signs off on removing access?) far more than a technical one.

The network can't deliver Zero Trust alone

There's an accountability mismatch at the heart of most programs. Application owners expect Zero Trust to be delivered to them at the network layer: make the network secure my app, segment it, enforce least privilege around it. In the same breath, they ask for the opposite: my app needs to reach everything, so open it up. Both requests land on the network team, and they contradict each other.

You cannot enforce least privilege on behalf of a team that refuses to define what "least" is. The network can write a tight policy, but only against a definition of "needed" that the application owner has to supply, host by host, flow by flow. When that definition comes back as "all of it, to be safe," you're left with two bad options: write the over-broad rule they asked for (which is not Zero Trust, whatever the diagram says) or scope it yourself and get blamed when something the owner never documented quietly breaks.

So Zero Trust at the network is a shared responsibility, and the application side has to play too. That means owning their dependencies, documenting what actually talks to what, justifying each ask instead of defaulting to "everything," and accepting that "give my app unrestricted access" is the direct opposite of the security posture they're demanding the network provide. The uncomfortable version: the network team gets held accountable for a Zero Trust outcome it can't reach alone, because half the inputs belong to people who'd rather not do the work of scoping their own application.

The things that have to touch everything

Then there's the dilemma that has no clean answer. Microsegmentation assumes you can draw tight boundaries around everything. But some entirely legitimate functions are the opposite of segmented by design: they have to reach the whole estate to do their job.

Configuration management pushes to every host: an Ansible control node, by definition, needs a path to everything it manages. Vulnerability scanning has to probe the entire environment, so Rapid7 or Nessus or Qualys needs broad reach to be worth running. CMDB discovery scans enumerate the whole network. Patch distribution, endpoint management, monitoring, backup: all of them are single sources that need to talk to nearly everything. A strict least-privilege model says no host should reach the entire estate. These tools require exactly that, and you can't segment your way out of it without breaking the function.

There's no making this disappear, but there is a way to hold it honestly. Treat these broad-access systems as their own tightly controlled tier: dedicated, hardened source identities, not shared with anything else. Scope by protocol even when the destination has to be broad, because Ansible needs SSH and WinRM, not "any to any," and a scanner needs its specific probe ports, not everything. Put strong identity and MFA on the control plane, make the access on-demand or time-bound wherever the tool allows it, and monitor these paths harder than anything else you run. That's the real definition worth landing on: Zero Trust doesn't mean zero broad access. It means every broad-access path is deliberate, owned, minimized to the protocol it actually needs, and watched like a hawk, rather than pretending it doesn't exist.

Where identity meets the rule: PAN-OS and Illumio

The identity problem is abstract until you have to write the rule that enforces it, and this is where the network layer, done right, actually delivers Zero Trust rather than talking about it. Both a next-gen firewall and a host-based segmentation platform can express policy against identity instead of IP address. Seeing how makes the whole model concrete.

PAN-OS: User-ID and dynamic membership

On a Palo Alto firewall, User-ID is the mechanism that puts human identity into a security rule. Instead of a rule that reads "allow 10.1.5.0/24 to the finance app," you write "allow members of the Finance group," and the firewall resolves that to live user-to-IP mappings pulled from Active Directory, the domain controllers, or an agent. The rule follows the person, not the address they happened to get from DHCP.

For workloads and machine identity, Dynamic Address Groups do the equivalent. Membership is defined by tags rather than a static IP list, so a rule references "everything tagged web-tier," and as workloads are tagged or untagged, by orchestration, by a script, by an external source, the rule's scope updates without a policy edit. The identity (the tag) drives enforcement; the IP is just plumbing.

Illumio: policy written entirely against labels

Host-based segmentation takes this further, there are effectively no IPs in the policy at all. In Illumio you label each workload by Role, Application, Environment, and Location, and rules are written purely against those labels: "the Web role of App-X in Production may reach the Database role of App-X in Production." The policy compute engine resolves those labels to the actual workloads and programs each host's own firewall through the agent. When a workload moves or its address changes, the policy holds, because it never named an address. It named an identity.

That's Zero Trust segmentation in its most literal form: enforcement bound to what a workload is, not where it sits on the network. And it lands on the same dependency as everything else in this post, the labels have to be right. A mislabeled workload gets the wrong policy just as surely as a stale AD group authorizes the wrong user. The enforcement mechanism is excellent; it still runs on the quality of the identity you feed it.

The same idea extends into the network fabric itself. Cisco TrustSec carries a Security Group Tag (SGT) with the traffic, assigned at the access layer by ISE based on who or what authenticated, and enforcement is written group-to-group in an SGACL matrix rather than by subnet. NAC platforms like ISE and Forescout are the classification layer underneath it, authenticating and profiling each device or user at admission and mapping it to the right tag, VLAN, or posture. Different vendors, same pattern, and the same catch: the SGT is only as trustworthy as the classification that assigned it, and the NAC decision is only as good as the device profiling and identity data behind it. Get the identity wrong at admission and you've simply propagated the wrong trust deeper into the network, now wearing a tag that makes it look deliberate.

What actually moves the needle

Identity is the hard part, but it's not hopeless. It just has to be treated as the foundation rather than a prerequisite someone else handles. What works:

• Inventory non-human identities first. Before any policy engine, find the service accounts, tokens, and machine identities and assign each a real owner. You can't verify what you haven't enumerated.
• Fix the directory before you automate against it. Orphaned accounts, group sprawl, and stale attributes are the label-quality problem in identity form. Remediation is unglamorous and it is the work.
• Be honest about the coverage split. Strong identity for what can hold it, compensating controls (tight segmentation, monitoring) for what can't, and don't pretend the second category is verified when it's really just fenced.
• Attack standing privilege incrementally. Start with the highest-risk grants, move them to just-in-time, and accept that this is a multi-year unwinding, not a switch.
• Sequence identity ahead of enforcement. A policy engine enforcing decisions built on bad identity data doesn't deliver Zero Trust, it delivers confident wrong answers.

The technology side of Zero Trust is real and it works. Policy engines, segmentation, identity-aware proxies, all of it does its job. But every one of them computes decisions from a single input: identity. Feed that input bad data and the most sophisticated policy engine in the world will enforce the wrong thing, precisely and confidently.

So "never trust, always verify" was never really about the verifying. It was about whether you can answer one question for every principal on your network: who, or what, is this? Most enterprises can't answer it yet. That question, not the architecture, is the Zero Trust program.

Written by Roman Dmytriv, network security engineer (CISSP), two decades securing and modernizing enterprise networks. More writing at blog.dmytriv.com, and I'm on LinkedIn.