Go to any major security vendor's website today. Palo Alto Networks. CrowdStrike. Zscaler. Okta. Microsoft. Cisco. Every single one of them will tell you they sell Zero Trust. Some of them have entire product lines organized around the label. They have Zero Trust platforms, Zero Trust architectures, Zero Trust bundles. The category has its own analyst quadrant, its own conference track, its own procurement checklist.
That fact alone should tell you something is deeply wrong with how Zero Trust is being marketed, and more dangerously, how it is being bought.
Zero Trust is not a product. It has never been a product. It is a design philosophy, an architectural stance, a set of principles for how an enterprise should think about trust in a world where the network perimeter no longer exists as a meaningful security boundary. You cannot buy it. You can only build it. And the organizations that confuse the two are spending significant security budgets on technology that makes their slide decks look better without materially reducing their risk.
Every enterprise that bought a "Zero Trust solution" without first doing the architecture work has paid for the label, not the outcome.
Where Zero Trust Came From and What It Actually Means
The Zero Trust model emerged from a 2010 paper by John Kindervag at Forrester Research, built on a simple and devastating observation about the dominant security architecture of the time: enterprises were building hard shells around soft interiors. Strong perimeter defenses, weak internal controls. The implicit assumption was that anything inside the network could be trusted. The threat actors figured this out and spent the next two decades exploiting it.
The principle Kindervag proposed was stark: never trust, always verify. Every user, device, application, and network flow must be authenticated and authorized, regardless of where it originates. Inside the network or outside it. On a corporate device or a personal one. From a known IP address or an unknown one. The perimeter is not the boundary of trust. Identity and context are.
Google operationalized this philosophy at scale with BeyondCorp, their internal Zero Trust implementation, which they began deploying in 2011 and published about extensively. The BeyondCorp papers are the closest thing to a practical reference architecture that Zero Trust has, and they are worth reading before any CIO signs a Zero Trust software contract. The core insight from BeyondCorp is that Zero Trust is not primarily a technology problem. It is an identity problem, a data classification problem, a network segmentation problem, and a policy enforcement problem. Solving those problems requires technology. But the technology is downstream of the architecture decisions, not the other way around.
Why the Product-First Approach Fails
The seductive thing about buying a Zero Trust product is that it feels like progress. A vendor demonstrates the platform. The demo is impressive. The contract gets signed. The technology gets deployed. The CISO presents the board with a slide: "We have implemented Zero Trust." And technically, they have done something. They have deployed a tool. What they have not done is change the architecture.
Here is what a product-first Zero Trust deployment typically looks like in practice. An enterprise buys a Software-Defined Perimeter or Secure Access Service Edge solution. They route remote access through it. They configure some conditional access policies in their identity provider. They retire the VPN. They call this Zero Trust. What they actually have is better remote access security, which is valuable, but it addresses one surface of the Zero Trust model while leaving the interior of the enterprise largely unchanged. Lateral movement by an attacker who achieves initial access is still possible. Implicit trust between internal applications still exists. Data classification is still not driving access policy. The hard shell has been replaced with a slightly better hard shell.
Real Zero Trust architecture is uncomfortable because it requires answering questions that most enterprises have been avoiding for years. What data do we have, where does it live, and who actually needs access to it? Which applications should be able to talk to which other applications, and why? Where are the trust relationships in our environment that we have never explicitly designed but are simply relying on? How do we verify that a device is in an acceptable security state before granting it access to sensitive systems, and what happens when it's not?
These are not questions that any product answers. They are questions that architecture answers. The product enforces the answer. But you have to arrive at the answer first.
The Five Architecture Decisions That Actually Define Zero Trust
If you want to build a Zero Trust architecture rather than buy a Zero Trust product, the work begins with five foundational decisions. These decisions are not one-time events. They are ongoing architectural commitments that require governance, tooling, and organizational discipline to maintain.
Decision 1: Identity is your new perimeter. This means making a genuine organizational commitment to strong identity verification for every user and service account, on every access attempt, regardless of network location. It means multi-factor authentication that is actually resistant to phishing, not just SMS-based 2FA that threat actors bypass routinely. It means privileged access management with session recording and just-in-time provisioning. It means service account governance: knowing what every non-human identity in your environment can access and why. Most enterprises claim to have strong identity posture. Most enterprises have significant gaps in it that they discover only after a breach. Identity architecture is foundational and non-negotiable. Everything else in Zero Trust rests on it.
Decision 2: Least privilege is not a policy. It is a process. Least privilege means every user, application, and service has access to exactly what it needs to perform its function and nothing more. In theory, every enterprise claims to operate this way. In practice, access accumulation over time is the norm. Employees change roles and retain old permissions. Applications are granted broad access because it's easier than figuring out the minimum required. Service accounts carry permissions that made sense for a project that ended three years ago. Zero Trust architecture requires a continuous process of access right-sizing: regular access reviews, automated detection of excessive privilege, and a provisioning workflow that makes granting minimal access the path of least resistance rather than the burdensome exception.
Decision 3: Microsegmentation is not just a network problem. Traditional network segmentation put different types of systems on different VLANs and called it a day. Microsegmentation in a Zero Trust architecture means defining precise, policy-driven access controls between individual workloads, applications, and services, regardless of whether they share a network segment. This requires knowing your application interdependencies with a level of precision that most organizations lack. CMDB quality, again, is foundational. You cannot write a segmentation policy for an application relationship you didn't know existed. Microsegmentation is operationally demanding to implement and maintain. It is also the control that most reliably stops lateral movement once an attacker achieves initial access. The difficulty of doing it right is exactly the reason most organizations skip it in favor of buying a product instead.
Decision 4: Data classification drives access policy. In a Zero Trust model, access decisions should be informed by the sensitivity of the data being accessed, not just the identity of the person requesting access. A user with valid credentials and a healthy device should still not have access to a dataset they have no business need to see. This requires knowing what data you have, where it lives, how sensitive it is, and who legitimately needs it. Data classification is one of the most underinvested areas in enterprise security, and one of the most consequential gaps in Zero Trust implementations. You cannot build data-aware access policy without data awareness. This is not a technology problem. It is a governance and classification discipline problem that technology can then enforce.
Decision 5: Continuous verification, not point-in-time authentication. Zero Trust architecture treats authentication as an ongoing assessment, not a gate you pass once. Device health should be evaluated continuously, not just at login. Behavioral anomalies should trigger step-up authentication or session termination. Risk signals from endpoint detection, identity analytics, and threat intelligence should feed access policy in real time. This requires an architecture that connects your identity platform, your endpoint management, your SIEM, and your access enforcement points into a coherent policy engine. Buying those products individually and expecting them to produce Zero Trust outcomes without the integration architecture to connect them is the most common and most expensive mistake enterprises make in this space.
Where ServiceNow Fits in the Zero Trust Architecture
For enterprises running ServiceNow, the platform plays a specific and underappreciated role in Zero Trust architecture. It is not a Zero Trust enforcement technology. But it is the governance and orchestration layer that makes Zero Trust architectures operationally sustainable.
Consider what Zero Trust requires operationally: continuous access reviews, privileged access request and approval workflows, incident response for access anomalies, CMDB-driven microsegmentation policy, vulnerability management feeding risk-based access decisions, and GRC compliance tracking against Zero Trust controls. These are all workflow and governance problems. They are exactly what ServiceNow was designed to manage at scale.
The enterprises that are building genuinely mature Zero Trust architectures are using ServiceNow's SecOps and GRC capabilities to govern the human workflows that sit around their Zero Trust enforcement technologies. Access certification campaigns. Privileged access request automation. Vulnerability-to-access risk correlation. Compliance evidence collection. The enforcement technology does the blocking and allowing. ServiceNow makes sure the right people are making the right decisions about what the enforcement technology should be configured to do.
Zero Trust without governance is just faster enforcement of the wrong policies. The governance layer is what turns Zero Trust from a technology deployment into an organizational capability.
A Practical Starting Point for Organizations That Haven't
If your organization is still in the early stages of Zero Trust, the right starting point is not a product evaluation. It is an architecture assessment. Before you evaluate any technology, you need to answer five questions about your current state.
First: what is the current state of your identity infrastructure? Do you have full MFA coverage across all users and all applications? Do you have a privileged access management solution governing administrative access? Do you have visibility into all service accounts and their permissions? The answers to these questions define your identity attack surface.
Second: do you have a CMDB that accurately reflects your environment? Can you identify the relationships between your applications and the data they access? Zero Trust architecture is only as good as the data it reasons from.
Third: where are the implicit trust relationships in your environment? Which applications talk to which other applications with no authentication between them? Which network segments have unrestricted lateral movement between hosts? Mapping these is not glamorous work. It is also the work that prevents breaches.
Fourth: what is your data classification posture? Do you know where your most sensitive data lives? Do your access policies reflect the sensitivity of what is being accessed, or only the identity of who is requesting access?
Fifth: how are you operationalizing Zero Trust governance? Who owns access reviews? What is the process for exception management? How does a vulnerability discovery translate into an access policy change? The governance model is what determines whether your Zero Trust architecture stays current or drifts back toward implicit trust over time.
Answer these five questions honestly before you buy anything. The answers will tell you which gaps are most urgent and, consequently, which technologies will actually reduce your risk rather than simply expanding your security vendor portfolio.
The Honest Conversation
Zero Trust is hard. Not because the technology is inaccessible, but because it requires an enterprise to confront the accumulated technical debt, governance gaps, and operational shortcuts of years of security decision-making under resource pressure. The vendors selling Zero Trust products are not lying when they say their technology supports Zero Trust architecture. They are just making it easy to buy the component without doing the architectural work that determines whether the component actually reduces risk.
The CISOs and CIOs who are building genuine Zero Trust capabilities are the ones willing to do that architectural work first. They are the ones asking hard questions about their own environment before they open a request for proposal. They are the ones treating Zero Trust as a multi-year architectural program, not a quarterly procurement decision. They are, not coincidentally, also the ones whose security posture is measurably improving rather than just becoming more expensive.
The perimeter is gone. The trust model that assumed otherwise is a liability. What replaces it is not a product. It is a decision to think about your architecture differently. Make the decision first. Then buy the tools that help you execute it.
Nya Akoma. Take Heart.