Serverless does not remove identity risk because functions still depend on roles, keys, tokens, and permissions to operate. If those identities are over-privileged or exposed, attackers can deploy code, reach data, and hide activity inside trusted cloud APIs. Governance has to follow the identity, not the runtime model.
Why This Matters for Security Teams
Serverless changes where code runs, not whether identity controls matter. Every function still depends on a cloud principal, an execution role, API keys, or tokens to read data, invoke services, and write logs. If that identity is over-privileged, broadly reusable, or difficult to rotate, the attack surface simply moves into provider-managed infrastructure. Guidance from the NIST Cybersecurity Framework 2.0 still applies: governance must follow assets and access, not deployment labels.
For non-human identities, serverless often creates false confidence because short-lived compute looks “ephemeral” while the permissions behind it remain persistent. That gap is exactly where attackers operate, especially when functions can chain into queues, storage, secrets managers, and downstream APIs without a human ever seeing the full path. NHIMG’s Top 10 NHI Issues consistently frames this as an identity lifecycle problem, not a runtime problem. In practice, many security teams encounter NHI abuse only after a serverless function has already been used to reach sensitive data, rather than through intentional governance of the identity that function inherited.
How It Works in Practice
Strict nhi governance for serverless starts with the execution identity, not the function code. A function should receive only the permissions it needs for one task, for one environment, for one short window. Current best practice is evolving toward just-in-time access, short TTL secrets, and workload identity that can be verified cryptographically at runtime. The SPIFFE workload identity specification is relevant here because it treats the workload as the subject of trust, which is more durable than relying on static API keys embedded in deployment pipelines.
Practitioners usually break the problem into a few controls:
- Use a dedicated role per function or per service boundary, not a shared broad role across many functions.
- Issue ephemeral credentials at invocation time, then revoke them automatically after the task completes.
- Store secrets in managed secret stores and rotate them aggressively, especially if functions call third-party APIs.
- Log identity use at the request level so that downstream API calls can be traced back to the exact function and trigger.
- Evaluate policy at runtime, because a serverless function’s context can change faster than static RBAC reviews can keep up.
NHIMG research notes that lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations in The State of Non-Human Identity Security, which is a useful reminder that serverless still fails when static secrets are left in place. Guide to SPIFFE and SPIRE is also relevant for teams building stronger workload identity handling across ephemeral services. These controls tend to break down when functions inherit broad platform roles in highly dynamic event-driven architectures because the blast radius grows faster than IAM review cycles can respond.
Common Variations and Edge Cases
Tighter serverless identity controls often increase operational overhead, requiring organisations to balance deployment speed against revocation, policy review, and observability demands. That tradeoff is real, especially in environments that create thousands of functions, ephemeral jobs, or event handlers per day. There is no universal standard for this yet, but current guidance suggests that the right answer is usually not “more serverless-native trust,” it is narrower trust boundaries and shorter-lived credentials.
Some edge cases need special handling. Functions that act as integration glue across SaaS tools often accumulate permissions over time, so a once-minimal role can become a privileged orchestration path. Multi-account or multi-tenant serverless platforms also complicate governance because the same code may run under different identities depending on trigger source, region, or tenant. In those cases, static role naming is not enough; teams need context-aware authorisation and strong separation of duties. The 52 NHI Breaches Analysis and Ultimate Guide to NHIs — Regulatory and Audit Perspectives reinforce that auditability matters as much as prevention. In practice, the hardest failures appear when serverless functions are allowed to reuse long-lived secrets across pipelines, because one compromised execution path can quietly become a reusable identity foothold.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Serverless often fails when non-human credentials are long-lived or reused. |
| OWASP Agentic AI Top 10 | Runtime authorization patterns overlap with autonomous workload governance. | |
| CSA MAESTRO | MAESTRO covers workload identity and policy for ephemeral cloud-native execution. | |
| NIST AI RMF | GOVERN | AI RMF governance principles support accountability for dynamic non-human execution. |
| NIST CSF 2.0 | PR.AC-4 | Access control needs to limit what serverless principals can reach. |
Inventory function identities and replace persistent secrets with short-lived, rotated credentials.
