blog.rust.gay

Zero trust networking basics

2026-08-20 · security networking

Zero trust networking is a security model that treats network location as a weak signal, not proof of safety. Instead of assuming that users, devices, or workloads inside a corporate network can be trusted, a zero trust approach verifies access requests based on identity, context, and policy before granting access to a specific resource.

That shift matters because modern environments rarely fit the old castle-and-moat picture. Employees work remotely, contractors use their own devices, services run in public clouds, and applications depend on APIs spread across organizations. NIST Special Publication 800-207 describes zero trust as a set of cybersecurity paradigms that move defenses away from static, network-based perimeters and toward users, assets, and resources. The practical consequence is simple to state but hard to implement: do not grant implicit trust because something is “inside the network” or because an organization owns the device.

What zero trust means in practice

NIST SP 800-207 defines a zero trust architecture (ZTA) as an enterprise approach that uses zero trust principles to plan infrastructure and workflows. In that model, no implicit trust is granted to assets or user accounts based solely on physical or network location, such as a local area network versus the internet, or based on asset ownership. Authentication and authorization are treated as discrete decisions performed before a session to an enterprise resource is established.

This is narrower and more useful than the marketing slogan “never trust anything.” Zero trust does not mean that systems operate without trust; it means that trust is explicit, scoped, and evaluated for each access decision. A user who authenticated this morning may still be denied access this afternoon if their device posture changes, their role changes, the resource is sensitive, or the request looks unusual. The unit of protection is the resource — an application, API, dataset, workflow, or service — rather than the network segment alone.

NIST also frames zero trust as a response to common enterprise trends: remote users, bring your own device (BYOD), and cloud-based assets outside an enterprise-owned network boundary. When resources live in many places, the network edge stops being a reliable proxy for safety. A packet arriving from an internal IP range might come from a compromised laptop, a misconfigured service, or an attacker who has already moved laterally. Zero trust designs controls for that reality.

Why perimeter-only security breaks down

Traditional perimeter security assumes that traffic crossing a controlled boundary can be filtered, and that traffic already inside the boundary is comparatively safe. That model can still provide value — firewalls, VPN concentrators, and segmented networks are not useless — but it fails as a complete security strategy when the boundary is porous or ambiguous.

Several forces erode the perimeter. Cloud services place data and compute outside the organization’s physical network. Remote and hybrid work moves users outside corporate offices. Mobile devices and contractor laptops blur ownership boundaries. Service-to-service communication inside data centers or Kubernetes clusters creates large volumes of east-west traffic that never crosses an internet firewall. If an attacker compromises one internal system, a flat or loosely segmented internal network can make lateral movement easier.

Zero trust addresses these weaknesses by changing the question. Instead of asking, “Is this request coming from the trusted network?”, the system asks, “Should this subject, using this device or workload identity, under these conditions, access this specific resource right now?” The answer can depend on user identity, group membership, device health, location, time, risk signals, and the sensitivity of the resource. The important part is that access is not inherited automatically from network position.

Identity-centric controls

Identity is the control plane in most zero trust designs. In this context, identity is broader than a human username and password. It can include employees, administrators, contractors, service accounts, workloads, APIs, and devices. Each subject needs a way to be identified and authenticated, and each access request needs an authorization decision tied to policy.

For people, identity-centric controls usually involve a central identity provider, strong authentication, and group or attribute-based access rules. Multi-factor authentication (MFA) is commonly used because passwords alone are easy to phish, reuse, or steal. NIST’s model separates authentication and authorization from the network path: proving who you are is necessary, but it does not automatically grant access to every system.

For workloads and services, identity often comes from certificates, workload identities, signed tokens, or platform-issued credentials rather than shared secrets. This matters in service meshes, cloud platforms, and CI/CD systems where machines communicate at high volume. Treating workloads as first-class identities makes it possible to apply policy to service-to-service traffic, not just human logins.

Device identity and posture are also part of the picture. A known user on an unmanaged, unpatched device may deserve different access than the same user on a managed device that meets security requirements. Zero trust implementations often combine user identity with device signals, but they should be careful not to assume that device ownership equals trust. NIST explicitly notes that asset ownership alone is not a basis for implicit trust.

Least privilege as an operating discipline

Least privilege means granting only the access required to perform a task, for only as long as needed, and only to the resources involved. It is one of the most important zero trust concepts and one of the hardest to maintain.

The difficulty is operational, not philosophical. Teams often do not know exactly which permissions an application, script, or administrator role needs. Broad permissions are convenient during development and incident response, so they tend to accumulate. Over time, “temporary” access becomes permanent, service accounts collect rights across systems, and internal networks become places where compromise of one identity can unlock many resources.

A practical least-privilege program starts by making access decisions visible. Inventory critical applications, data stores, and administrative interfaces. Identify who and what can access them today. Remove access that is clearly unnecessary, then tighten policies around the highest-risk resources first: identity systems, source control, production infrastructure, secrets stores, and sensitive data. Where possible, prefer short-lived credentials and time-bound elevation over standing administrative access.

Least privilege also applies to network reachability. Even when identity checks are strong, limiting which systems can connect to which services reduces the blast radius of a compromise. This is where segmentation and service-level policy support the same goal: a subject should not be able to reach resources it has no business accessing.

Microsegmentation and limiting lateral movement

Microsegmentation is a technique for dividing environments into smaller zones or enforcing policy between workloads, applications, or services. The goal is not to create network diagrams for their own sake; it is to limit lateral movement. If an attacker gains access to one component, segmentation and policy controls can prevent that foothold from becoming broad access to unrelated systems.

In a zero trust framing, microsegmentation works best when paired with identity-aware policy. Network rules alone can say that service A may connect to service B on a specific port. Identity-aware controls can add context about which workload, user, or device is making the request and whether that access is appropriate. The exact mechanism varies — firewalls, cloud security groups, service mesh policies, application gateways, or host-based controls — but the concept is consistent: reduce implicit reachability.

Microsegmentation is not the same as zero trust, and buying a segmentation product does not automatically produce a zero trust architecture. Segmentation can exist in a perimeter-centric environment, and a poorly planned segmentation project can create brittle rules that teams work around. The useful question is whether segmentation decisions are tied to real application dependencies and enforced as part of a broader policy model that includes identity, authorization, and monitoring.

Continuous verification and policy decisions

Zero trust is often summarized as continuous verification. That phrase is easy to misunderstand. It does not usually mean asking a person to complete MFA every few seconds. It means that access decisions should consider current signals and that sessions should not be treated as permanently trusted after an initial login.

Continuous verification can include re-evaluating access when risk changes, expiring sessions, requiring step-up authentication for sensitive actions, checking device compliance, and monitoring behavior for signs of compromise. NIST emphasizes that authentication and authorization occur before a session to an enterprise resource is established; mature implementations extend that idea by making trust decisions dynamic rather than one-time events.

Logging and telemetry make this possible. If an organization cannot observe authentication events, device state, administrative actions, API calls, and resource access patterns, it cannot evaluate whether policies are working. Visibility is not a substitute for access control, but it is necessary for adjusting controls as systems and threats change.

What zero trust is and is not

Zero trust is an architecture and operating model, not a single product. A vendor may sell components that help — identity providers, MFA, endpoint management, secure access proxies, service mesh policy, logging pipelines — but no appliance turns an enterprise into a zero trust environment by itself. NIST describes ZTA as a way to plan infrastructure and workflows, which implies changes to process, inventory, and governance as well as technology.

Zero trust is also not a reason to remove every existing control. Firewalls, network segmentation, patching, backups, endpoint detection, and incident response still matter. The model changes how those controls are used: they should protect specific resources and support explicit policy decisions, rather than relying on a trusted interior network.

It is not a claim that breaches become impossible. A zero trust design aims to reduce implicit trust and limit the impact of compromise. Attackers can still phish users, exploit software, abuse valid credentials, or find policy gaps. The value of zero trust is that a successful initial compromise should be harder to turn into unrestricted access across the environment.

Finally, zero trust is not only for large enterprises with greenfield cloud systems. CISA’s Zero Trust Maturity Model is intended as a roadmap that agencies can reference while transitioning toward zero trust architecture. It describes maturity across five pillars and three cross-cutting capabilities, with examples ranging from traditional to optimal approaches. That framing is useful outside government too: organizations can make incremental progress by improving identity, devices, networks, applications, data controls, and visibility rather than waiting for a complete redesign.

Practical boundaries for implementation

A realistic zero trust program starts with scope. Pick a specific protect surface — a critical application, an administrative plane, a sensitive dataset, or a set of externally exposed services — and map the subjects, devices, workflows, and dependencies around it. Trying to “do zero trust” to an entire enterprise at once usually produces slogans instead of enforceable policy.

Next, establish authoritative identity and asset information. Policies are only as good as the inventory behind them. If you do not know which services exist, who owns them, which accounts can administer them, and where sensitive data lives, access decisions will be based on guesses.

Then apply controls in layers. Strengthen authentication for users and administrators. Reduce standing privileges. Limit network paths to sensitive services. Make service-to-service access explicit where feasible. Collect logs that show whether policies are being followed. Each step should make implicit trust more visible and replace it with a deliberate rule.

Expect trade-offs. Stricter controls can break legacy workflows, slow incident response, or create administrative overhead. The answer is not to abandon the model, but to design exceptions narrowly, review them regularly, and prefer compensating controls over silent trust. Zero trust works when it is treated as an engineering and governance practice: define the resource, verify the subject, enforce least privilege, observe the result, and adjust.

Conclusion

Zero trust networking basics come down to a change in assumptions. Network location, device ownership, and previous access are signals, not guarantees. NIST SP 800-207 captures the core idea by focusing protection on users, assets, and resources, requiring authentication and authorization before access to an enterprise resource is established, and avoiding implicit trust based on where a request originates.

For practitioners, the useful path is incremental. Start with identity, inventory, and the systems that would hurt most if compromised. Apply least privilege, narrow reachability, and continuous policy evaluation where they reduce real risk. Use maturity models such as CISA’s as planning guides, not compliance theater. The result is not a network with no trust, but a system where trust is earned, limited, and revisited.

Sources

← back to posts