# Automation Is How Zero Trust Survives Contact with Operations > Zero Trust needs sound identity, policy, and enforcement. Automation keeps those controls current as systems and people change. - Published: 2024-01-01 - Updated: 2026-07-30 - Tags: Zero Trust, Automation, Security Architecture - Source: https://stevenfoerster.com/notes/zero-trust-without-automation/ Zero Trust is appealing because it rejects implicit trust based on network location. Access is decided from identity, resource, device, and other policy inputs, with least privilege and ongoing evaluation instead of a permanently trusted internal network. The problem is that these promises are only true in a world where identity, authorization, and configuration can update themselves at the speed of change. Without automation, Zero Trust becomes a manual process, and manual processes do not scale. At useful scale, Zero Trust needs an automated control plane, not just a policy. Human governance still belongs in the system: people define policy, approve exceptional access, investigate signals, and accept risk. The failure begins when routine identity and policy changes can take effect only through manual tickets. At that point, the access model falls behind the environment it is meant to describe. ## The operational reality of Zero Trust Zero Trust systems rely on three things happening continuously: identity that is current, with users, services, and devices known and verified in real time; policy that is enforced consistently across every system; and context that feeds those decisions: risk signals like device posture, behavior, and environment. Each of these is operationally heavy. In a manual model, identity changes require tickets, policy updates require meetings, and context signals are reviewed after the fact. That cadence is incompatible with Zero Trust. The system simply changes too quickly. ## The gap between policy and reality Many teams adopt Zero Trust as a strategic goal, but operationally they are still working in a perimeter mindset. For example, a policy might state that every service-to-service call must be authenticated with short-lived credentials, but the actual system relies on long-lived API keys because rotation is too painful. The policy exists, but the system does not. Zero Trust without automation tends to produce exception overload, shadow pathways, and stale identity. The number of exceptions grows because policies are hard to enforce manually. Teams build side channels to move faster, bypassing the policy layer. Accounts linger, devices drift, and the access graph is wrong. These are structural failures of the model, not minor flaws. ## Example: service identity without provisioning The following is an illustrative failure pattern rather than an account of a specific company. A growing software organization mandates mutual TLS with short-lived certificates for every internal service call. The identity system is solid. The failure happens at provisioning. Service owners must request certificates manually, wait for approval, and roll them out on a quarterly schedule. On paper, the identity system exists. In practice, teams have an incentive to build shared service accounts to avoid the provisioning work, concentrating trust in the exact place the design meant to remove it. The design fails even if the cryptography is correct because the operational workflow makes the secure path too expensive. The remedy is straightforward but non-trivial: automate certificate issuance, integrate it with deployment pipelines, and enforce rotation on a short cadence. ## Automation is the control plane In practice, Zero Trust needs a control plane that connects identity, policy, and enforcement. That control plane is automation. It includes: > - **Provisioning pipelines** that create and decommission identities automatically. > - **Policy-as-code** that version-controls access rules and applies them consistently. > - **Continuous validation** that checks whether enforcement matches intent. > - **Drift detection** that surfaces when systems move outside their expected posture. If you cannot list your identity authorities, you cannot automate them. With these in place, Zero Trust is workable. Without them, it depends on people who are already overburdened. ## What automation changes Automation changes the economics of security. It reduces the cost of doing the right thing and increases the cost of deviation. It turns policy into infrastructure rather than a document. It also gives leaders real-time visibility into whether the system still reflects its design. That's why I treat automation as a capability that enables Zero Trust, not the definition of it. The tooling turns policy into repeatable enforcement. Its quality matters alongside identity proofing, policy design, asset inventory, enforcement coverage, and operational ownership. ## Common automation pitfalls Automation does not magically create trust. It can fail in subtle ways. Teams often automate approvals but not provisioning, which keeps the bottleneck alive; the real goal is reducing time-to-identity, not digitizing ticket forms. A Zero Trust control that covers 80 percent of services still leaves a large untrusted surface, and exceptions grow around the gaps. And if the automation fails regularly, engineers will route around it, since reliability is part of the security model. A useful checkpoint is to ask whether your automation makes the secure path the fastest path. If the answer is no, the system is still relying on heroic effort. Automation should feel boring. When it is noisy or unreliable, it becomes its own source of risk. More broadly, defaults scale better than any other security control; once the secure path stops being the easiest one, coverage erodes silently no matter how well the controls are designed. ## Source - [NIST SP 800-207: Zero Trust Architecture](https://doi.org/10.6028/NIST.SP.800-207)