What is the difference between self-hosted Zero Trust and a SaaS access gateway?

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.

Where the Difference Actually Shows Up

The practical difference is not just where the software runs. It is whether access control, inspection, and auditability remain inside your boundary or are partly mediated by a provider. Self-hosted Zero Trust is usually chosen when the organisation needs tighter control over policy enforcement, traffic visibility, and data locality. A SaaS access gateway is often attractive when speed of rollout, lower operational burden, and simpler administration matter more than direct control of the enforcement path.

That distinction becomes important for systems that expose privileged internal applications, regulated datasets, or autonomous workloads that must be limited in very specific ways. A provider-managed gateway may still enforce strong policy, but it also creates a dependency on the vendor’s control plane, logging model, and tenancy design. In Zero Trust terms, the question is less about branding and more about who can observe, decide, and revoke access at the moment a request is made.

For teams comparing the two models, the most useful reference point is NIST SP 800-207 Zero Trust Architecture, which frames Zero Trust around continuous evaluation rather than trust by network location.

In practice, many teams discover the trade-off only after they need to investigate an access decision or restrict an internal system that the gateway can reach but cannot fully explain.

How the Two Models Operate in Practice

Self-hosted Zero Trust typically places policy decision points, proxies, identity checks, and logs inside infrastructure the organisation controls. That makes it easier to tie access to internal identity sources, segmentation rules, device posture checks, and application-specific policy. It also allows closer integration with systems that need special handling for secrets, internal APIs, or machine-to-machine access paths. For workloads that depend on service accounts, API keys, or workload identity, this can be a meaningful advantage because the organisation can align access enforcement with its own credential lifecycle and audit requirements.

A SaaS access gateway shifts some of that work to the provider. The gateway can simplify deployment by reducing the number of components a team must run, patch, and scale, and it often helps when organisations want quicker rollout across many apps. But the operational model changes: the provider may become part of the enforcement path, the inspection path, or both. That means availability, latency, logging retention, and policy change workflows are now partly external concerns. For some teams, that is acceptable if the apps are low sensitivity or the governance model is mature enough to absorb the dependency.

Current guidance suggests treating the control boundary as the deciding factor. If policy must be enforced with direct visibility into internal traffic, or if you need immediate administrative control over revocation and inspection, self-hosted designs usually fit better. If you mainly need broad access mediation and are comfortable with an external control plane, a SaaS gateway can be a pragmatic choice. The most important design question is whether the gateway can enforce the same decision quality you would expect from an internal proxy, not whether it uses the Zero Trust label.

A useful practitioner check is whether the gateway can preserve source identity, application context, and audit logs in a form that your security and compliance teams can independently verify. The Ultimate Guide to NHIs is helpful here because it ties Zero Trust to credential lifecycle, visibility, and offboarding realities that often determine whether the design works outside the diagram.

These models tend to break down when the gateway becomes a choke point for high-volume internal service traffic and cannot provide the same fidelity of identity, policy, and log correlation that the applications need.

When the Choice Becomes a Governance Decision

Tighter control usually increases operational burden, so the decision is not purely technical. Self-hosted Zero Trust can demand more engineering, more patching, and more care around high availability, while SaaS gateways can reduce those duties but increase reliance on vendor controls, shared tenancy assumptions, and external incident response. That is a real trade-off, not a theoretical one.

This becomes especially relevant in regulated environments, environments with internal agentic systems, or organisations that need evidence of who observed access, who approved policy, and how quickly access can be revoked. If the primary concern is minimising the blast radius of a compromised internal account or machine credential, the ability to localise enforcement and inspection often matters more than deployment convenience. If the main concern is getting many applications behind consistent access controls quickly, a SaaS gateway may be the better first step, provided the provider’s logs, policy model, and recovery posture are acceptable.

For deeper context on the control side, the OWASP Non-Human Identity Top 10 is useful when the decision hinges on protecting machine access paths and the secrets or tokens that feed them. Where the question is broader architecture and resilience, NIST’s Zero Trust guidance remains the better anchor.

Practitioners often underestimate that the real decision is not gateway versus gateway, but whether the organisation can prove enforcement, audit, and revocation at the layer where access actually happens.

Risk and Threat Considerations

The main risk with a SaaS access gateway is dependency concentration. If the provider’s control plane, logging path, or policy engine is disrupted or misconfigured, access decisions and visibility can be impaired across many applications at once. A self-hosted model shifts that operational risk inward, but it gives the organisation more direct control over failure handling and forensic access.

Failure mechanism: Compromise or outage in the enforcement path can create blind spots, stale policy, or failed revocation. In provider-mediated models, the risk also includes trust in a third-party tenancy boundary, logging completeness, and administrative separation between customer environments.

Impact: Sensitive traffic may be observed outside the intended boundary, access may remain valid longer than expected, and incident response may lose the evidence needed to prove what was allowed, denied, or changed.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC-1 — Identity Management and Access Control	This compares access enforcement models and who controls access decisions.
	PR.PT-3 — Platform Security	The question hinges on where routing and enforcement are operated and observed.
	DE.CM-1 — Monitoring and Logging	Logging location and verifiability are central differences between the two models.
Recommendation — Define and enforce access decisions at the boundary that protects each application. Harden the enforcement path and ensure traffic inspection stays under trusted control. Retain and validate logs where they support independent investigation and audit.
NIST Zero Trust (SP 800-207)	SP 800-207 — Zero Trust Architecture	The topic is explicitly about Zero Trust architectural placement and trust boundaries.
Recommendation — Place policy decision and enforcement points so they continuously verify each request.
CIS Controls v8	6.3 — Access Control Management	The models differ in how access is granted, mediated, and revoked.
Recommendation — Centralise access governance and revoke paths quickly when risk changes.

Practitioner Guidance

What to prioritise: Decide first whether your primary requirement is direct enforcement control or deployment simplicity. If the system handles regulated data, privileged internal services, or machine-to-machine access, prioritise the model that lets you prove policy execution and revocation speed.

What to verify: Confirm where policy is evaluated, where logs are written, who can change rules, and how quickly access can be removed during an incident. If the provider cannot expose those answers cleanly, treat that as a governance gap, not a minor implementation detail.

Decision rule: If the access path itself is part of the security boundary, prefer the model that keeps enforcement and observability closest to the assets you are protecting. If the boundary is already well abstracted and the apps are lower sensitivity, a SaaS gateway may be an acceptable trade-off.

Practitioner takeaway: The best choice is the one that preserves decision authority, auditability, and revocation where the risk actually lives, not the one that is easiest to deploy first.