Compliance Alignment Guide

TAC and NIST

How TAC maps to NIST SP 800-207 (Zero Trust Architecture) and NIST SP 800-171 (Protecting Controlled Unclassified Information).

↓ Download as PDF Talk to a Specialist

Note: This guide covers both NIST SP 800-207 and NIST SP 800-171. 800-207 defines the zero trust architecture principles TAC implements. 800-171 addresses protection of Controlled Unclassified Information (CUI) and is a key requirement for CMMC 2.0 compliance.

NIST SP 800-207

Zero Trust Architecture

The federal standard for zero trust. TAC implements the Policy Engine, Policy Administrator, and Policy Enforcement Point in one platform.

TAC Scope in NIST

TAC implements the Policy Engine, Policy Administrator, and Policy Enforcement Point defined in NIST SP 800-207 in a single, unified platform — controlling access to applications and systems handling CUI. TAC addresses access control, authentication, audit, boundary protection, and communications encryption requirements (800-171 Families 3.1, 3.3, 3.5, 3.13) for systems in scope.

TAC does not encrypt CUI at rest, scan or sanitise CUI content automatically, replace network segmentation between enclaves, or perform vulnerability scanning. Families such as 3.8 (Media Protection), 3.10 (Physical Protection), 3.11 (Risk Assessment), and 3.12 (Security Assessment) are satisfied by complementary controls in your environment.

ZTA Principles

Tenets of Zero Trust (NIST SP 800-207)

TAC as a unified 800-207 architecture. NIST SP 800-207 defines Zero Trust Architecture through three logical components: the Policy Engine (PE) makes access decisions, the Policy Administrator (PA) communicates them and manages sessions, and the Policy Enforcement Point (PEP) enforces them at the point of access. TAC implements all three components in a single platform, eliminating the integration complexity of multi-vendor zero trust architectures.

Requirement	How TAC Delivers
Verify all users, devices, and connections	TAC evaluates identity, device posture, and policy compliance on every access request — regardless of network location or prior authentication. All verification occurs over an encrypted channel using TLS 1.2 or TLS 1.3 with FIPS 140-2 compliant cryptographic modules.
Least privilege access	Granular policy engine grants minimum required access per user, per application, per session. Standing privileges eliminated. No implicit trust based on network location.
Assume breach	Reverse proxy architecture ensures applications are never directly addressable from any network. TAC prevents lateral movement to TAC-protected applications — every connection requires policy evaluation regardless of network origin. (Note: TAC does not prevent lateral movement between systems outside its enforcement scope; network segmentation remains a complementary control.)
Inspect and log all access	Every access request — human and AI agent — is logged with full attribution including identity, device, location, application, and policy decision. For advanced scenarios, TAC supports custom JavaScript policies that can inspect, log, modify, or block request and response content based on payload data (power-user feature).
Authenticate before connecting	Identity verification, MFA challenge, and device posture validation all occur at the proxy layer before any connection to a target application is established. No path exists to bypass this sequence.
Microsegmentation	Each protected application is individually governed by its own policy. Compromising access to one application does not grant access to others. Per-application access lists, MFA requirements, and device posture rules apply independently.
Service accounts and AI agents as first-class identities	Non-human identities — service accounts, API clients, automated systems, and AI agents — governed by the same identity, policy, and audit framework as human users. No separate identity silo for programmatic access. Critical for federal environments deploying AI workloads against CUI.
Continuous device posture validation	Device posture is evaluated on every request, not just at login. OS version, patch level, antivirus status, disk encryption, firewall status, and domain join status are checked. Non-compliant devices are denied access in real time; sessions are revoked if compliance lapses mid-session.

NIST CSF

Protect — Identity Management & Access Control (PR.AC)

Requirement	How TAC Delivers
PR.AC-1 — Identities and credentials managed	TAC identity federation manages credential validation across all connected directory sources (Active Directory, LDAP, SAML, RADIUS, OIDC, SQL, custom). Real-time revocation when user status changes in the source directory.
PR.AC-3 — Remote access managed	TAC reverse proxy provides authenticated, policy-governed remote access to all protected applications without exposing network ports. Can replace traditional VPN for application access while maintaining per-application policy, MFA, device posture, and full audit trail.
PR.AC-4 — Access permissions and authorisations managed	Unified policy engine manages access rights across all identity sources with granular per-application, per-user policies. Role-based and attribute-based access control supported. Policy changes take effect immediately.
PR.AC-5 — Network integrity protected	All access flows through a single encrypted channel (TLS 1.2 or TLS 1.3 with FIPS 140-2 compliant cryptographic modules). TAC is the sole gateway to protected applications. Other inbound ports closed at the firewall.
PR.AC-7 — Users, devices, and other assets authenticated commensurate with risk	Risk-appropriate authentication through layered factors: identity verification, MFA, device posture, geolocation, and time-of-day rules. Step-up authentication can be configured per application based on sensitivity.

NIST SP 800-171

Protecting CUI

Key controls for organisations handling Controlled Unclassified Information (CUI), including DIB contractors and CMMC 2.0 candidates.

AC Family

Access Control (3.1)

Requirement	How TAC Delivers
3.1.1 — Limit system access to authorised users	TAC identity federation connects to all major directory services. Only authenticated users matching access policy reach applications handling CUI.
3.1.2 — Limit system access to authorised functions	Policy engine restricts each user to only the applications and functions they are explicitly permitted to access. Per-application authorisation enforced on every request.
3.1.3 — Control CUI flow	TAC mediates and logs all access paths to applications containing CUI. (Note: TAC controls access to CUI-containing applications, not information flow within applications. Data-level CUI flow controls require complementary DLP or application-layer controls.)
3.1.5 — Employ principle of least privilege	Granular policy engine grants minimum required access per user, per application, per session. No standing administrative access; privilege elevation requires explicit policy match.
3.1.12 — Monitor and control remote access sessions	Every remote session is authenticated, device-posture-validated, policy-governed, and fully logged. Real-time session revocation supported — policy changes take effect immediately.
3.1.13 — Employ cryptographic mechanisms to protect remote access	All remote access traffic encrypted via TLS 1.2 or TLS 1.3 with FIPS 140-2 compliant cryptographic modules. Single encrypted port for all communications. No path exists to access protected applications through unencrypted protocols when TAC is deployed.
3.1.20 — Verify external connections	All external connections pass through TAC’s identity verification, MFA, device posture, and policy evaluation before reaching protected applications. No anonymous or unverified external access path exists.

IA Family

Identification and Authentication (3.5)

Requirement	How TAC Delivers
3.5.1 — Identify system users, processes, and devices	Every user, service account, AI agent, and device identified against connected identity sources before any access is granted. The same policy engine governs human and non-human identities. Critical for federal environments deploying AI workloads against CUI.
3.5.2 — Authenticate user, process, and device identities	Identity verification required for every user, process, and device before access. Built-in MFA includes FIDO2 / WebAuthn (phishing-resistant), SafeLogin (proprietary), TOTP, push notifications, SMS, OTP, and hardware tokens. Third-party MFA integration with virtually any provider including Duo, RSA, Swivel, biometric solutions, and others. All MFA methods included in base licence.
3.5.3 — Use multi-factor authentication for privileged and non-privileged accounts	MFA mandatory for all access to CUI applications, including legacy applications that cannot natively support modern authentication. MFA applies to both privileged administrative access and standard user access.
3.5.6 — Disable identifiers after inactivity	Session timeout policies are configurable per application and user group. Real-time access revocation when user status changes in the source directory — no need to wait for next login cycle.

AU Family

Audit and Accountability (3.3)

Requirement	How TAC Delivers
3.3.1 — Create and retain system audit records	Comprehensive audit log of every access event — user identity, authentication method, device posture, source IP, geolocation, timestamp, application accessed, and policy decision. Logging is automatic and cannot be disabled for protected applications.
3.3.2 — Ensure user actions are uniquely traceable	Every action attributed to a verified identity. No anonymous or pseudonymous access to CUI applications. Service accounts and AI agents are uniquely identified.
3.3.4 — Alert on audit logging process failure	TAC provides native real-time monitoring and alerting on access events and platform health. Logging failures or platform issues are surfaced through the admin console and via SIEM integration.
3.3.6 / 3.3.7 — Audit reduction and time stamps	Centralised audit data exportable via syslog or API to your SIEM for downstream correlation, reduction, and reporting. All log entries include authoritative timestamps.
3.3.8 — Protect audit information	Tamper-evident, centralised logging. Audit data cannot be modified through the TAC console. Export controls preserve integrity for downstream forensic analysis.
3.3.9 — Limit management of audit logging functionality	Audit logging configuration is restricted to authorised administrators through TAC’s admin policy framework. Administrative actions on the audit logging functionality are themselves logged.

SC Family

System and Communications Protection (3.13)

Scope note. TAC addresses boundary protection and cryptographic protection in transit. TAC does not address protection of CUI at rest (3.13.11, 3.13.16), denial-of-service protection (3.13.6), or collaborative computing device controls (3.13.12). Those controls require complementary infrastructure and endpoint controls in your environment.

Requirement	How TAC Delivers
3.13.1 — Monitor, control, and protect communications at external boundaries	TAC’s reverse-proxy architecture is the external boundary for protected applications. All inbound traffic monitored, controlled by policy, and protected by encryption. Other inbound ports closed at the firewall.
3.13.5 — Implement subnetworks for publicly accessible system components	TAC enforces a logical separation between public-facing access (the TAC entry point) and the trusted application zone. CUI applications are never directly addressable from the internet; the TAC proxy is the sole intermediary.
3.13.8 — Implement cryptographic mechanisms to prevent unauthorised disclosure during transmission	All traffic to and from protected applications encrypted via TLS 1.2 or TLS 1.3 with FIPS 140-2 compliant cryptographic modules. Single encrypted port for all access. End-to-end encryption between the user’s device and TAC, and between TAC and the backend application.
3.13.15 — Protect authenticity of communications sessions	Every connection is authenticated and policy-evaluated. Sessions cannot be hijacked through network-level attacks because the encrypted channel terminates at the TAC proxy with strong session controls. Mid-session device posture changes trigger immediate session revocation.

Why TAC for NIST

Federal-Ready Advantages

Five capabilities that make TAC especially effective for federal and DoD environments handling CUI.

Unified PE + PA + PEP — One Platform

NIST 800-207 defines three logical zero trust components: Policy Engine, Policy Administrator, and Policy Enforcement Point. TAC implements all three in a single, integrated platform. No multi-vendor integration. No policy synchronisation drift. No gaps between components — decisions, communication, and enforcement happen in the same engine.

Close All Ports — Minimum Attack Surface for CUI

TAC closes all inbound firewall ports except one encrypted channel (TLS 1.2 or TLS 1.3 with FIPS 140-2 modules) for the CUI applications it fronts. Most competing approaches leave datacenter ports open behind their cloud or concentrator — TAC closes them. Critical for federal authorisations where attack surface is heavily scrutinised.

Legacy Federal Application Protection

Many federal agencies and DIB contractors run critical CUI systems on legacy applications that cannot natively support MFA or modern authentication. TAC injects MFA, device posture, and continuous validation in front of any application — without changing a single line of code or requiring re-authorisation.

Single-Tenant Isolation — Sovereign CUI Boundaries

Every TAC deployment is a dedicated, isolated Secure Virtual Appliance — on-premises, in your cloud account, or hybrid. Policies and audit data for your CUI never co-mingle with another organisation’s environment. Matters for federal customers with sovereignty or compartmentalisation requirements.

All-Inclusive Licensing — No Authorisation Gaps

TAC includes every security feature in the base licence: all MFA methods, device posture validation, AI agent governance, SSO, and 24×7 support. No add-on tiers, no per-user MFA surcharges. Eliminates the risk of authorisation gaps caused by deferred security purchases.

NIST Coverage Summary

TAC Control Coverage at a Glance

Framework / Family	Scope	TAC Coverage
NIST SP 800-207	Zero Trust Architecture (PE / PA / PEP)	All three logical ZTA components in one platform; 8 ZT tenets addressed end-to-end
NIST CSF	Protect — PR.AC (Access Control)	Identity management, remote access, network integrity, risk-appropriate authentication
NIST 800-171 — 3.1	Access Control	Authorised access, least privilege, CUI access mediation, remote session monitoring, FIPS 140-2 encryption
NIST 800-171 — 3.3	Audit and Accountability	Comprehensive attributed audit trail, tamper-evident logging, native real-time alerting, SIEM export
NIST 800-171 — 3.5	Identification and Authentication	Multi-directory federation, built-in & third-party MFA, service accounts & AI agents, device posture
NIST 800-171 — 3.13	System and Communications Protection (partial)	Boundary protection, public-access boundary, TLS 1.2/1.3 with FIPS 140-2; does not address CUI at rest

Preparing for NIST Compliance?

Our engineers can walk through your specific NIST 800-207 or 800-171 requirements and show exactly how TAC addresses each control.

Talk to a Specialist Back to Resources

TAC and NIST Compliance Guide