A hub-and-spoke model is an architecture where a central hub coordinates communication, control, or data flow between multiple connected spokes. In identity and security, the hub often enforces policy, aggregates telemetry, or brokers access, while spokes represent systems, applications, or environments that depend on the hub for consistent governance and routing.
What the hub-and-spoke model means in security architecture
The hub-and-spoke model is an architectural pattern, not a product category. Its defining feature is central coordination: the hub becomes the control plane or distribution point, while spokes depend on it for routing, policy enforcement, aggregation, or controlled access. That central point can simplify governance, but it also creates a place where design decisions become highly consequential.
In cybersecurity, the model is common where a single team or platform must impose consistent controls across many environments. The same pattern can describe network design, cloud landing zones, identity governance, telemetry pipelines, or operating-model structures. The security question is always the same: what must the hub do, and how much authority or dependency are you concentrating there?
How hub-and-spoke changes control and trust boundaries
The model shifts trust from many local connections to one managed intermediary. That can improve consistency because policy, inspection, logging, and access decisions are handled in one place. It can also reduce configuration drift across spokes, especially when the hub owns standard routes, baseline controls, or shared services.
At the same time, the hub becomes a boundary that must be designed for resilience and scrutiny. If it is too permissive, every spoke inherits that weakness. If it is too fragile, outages or misconfigurations at the centre can interrupt many dependent systems at once. Security operating model and organisation design often follows the same logic: centralisation can improve decision quality, but only when accountability and decision rights are explicit.
Where hub-and-spoke is commonly used
In cloud and network design, hub-and-spoke often underpins shared connectivity, inspection, egress control, and segmented access between environments. In identity and governance contexts, the hub may be the service that brokers access decisions, applies policy, or coordinates telemetry from many dependent systems. The pattern is attractive because it supports repeatability and standardisation without requiring every spoke to reinvent core controls.
It is also useful for operating models. A central security or identity function can define standards and provide shared services, while business units, platforms, or regional teams act as spokes. This makes the model relevant to both technology architecture and governance structure. Identity team operating model and Google Cloud Enterprise Foundations Blueprint Guide both reflect that centralised coordination pattern in practical terms.
Why the model matters when systems scale
The architecture becomes more valuable as the number of spokes grows, because manual point-to-point control does not scale cleanly. A hub can provide a single place for logging, routing rules, policy enforcement, or service governance. That helps security teams see the environment as a system, rather than as disconnected fragments.
But the same scaling benefit can turn into concentration risk if the hub is oversized, underspecified, or treated as an assumption rather than a controlled dependency. Design quality matters more than the label itself. A well-run hub-and-spoke model is deliberate about what is centralised, what remains local, and what failure modes are acceptable. Cloud network security is one area where those trade-offs are especially visible, because shared connectivity and segmentation choices directly affect exposure.
Risk and Threat Considerations
Hub-and-spoke creates a concentration point that can magnify both operational failure and attacker payoff. If the hub is compromised, misconfigured, or unavailable, many spokes can inherit the impact at once. In security terms, this makes the hub attractive for privilege abuse, traffic interception, policy bypass, or broad disruption.
Failure mechanism: Weak segmentation, excessive trust in the hub, or poor change control can let one error or compromise cascade across all dependent spokes.
Impact: The result can be enterprise-wide policy failure, loss of visibility, degraded resilience, or large-scale access and routing disruption.
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 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RR-01 — Roles, Responsibilities, and Authorities | Hub-and-spoke depends on clear central authority and spoke ownership. |
| PR.AA-05 — Protective Technology | The hub often enforces access and routing controls across dependent spokes. | |
| GV.SC-08 — Cybersecurity Supply Chain Risk Management | Hub-and-spoke concentration creates dependency and shared-service risk across connected environments. | |
| Recommendation — Define hub and spoke responsibilities so control decisions and escalation paths are unambiguous. Centralize enforcement where appropriate and validate that hub controls consistently protect connected systems. Assess central dependencies and reduce single-point concentration in shared connectivity and governance layers. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | A hub commonly serves as the controlled boundary between multiple connected segments or environments. |
| AC-6 — Least Privilege | Central hubs should broker only the access needed for governance and routing, not broad implicit trust. | |
| Recommendation — Use boundary protections at the hub to constrain traffic, trust, and exposure between spokes. Limit hub authority to the minimum needed and avoid granting broad transitive access across spokes. | ||
Practitioner Guidance
Why practitioners should care: Treat the hub as a high-consequence control surface, not just a convenient routing layer. The more functions you centralise, the more important it becomes to define ownership, recovery expectations, and the blast radius you are willing to accept.
Practitioner takeaway: Use the hub-and-spoke model when central control genuinely improves governance, but design it so the central point can fail safely rather than fail catastrophically.
Related resources from NHI Mgmt Group
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 October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org