Zero Trust Is a Direction, Not a Product

The asset inventory says 4,200 servers. The discovery tool reports 9,800. The reconciliation spreadsheet has a column labeled “probably a VM.” Three months later the number is 11,000, and the CMDB owner has stopped attending the meeting. Somewhere in that gap between 4,200 and 11,000 is the actual perimeter.

The vendor presentation ends with a topology diagram where the perimeter doesn’t exist. Users float in a white space, connecting directly to applications through a glowing icon. It looks clean. It gets funded. The purchase order covers a gateway, an identity integration, and device checks. It does not cover discovering the service account that keeps the month-end close running.

The enterprise buys a zero trust network access product to replace the VPN. The deployment finishes, the board gets a slide, and the organization swaps a legacy client for a modern agent. But if the new gateway grants every employee the same broad application reach the old tunnel did, the login screen changed and the trust model did not. Network location was a proxy for trust because it was cheap, not because it was true. Swapping the tunnel for an identity-aware proxy is just moving trust from the copper wire to the session token. If the backend applications still inherently trust the internal IP space, the work hasn’t started.

Zero trust is an identity cleanup project wearing a networking disguise. Deployments stall not because network routing is hard, but because the identity store is a swamp. You cannot enforce conditional access if you have five disconnected identity providers, nested groups no one understands, and service accounts shared across departments. Multi-factor authentication answers who is at the keyboard. It does not answer what that authenticated session should be allowed to reach, what the service account does at 3 a.m., or whether the device is patched.

The vendor’s unit of sale is a license. The enterprise’s unit of work is a decision. For every request, what evidence exists, who or what evaluated it, what was allowed, and can you prove it six months later. Vendors cannot invoice for the organizational decision of who should have access to what.

The vendor demo shows a seamless proxy fronting a modern web application. The enterprise reality is a massive portfolio of on-premise applications built in 2005 that only understand IP whitelisting and LDAP. The program dies on this long tail. It dies on the manufacturing floor’s legacy ERP system, which breaks because hardcoded IP addresses are embedded in custom scripts written a decade ago. It dies on the mainframe, which does not care about your reference architecture. It dies on the application that claims to support SAML, which in practice means one flow for the admin console, while the API uses a static key and the nightly integration runs from a jump host with an IP allowlist. That is 80% of the traffic, completely uncovered.

When an internal application goes behind an identity-aware proxy, browser access works. Overnight processing fails because a scheduled job authenticates with an account created years ago and documented nowhere. The migration has exposed an ownership problem that the proxy cannot resolve. Every exception list is a portrait of an organization’s unresolved arguments. The exception process is part of the access model, not a pause in it. Every entry needs an owner and an expiry date. If an application owner will not fund their app’s change to support modern authentication, the risk gets accepted in writing by someone with a name and a title. That is the whole negotiation.

The first enforcement that breaks someone’s Tuesday decides whether the program survives. A policy requires a compliant, managed device to access email. Executives are locked out because they forward mail to unmanaged personal tablets. Sales reps are locked out because their laptops missed a management check-in. The security team spends the week writing exceptions. A policy the help desk cannot diagnose will eventually be weakened by the people trying to keep work moving. Have the rollback and the communications written before the enforcement goes live. And make sure the break-glass runbook is not stored inside the SSO-protected wiki that caused the outage in the first place.

If your program has a percentage complete, someone is measuring the wrong thing. The slide at the steering committee says the program is 62% complete. That just means 62% of workstreams have a green status. Nothing has changed about who can reach the payroll database. Measure revocation, not deployment. Measure the mean time to revoke access. Measure the percentage of access with a named owner. Measure the reduction in standing privilege. Standing privilege is a liability that accrues interest.

You can buy enforcement points and a policy engine. You cannot buy the inventory, the entitlement model, or organizational agreement on what trusted means for a given request. The vendor delivers a platform, but the program only survives the first time it blocks a legitimate user and you have to explain why.