Teams often assume serverless can be governed like a traditional host, but there is no persistent machine to anchor enforcement. Security has to move to identity-aware relationships between functions, APIs, and data stores. If policy is not derived from those relationships, serverless access becomes too broad or too stale to trust.
Why This Matters for Security Teams
Serverless segmentation fails when teams assume network placement is the control plane. In serverless, functions scale dynamically, run briefly, and inherit permissions through identities, event sources, and managed integrations rather than stable hosts. That shifts the real question from “what subnet is this in?” to “what can this function call, read, or assume?” Current guidance from the NIST Cybersecurity Framework 2.0 is useful here, but it has to be translated into identity-aware control design for ephemeral workloads.
This is where NHI governance becomes central. NHIs outnumber human identities by 25x to 50x in modern enterprises, and NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs. In serverless, those identities are often the segmentation boundary itself. If policy is not tied to function-to-function trust, data-store access, and event-trigger scope, segmentation becomes a paper exercise that does not match runtime behaviour. In practice, many security teams discover the gap only after a function has already been over-permissioned or a stale integration path has already been abused.
How It Works in Practice
Effective serverless segmentation starts with mapping relationships, not infrastructure. Teams should identify each function, its execution role, the events that can invoke it, the APIs it can call, and the data stores it can touch. The control objective is to reduce blast radius by making each trust edge explicit and narrowly scoped. That usually means separate roles per function, strict event source filtering, resource policies on queues and topics, and service-to-service authentication that is bound to workload identity rather than shared network access.
In cloud-native environments, NIST Cybersecurity Framework 2.0 helps anchor the governance model, especially for access control, asset visibility, and continuous monitoring. For serverless specifically, the policy model should be derived from what each function needs at runtime. That includes:
- Least-privilege execution roles with no broad wildcard permissions.
- Separate segmentation for development, test, and production event paths.
- Explicit allow lists for triggers, APIs, and downstream resources.
- Short-lived credentials or federated identity where possible, not long-term secrets in code.
- Continuous review of invocation chains so policy stays aligned as workflows change.
NHIMG research is especially relevant because serverless environments often inherit the same NHI problems seen elsewhere. The Ultimate Guide to NHIs highlights how excessive privilege and weak offboarding remain common, and those issues become harder to detect when identities are embedded in functions, pipelines, and managed services. Segmentation is therefore not just about containment, but also about lifecycle governance for every non-human identity that can move data or invoke another service. These controls tend to break down when teams reuse a single execution role across many functions because policy drift then turns a small trust failure into a platform-wide access pattern.
Common Variations and Edge Cases
Tighter segmentation often increases operational overhead, requiring organisations to balance isolation against deployment speed and policy complexity. That tradeoff is sharpest in event-driven architectures, where a single business transaction may span multiple queues, functions, and managed services. Best practice is evolving, and there is no universal standard for this yet, but the direction is clear: segment by identity and data sensitivity, not by assumed network zone.
Edge cases usually appear in shared libraries, cross-account integrations, and third-party event sources. A function may be isolated at the code level but still able to assume a broader role through an inherited trust policy. Similarly, a queue or topic may be treated as low risk while actually serving as the bridge between two sensitive domains. Teams should also be careful with “temporary” exceptions, because serverless platforms reward rapid reuse and those exceptions often become permanent. For broader control design, current guidance suggests pairing identity-aware segmentation with monitoring and periodic entitlement review, rather than relying on static perimeter rules alone.
Where this breaks down most often is in multi-team platforms with inconsistent tagging, unclear ownership, and shared deployment pipelines, because the trust graph changes faster than manual policy reviews can keep up.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST IR 8596 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | Serverless segmentation is fundamentally an access control and trust-boundary problem. |
| OWASP Non-Human Identity Top 10 | Serverless workloads rely on non-human identities that often become the real segmentation boundary. | |
| NIST Zero Trust (SP 800-207) | JIT access | Zero trust principles fit ephemeral functions better than network-centric segmentation. |
| NIST IR 8596 | Cyber AI monitoring can help detect abnormal function-to-function behaviour and policy drift. | |
| MITRE ATT&CK | T1528 | Compromised account and token abuse often underpins lateral movement in cloud and serverless paths. |
Use AI-assisted detection to flag anomalous invocation paths, privilege creep, and unusual data access.
Related resources from NHI Mgmt Group
- What do security teams get wrong about externalized authorization in serverless?
- What do security and privacy teams get wrong about behavioural segmentation?
- What do security teams get wrong about segmentation in healthcare?
- What do security teams get wrong about segmentation in AI threat scenarios?
