Zero Trust Is a Security Model, Not a Product Purchase
The discussion in Communications of the ACM about the pros and cons of Zero Trust arrives at a useful moment. Zero Trust has become a default term in cybersecurity procurement, board presentations, government guidance, and vendor marketing. Yet its popularity has also created a problem: many organizations treat it as a technology category they can buy rather than an operating model they must design, govern, and continuously improve.
The core premise is straightforward: no user, device, workload, application, or network location should receive implicit trust. Access should be explicitly verified, constrained to the minimum necessary privilege, and continuously reassessed using contextual signals. Those signals can include identity assurance, device health, session risk, location, application sensitivity, behavior, and the classification of the data being requested.
That premise is compelling because traditional perimeter security no longer matches how most organizations work. Employees connect from unmanaged networks, applications run across SaaS and cloud platforms, APIs expose business processes, and machine identities now outnumber human identities in many environments. But the value of Zero Trust depends less on adopting the label and more on making disciplined architectural and operational decisions.
The Strongest Case for Zero Trust
It limits the blast radius of compromised credentials
Credential theft remains one of the most practical paths into enterprise systems. A phishing-resistant MFA deployment can reduce account takeover risk, but it cannot guarantee that every authenticated session is legitimate. Attackers may hijack browser sessions, abuse OAuth consent, exploit overprivileged service accounts, or operate through a valid identity after a successful social-engineering attack.
Zero Trust changes the question from “Did this user authenticate?” to “Should this specific identity access this specific resource, from this device, under these conditions, right now?” That distinction matters. A marketing employee who authenticates legitimately should not automatically be able to reach source-code repositories, payroll systems, production cloud consoles, or sensitive customer records.
By enforcing least privilege and segmenting access around individual applications and resources, organizations reduce lateral movement. A compromised laptop or account can still create damage, but it should not become a master key to the environment.
It better fits hybrid work and cloud architectures
VPN-centered access models were designed for a different operating reality. Once connected to a corporate network, users often receive broad network-level reachability. This may be convenient, but it expands the attack surface and makes internal discovery easier for an intruder.
Zero Trust Network Access (ZTNA) can provide application-specific connectivity instead. Rather than placing a user “on the network,” it brokers access to approved applications after evaluating policy. This approach is particularly valuable for remote contractors, third-party support teams, distributed employees, and administrators who need controlled access to a narrow set of systems.
For cloud environments, the same logic applies to identity and workload access. A development workload should receive only the permissions it needs to retrieve a secret, call an API, or access a database. Broad, persistent cloud roles are operationally convenient but dangerous when tokens, keys, or service identities are compromised.
It can improve visibility and policy consistency
A mature Zero Trust program requires organizations to identify their assets, applications, identities, data flows, and authorization paths. That discovery work is often difficult, but it exposes risks that have remained hidden: dormant accounts, unmanaged devices, excessive permissions, legacy protocols, undocumented integrations, and systems without an accountable owner.
Centralizing access decisions can also make policy more consistent. For example, an organization can require phishing-resistant authentication for administrative actions, block access from noncompliant devices, and demand step-up verification before opening sensitive records. These controls can be applied based on risk rather than relying only on a network boundary that users and applications increasingly bypass.
The Cons: Why Zero Trust Programs Fail or Stall
Complexity is real, especially in legacy environments
Zero Trust is not a simple replacement for a VPN or firewall. It touches identity providers, MFA, endpoint management, network architecture, cloud permissions, application authorization, data classification, logging, incident response, and third-party access.
Legacy applications are a frequent obstacle. Some depend on flat networks, hard-coded service accounts, insecure protocols, or broad administrative privileges. Others cannot support modern authentication or granular authorization. Trying to impose a perfect Zero Trust design immediately can interrupt critical business processes.
The practical answer is not to abandon the model. It is to prioritize. An organization should begin with high-value applications, privileged users, externally exposed services, and data with regulatory or contractual sensitivity. Legacy systems can receive compensating controls—such as isolation, jump hosts, stronger monitoring, or strict vendor access windows—while a modernization plan is developed.
Friction can damage adoption if policies ignore workflows
Security teams sometimes interpret Zero Trust as a reason to challenge users constantly. Repeated MFA prompts, blocked sessions during travel, inaccessible applications, and unclear approval paths will drive employees toward workarounds. They may use personal email, consumer file-sharing services, unsanctioned SaaS tools, or shared accounts to get work done.
Good Zero Trust design should be risk-adaptive rather than uniformly restrictive. A managed device using a phishing-resistant authenticator to access a low-risk collaboration tool should have a smoother experience than an unmanaged device attempting to export sensitive data or administer production infrastructure.
User experience is therefore not a secondary concern. It is part of the security control. Measure authentication failures, help-desk tickets, access-request turnaround time, policy exceptions, and abandoned workflows. If a security policy causes widespread operational friction, investigate whether the policy is too broad, whether the identity data is incomplete, or whether application owners were excluded from the design process.
Vendor sprawl can undermine the strategy
Many vendors market Zero Trust capabilities: identity platforms, endpoint detection tools, SSE and SASE services, ZTNA products, microsegmentation platforms, cloud security tools, data security systems, and SIEM solutions. Each may add value, but buying multiple overlapping products without a target architecture can increase cost, create policy conflicts, and leave critical integrations unfinished.
Security leaders should define desired outcomes before choosing tools. Examples include reducing privileged standing access, eliminating VPN access for third parties, enforcing device compliance for sensitive applications, or rotating and governing machine credentials. Technology should support measurable outcomes, not become the outcome itself.
What a Practical Zero Trust Roadmap Looks Like
Start with identity and privileged access
Identity is usually the most effective starting point because it sits at the center of user and workload access. Inventory human accounts, service accounts, API keys, certificates, OAuth applications, and privileged roles. Remove inactive identities, eliminate shared administrator accounts where possible, and require MFA that resists phishing for administrators and high-risk users.
Then reduce standing privilege. Use just-in-time elevation, time-limited access, approval workflows where justified, and separate administrative identities from everyday productivity accounts. These steps deliver tangible risk reduction before an organization attempts sophisticated segmentation.
Map critical resources and access paths
Do not begin with every application. Identify the systems whose compromise would cause the greatest operational, financial, safety, or regulatory impact. For each one, document:
- The data it contains or processes.
- The users, devices, services, and vendors that require access.
- Current authentication and authorization methods.
- Dependencies on networks, APIs, secrets, and infrastructure.
- The business owner accountable for access decisions.
This map makes it possible to write policies that reflect real work rather than assumptions. It also reveals where access is broader than necessary.
Implement controls in incremental, measurable phases
A credible roadmap may begin by replacing broad remote access for a single application group with ZTNA, then expand to third-party access and privileged administration. In parallel, endpoint compliance rules can be introduced for high-risk resources, with clear remediation guidance for users.
Track outcomes such as the percentage of critical applications protected by MFA and conditional access, the number of privileged accounts with standing access, time to revoke vendor access, number of exposed services, and unauthorized lateral-movement paths found during testing. These metrics turn Zero Trust from a slogan into a risk-management program.
The Bottom Line for Security Leaders
The principal benefit of Zero Trust is not that it prevents every breach. No architecture can make that promise. Its value is that it assumes compromise is possible and makes unauthorized expansion harder, more detectable, and less damaging.
The trade-off is that Zero Trust requires sustained work across technology, governance, and business processes. Organizations that frame it as a one-time deployment will likely accumulate tools without achieving meaningful reduction in risk. Those that begin with identity, privileged access, high-value resources, and practical policy enforcement can steadily strengthen resilience without disrupting the business.
FAQ
Is Zero Trust the same as MFA?
No. MFA is an important identity verification control, but Zero Trust is a broader security approach. It also includes least privilege, device posture checks, resource-level authorization, segmentation, continuous monitoring, and access reassessment based on risk.
Does Zero Trust eliminate the need for firewalls and VPNs?
No. Firewalls, secure remote connectivity, endpoint security, and network controls still have roles. Zero Trust changes how they are used by reducing implicit trust and focusing access policy on identities, devices, and specific resources. In many cases, ZTNA can reduce dependence on broad VPN access, but a transition should be carefully planned.
What is the best first Zero Trust project?
For most organizations, start with identity security: phishing-resistant MFA for privileged users, an inventory of accounts and service identities, removal of dormant access, and reduction of standing administrative privileges. These initiatives are measurable and often reduce risk quickly.
How can a smaller organization adopt Zero Trust without a large budget?
Focus on fundamentals before buying a broad platform. Use a central identity provider, enforce MFA, maintain accurate device inventory, apply least-privilege roles, restrict administrator access, patch endpoints, and remove unnecessary external exposure. Expand toward application-specific access and stronger monitoring as resources permit.
Fuente: cacm.acm.org — Wed, 10 Sep 2025 07:00:00 GMT
