TL;DR: As data volumes grow, legacy, vertically scaled architectures create bottlenecks, with read-heavy Command Center calls taking 30 seconds or more until a read-optimised Entity Lookup Service reduced responses to under 3 seconds, according to Commvault. The architectural shift matters because identity and access controls for modern platforms must now assume distributed services, independent scaling, and a centralized control plane.
At a glance
What this is: This is a Commvault analysis of why vertically scaled data infrastructure breaks down at modern volumes and how horizontal scaling plus a control plane restores manageable performance.
Why it matters: It matters because IAM, NHI, and platform teams increasingly govern distributed services that need consistent access oversight, not one-machine assumptions.
Context
Data infrastructure becomes an identity governance problem when the platform is no longer a single system with a single operating boundary. As services spread across machines and regions, access, administration, and auditability have to be designed for distributed execution rather than centralized handoffs.
Commvault’s article argues that the old pattern of scaling one machine upward eventually creates bottlenecks in performance and management. For practitioners responsible for identity and access controls, the architectural question is no longer only capacity planning. It is how to preserve control when services, workloads, and administrative functions are split across multiple nodes and environments.
Key questions
Q: How should security teams govern a single control plane that manages many environments?
A: Treat the control plane as a privileged administration tier, not just another interface. Give it tighter authentication, detailed logging, and change control because it concentrates the authority to affect multiple systems at once. The governance goal is not only uptime, but provable oversight over distributed operations.
Q: What breaks when platform services are scaled vertically instead of horizontally?
A: Vertical scaling can postpone capacity problems, but it leaves the governance model tied to one machine and one failure domain. As workloads grow, that creates rigidity in deployment, resilience, and administration. The control issue is that access and operational oversight remain too centralized for the way the platform actually runs.
Q: How do teams know whether a read-optimised lookup layer is safe for operational decisions?
A: Use it only when the team can clearly define what is authoritative and what is replicated. If a denormalized lookup service feeds operational decisions, the organisation must understand freshness, ownership, and sync boundaries. Otherwise faster responses can conceal stale state and inconsistent governance outcomes.
Q: What should IAM teams do when services can run independently across multiple machines?
A: Move from host-by-host thinking to service-by-service governance. Track each modular service’s identity, administrative scope, and lifecycle owner so scaling out does not create unmanaged access paths or inconsistent controls. Independent execution still needs central policy, but enforcement must follow the service boundary.
Technical breakdown
Why vertically scaled platforms create control bottlenecks
Vertical scaling adds memory and CPU to a single machine, but it does not change the underlying governance model. The article shows the limit of this approach: foundational services on one machine become rigid, harder to extend, and less resilient as workload diversity increases. In identity terms, this is the difference between one administrative choke point and a distributed service estate that needs consistent policy enforcement across instances. Once platform functions are spread across nodes, the control problem shifts from raw capacity to repeatable entitlement and service management.
Practical implication: review whether access and administrative models still assume a single execution point for services that now run across multiple machines.
How read-optimised services separate performance from system of record
The Entity Lookup Service is a classic read-optimised pattern. Instead of forcing every read-heavy request to traverse the transactional system of record, it maintains a denormalized copy of key relational data in a document store. That lets the platform answer user-facing queries faster without overloading write-heavy operational databases. For identity teams, the architecture matters because control surfaces often lag when every request depends on the same central store. Separating operational writes from query paths can improve responsiveness, but it also creates a governance requirement to understand which data is authoritative and where stale copies can affect decisions.
Practical implication: distinguish between authoritative control data and replicated lookup data so governance decisions are not made against stale state.
What a control plane changes in distributed administration
A global control plane does not remove distributed infrastructure. It makes distributed infrastructure governable by giving administrators one place to manage multiple environments. That is the architectural significance of the Global Command Center in the article: oversight is centralized even though execution remains spread across regions and CommCells. For IAM practitioners, this maps to a familiar pattern where policy, monitoring, and administrative intent are centralized while the underlying workloads remain distributed. The control plane becomes the place where consistency, visibility, and operational coordination are enforced.
Practical implication: treat the control plane as a privileged governance layer and apply stronger access, logging, and change controls there than on ordinary workload nodes.
NHI Mgmt Group analysis
Horizontal scale changes the identity problem from capacity to governability. Once platform services stop living on one machine, access control, administration, and audit all have to work across distributed runtime boundaries. That is not just an engineering refactor; it is a governance shift that makes single-instance assumptions unreliable. The practitioner conclusion is that identity controls must be designed for service estates, not servers.
Control planes become the new high-value identity surface. When multiple environments are managed from one administrative interface, the control plane becomes the place where policy, visibility, and operational authority converge. That concentrates risk as well as convenience. The implication for IAM and PAM teams is that the governance model must treat the control plane as a privileged tier with stricter oversight than ordinary service nodes.
Read optimisation and administrative centralisation solve different problems but create one shared requirement: authoritative state. A denormalized lookup layer can improve responsiveness, while a single pane of glass can simplify multi-environment oversight, but both depend on knowing which data and which actions are authoritative. Without that clarity, teams can accelerate the wrong decisions. The practitioner conclusion is to define source-of-truth boundaries before scaling either operations or governance.
Microservices do not reduce governance demand; they redistribute it. Breaking a monolith into smaller services makes deployment more flexible, but each new service still needs identity, logging, and lifecycle control. The article’s architectural direction reflects where enterprise platforms are headed: modular execution with centralized administration. The implication for practitioners is that identity governance must follow the same split, with local execution diversity and centralized policy enforcement working together.
What this signals
Control-plane concentration is now a governance pattern, not just an architecture choice: as platforms distribute execution across machines and regions, central administration becomes the place where privilege accumulates. IAM and PAM teams should expect the strongest control requirements to move upward into the management plane, while ordinary nodes become execution surfaces rather than governance anchors.
Horizontal scaling changes where trust is enforced: once services can be deployed independently, access decisions, logging, and lifecycle ownership need to travel with the service boundary instead of staying tied to one server. That is the practical difference between a modern platform and a legacy one.
Authoritative state becomes the deciding issue: if a platform uses replicated or denormalized data for speed, practitioners must know which layer can govern change and which layer is only for retrieval. Without that separation, operational convenience starts to override access discipline.
For practitioners
- Map privileged control surfaces Inventory which administrative consoles, service hosts, and control-plane functions can change platform-wide state, then classify them as privileged access paths. Focus review effort on the interfaces that affect multiple CommCells or services at once.
- Separate authoritative from replicated data Document which records are system of record and which are denormalized lookup copies, especially where access or operational decisions rely on the read layer. Require clear ownership for each source of truth.
- Apply stronger governance to control planes Put tighter authentication, logging, and change approval around the single administrative plane than around ordinary workload nodes. The control plane should be treated as a high-impact administrative tier.
- Review service lifecycle ownership across nodes Assign explicit owners for each modular service so deployment, access, and retirement are governed consistently when components can run on different machines. Avoid letting decentralised runtime choices create unmanaged administrative drift.
Key takeaways
- Vertical scaling eventually exposes a governance limit, not just a performance limit, because the platform’s operating assumptions no longer match how the services actually run.
- The article’s architectural shift shows why modern infrastructure needs both distributed execution and centralized administration to stay manageable at enterprise scale.
- IAM and PAM teams should focus on privileged control planes, authoritative state, and service-level ownership as platforms become more modular.
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 SP 800-53 Rev 5, 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 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Central administrative planes need tightly governed entitlements across distributed environments. |
| Recommendation — Apply PR.AA-05 to restrict who can administer multi-environment control planes and service orchestration layers. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Privileged control surfaces in the control plane need least-privilege administration. |
| Recommendation — Enforce AC-6 on control-plane and service-administration accounts that can change platform-wide state. | ||
| CIS Controls v8 | CIS-5 — Account Management | Modular services and central administration both require disciplined account ownership and review. |
| Recommendation — Use CIS-5 to inventory, own, and review administrative accounts across distributed services. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust principles — Zero Trust principles | Distributed execution and centralized administration fit continuous verification and explicit trust boundaries. |
| Recommendation — Apply Zero Trust principles to verify access at the control plane and around service boundaries. | ||
Key terms
- Control Plane: The control plane is the set of actions that create, configure, or manage a service. For AI workloads, it covers deployment and administration of the model platform, while data-plane permissions govern what the service and its identities can read or process.
- Horizontal scaling: Horizontal scaling increases capacity by adding more machines or instances instead of making one machine larger. It changes governance because responsibility, telemetry, and access paths are no longer concentrated in a single system, which forces teams to standardise how distributed components are managed.
- Microservices Architecture: A microservices architecture splits an application into smaller services that communicate over defined interfaces. This improves update speed and scaling, but it also increases the number of identity relationships, access scopes, and service-to-service permissions that must be governed consistently.
- Denormalized Lookup Layer: A denormalized lookup layer is a read-optimised copy of key data used to speed up queries without hitting the transactional system every time. It improves performance, but teams must still know which data is authoritative before using it for operational or security decisions.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 9, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org