What is the difference between a single-tenant gateway model and a multi-tenant workspace model?

A single-tenant model gives each tenant its own dedicated control plane and data plane, with the clearest separation and the highest operational overhead. A workspace-based multi-tenant model keeps a shared data plane but isolates configuration objects in the control plane, usually with RBAC. That improves efficiency, but it also requires stricter coordination to avoid route collisions and policy conflicts.

How the two models split control and data ownership

The core difference is where tenancy boundaries live. In a single-tenant gateway model, each tenant gets its own dedicated control plane and data plane, so the routing logic, policy enforcement, and operational state stay isolated by design. In a workspace model, the control plane is shared, while workspaces isolate configuration objects and policies, which makes the platform lighter to operate but more dependent on disciplined access control and change coordination.

That difference matters because the control plane is where operators define routes, rules, and administrative state. When it is dedicated, tenant-specific changes are easier to reason about and blast radius is narrower. When it is shared, the platform can scale more efficiently, but every change must be evaluated against coexistence with other workspaces, especially where shared routing, naming, or policy evaluation logic can overlap.

Efficiency gains also come with a governance trade-off: a shared workspace model usually depends on stronger authorisation discipline and clear ownership of configuration boundaries, while a dedicated model reduces that coordination burden but increases infrastructure overhead and tenant-specific operational work.

Where the operational and security differences show up

Single-tenant gateway deployments are typically easier to segment, troubleshoot, and audit because one tenant’s configuration cannot collide with another tenant’s runtime state in the same shared control plane. That makes them attractive when isolation, custom policy behavior, or tenant-specific compliance requirements matter more than platform efficiency.

Workspace-based multi-tenancy is usually chosen when teams want to centralise the gateway layer and reduce duplication. The practical benefit is simpler platform management, but the cost is that shared design decisions, such as route precedence, object naming, and policy inheritance, become cross-tenant concerns. The more dynamic the environment, the more important it is to govern configuration change and access paths as first-class security controls.

For practitioners, the important distinction is not just “shared versus dedicated,” but “what failure mode is acceptable.” A dedicated model tolerates less accidental interference but consumes more resources. A workspace model can be much more efficient, but its control plane becomes a shared dependency that must be protected from accidental overlap and from over-broad administrative access.

What to verify before choosing one model over the other

The deciding question is whether the gateway layer is acting as a tenant-isolated security boundary or as a shared operating platform. If tenant policy, route definitions, and administrative actions must remain strongly separated, the single-tenant model is the safer default. If the business values operational efficiency and can enforce strict workspace scoping, the multi-tenant model can be appropriate.

When evaluating a workspace model, verify that policy collisions are impossible or explicitly resolved, that route ownership is unambiguous, and that role assignments are narrow enough to prevent one workspace from influencing another. When evaluating a single-tenant model, verify that the cost of duplicated infrastructure is justified by the isolation requirement rather than by habit.

That is why multi-tenant models often align with mature platform governance, while single-tenant models align with stricter separation requirements and simpler failure containment. If the environment already struggles with change control, the shared model tends to expose those weaknesses faster; if the environment is stable and well-governed, the shared model can deliver substantial efficiency without materially increasing risk.

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, 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 CSF 2.0	GV.OC — Governance and Organizational Context	Tenant model choice depends on isolation, ownership, and operating assumptions.
	PR.AC — Identity Management, Authentication, and Access Control	Workspace isolation depends on tightly scoped administrative access and policy control.
	PR.PT — Protective Technology	Gateway tenancy affects how routing and policy enforcement are separated and protected.
Recommendation — Document the tenancy model as an organizational decision tied to isolation and operational risk. Enforce least-privilege access to workspace administration and configuration. Implement tenant-separation controls that prevent cross-workspace policy interference.
CIS Controls v8	6 — Access Control Management	Shared workspace governance relies on controlled access to configuration objects and routes.
	4 — Secure Configuration of Enterprise Assets and Software	Route collisions and policy conflicts are configuration risks in shared gateway models.
Recommendation — Restrict administrative permissions to the minimum set needed for each workspace. Standardise and validate gateway configuration to prevent conflicting policy state.
NIST Zero Trust (SP 800-207)	3 — Enforce Least Privilege Access	Shared workspaces need narrow permissions to stop one tenant influencing another.
	5 — Continuous Diagnostics and Mitigation	Shared control planes require ongoing monitoring for conflicting routes or policy drift.
Recommendation — Apply least privilege to every workspace and administrative role. Continuously monitor gateway state for unauthorized or conflicting changes.

Practitioner Guidance

What to prioritise: Start by deciding whether tenant separation is a compliance or blast-radius requirement, or merely a convenience preference. If route collisions or policy overlap would be unacceptable, treat dedicated tenancy as a control decision, not an architecture preference.

What to verify: In a workspace model, verify that object ownership, naming conventions, and access boundaries are enforced consistently enough that shared control-plane state cannot create cross-tenant side effects. In a single-tenant model, verify that operational duplication does not create configuration drift across tenants.

Practitioner takeaway: Use single tenancy when isolation is the primary requirement, and use workspace multi-tenancy only when you can prove that shared control-plane efficiency does not weaken governance or create tenant interference.