Zero Trust is a concept mentioned in almost every security presentation today. However, when we look at its implementation in the field, we often see it applied in the wrong place, with wrong expectations, and using the wrong tools. The main reason for this is that Zero Trust is positioned as a technology or a purchasable product. In reality, Zero Trust is not a licensed, boxed, or vendor-specific solution. It is an architectural perspective and, more importantly, a mindset.

The essence of Zero Trust is clear: Never trust, always verify. Do not implicitly trust any user, any device, or any connection. Trust is a state that must be continuously re-earned. This approach completely eliminates the classic “inside is safe, outside is dangerous” assumption. Because in the modern IT world, inside and outside are no longer separated by clear boundaries.

In summary:

• Zero Trust is an architectural approach, not a product
• It rejects the concept of implicit trust
• It is based on continuous verification

This article is part of a series that treats IT infrastructure as a system. For the starting point: IT Infrastructure Is Not a Collection of Products

Zero Trust Belongs to No Vendor

Zero Trust began taking shape through the visions of security vendors. However, an important distinction must be made: Zero Trust is not a concept “owned” by any vendor. It cannot be represented by a single technology.

The reason is this: Zero Trust requires multiple layers to work together consistently and simultaneously. If network, security, identity, user, device, and application layers operate in silos, Zero Trust remains only a narrative. It has no architectural counterpart.

Key points:

• Zero Trust does not belong to any vendor
• It cannot be built with a single technology
• Cross-layer consistency is required

User and Device Verification: Where the Architecture Begins

Zero Trust architecture starts with a fundamental question:

“Should this user and this device actually have access to the resource they are trying to reach right now?”

To provide a meaningful answer, the first step is verifying the users and devices joining the network. Active Directory, LDAP, or modern identity providers sit at the center of this structure. What resources a user can access is determined not only by their identity but also by their role and risk posture.

But from a Zero Trust perspective, it is not only about who the user is — the device’s status, whether it belongs to the corporate inventory, and its compliance with security policies are all part of this decision.

Key takeaways:

• User verification alone is not sufficient
• Device identity and posture are also evaluated
• Access decisions are context-driven

VPN ≠ Zero Trust: The Right Framework for Remote Access

Remote work is no longer the exception — it is the standard. Yet many organizations still operate with classic VPN logic: the user connects to VPN and instantly becomes part of the entire local network. This is not Zero Trust. This is simply remote access.

In a Zero Trust architecture, remote access does not mean “access to everything.” The user only accesses the applications or resources they are authorized for. The goal is always the same: minimize access and continuously verify it.

Key points:

• VPN ≠ Zero Trust
• Access should be to the resource, not the entire network
• Authorization is continuously verified

Continuous Verification and MFA

What distinguishes Zero Trust from classic security approaches is that authentication is not treated as a one-time event. As user and device behavior changes, access is continuously re-evaluated.

This is where Multi-Factor Authentication (MFA) comes in. Additional layers such as SMS, mobile app notifications, hardware tokens, or biometric verification are used. Especially for critical applications like mail servers, financial systems, or ERP, users are required to re-verify themselves at regular intervals.

In summary:

• Verification is continuous
• MFA is a core component of Zero Trust
• Intervals are shortened for critical resources

Firewall: The Policy Decision Point

The firewall layer plays a central role in Zero Trust architecture. But this role goes far beyond the classic “device that controls internet egress.” In the Zero Trust approach, the firewall is a decision point with identity and context awareness.

Rules defined on the firewall should not be based solely on IP or port. When user-, group-, and application-based rules can be written, Zero Trust becomes truly implementable.

To understand how switches, firewalls, and APs work together: Switch, Firewall, AP — Why Choosing the Right Products Is Not Enough

This layer in summary:

• Firewall is the policy decision point
• Identity and application awareness are essential
• Port-based rules are not sufficient

The Access Layer: Where Zero Trust Starts

Zero Trust is not only applied at the firewall and VPN layers. The access layer is where the architecture begins. 802.1X and NAC solutions come into play here. All switch ports and wireless access are controlled by a central system. Users or devices are verified before joining the network, and based on this verification, VLANs are dynamically assigned or policies are applied.

Key points:

• Zero Trust starts at the access layer
• 802.1X provides centralized control
• Static VLAN / SSID structures do not scale

Device Profiling and IoT

In modern Zero Trust architectures, not only user devices but all endpoints connecting to the network are brought under control. Printers, cameras, IP phones, card readers — all are included in the verification process.

Next-generation NAC solutions combine multiple parameters such as DHCP fingerprint, CDP/LLDP information, and device manufacturer data to perform device profiling. Whether the device is up to date, its security posture, and compliance with corporate standards are all evaluated.

Key points:

• Device profiling is critically important
• MAC address alone is not sufficient
• Inventory integration is essential

Guest Access: Trust Is Never Assumed

Even guest access is controlled in Zero Trust architecture. Guest users are verified through guest portals and are granted access only for a specific duration and with specific permissions. Guests can typically only access the internet; their access to company resources is restricted.

In summary:

• Guest access is not unlimited
• Time- and permission-based controls are applied
• Trust is never assumed

Continuous Monitoring: The Most Critical Part of the Architecture

Access and behavior are monitored and logged at every layer. If an anomaly or risky activity is detected, the system automatically restricts access or requests additional verification.

For building real visibility into your infrastructure: The Monitoring Mindset: Not Just Seeing, But Understanding and Acting Proactively

Conclusion

Zero Trust is not a product. It cannot be built with a single device. You cannot say “we implemented it, we’re done.”

Zero Trust is a living architecture in which firewall, switch, and wireless infrastructure work together by drawing user and device information from a central point, with access being re-questioned at every stage. That is why Zero Trust should be seen not as a technology to be purchased, but as a capability to be designed and operated.

Note

This article was originally introduced on Substack in a shorter, narrative form. This version expands the architectural foundation for the series.

👉 Read the article on Substack: Click Here

Related Articles

Architecture & Security Design

• 📐 IT Infrastructure Is Not a Collection of Products — The foundational article of this series
• 🏗️ Switch, Firewall, AP — Why Choosing the Right Products Is Not Enough — Systems thinking in core network design
• 📊 The Monitoring Mindset: Not Just Seeing, But Understanding and Acting Proactively — Building real visibility into your infrastructure

Technical Engineering

• 🔐 Unlocking Success in 802.1X Projects: Field Insights — Identity-based access in enterprise networks
• 🛡️ Network Packet Broker (NPB) Masterclass — Advanced traffic visibility and security strategy
• 🛠️ The Backdoor of the Network: Next-Gen Console Server Architecture — Out-of-band access when everything else fails

Why real infrastructure design starts with systems, not tools

This article serves as the architectural foundation of the series. Before we talk about switches, firewalls, wireless, Zero Trust, or 802.1X, we need to be clear about one thing:

IT infrastructure is not the sum of the products you purchase. It is the result of how systems behave together under pressure.

Where most infrastructure projects really fail

Most infrastructure initiatives begin with good intentions. A refresh is planned, a budget is approved, and the discussion quickly turns into product comparisons. Vendors are evaluated, feature lists are compared, and datasheets are studied in detail.

Yet many of these projects fail in practice—not because the chosen products are bad, but because the infrastructure never becomes a system.

What I have seen repeatedly over the years is this pattern: Each component works perfectly on its own, but the overall behavior of the environment is unpredictable. Identity is handled in one place, segmentation in another, policy enforcement somewhere else, and operations are stitched together manually. When something breaks, no single layer has the full context.

The infrastructure exists. But infrastructure behavior does not.

Products solve problems. Systems sustain operations.

A product is designed to solve a specific problem. An infrastructure is designed to sustain an organization.

This distinction is subtle but critical. Products can be replaced. Systems must evolve.

When infrastructure is built as a collection of tools, decisions are optimized locally. Each team chooses what works best for its own domain. Over time, these local optimizations accumulate into global complexity. Integration becomes fragile, troubleshooting becomes slow, and every change carries risk.

A system-oriented design works differently. It starts by asking fundamental questions:

• Where does identity originate, and how far does it travel?
• Where are trust boundaries defined?
• Which components make policy decisions, and which merely enforce them?
• How is context preserved across layers?
• What happens operationally when something fails?

Without clear answers to these questions, even the best products will eventually work against each other.

For a deep dive into how identity and trust boundaries are defined in practice, see: The Zero Trust Mindset: Engineering Security as an Architecture, Not a Product

Architecture reveals itself under stress

Infrastructure design is easy when everything works. Architecture only reveals itself when something goes wrong.

Incidents, scale events, security breaches, and operational changes expose design assumptions that were never written down. In environments built from loosely connected products, these moments turn into firefighting exercises. Temporary fixes become permanent exceptions. Over time, the infrastructure loses coherence.

Well-designed systems behave differently. They degrade gracefully. Responsibilities are clear. Failures are contained. Recovery paths are understood in advance. This is not accidental—it is the result of deliberate architectural choices.

Integration is not a feature

One of the most common misconceptions in infrastructure design is treating integration as a checkbox. Products are assumed to integrate because they support the same standards or come from the same vendor.

Real integration is not about compatibility. It is about shared context.

Identity-aware enforcement, consistent segmentation, unified logging, predictable policy behavior—these are not guaranteed by buying “integrated” products. They must be designed, tested, and operated as part of a system.

Without this, integration exists only on slides.

Operations define the real architecture

The true architecture of an environment is not found in diagrams. It is found in operational workflows.

• How are changes deployed?
• How are incidents diagnosed?
• How are exceptions handled?
• How is automation introduced?
• How are responsibilities divided across teams?

If these workflows are manual, fragmented, or undocumented, the infrastructure will reflect that reality—regardless of how modern the technology stack appears.

This is why automation, observability, and lifecycle management are not optional extras. They are architectural elements. Infrastructure that cannot be operated consistently will never scale safely.

For a practical framework on building real observability into your infrastructure, see: The Monitoring Mindset: Not Just Seeing, But Understanding and Acting Proactively

Why this matters before we talk about networking

Networking is often where these problems become visible first. Traffic flows expose broken trust models. Segmentation highlights missing identity. Performance issues reveal architectural shortcuts.

But networking is not the root cause. It is the mirror.

That is why this series starts here. Before diving into core network design, vendor strategies, Zero Trust, or 802.1X, we need a shared understanding: infrastructure must be treated as a system with intent, not a shopping list with budget.

The principle that guides the rest of this series

Every article that follows builds on a single principle:

Design the system first. Choose the products second.

When this order is reversed, infrastructure becomes expensive and fragile. When this order is respected, infrastructure becomes predictable and adaptable.

What comes next

The next article in this series applies this thinking directly to the core network:

• Why a core network is not a list of switches, firewalls, and access points
• How integration, capacity planning, and operational context define real network architecture

This first article exists to set the baseline. Everything else builds on top of it.

Note

This article was originally introduced on Substack in a shorter, narrative form. This version expands the architectural foundation for the series.

👉 Read the article on Substack: Click Here

Related Articles

If you found this article useful, you may also be interested in these:

Architecture & Security Design

• 🏗️ Switch, Firewall, AP — Why Choosing the Right Products Is Not Enough — Applying systems thinking to core network design
• 🛡️ The Zero Trust Mindset: Engineering Security as an Architecture, Not a Product — Why Zero Trust is a philosophy, not a product
• 📊 The Monitoring Mindset: Not Just Seeing, But Understanding and Acting Proactively — Building real visibility into your infrastructure

Technical Engineering

• 🛠️ The Backdoor of the Network: Next-Gen Console Server Architecture — Out-of-band access when everything else fails
• 🛡️ Network Packet Broker (NPB) Masterclass — Advanced traffic visibility and security strategy
• 🔐 Unlocking Success in 802.1X Projects: Field Insights — Identity-based access in enterprise networks