Zero trust That Works After the Slide Deck Is Gone

Somewhere in almost every large organization, there's a beautiful zero-trust architecture diagram that has never had to survive an ordinary Tuesday. The arrows are clean, the trust boundaries are immaculate, and the words continuous verification appear in several places. Then somebody needs to fix a broken application at midnight, a contractor cannot authenticate, and an administrator discovers that the emergency procedure is to turn off half the controls. That's when I become interested in the architecture.

Zero trust is an approach to making access decisions around users, devices, resources, and context rather than granting implicit trust because a connection happens to originate inside a particular network (Rose et al., 2020). That sounds straightforward. Operating it across inherited systems, cloud services, human exceptions, and imperfect identity data is considerably harder. The interesting question isn't whether an organization has adopted the language. It's whether access decisions are specific, defensible, observable, and reversible when something goes wrong.

I would start by asking which resources deserve the strongest access decisions. A payroll application, source-code repository, domain administration interface, industrial controller, and public marketing site do not present identical consequences. Nor do the people and services that reach them. NIST SP 800-207 describes a resource-centered model rather than a new perimeter with a different logo (Rose et al., 2020). The practical translation is to define the resource, its legitimate users, the actions they require, and the conditions under which access should be granted or denied.

This sounds basic until you ask an application owner to list every machine identity with production privileges. Human accounts tend to get attention because they're visible in HR systems and identity directories. Service principals, integration credentials, automation tokens, emergency accounts, and legacy application secrets often live somewhere less convenient. An organization can deploy strong interactive authentication while leaving a highly privileged machine credential effectively unattended. The access model must account for both.

I also want the owners of critical applications in the room. Security cannot invent a correct authorization policy without understanding the work. If the policy breaks the business, people will bypass it; if it grants every requested exception indefinitely, it stops being a policy. The objective is a controlled mechanism for deciding what is necessary, what is temporary, and who accepts the consequences of a deviation.

Authentication asks whether the claimant can establish an identity at a required assurance level. Authorization asks whether that identity may perform a particular action on a particular resource. Mixing them up creates expensive confidence. A strongly authenticated user can still have far too much access. NIST's 2025 Digital Identity Guidelines distinguish identity proofing, authentication, and federation, and their companion authentication guidance addresses authenticator assurance and lifecycle management (Temoshok et al., 2025a, 2025b).

In practice, I would examine how identities are created, changed, suspended, and retired; whether privileged actions require a different level of assurance; how recovery works when authenticators fail; and how authorization reflects actual job duties. I would also ask how quickly the organization can revoke access across dependent systems. An account disabled in one directory may retain a valid session or token elsewhere. If revocation takes hours and nobody knows which applications honor it, the supposed boundary is much weaker than the policy suggests.

The same applies to device trust. A managed laptop can supply useful evidence about its configuration and health, but that evidence is not a moral certificate. Devices change state. Agents stop reporting. Inventory records drift. Conditional access rules should define what happens when evidence is missing, stale, or contradictory. An architecture that always permits the session when telemetry disappears has made a decision, whether anyone admits it or not.

One of the more useful distinctions in NIST's architecture is between policy decisions and policy enforcement (Rose et al., 2020). The former determines whether a request should be allowed; the latter makes that decision real. In an operating environment, I want to know which system made the decision, what evidence it used, how that decision was logged, and who can challenge or override it. A policy that nobody can explain is difficult to debug and almost impossible to defend when an outage follows.