Zero Trust Access
Every principle of NIST 800-207. In one platform.
Most products claim “zero trust.” Few actually implement the NIST SP 800-207 architecture. TAC enforces every tenet — verify every user, every device, every request, every time — from a single reverse-proxy platform you control.
The Challenge
The market is full of products labeled “zero trust.” Most aren’t.
NIST SP 800-207 defines zero trust as a specific architecture — not a marketing label. It requires per-request authentication, continuous device evaluation, dynamic policy, full-traffic inspection, and microsegmentation at the resource level. Most products labeled “zero trust” meet some of these requirements. Few meet all of them.
The VPN-in-a-cloud problem
Many “ZTNA” products are essentially cloud-hosted VPNs. They tunnel application traffic but don’t evaluate identity, device, or policy on each request — once a session opens, the user has broad access.
The identity-only problem
SSO and MFA layers verify a user at login, then trust them for hours. That’s not zero trust — that’s perimeter authentication moved to the cloud. NIST 800-207 requires continuous, per-request evaluation.
The agent gap
Real zero trust governs every identity that requests resources — including AI agents, service accounts, and machine identities. Most platforms govern people only, leaving non-human access ungoverned by design.
The cloud-only ceiling
Cloud-native zero trust products can’t reach what runs on-prem — legacy applications, thick clients, OT systems, mainframes. Your most critical resources stay outside the policy engine.
The opaque policy problem
When the policy engine is a vendor’s black box, you can’t audit what was decided or why. NIST 800-207 requires policy to be inspectable, logged, and under the relying organization’s control.
The licensing trap
True zero trust requires device posture, continuous evaluation, and full audit. With most vendors, each of these is a separate SKU. The architecture costs less to specify than to actually buy.
The Seven Tenets
NIST SP 800-207, tenet by tenet — and how TAC implements each one.
NIST SP 800-207 Section 2.1 defines seven foundational tenets of a zero trust architecture. Every legitimate ZTA implementation must address all seven. Here’s what each tenet requires — and how TAC implements it in production today.
All data sources and computing services are resources
NIST 800-207 § 2.1, tenet 1
Every protected asset — not just servers, but APIs, databases, file shares, SaaS apps, OT devices, and AI agents — is treated as a resource that requires authenticated, authorized access.
TAC governs access to web apps, thick-client apps, RDP, SSH, VDI, file collaboration, APIs, OT systems, and AI agents through one reverse-proxy enforcement layer. Every resource lives behind the same policy engine.
All communication is secured regardless of network location
NIST 800-207 § 2.1, tenet 2
Encryption and authentication apply equally to internal and external traffic. There is no “trusted network.” A request from inside the LAN gets the same treatment as a request from a coffee shop.
Every connection — on-prem, remote, hybrid — flows through TLS 1.2/1.3 encrypted reverse proxy. No internal “fast path” that bypasses inspection. Single inbound port at the perimeter.
Access is granted on a per-session basis
NIST 800-207 § 2.1, tenet 3
A session granting access to one resource does not implicitly grant access to others. Each application access requires its own authentication, authorization, and policy evaluation.
Per-application, per-session policy enforcement. Authentication to one resource never grants implicit access to another. Tokens are session-scoped and useless outside their granted context.
Access is determined by dynamic policy
NIST 800-207 § 2.1, tenet 4
Policy decisions are based on identity, device posture, application sensitivity, and context (time, location, threat signals) — evaluated against the request in real time, not from a static rule table.
ABAC, RBAC, CBAC, and PBAC engine evaluates identity, device, and context on every request. Step-up authentication and mid-session access revocation trigger automatically as conditions change.
The enterprise monitors and measures the integrity and security posture of all owned and associated assets
NIST 800-207 § 2.1, tenet 5
Device posture — patch level, OS version, EDR status, configuration compliance — is continuously evaluated. A device that was compliant at login can be quarantined mid-session if posture degrades.
Native device posture checks evaluate OS, patches, AV, certificates, hardware ID, and installed software — no third-party MDM required. Posture is re-evaluated on every request, so a device that drifts out of compliance mid-session can be challenged or denied immediately.
All resource authentication and authorization are dynamic and strictly enforced before access is allowed
NIST 800-207 § 2.1, tenet 6
Authentication and authorization happen at every request, not just at session start. Re-authentication and re-authorization are triggered by risk events, time elapsed, or sensitive resource access.
MFA enforced at TAC on every session, independent of IdP. Step-up MFA triggers on posture change, geo/network change, sensitive resource access, or policy-defined conditions — not just on initial login.
The enterprise collects as much information as possible about the current state of assets, network infrastructure, and communications and uses it to improve security posture
NIST 800-207 § 2.1, tenet 7
Every authentication, authorization decision, policy change, and session event is logged with full attribution, providing the visibility needed to continuously improve security posture.
Full session lifecycle logged: every request, every decision, every state change — attributed by user, device, source, target, and policy. Syslog export to your SIEM and SOAR provides the raw audit data your security tools need for downstream behavioral analytics and risk scoring.
Zero Trust vs. Zero Trust Washing
What NIST 800-207 actually requires — vs. what most “zero trust” products do.
The term “zero trust” has been applied to products that meet two or three of the seven tenets and call it done. Here’s what an honest comparison looks like — the architectural requirement, what most products labeled “zero trust” actually deliver, and what TAC delivers.
“Zero trust” is a term that has been stretched well past its original meaning. NIST SP 800-207 is the specific, technical standard that defines what zero trust architecture actually is. When evaluating a platform, ask: does it implement all seven tenets, on all resources, for all identities? If the answer is partial, what you have is a zero-trust-flavored product — not a zero trust architecture.
TAC and NIST — Full Compliance Alignment Guide
Detailed mapping of TAC capabilities to NIST SP 800-207 and NIST SP 800-171 (CUI protection / CMMC 2.0). Built for security architects, compliance teams, and procurement.
Ready to See Real Zero Trust?
Walk through your environment with a PortSys engineer.
We’ll show you which of the seven NIST 800-207 tenets your current stack actually implements — and where TAC closes the gaps. 30 minutes. No slideware.