Zero Trust Architecture Based on NIST SP 800-207
By M. Crawley
Zero Trust becomes much clearer when you see it as a mindset instead of a product.
Hearing the term Zero Trust can easily compel you to initially believe that it may be some impossible concept to apply. You may think, how can we build systems and applications that trust nothing, how could this be applicable in a real world sense. Well, I can tell you it’s not that intense. Especially, after working on my Zero Trust gap analysis and reading NIST Special Publication 800-207 as a guide. I learned this principle is less about not about not trusting anything and more about not trusting by default.
What Zero Trust Actually Means
In a traditional network environment, security is focused intensely on keeping threats out and once traffic gets past the perimeter there is almost an explicit level of trust attached. In practice, that takes the shape of authenticated users being able to roam freely because the assumption was simple: if they got through the front door, they must belong here.
But that logic falls apart pretty quickly when you think about it. If an attacker were to compromise an internal system that means they’re now "inside". Does that mean they belong there? Of course not. What about someone who phishes an employee and steals their credentials? They've got valid authentication now, so by that same logic, they're entitled to everything that employee can access.
Zero trust challenges this way of thinking and applying security. The fundamental principle is really simple. It emphasizes explicit verification of all systems, applications, and users before granting access, regardless of where the request comes from. Being on the internal network doesn't mean anything, and having a corporate device most definitely doesn’t warrant automatic access. Every access request is evaluated against several criteria before being approved.
Why NIST SP 800-207 Matters Here
The NIST released Special Publication 800-207 to provide organizations with a guideline for implementing zero trust architecture.
It gives a clear understanding of what zero trust architecture is and how it looks in an operational sense. It focuses on the actual components needed, how they should interact, and the principles that should guide implementation decisions. With this publication, organizations have a reference point by which they can evaluate whether their zero trust implementation follows best practices which result in best security application.
Many vendors claim their products enable zero trust, but NIST 800-207 lets you verify whether those claims hold up against a standardized definition.
Core Principles from the Document
NIST describes several foundational principles that define zero trust architecture to help companies decide how to integrate it into their environment.
All data sources and computing services, such as database servers, applications, and file shares, are considered resources that need protection. There are no tiers where some systems are trusted and others need scrutiny because zero trust treats all systems equally.
Any and all communication needs to be secured regardless of network location. This is the big change from traditional perimeter security. For example, the traffic between two internal servers should receive the same level of inquiry as traffic from external sources because the network location no longer serves as a security boundary.
Access to individual resources is granted on a per session basis. Permanent access to resources becomes a thing of the past here and is non-existent in a zero trust environment. Every time an access request is made, it is evaluated against specific conditions. Using a session-based approach such as this one means you can revoke access dynamically as conditions change.
Access to resources is determined by a policy which considers multiple factors, such as who's requesting access, what device they're using, where they're connecting from, what they're trying to access, what time it is, and what the current threat level looks like.
The company should use security tools that monitor and measure the security posture of all owned and associated devices. You can't make good access decisions without knowing whether the requesting device is actually secure, so it is necessary to query whether it is patched, running the appropriate security software, and/or showing signs of compromise. The answers to these questions feed into access decisions.
How Zero Trust Architecture Actually Works
Let's walk through what happens when someone tries to access a resource in a zero trust environment. Say an employee needs to access a customer database to pull a report.
The request first goes to the Policy Enforcement Point (PEP) which is like the gatekeeper standing between a user and the target resource. The PEP isn’t the decision maker here, instead it asks the Policy Engine (PE) whether this request should be allowed.
The Policy Engine checks the request against configured policies. It checks for the identity of the user, what groups are they in, what device they're using and its compliance status, the user's role access, and a much wider array of questions.
All of these factors get evaluated against policies that define acceptable combinations for access. Maybe one policy says database access requires a user to be authenticated, connecting from a managed device with the latest patches, having successfully completed MFA in the last hour, and connecting from an approved geographic location.
If the Policy Engine approves the request, it tells the Policy Administrator to configure access. The Policy Administrator doesn't make decisions, it just implements the ones made by the Policy Engine. It might establish a temporary connection, configure firewall rules, issue a short-lived token, or whatever the implementation requires.
What This Looks Like in Practice
Here's a scenario that explains how this would play out in the real world. Let’s say an employee's laptop gets infected with malware. In a traditional environment, that malware could start scanning the internal network and trying to access different endpoints because just being on the internal network gives it a starting point.
In a zero trust environment, the compromised device starts failing security posture checks, so when it tries to access resources, the Policy Engine sees that the device is showing signs of compromise and failing integrity checks. Access is automatically denied on these grounds.
Or imagine a contractor who needs temporary access to certain project files. In traditional setups, you might give them VPN access and network permissions for the time of their contract and that results in them being "inside" the network.
With zero trust and the principle of least privilege, you grant access to exactly what they need and nothing else. Their access gets evaluated per session, and when their contract ends, you don't have to worry about staff forgetting to remove all their permissions because as a fail safe in the zero trust environment, their identity just stops passing policy evaluation.
