Runtime groups organise the gateway runtimes themselves. They define the configuration boundary for services, routes, certificates, plugins, and control plane management. Custom teams define who can access those runtimes and which entities they can change. In practice, runtime groups control the technical scope, while teams and permissions control human authority over that scope.
Runtime groups versus custom teams: the clean mental model
Runtime groups are the technical boundary. They collect gateway runtimes into a manageable scope so configuration, certificates, plugins, routes, and control plane administration apply to the right runtime set. Custom teams are the human boundary. They define which people can see, manage, or modify those runtimes, so the two objects solve different problems even though they interact in the same platform.
That distinction matters because a runtime group is about what exists and how it behaves, while a team is about who may act on it. If you blur them, you end up confusing platform topology with access governance, which makes operational ownership harder to reason about and increases the chance of misdirected changes.
What each object actually controls in API management
A runtime group is the container for gateway scope. It determines where shared runtime settings live and where changes propagate, which is why it is the right construct for platform consistency, environment separation, and configuration rollout. If a route, plugin, or certificate should apply to a specific runtime estate, the runtime group is the object that establishes that estate.
A custom team is an access wrapper around that estate. It does not define the runtime itself; it defines the administrative relationship to it. In practice, teams determine who can enter the management surface, assign responsibility, and restrict edits to authorised operators or service owners. The technical boundary remains the runtime group, but the governance boundary is enforced through the team.
This separation is especially useful in multi-environment operations. You can keep a runtime group aligned to a production, staging, or regional deployment pattern while giving different teams different levels of authority over each scope. That lets platform engineers standardise the runtime while application teams or regional operators retain only the access they need.
How to think about ownership, change control, and delegation
The easiest way to distinguish them is to ask two questions. First: what set of runtimes should share configuration and lifecycle management? That points to the runtime group. Second: who should be allowed to administer that set? That points to the custom team.
From an operational standpoint, runtime groups support consistency and blast-radius control, because they define the scope in which a configuration change applies. Custom teams support delegation and separation of duties, because they prevent every user from inheriting the same level of control over every runtime. If you need to delegate safely, you typically create the runtime scope first and then attach the team permissions that match the intended authority model.
That ordering is important. Teams should usually map to an already-defined runtime scope, not the other way around. If access policy is driving the shape of the runtime estate, the platform usually becomes harder to govern, because permissions start to reflect organisational convenience rather than technical reality.
Risk and Threat Considerations
The main risk is mixing up scope and authority. When runtime groups are treated like teams, operators may grant broader change rights than intended, or they may assume that membership implies technical control over a runtime estate when it does not. The opposite error is also common: users may think they control a runtime because they belong to a team, when the underlying group boundary still prevents the change.
Failure mechanism: Misaligned group and team design creates overbroad access, weak segregation of duties, and change paths that are harder to review or revoke. In API platforms, that can translate into unintended configuration drift, certificate exposure, or plugin changes that apply more widely than the operator expected.
Impact: The result is not just administrative confusion. It can become a control failure that affects routing, authentication material, runtime integrity, and the reliability of production APIs. In the worst case, an access mistake at the team layer can give a user authority over a runtime scope that was meant to stay tightly controlled.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Teams govern who can change management functions across runtime scopes. |
| Recommendation — Map runtime-management permissions to function-level authorization and restrict admin actions by role. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Custom teams should limit who can administer each runtime group. |
| AC-5 — Separation of Duties | The runtime boundary and team authority should remain distinct controls. | |
| Recommendation — Assign only the minimum admin rights needed for each runtime group. Split runtime ownership and approval rights to reduce change-risk concentration. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The answer hinges on distinguishing technical scope from authorised access. |
| A.8.9 — Configuration management | Runtime groups define the configuration boundary for shared API runtime settings. | |
| Recommendation — Define and enforce access rules separately from runtime topology. Group runtimes so shared configuration changes are controlled and traceable. | ||
Practitioner Guidance
What to verify: Confirm that every runtime group has a clearly defined operational purpose, and that each custom team maps to a deliberate authority model over that purpose. If you cannot explain why a team needs access to a specific runtime group, the permission is probably too broad.
Decision rule: Use runtime groups to express technical boundaries and change domains; use custom teams to express delegated administrative rights. If a request is about “who can manage it,” treat it as a team question. If it is about “what shares the same runtime configuration,” treat it as a runtime-group question.
Practitioner takeaway: Good API management separates platform shape from human authority. The runtime group defines the control surface, and the custom team defines who is trusted to touch it, so keep those concerns distinct when designing access and ownership.
Related resources from NHI Mgmt Group
- What is the difference between code scanning and runtime identity monitoring?
- What is the difference between an API-management-first MCP strategy and an AI-runtime-first control plane?
- What is the difference between API discovery, posture management, and runtime protection?
- What is the difference between runtime protection and NHI lifecycle management?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
