NIST SP 800-207 defines what zero trust architecture should look like. Here is how TAC implements every tenet — and why most tools only implement some of them.
NIST Special Publication 800-207, Zero Trust Architecture, was published in August 2020 and has become the definitive federal reference for what zero trust means technically. It defines seven core tenets — principles that a genuine zero trust architecture must implement.
The document is careful to note that zero trust is an architecture, not a product. No single tool is “zero trust.” But tools can implement the tenets or fail to implement them — and the gap between marketing claims and architectural reality is significant.
Tenet 1: All Data Sources and Computing Services Are Resources
NIST 800-207 defines resources broadly — not just web applications, but databases, APIs, file shares, IoT devices, and any other system that processes or stores enterprise data.
How TAC implements this: TAC’s reverse proxy governs access to any resource reachable over a network — web applications, thick-client applications, APIs, database interfaces, IoT management consoles, SCADA systems, and internal tools. TAC does not distinguish between modern and legacy resources.
Where competitors fall short: Solutions requiring SAML or OIDC implicitly define “resources” as only modern, protocol-compliant applications. Legacy systems and thick clients fall entirely outside their scope.
Tenet 2: All Communication Is Secured Regardless of Network Location
How TAC implements this: All traffic to TAC-protected applications flows through a single TLS 1.3 encrypted channel. There is no unencrypted access path to any TAC-protected resource, regardless of whether the request originates inside or outside the corporate network.
Tenet 3: Access Is Granted on a Per-Session Basis
How TAC implements this: TAC evaluates identity, device posture, and policy compliance on every access request. Session establishment does not confer ongoing trust. If a device falls out of compliance mid-session, access is revoked immediately.
Where competitors fall short: Many identity platforms evaluate trust at authentication time and issue tokens that remain valid for hours or days. A device that becomes non-compliant retains its access token until it expires.
Tenet 4: Access Is Determined by Dynamic Policy
How TAC implements this: TAC’s unified policy engine evaluates access decisions based on user identity and group membership, device posture (OS version, patches, antivirus, disk encryption, domain join, certificates), network location, time of day, and application being accessed.
Where competitors fall short: Point solutions typically evaluate only the signals within their domain. Without a unified policy engine that considers all signals together, the zero trust architecture is fragmented.
Tenet 5: Monitor the Integrity and Security Posture of All Assets
How TAC implements this: TAC validates device posture on every access request — not just at login. Posture checks include OS version, patch level, antivirus status, disk encryption, firewall status, domain join, and certificate validity. Non-compliant devices are blocked immediately.
Tenet 6: Authentication and Authorisation Are Dynamic and Strictly Enforced
How TAC implements this: TAC’s reverse proxy is the Policy Enforcement Point. No request reaches a protected application without passing through authentication, device posture validation, and policy evaluation. Applications are never directly accessible — they are only reachable through TAC. This is architectural enforcement, not policy-layer enforcement. Policy-layer enforcement can be bypassed if an alternative path to the application exists. Architectural enforcement cannot.
Tenet 7: Collect as Much Information as Possible About Assets and Communications
How TAC implements this: TAC generates forensic-grade audit logs for every access event — human user and AI agent — with full attribution: identity, device, location, application, policy decision, and timestamp. These logs support SIEM integration for real-time analysis.
The Difference Between Implementing Tenets and Marketing Them
Many vendors claim NIST 800-207 alignment. The most common gaps are: only covering modern protocol-compliant applications (Tenet 1), issuing long-lived tokens rather than per-session evaluation (Tenet 3), evaluating only a subset of signals rather than a unified policy (Tenet 4), and enforcement that can be bypassed via alternative network paths (Tenet 6).
When evaluating zero trust tools against NIST 800-207, the right question is not “do you support zero trust?” It is: “for each of the seven tenets, show me exactly how your architecture implements it — and what happens to systems that fall outside your scope.”
Read the full NIST compliance guide for a control-by-control mapping of TAC to NIST 800-207 and 800-171. Read the guide →