Why do containers and serverless functions complicate traditional cloud security controls?

Why This Matters for Security Teams

Containers and serverless functions expose a gap between classic cloud controls and how modern workloads actually behave. Traditional controls assume durable hosts, stable IP ranges, and a predictable asset inventory. That assumption breaks when code is packaged into short-lived images, scheduled across clusters, or invoked only for milliseconds. Security teams then lose the context needed to answer a basic question: what is this workload, what may it call, and for how long?

This is why workload identity and lifecycle-aware governance matter. NHI Management Group has repeatedly highlighted that identity failures, not just network exposure, drive real-world compromise in ephemeral environments, including the Top 10 NHI Issues and the Ultimate Guide to NHIs. For containerized and serverless estates, the right control plane is not the perimeter, but the identity and policy layer tied to each execution.

Industry guidance is converging on this view. The NIST Cybersecurity Framework 2.0 and the CSA Cloud Controls Matrix both emphasize asset visibility, access governance, and continuous monitoring, but neither can be applied as a simple host-centric checklist in ephemeral environments. In practice, many security teams discover the control gap only after credentials, secrets, or over-broad service permissions have already been reused across transient workloads.

How It Works in Practice

Effective control design starts by treating each container or function as a workload identity rather than a machine. That means binding trust to cryptographic identity, runtime context, and declared purpose, not to a fixed host. Where possible, organisations should issue short-lived credentials per task, rotate secrets automatically, and revoke access when the job completes. Static keys embedded in images or environment variables create a persistence problem that traditional server controls were never meant to solve.

Policy also has to move from pre-defined rules toward request-time evaluation. A workload may need to call a database in one phase, a queue in another, and a third-party API only under a specific condition. Controls therefore need to evaluate who is calling, from where, with which service account, and for what action at runtime. The NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful baseline for access enforcement and monitoring, while the Ultimate Guide to NHIs maps those ideas to non-human identity operations.

• Use workload identity for every container, job, and function, rather than shared platform credentials.
• Prefer ephemeral tokens and JIT issuance over long-lived secrets in build files or environment variables.
• Attach policy to execution context, such as namespace, function, image provenance, or runtime attestation.
• Log identity, not just source IP, so response teams can trace which workload performed each action.

These controls tend to break down in autoscaling environments with weak inventory hygiene, because the workload may disappear before the security team can correlate its identity, permissions, and outbound activity.

Common Variations and Edge Cases

Tighter workload controls often increase operational overhead, requiring organisations to balance speed of delivery against identity discipline. That tradeoff becomes more pronounced in multi-cloud and platform engineering environments, where teams want reusable templates and minimal friction.

There is no universal standard for how to secure every container or function pattern yet. Best practice is evolving around short-lived credentials, policy-as-code, and runtime attestation, but the right implementation depends on whether the workload is stateless, event-driven, batch-oriented, or long-running. A batch job may tolerate a different credential cadence than a request-driven function, and a service mesh may reduce some network exposure while adding its own identity management complexity.

NHIMG research shows how common this gap is: in The 2024 Non-Human Identity Security Report, 35.6% of organisations cited consistent access across hybrid and multi-cloud environments as their top NHI challenge, and 88.5% said their non-human IAM lags behind or merely matches human IAM. That is a strong signal that container and serverless security cannot rely on yesterday’s host-based assumptions. For teams building governance programs, the practical answer is to anchor controls in lifecycle, identity, and policy, then adapt them to the workload’s actual execution model.

Related resources from NHI Mgmt Group

• Why do AI systems complicate traditional data security controls?
• Why do containers and serverless functions create blind spots for endpoint security?
• How should security teams cover ephemeral containers and serverless workloads in multi-cloud environments?
• What breaks when organisations rely on traditional security controls instead of CASB in cloud environments?