Notifications
Clear all
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.
NHIMG editorial — based on content published by StrongDM: Cloud Native Security: Definition, Challenges, and Solutions
By the numbers:
- 72% of organizations admit they moved to the cloud prematurely before they had the right skills or resources to operate securely.
- 75% of IT professionals say that transitioning to the cloud significantly expanded their organization's attack surface.
- 59% believe the transition to the cloud made their organization less secure.
Questions worth separating out
Q: How should security teams govern privileged access in cloud native environments?
A: They should treat privileged access as a cloud control problem, not just an administrator problem.
Q: Why do cloud native environments expand identity and access risk?
A: Because cloud systems change faster than traditional access reviews can follow.
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.
Practitioner guidance
- Inventory cloud-owned identity boundaries Map which access controls, credentials, logs, and configuration settings are customer-owned across cloud, cluster, container, and code layers.
- Remove default credentials from cloud resources Replace vendor-default logins and static administrative secrets with centrally governed access paths.
- Tighten cluster access to service boundaries Limit Kubernetes access to the smallest practical service scope and require authentication for control-plane and pod-level operations.
What's in the full article
StrongDM's full article covers the operational detail this post intentionally leaves for the source:
- How StrongDM frames the four-layer cloud native security model across cloud, cluster, container, and code.
- The article's practical discussion of PAM in cloud environments, including default credentials and access logging.
- The FAQ section's comparison between cloud-based and cloud native security models.
- The article's explanation of the 3 Rs of cloud security: rotate, repair, and repave.
👉 Read StrongDM's analysis of cloud native security controls and PAM →
Cloud native security and access control gaps: what teams miss?
Explore further
08/06/2026 7:01 pm
Cloud native security failures are usually identity failures first. The article correctly frames cloud, cluster, container, and code as layered security domains, but the operational choke point is still access. Default credentials, over-provisioned administrators, and weak visibility convert cloud scale into identity sprawl. For IAM and PAM teams, the lesson is that cloud-native security is an access governance problem with technical symptoms.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means privilege sprawl is often hidden until access is abused.
A question worth separating out:
Q: What should organisations do first when cloud access feels too broad?
A: Start by mapping where privileged access actually exists across cloud, Kubernetes, and supporting tooling. Then remove default credentials, narrow role scope, and replace persistent admin access with tighter approval and logging controls. A clear inventory usually reveals more risk than the team expected.
👉 Read our full editorial: Cloud native security still fails where PAM and access models lag
