How Organizations
Actually Deploy TAC
Ten deployment patterns and six architecture roles, drawn from real TAC environments — government, healthcare, finance, energy, and global enterprise. Most customers start with one and expand; everything on this page runs on the same platform, the same policy engine, and the same single license.
Where Customers Start (Ten Entry Points)
Most TAC deployments begin with one urgent problem — a VPN renewal, a gateway at end-of-life, an auditor’s finding. These are the ten most common entry points, each drawn from a real deployment.
Replace the VPN
The situation: VPN concentrators grant network-level access, expose inbound ports, and cost per-device money. Every user on the VPN can reach far more than they need.
The deployment: TAC publishes each application individually through the reverse proxy — application-level access, not a network tunnel. Run TAC alongside the VPN during transition, then decommission it.
Real result: A US portfolio management firm eliminated $1,000+ per-device VPN hardware and saves $100K+ annually. A UK county council replaced VPN for 8,000+ employees.
Retire an End-of-Life Gateway
The situation: Microsoft UAG, TMG, and similar gateways reached end-of-life years ago — but they are still in production fronting critical apps, unsupported and unpatched.
The deployment: TAC takes over the publishing role in place, app by app — same URLs for users, modern policy enforcement underneath.
Real result: An NHS university hospital trust replaced UAG in under a day, adding BYOD support in the process. A Canadian federal health agency did it in two, adding Mac support their old gateway never had.
Vendor & Third-Party Access
The situation: Vendors, integrators, and contractors need access to specific systems — from laptops you do not manage, on schedules you do not control.
The deployment: Each vendor authenticates through their own IdP (federated) or a TAC-managed identity scoped to specific systems and time windows. MFA and clientless posture checks apply to devices you have never touched — and where a partner’s device policies rule out assessment entirely, TAC’s seamless integration with Microsoft RDP App publishing delivers individual applications with nothing landing on their endpoint (RDP App licensing is Microsoft’s — and often already in the customer’s estate). Every session logged with full attribution.
Real result: Oklahoma Municipal Power Authority put every vendor path to SCADA behind TAC — one encrypted port, NERC CIP access control met.
MFA on Apps That Can’t Do MFA
The situation: Legacy EHRs, ERP systems, and custom line-of-business apps predate modern authentication. Auditors want MFA everywhere; the apps cannot comply.
The deployment: TAC enforces MFA at the proxy — FIDO2, hardware tokens, push, or SafeLogin (PortSys’s built-in MFA method) — before the request ever reaches the application. Zero application changes.
Real result: An NHS acute hospital trust enforced MFA and device posture on legacy EHR systems that could not natively support either.
BYOD and Any-Device Access
The situation: Clinicians, consultants, and remote staff work from personal devices. MDM enrollment is friction many will not accept — but unmanaged access is risk you cannot.
The deployment: TAC checks device posture on every session — clientless for core signals, with the optional TAC client unlocking deeper inspection where the device allows it — and scales access to what the device’s state justifies.
Real result: A 550-bed NHS trust delivers secure BYOD access for 5,000 employees and 1,000 partner users.
Secure Remote Access to OT & SCADA
The situation: Engineers and vendors need remote paths to HMIs, historians, and engineering workstations — and every remote path into OT is an attack path.
The deployment: TAC sits in the IT/OT DMZ as the only path to the systems that command OT. Identity, MFA, posture, and per-system policy on every session — zero changes to OT devices or protocols.
Real result: OMPA secured distributed generation facilities: one inbound port, zero changes to OT applications, NERC CIP access control and audit met.
Shrink the Attack Surface to One Port
The situation: Years of point solutions leave dozens of inbound ports open — RDP here, a partner portal there, a legacy gateway nobody remembers. Each one is discoverable and each one is a target.
The deployment: Applications move behind TAC one at a time; their inbound ports close as they go. End state: one encrypted TLS port, applications invisible to the internet.
Real result: A US federal agency reduced its inbound exposure to TAC’s single port while meeting NIST 800-171 access requirements.
Global and Restricted-Region Deployment
The situation: Global workforces need consistent, fast, compliant access — including in regions where cloud-routed security products do not work or are not permitted.
The deployment: TAC scales from one SVA to a geo-distributed array with unified policy. Because it is self-hosted, it runs wherever you need it — including jurisdictions no vendor cloud can serve.
Real result: ZS Associates runs 8 TAC instances for 17,000+ users across 35 countries — including behind China’s Great Firewall — securing 1,300+ federated applications.
Compliance-Driven Zero Trust
The situation: An auditor, framework, or contract deadline — CJIS, NERC CIP, CMMC, HIPAA, NIST 800-171 — requires MFA, access control, and audit evidence you cannot currently produce.
The deployment: TAC becomes the enforcement and evidence layer: MFA on everything, per-request policy, and a complete, attributed log of every access, produced in the normal course of operation.
Real result: From a municipal power authority’s NERC CIP program to federal NIST 800-171 environments, TAC deployments generate the access-control evidence audits require.
Get Ahead of AI Agents
The situation: AI agents are starting to call APIs and query systems across your environment — a new class of identity most access stacks cannot even see.
The deployment: Customers deploy TAC as the enforcement point for human access today — the same proxy every agent request will have to cross tomorrow. AI Agent Governance is next on the TAC platform, built on that enforcement point.
Real result: The architecture is in production now; the agent module lands on top of it. Join the launch list to deploy it first.
Where TAC Goes From There (Six Architecture Roles)
Entry points solve the problem that brought you in. These six roles are what TAC becomes as it grows in your environment — from a targeted bridge beside the identity investment you already own, to the single enforcement point in front of everything. Same platform, same license, no new products along the way.
The Central Access Point for Everything
One enforcement point in front of all of it — cloud applications, local applications, OT and IoT control systems. Every request from every identity crosses the same proxy, gets the same policy evaluation, and lands in the same audit trail. One console, one policy engine, one place where access happens.
The Enforcement Bridge Between Your IdP and Your Cloud Apps
Keep your IdP — Entra, Okta, Ping, AD FS. It authenticates; TAC adds what a login event cannot: conditional access evaluated on every request, device inspection, geo-IP policy, session-long enforcement. Next on TAC: distinguishing AI from non-AI principals at this same bridge — so agent traffic gets its own policy the moment it appears.
The Bridge From an External IdP to Your Local Applications
The inverse bridge: credentials validate against your external IdP, and TAC enforces everything else — MFA step-up, device posture, geo and network rules, per-application policy — for the on-premises and legacy applications your identity cloud cannot reach. This is how identity-cloud customers extend their investment instead of replacing it.
The AI Agent GatewayNext on TAC
A dedicated enforcement path for AI agents, exclusively: agents reach only the systems they are permitted to reach, under the circumstances you define — scope, schedule, source, and context. Human traffic and agent traffic share the same policy engine but live under different rules. Built on the enforcement point already in production; the agent module is next on the platform.
The Secure Jump Server for Cloud Administration
Admin access is the highest-value target in your environment. TAC replaces soft-target jump hosts and bastion servers as the way administrators reach cloud consoles and environments — with granular policy on who, from which device, from where, at what time, into which environment, and a complete, attributed log of every privileged access.
The Full IdP — and the Complete Enforcement Point
TAC can be the identity provider itself, consuming credentials from any repository you already have — AD, LDAP, SQL, SAML, OIDC — while acting as the complete enforcement point for every request. For organizations whose identity vendor covers local applications only partially (a separate gateway here, an agent there), this role extends identity to everything, uniformly, through one platform.
Start anywhere.
Grow into everything.
Every entry point and every role on this page runs on the same Secure Virtual Appliance, the same policy engine, and the same all-inclusive license. Solve the urgent problem first — most customers do — and the platform you deployed for it is already the architecture you’ll grow into.