A trust model where one identity provider serves many applications through a central trust relationship. It simplifies onboarding and policy consistency for large application estates, especially when many service providers need to trust the same source of identity.
Expanded Definition
Hub-and-spoke federation is a trust architecture in which one central identity provider acts as the hub and multiple applications, APIs, or service providers rely on that single trust relationship as the spoke. In NHI and IAM programs, it is used to simplify authentication, centralise policy decisions, and reduce duplicate identity administration across large estates. That centralisation is also what distinguishes it from ad hoc point-to-point trust, where every application establishes its own relationship and policy logic.
In practice, the model is often implemented with SSO, token issuance, and federation assertions, but definitions vary across vendors on how much policy enforcement belongs at the hub versus the spoke. NHI Management Group treats the model as a governance pattern as much as a technical one, because the hub becomes the control plane for lifecycle, revocation, and assurance decisions. For a general control baseline, the NIST Cybersecurity Framework 2.0 reinforces the need to govern access and trust relationships consistently across the environment.
The most common misapplication is treating hub-and-spoke federation as a substitute for application-specific authorization, which occurs when teams assume central authentication alone is enough to manage downstream privilege.
Examples and Use Cases
Implementing hub-and-spoke federation rigorously often introduces dependency on the hub’s availability and policy quality, requiring organisations to weigh consistency against blast radius and operational coupling.
- A software platform uses one central IdP to federate access for dozens of internal engineering tools, reducing duplicated user and NHI onboarding.
- A cloud operations team issues tokens from a single trust domain so service accounts can authenticate to multiple environments without storing separate local secrets.
- A merger integration project connects acquired business applications to the corporate hub instead of building separate trust paths for every application pair.
- An organisation uses the hub to enforce policy changes, then rotates credentials and validates service account access against guidance in the Ultimate Guide to NHIs.
- A security team replaces legacy shared API keys with federated workload identity, aligning the design with NIST Cybersecurity Framework 2.0 principles for controlled access and governance.
These patterns are most effective when the hub also supports revocation, logging, and lifecycle control. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts, which makes a central federation hub valuable for discovery as well as access delivery. The same Ultimate Guide to NHIs also shows that 97% of NHIs carry excessive privileges, so federation should be paired with privilege scoping rather than assumed to solve it automatically.
Why It Matters in NHI Security
Hub-and-spoke federation matters because the hub concentrates trust. If that trust relationship is weakly governed, a compromise of the central identity plane can cascade into many applications, service accounts, and automation paths at once. For NHI security, this means the model can reduce sprawl while also increasing the importance of token hygiene, approval workflows, and revocation speed. It is especially relevant when workloads rely on long-lived secrets or when multiple teams share the same source of identity without consistent policy enforcement.
The risk is not theoretical. NHI Management Group reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and that 91.6% of secrets remain valid five days after the targeted organisation is notified. Those patterns make central federation a governance priority, not just an architecture preference, because delayed invalidation at the hub can leave every spoke exposed. For broader identity and access governance, NIST Cybersecurity Framework 2.0 helps anchor access control, monitoring, and response expectations, while the Ultimate Guide to NHIs provides the operational context for lifecycle control and visibility.
Organisations typically encounter the consequences after a central token issuer, trust broker, or identity provider is compromised, at which point hub-and-spoke federation becomes operationally unavoidable to inspect, contain, and reissue trust.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Covers access permissions and trust relationships that hub-and-spoke federation centralises. |
| NIST CSF 2.0 | PR.AC-7 | Supports authentication validation across federated identities and service access paths. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Federated NHI trust depends on strong identity lifecycle and inventory controls. |
Validate federated identities consistently at the hub and revoke trust quickly when compromise is suspected.
