John Kindervag on Zero Trust: Five Steps to Limit Access and Contain Attacks

Zero Trust changes the starting assumption of network security: a connection earns access through verification rather than inheriting trust from its location. John Kindervag developed the approach after questioning why systems behind a firewall were treated as safe while those outside it were not. His practical answer is a five step method: identify what matters, map how it operates, design around those needs, restrict access, and keep refining the controls.

The shift matters as organizations use remote work, hybrid cloud services and employee owned devices. Those environments make a simple inside versus outside boundary less useful. Kindervag’s central point is that Zero Trust is a security strategy built from tailored policies and technology, not a product that an organization can purchase and install by itself.

From firewall trust to verification

Kindervag’s idea took shape while he was working with firewalls. He saw a model that assigned trust based on whether a packet came from inside or outside the perimeter, even though location alone said little about whether it was safe. “I started saying that firewalls should have a trust level of zero. You should treat every packet the same,” he recalled.

He joined research group Forrester in 2008, where he spent two years on primary research and began building prototypes of Zero Trust environments. He then continued studying the model and developing proof of concept systems. Adoption was slow: Kindervag says he often heard that organizations had always done things a particular way. His reply was that the familiar approach wasn’t working.

During the first five years, he says, he was among the few designing and overseeing Zero Trust environments. That gave him opportunities to make mistakes, learn from them and document lessons for others. One of his key reframings was to replace the broad idea of an attack surface with a smaller “protected surface.” As he put it, the focus should be what an organization needs to protect, rather than every possible way it might be attacked.

The source cites two adoption figures: Gartner reported that 63% of organizations worldwide had implemented a Zero Trust strategy, while a Microsoft report found that 82% of companies had adopted it within the prior three years. These figures use different measures and shouldn’t be read as competing estimates of the same population. The article also says federal agencies were later directed to adopt Zero Trust.

What Zero Trust means in practice

Kindervag argues that trust is a poor basis for decisions made by digital systems. Zero Trust assumes that no user, device or connection is safe by default, then grants only the access required for a legitimate task. He jokes about putting money in a “trust jar” whenever someone describes a digital system as trusted, a way to underline how easily the term can obscure security assumptions.

This approach doesn’t prevent attackers from trying to get in. Its purpose is to make their attempts less effective by limiting access and reducing the paths available to exploit. “Zero Trust doesn’t stop attacks—it makes them unsuccessful,” Kindervag said. That distinction is useful for setting expectations: the design aims to constrain what a compromised account or device can reach, rather than promise that no intrusion will occur.

That also explains why a vendor cannot sell Zero Trust as a standalone product. Organizations need a strategy, policies suited to their systems, and technologies that enforce those policies. Kindervag’s concise version is: “You can’t buy Zero Trust — you do it.”

A five step implementation method

1. Define the protected surface

Start with the specific data, applications, assets or services that need protection, grouped in the source as DAAS. This narrows a sprawling security problem into a manageable set of high value resources. Teams can then direct their effort toward those resources instead of trying to secure every part of the environment equally.

2. Map transaction flows

Document how users and systems interact with the protected resources and how data moves between them. These flows expose dependencies and normal workflows. Without that view, security rules can block legitimate work or leave important paths uncontrolled. Mapping the flows also provides the information needed to plan micro-segmentation.

3. Design the environment around the flows

Build the Zero Trust architecture around the protected surface and the transactions it must support. Micro-segmentation is one tool for separating parts of an environment and controlling communication between them. The design should fit the organization’s own systems and dependencies rather than forcing them into a generic template.

4. Write precise access policies

Set the default to deny, then permit narrowly defined actions for authorized users and systems. Rules should specify which resources an identity can access and when that access is appropriate. This replaces broad permissions that can be abused with more limited instructions that reduce unnecessary exposure.

5. Monitor and refine

Zero Trust requires continuing observation and adjustment. Systems, users and business needs change, so policies that once matched normal activity can become outdated. Kindervag describes the work as ongoing monitoring and improvement: teams should use what they learn to update the environment over time.

Segmentation limits the damage

Micro-segmentation is meant to reduce how far an intruder can move after gaining access. If malware reaches one part of a segmented environment, controls can restrict its connections to other systems. Kindervag gives ransomware as an example: Zero Trust controls may block communication with command and control servers, while segmentation limits movement across the network.

“Even if malware gets into a Zero Trust environment, it’s contained,” he said. That is a claim about reducing impact, not guaranteeing containment in every deployment. The result depends on how well an organization has identified its protected resources, mapped their communications and configured its access rules.

AI, machine learning and faster response

Kindervag expects artificial intelligence and machine learning to help teams monitor Zero Trust environments and respond to threats more quickly. In his account, these systems can analyze telemetry from across an environment and feed useful signals back into security operations. That creates a feedback loop in which observations from real activity can inform later monitoring and policy decisions.

He describes the goal as “anti-fragile”: a system that learns from stress and improves through use. The analogy is exercise, where strain can lead to stronger muscles. Applied to security, the idea is that exposure to attempted attacks can produce better defenses if teams can identify what happened and adjust their controls. AI and machine learning could help process more activity than people can review by hand, though the source offers no benchmark for the resulting gains in accuracy or response time.

Automation is also central to Kindervag’s case for keeping pace with attackers. Attackers can try again without waiting for an organization’s internal approval process; defenders often face slower procedures. He argues that automated analysis and response can narrow that gap by finding patterns across large volumes of data and acting faster than a human analyst could alone. The practical value will depend on the quality of the data and the rules governing automated action.

For security teams, the actionable starting point is modest: choose a valuable resource, understand its legitimate transaction flows, then apply narrow access rules and monitor the results. Kindervag’s framework treats Zero Trust as an iterative operating model, with segmentation to limit reach and automation to help teams adapt as activity changes.