TL;DR: Cloud management platforms centralize orchestration, cost, monitoring, and security controls across hybrid environments, but the source article shows that identity, governance, and compliance remain only one part of the stack according to Zluri. The practical issue is that cloud control planes can simplify operations without solving who or what should hold access, how that access is reviewed, or when it should be revoked.
At a glance
What this is: This is a vendor roundup of cloud management platforms, and its core finding is that cloud orchestration tools improve visibility and control but still depend on underlying identity governance.
Why it matters: It matters to IAM practitioners because cloud management platforms can broaden access paths for humans, service accounts, and automated workflows without resolving entitlement scope, lifecycle, or review discipline.
👉 Read Zluri's guide to the 14 best cloud management platforms in 2026
Context
Cloud management platforms centralize provisioning, monitoring, orchestration, and policy enforcement across hybrid and multi-cloud environments, but they do not remove the identity problem underneath them. Once cloud operations become self-service and API-driven, access scope, review, and de-provisioning become identity governance issues as much as infrastructure issues.
For IAM, NHI, and platform teams, the real question is not whether a CMP can automate cloud administration. It is whether the platform is being introduced with enough role design, entitlement boundaries, and lifecycle control to prevent cloud convenience from turning into standing privilege and unmanaged access drift.
Key questions
Q: How should security teams govern access in cloud management platforms?
A: They should treat the CMP as an access broker, not just an operations tool. That means mapping every role, workflow, and service account to a named owner, then reviewing whether the permissions are still needed after provisioning ends. If the platform can create access faster than it can retire it, governance is already behind.
Q: Why do cloud management platforms create non-human identity risk?
A: Because every automated workflow can create credentials, delegated permissions, and service accounts that persist beyond the task they were meant to support. The risk is not the platform itself, but the scale at which it can multiply identities faster than lifecycle governance can track them.
Q: What do teams get wrong about policy-based controls in cloud platforms?
A: They assume policy checks and RBAC are enough on their own. In practice, policy enforcement only works if the identities behind the actions are properly scoped, logged, reviewed, and offboarded. Without that, the platform can look controlled while the underlying access model still drifts.
Q: How do organisations know if their cloud governance is working?
A: Look for evidence that access can be traced from request to owner to removal, across both human and non-human identities. If teams can see cloud spend and resource usage but cannot explain who still holds access or why, governance is incomplete.
Technical breakdown
Cloud management platform governance and access control
A cloud management platform is an orchestration layer that brokers requests across cloud resources, policy engines, and service catalogs. Its governance value depends on how it mediates identity, because the platform often becomes the decision point for who can provision, modify, or retire infrastructure. Role-based access control, policy checks, logging, and approval paths only work when the identities behind them are cleanly defined and continuously governed. In practice, CMPs can reduce operational friction while still amplifying access if roles are too broad or service accounts are over-permissioned.
Practical implication: map every CMP action to a named identity and entitlement before the platform is rolled out broadly.
Self-service portals, automation, and non-human identity sprawl
Self-service portals and automated workflows are the most attractive parts of a CMP, but they also create the fastest path to NHI sprawl. Every provisioned resource can introduce service accounts, API keys, tokens, certificates, or delegated roles that outlive the task they were created for. When automation is used to accelerate delivery, the control question becomes whether the new identity artefacts are traceable, scoped, and revoked on schedule. Without that discipline, the platform turns cloud governance into a scale problem rather than a control problem.
Practical implication: inventory the identities created by each workflow and tie them to ownership, expiration, and revocation rules.
Governance, compliance, and audit evidence in multi-cloud control planes
Governance features in CMPs often promise policy enforcement, auditing, and reporting across multiple clouds, but those functions only create value if the evidence is identity-specific and lifecycle-aware. Audit logs that show a resource was created are not enough unless they also show who or what created it, which permissions were used, and whether access remained justified after the workflow ended. This is where cloud platforms intersect with NHI governance: control planes can surface activity, but they do not by themselves prove entitlement correctness or offboarding completeness.
Practical implication: require audit trails that connect provisioning events to identity ownership, access scope, and offboarding status.
Breaches seen in the wild
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
- ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Cloud management platforms are becoming identity control planes by accident, not by design. The article focuses on orchestration, monitoring, cost, and security, but each of those functions depends on identity decisions hidden underneath the platform. That means the CMP can end up governing access paths without owning lifecycle discipline, which is where entitlement drift begins. Practitioners should treat CMP deployment as an identity architecture decision, not just an operations upgrade.
Policy-based access without lifecycle enforcement is a governance gap, not a control strategy. The source article praises role-based controls, compliance checks, and centralized dashboards, but those controls are only partial if service accounts, API keys, and delegated roles are not offboarded when tasks end. This is the specific failure mode many cloud programmes miss: access is granted through the platform, but never retired with the same rigour. The practical conclusion is that CMP governance must be matched to identity lifecycle governance.
Self-service cloud delivery expands the attack surface by multiplying non-human identities. Every portal request, template, and automation path can generate new credentials and permissions faster than human review cycles can track. That is why cloud governance and NHI governance are converging into the same operating problem. Teams that still separate infrastructure control from identity control will keep discovering access they cannot confidently explain.
Cloud cost optimisation and identity governance are now linked operational disciplines. The article treats cost, performance, and security as separate CMP benefits, but over-provisioned access and unmanaged automation create both security waste and financial waste. This is where the field needs better cross-domain thinking: entitlement sprawl is not just a risk issue, it is a cloud efficiency issue. Practitioners should fold identity scope review into every cost and resource review cycle.
Named concept: identity drift inside cloud control planes. Cloud platforms can preserve the appearance of governance while the actual identities behind workflows accumulate permissions, tokens, and exceptions across multiple environments. That drift is especially hard to see in hybrid and multi-cloud estates because the control plane presents a unified experience while the identity estate remains fragmented. The lesson for practitioners is that platform centralisation does not equal identity centralisation.
From our research:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- That leaves 38% with no or low visibility and a further 47% with only partial visibility, which is why cloud control planes cannot be treated as complete identity governance systems on their own.
- For lifecycle governance context, see NHI Lifecycle Management Guide for how provisioning, rotation, and offboarding need to stay tied together.
What this signals
Identity drift inside cloud control planes: the more a CMP centralises orchestration, the easier it becomes to lose sight of which identities were created to support which workflows. That drift is most dangerous when provisioning speed outpaces lifecycle review, because the platform can keep operating while access responsibility quietly fragments across teams and clouds.
With 1 in 4 organisations already investing in dedicated NHI security capabilities and another 60% planning to do so within twelve months, per The State of Non-Human Identity Security, cloud governance programmes will increasingly be measured by how well they control machine access, not just human access.
Teams should expect CMP governance to converge with identity governance, zero trust design, and audit evidence requirements. Where cloud operations once sat apart from IAM, self-service infrastructure now forces the same questions about ownership, expiry, and accountability into one programme.
For practitioners
- Bind CMP actions to named identities Require every provisioning, orchestration, and de-provisioning action to resolve to a specific human, service account, or automation identity before the platform is approved for broad use.
- Inventory non-human identities created by workflows Track the service accounts, API keys, tokens, and certificates generated by self-service catalog items, automation jobs, and cloud templates, then assign owners and expiry rules.
- Connect audit logs to entitlement lifecycle Review whether logs show who approved access, what permissions were granted, when they were last used, and whether they were revoked after the workflow completed.
- Fold access review into cloud governance Add CMP-generated access paths to recertification and exception review so cloud convenience does not bypass existing identity governance controls.
Key takeaways
- Cloud management platforms improve orchestration, but they do not eliminate the identity governance burden underneath cloud access.
- The main risk is not just resource sprawl, but non-human identity sprawl created by self-service and automation paths.
- Practitioners should tie every cloud workflow to ownership, entitlement scope, and offboarding before treating CMP governance as complete.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Cloud automation can create lingering credentials and service accounts. |
| NIST CSF 2.0 | PR.AC-4 | CMP role controls and access logging map directly to managed access permissions. |
| NIST Zero Trust (SP 800-207) | AC-6 | Cloud self-service must enforce least privilege across dynamic access paths. |
Map CMP entitlements to PR.AC-4 and validate least privilege across cloud workflows.
Key terms
- Cloud Management Platform: A cloud management platform is a control layer that helps organisations provision, monitor, and govern resources across cloud environments. It centralises operational tasks, but the underlying identity model still determines who or what can act, which permissions persist, and how access is retired.
- Non-Human Identity: A non-human identity is any machine or workload credential used by software instead of a person, including service accounts, API keys, tokens, and certificates. In cloud platforms, these identities often multiply through automation and must be governed with the same care as human access, but on a faster lifecycle.
- Identity Drift: Identity drift is the gradual mismatch between intended access and actual access over time. In cloud control planes, it appears when workflows create new permissions, exceptions, or credentials faster than governance teams can review, revoke, or reconcile them.
- Access Lifecycle: Access lifecycle is the full sequence of granting, using, reviewing, and removing access. For cloud management platforms, the critical issue is whether that lifecycle follows every human and non-human identity created by self-service or automation, especially when resources are short-lived.
Deepen your knowledge
Cloud management platform governance now depends on how well teams control non-human identities, and that is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your cloud programme is growing faster than your identity controls, this is the right starting point.
This post draws on content published by Zluri: IT Teams 14 Best Cloud Management Platforms in 2026. Read the original.
Published by the NHIMG editorial team on 2026-03-12.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org