Cloud native security still fails where PAM and access models lag

At a glance

What this is: This is a cloud native security analysis arguing that traditional security and access models break down as cloud, Kubernetes, containers, and code increase the attack surface.

Why it matters: It matters because IAM, PAM, and NHI programmes all inherit the same cloud-native access problems when credentials, privileges, and visibility are not reworked for distributed environments.

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.

👉 Read StrongDM's analysis of cloud native security controls and PAM

Context

Cloud native security is the practice of protecting cloud environments, clusters, containers, and code as a single attack surface rather than treating the cloud as an extension of on-premises infrastructure. The problem is that many organisations kept legacy access assumptions while moving into environments where privileges, services, and deployment paths change far faster than traditional controls can track.

That gap is directly relevant to IAM, PAM, and NHI governance because the same environment that expands application velocity also expands credential sprawl, over-privilege, and observability gaps. In cloud-native programmes, access management has to be designed for distributed infrastructure, not retrofitted after the fact.

Key questions

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. Enforce least privilege, remove default credentials, require session logging, and keep elevated access task-scoped wherever possible. The goal is to reduce the blast radius of each identity and make every privileged action auditable.

Q: Why do cloud native environments expand identity and access risk?

A: Because cloud systems change faster than traditional access reviews can follow. Infrastructure is distributed, services are ephemeral, and permissions often accumulate across clusters, pipelines, and admin roles. That combination makes stale privilege, inconsistent policy, and weak visibility more likely unless identity controls are built into the environment from the start.

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. In cloud native environments, workloads move, scale, and disappear quickly, so static roles and delayed reviews miss risk. Teams end up with broader access than they intended and less visibility than they need.

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.

Technical breakdown

Cloud native security and the shared responsibility model

Cloud native security starts with the shared responsibility model. Cloud providers secure the underlying infrastructure, but customers remain responsible for configuration, identity controls, default credential changes, logging, and access policy. In practice, the control failure is often not the platform itself but the assumption that managed cloud services automatically secure themselves. Once teams move into hybrid or multi-cloud estates, visibility and configuration drift become the main technical problem, because every control plane has different identity and access boundaries.

Practical implication: teams should map which identity and access controls remain customer-owned in each cloud before treating any environment as secure.

Kubernetes clusters, privilege, and lateral movement risk

Kubernetes clusters create a dense trust environment because pods, services, and control-plane objects communicate continuously. If an attacker reaches one workload or one overly privileged identity, they can often move laterally across adjacent cluster resources. That is why least privilege, network segmentation, and cluster-level authentication are not optional add-ons. The technical risk is compounded when access is granted broadly to make deployment easier, because operational convenience can silently become privilege accumulation.

Practical implication: restrict cluster access by service boundary, not by convenience, and continuously review who can reach control-plane and workload identities.

PAM for cloud native access and ephemeral credentials

Privileged access management in cloud native environments is about more than administrator accounts. It must control default credentials, replace static access where possible, and log every elevated action across databases, servers, and clusters. StrongDM's article also points to the need for stronger security policies around approved admins, because excessive permissions remain dangerous even when the user is legitimate. In cloud-native operations, ephemeral or task-scoped access is more useful than persistent privilege because the blast radius is smaller and auditability is better.

Practical implication: move high-risk cloud access toward task-scoped privilege with complete session logging and remove default credentials from all platforms.

Threat narrative

Attacker objective: The attacker aims to turn one weak cloud identity or misconfigured access path into control over a wider cloud estate.

1. Entry begins when cloud environments are left with default credentials or broadly exposed access paths, giving attackers an easy foothold into cloud resources.
2. Escalation follows when excessive permissions or weak cluster boundaries let the attacker reach additional workloads, control-plane functions, or sensitive infrastructure.
3. Impact occurs when compromised cloud access is used to tamper with resources, exfiltrate data, or disrupt cloud-native services across the environment.

Breaches seen in the wild

• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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 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.

Standing privilege is the cloud native control assumption most likely to fail. Traditional privilege models assume access can be granted, held, and monitored over time. Cloud environments break that premise because identities are distributed, workloads are ephemeral, and administrative scope changes faster than review cycles can keep up. Practitioners should treat persistent privilege as a structural mismatch with cloud-native operations.

Cloud native security demands lifecycle governance for service identities, not just human admins. The article discusses developers and DevOps workflows, but the deeper issue is that machine identities now sit inside the same trust fabric as human operators. NHI governance has to cover rotation, revocation, and least privilege across cloud services, deployment tooling, and platform access. That is where cloud-native resilience either holds or collapses.

Identity blast radius is now the decisive cloud risk metric. Identity blast radius: the amount of cloud infrastructure, data, and control that one credential or role can reach before detection or revocation. In cloud-native estates, large blast radius is created by default credentials, broad admin roles, and poor access logging. Teams should measure that exposure directly rather than relying on generic cloud posture language.

Cloud native security is validating the Zero Trust argument for privileged access. The article's PAM section reinforces that trusted internal users still need controlled, logged, and bounded access. That aligns with the Zero Trust view that trust should be continuously earned, not inherited from network location or role history. Security teams should use this as a forcing function to re-evaluate where persistent privilege still exists.

From our research:

• 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.
• For a broader control baseline, see OWASP Non-Human Identity Top 10 for the most common NHI failure modes teams should be measuring against.

What this signals

Cloud native programmes are moving beyond perimeter thinking, but many access models still assume identities are stable, centrally managed, and easy to review later. That assumption does not survive distributed cloud operations, where privilege often expands faster than governance.

Identity blast radius: the practical measure of how much cloud infrastructure one credential, role, or service account can reach. Teams that do not measure blast radius end up managing cloud security as a configuration issue when it is really an identity scope problem.

NHI and PAM programmes should now be aligned around cloud control plane visibility, privileged session logging, and service identity governance. The organisational question is no longer whether the cloud is secure in principle, but whether access can be proven narrow enough in practice.

For practitioners

• Inventory cloud-owned identity boundaries Map which access controls, credentials, logs, and configuration settings are customer-owned across cloud, cluster, container, and code layers. Use that map to identify where legacy on-premises assumptions still govern access decisions.
• Remove default credentials from cloud resources Replace vendor-default logins and static administrative secrets with centrally governed access paths. Prioritise systems where default permissions still include admin-level access because those paths are the easiest to exploit.
• 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. Pair that with network segmentation so one compromised pod cannot freely reach adjacent resources.
• Apply task-scoped privilege to cloud administration Use time-bound, session-recorded access for high-risk cloud tasks instead of persistent admin rights. That reduces the opportunity for misuse and creates an audit trail for every privileged action.

Key takeaways

• Cloud native security failures usually start with identity and access assumptions that no longer fit distributed infrastructure.
• The article's own data points to a large cloud security maturity gap, especially around skills, attack surface growth, and perceived risk.
• The control priority is to narrow privilege, remove default access, and make cloud actions fully observable across every layer.

Key terms

• Cloud Native Security: Cloud native security is the practice of protecting applications, platforms, and data in environments built around distributed cloud services, containers, and infrastructure automation. It treats identity, configuration, and observability as core controls because the environment changes too quickly for static perimeter models to work well.
• Identity Blast Radius: Identity blast radius is the amount of infrastructure, data, and control a single credential, role, or service account can reach before it is detected or revoked. In cloud native environments, it is a more useful risk lens than simple account counts because one overpowered identity can affect many systems at once.
• Shared Responsibility Model: The shared responsibility model divides security duties between the cloud provider and the customer. The provider secures the underlying cloud platform, while the customer must secure configuration, access controls, credentials, and logging. Misunderstanding that split is a common source of cloud security failure.
• Standing Privilege: Standing privilege is persistent access that remains available beyond the immediate task that required it. In cloud native operations, standing privilege creates unnecessary exposure because identities, workloads, and admin needs change quickly, but the access often stays in place longer than the risk justifies.

Deepen your knowledge

Cloud native access governance and privileged control are covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to align cloud security with identity governance, it is a useful place to start.

This post draws on content published by StrongDM: Cloud Native Security: Definition, Challenges, and Solutions. Read the original.