Topic starter
08/06/2026 5:03 pm
TL;DR: Cloud native security is built around protecting cloud, cluster, container, and code layers, but StrongDM argues that 72% of organisations moved to the cloud before they had the right skills or resources to operate securely, leaving access control and observability gaps. The real issue is not cloud adoption itself, but whether IAM, PAM, and lifecycle governance were redesigned for cloud-native conditions.
Editorial analysis by NHI Mgmt Group, based on content published by StrongDM: “Cloud Native Security: Definition, Challenges, and Solutions”.
By the numbers:
- 72% of organisations admit they moved to the cloud before they had the right skills or resources to operate securely.
- Breaches caused by cloud vulnerabilities have increased by 540% since 2016.
- 75% of IT professionals say transitioning to the cloud significantly expanded their organization's attack surface.
Key questions
Q: What breaks when teams keep on-premises access models in the cloud?
A: The main failure is that access is granted as if assets were stable and centrally managed.
Q: When should teams prioritise PAM over additional cloud tooling?
A: Prioritise PAM when default credentials, excessive permissions, or weak privilege logging are the main exposure.
Q: What are the signs that cloud access management is failing in an organisation?
A: Common signs include orphaned accounts, inconsistent permissions across platforms, delayed de provisioning when employees change roles, and weak visibility into who accessed what and when.
Practitioner guidance
- Rebuild access controls around cloud-native runtime conditions Review whether current IAM and PAM controls assume static hosts, stable users, and predictable access paths.
- Replace default cloud credentials with governed privileged access Find cloud environments and resources that still rely on default login credentials or broad admin accounts, then move them into a controlled privileged access model with logging and task-based access scope.
- Apply least privilege to cluster communication paths Define which users, services, and pods can reach cluster components, then restrict pod-to-pod and user-to-cluster access with network policies, authentication, and explicit permission boundaries.
Bottom line: Cloud native security fails when organisations keep using access models that were designed for slower, more static environments.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
08/06/2026 7:01 pm
Cloud native security fails first at the access model, not the cloud layer. The article's central message is that organisations often secure the provider boundary while leaving identity and permission design rooted in on-prem assumptions. That creates a mismatch between how cloud systems behave and how access is governed. The practical conclusion is that cloud security programmes have to start from runtime access, not from perimeter inheritance.
A few things that frame the scale:
- Kubernetes production adoption has surged from 66% in CNCF's 2023 survey to 82% in 2025.
A question worth separating out:
Q: How should teams align IAM and PAM for cloud native security?
A: IAM should define who or what is eligible for access, while PAM should govern how privileged access is issued, constrained, and logged in cloud environments. Treat them as complementary controls rather than separate programmes, because cloud-native risk emerges when identity assignment and privilege execution are managed in different silos.
👉 Read our full editorial: Cloud native security still fails where PAM and access models lag
This post was modified 4 days ago by NHI Mgmt Group