Zero trust was always about implicit trust, explains David Brown at FireMon; we just forgot where the term came from

There is a reasonable objection to the term "Zero Trust" that security professionals rarely say out loud – perhaps because the model is so widely accepted that questioning the name feels pedantic. But it is a fair one. Organisations implementing Zero Trust spend considerable effort building policies that define exactly when and how access is granted: based on identity, device state, business context, and verified intent. That is not the absence of trust.
The principles are sound, and proper implementation delivers real improvements in access control and risk posture. But the phrase always invites a reasonable question: if the first thing you do is define who and what you trust, what exactly is "zero" about it?
The answer, it turns out, is in the history.
When John Kindervag developed the Zero Trust model at Forrester Research, he was responding to a fundamental flaw in how organisations thought about access: the assumption that anything inside the network perimeter could be trusted by virtue of its location alone. The model he proposed – never trust, always verify – was a direct challenge to that assumption. But the logic it drew upon was not new.
Some early firewall architectures encoded trust as a numerical value. Each interface could be assigned a trust level on a scale from zero to one hundred: zero for the external, untrusted world; one hundred for the fully trusted internal network. The behaviour that followed from those assignments was precise: traffic moved freely from high-trust zones toward low-trust zones, but any request originating from a low-trust source required explicit authorisation to proceed. Without that authorisation, it was denied by default.
A trust level of zero did not mean "this traffic is forbidden." It meant "this traffic has no implicit permission and must earn its access explicitly." The burden of proof sat entirely with the request, not with the rule that might block it.
Zero Trust, in its original conception, applies that same logic universally. Every access request – regardless of where it originates in the network – is treated as though it comes from a low-trust source. Network location confers nothing. A system sitting inside the corporate perimeter holds no advantage over one outside it. Access must be granted on the basis of what a request actually is: its identity, its verified state, its legitimate business purpose.
So, Zero Trust is not about eliminating trust at all. It is about eliminating the implicit kind: the trust that was historically extended by default to anything that happened to be on the right side of a firewall. The model demands that trust is explicit, documented, and continuously validated.
The practical implication of this reframing is significant, and it is one that many Zero Trust programmes have not fully absorbed.
Zero Trust operates across identity verification, device posture, application access, and data protection. Network policy is the enforcement layer that runs beneath all of it, determining what is permitted to flow between which systems and under what conditions.
If the model’s defining characteristic is the removal of implicit trust, then its success is measured not by the capabilities of the enforcement technologies deployed across a system, but by the quality of the policies those technologies enforce.
Consider what explicit access actually requires. It requires that every permitted connection between systems – every allowed flow between a workload and a resource, every approved path through a micro-segmented environment – must reflect a deliberate decision: this identity, in this state, serving this business purpose, may access this resource. Not a legacy rule that has survived through inertia or an exception approved during an incident and never revisited. A considered, current, intentional authorisation.
Most large enterprises inherit a policy estate that falls well short of that standard. Firewall rules accumulate over years, often written to quickly solve specific problems and then left in place indefinitely. Access policies approved for one system configuration remain in place after that configuration has changed. Permissions granted during a project extend beyond the project’s end. The result is an estate in which the implicit trust that Zero Trust is meant to eliminate has not been removed at all; instead, it has simply been encoded into policies that predate the programme and continue to function alongside it.
This is a structural problem that enforcement technology alone cannot resolve. Micro-segmentation enforces boundaries accurately and deliberately and, where implemented well, delivers exactly what Zero Trust requires at the workload level. Policy governance is what ensures the broader environment remains coherent with the same objectives – identifying where accumulated rules contradict current intent and maintaining the alignment that no single enforcement technology can sustain across the full estate on its own.
Returning to the original firewall analogy is instructive here. The trust-level model worked because the rules governing access from low-trust sources were explicit and accountable. Someone had to define what was permitted. That definition was documented. It could be reviewed. When it was wrong, it could be corrected.
What erodes Zero Trust implementations is the loss of that accountability across the policy estate as a whole. The policy surface – the full set of rules, entitlements, and access grants that together determine what an organisation actually permits – grows in ways that are rarely visible from any single vantage point. Individual policies may be correct, but their aggregate effect may be something quite different.
Treating policy governance as a continuous discipline rather than a project milestone is what separates organisations that realise the model’s promise from those that implement the framework without achieving its intent. That means maintaining an accurate, consolidated understanding of the access state across legacy infrastructure, cloud environments, and micro-segmented workloads together, not in isolation. It means establishing the capacity to identify drift between the access model as designed and the policies as they stand. And it means being able to validate, credibly and continuously, that what every enforcement layer permits genuinely reflects the access model the organisation intends to operate.
Network Security Policy Management (NSPM) provides the foundation for that governance work. It gives organisations a consolidated view of their full policy estate – from firewall infrastructure to cloud-native controls and micro-segmentation boundaries – so that policy intent can be governed consistently across every enforcement layer. Where what is permitted diverges from what the access model requires, NSPM creates the basis for correction. The technology of enforcement and the discipline of policy governance are not separate investments; they are the same programme.
Zero Trust, correctly read, sets a demanding standard: no access without explicit justification, no permission that cannot be accounted for, no trust that has not been earned.
That standard did not originate with a modern security framework. It was present at the zero end of a trust scale on a firewall interface decades ago – the point at which nothing was assumed, and everything had to be earned. Kindervag’s insight was to recognise that the same discipline needed to apply everywhere, not just at the perimeter.
So, the question for today’s security leaders is does your organisation’s policy estate actually meet this standard? Not whether Zero Trust principles are on the roadmap. Not whether the right enforcement technologies are deployed. But are the policies that these technologies enforce genuinely explicit, current, and coherent with the model’s founding intent?
That is the standard Zero Trust has always set. And it is a policy question before it is anything else.
David Brown is SVP International Business at FireMon
Main image courtesy of iStockPhoto.com and narvo vexar
© 2025, Lyonsdown Limited. teiss® is a registered trademark of Lyonsdown Ltd. VAT registration number: 830519543