Self-hosted Zero Trust keeps policy evaluation, request routing, and logging inside the organisation's own infrastructure. A SaaS access gateway processes access through the provider's environment, which can simplify deployment but also introduces external dependencies. For internal systems, AI agents, and regulated data, the key difference is who controls the enforcement path and where sensitive traffic is observed.
How the control plane differs from the provider plane
Self-hosted Zero Trust keeps the enforcement path inside your environment, so policy decisions, routing, and logs stay under your operational control. A SaaS access gateway moves part of that path into the vendor’s service, which can reduce deployment burden but also makes availability, logging, and change control partially dependent on the provider. That architectural split is the real difference.
For teams comparing the two, the most important question is not whether both can broker access, but where the decision point lives and how much trust you place in an external service to inspect or mediate sensitive traffic.
What changes for internal systems, AI agents, and regulated data
The difference becomes material when the traffic itself is sensitive. With internal systems, you often want direct control over segmentation, policy enforcement, and observability because the gateway is part of the trust boundary. With AI agents, the same question extends to tool access and delegated actions, where the enforcement path needs to be tightly bounded and auditable. With regulated data, external processing can introduce data residency, retention, and audit concerns even if the access experience is simpler.
A self-hosted design usually gives you cleaner alignment between the policy engine, the protected application, and the audit trail. A SaaS gateway may still be appropriate for lower-risk access paths, but the trade-off is that the vendor becomes part of the operational trust chain.
How to think about latency, visibility, and lock-in
Self-hosted controls often demand more engineering effort, but they give you more freedom to tune routing, log retention, conditional access logic, and integration with internal identity sources. SaaS gateways are often faster to stand up and can be easier to standardise across distributed teams, but they can also create lock-in around policy language, connector design, and telemetry access. The practical difference is how much of the access decision you can independently inspect and reproduce.
For a simple remote-access use case, SaaS convenience may be enough. For crown-jewel systems, high-value admin paths, or environments with strict evidence requirements, most teams will want the ability to prove exactly how access was granted, logged, and revoked without relying on a provider’s opaque control path.
Risk and Threat Considerations
The main risk difference is concentration. A SaaS access gateway can become a single externally managed dependency for many sensitive systems, so a provider outage, misconfiguration, or account compromise can affect broad access paths at once. Self-hosted Zero Trust shifts more responsibility onto your team, but it reduces dependence on an outside control plane for enforcement and visibility.
Failure mechanism: If the gateway or its administration plane is compromised, the attacker may inherit policy control, manipulate routing, or observe access metadata and session handling across multiple applications.
Impact: That can turn one access-layer failure into broad lateral movement, data exposure, or loss of audit confidence, especially where the gateway sits in front of privileged, internal, or regulated resources.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Access gateways enforce and mediate traffic flow to protected systems. |
| AU-2 — Audit Events | The question turns on where access logs are captured and retained. | |
| SC-7 — Boundary Protection | Both models are about how the access boundary is implemented and trusted. | |
| Recommendation — Enforce AC-4 to control where sensitive requests can travel and be inspected. Define AU-2 events for gateway decisions, routing, and administrative actions. Apply SC-7 to keep enforcement and inspection at the intended boundary. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | This comparison is about controlling and observing the access path. |
| Recommendation — Use CIS-12 to harden and monitor the infrastructure that mediates remote access. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The core distinction is where policy enforcement and trust evaluation occur. |
| Recommendation — Place policy enforcement close to the protected resource and verify every access request. | ||
Practitioner Guidance
What to verify: Confirm whether the product exposes the full policy decision path, log export, and revocation workflow in a way you can independently operate and audit. If you cannot prove those things without the vendor’s help, treat the gateway as part of your trust boundary rather than just a convenience layer.
Decision rule: Use a self-hosted pattern when you need strict control over enforcement, evidence, or data handling; use a SaaS gateway when speed, standardisation, and reduced operational burden matter more than full control of the path.
Practitioner takeaway: The best choice is the one whose control plane matches the sensitivity of the traffic, because the main security question is who can mediate access, observe it, and alter it when something goes wrong.
Related resources from NHI Mgmt Group
- How should teams govern zero trust access in self-hosted environments?
- Who is accountable when SaaS access cannot be fully enforced under zero trust?
- How should security teams choose between a self-hosted LLM gateway and a managed SaaS gateway?
- How should security teams use an enterprise browser to enforce zero trust for SaaS access?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org