The security split in which the cloud provider protects the underlying serverless infrastructure while the customer secures function code, permissions, secrets, and data handling. In practice, teams must still manage identity controls, dependency risk, and monitoring because the provider does not secure application logic for them.
What the shared responsibility model means in serverless
Serverless changes where responsibility sits, but it does not remove it. The provider still operates the managed runtime and infrastructure, while the customer remains accountable for application logic, configuration choices, access decisions, and the data that functions can reach.
This split is easy to misunderstand because the service feels “fully managed.” In practice, teams inherit the security consequences of the code they deploy, the permissions they grant, and the services their functions can call, even when the platform abstracts away servers, scaling, and patching.
What stays with the provider, and what stays with you
The provider typically secures the underlying compute fabric, isolation layer, availability of the platform, and much of the operational hardening of the serverless service itself. The customer is responsible for the function package, event sources, identity and access rules, secrets, data flows, and any business logic exposed through the function.
That boundary matters because security controls move upward into configuration and design. A serverless workload can be well served by least privilege, strong authentication, and disciplined secret handling, but those outcomes depend on the customer’s implementation rather than the platform alone. For access to functions and APIs, organisations often map their controls to established guidance such as NIST SP 800-63 Digital Identity Guidelines and RFC 7523 when token-based service authentication is in play.
Why identity, permissions, and secrets matter so much
Serverless functions often need to call storage, queues, databases, and third-party APIs, which means their permissions can become the main security boundary. If a function is over-privileged, an attacker who reaches the code path may gain broad access to downstream services and data. Secret leakage is equally important because credentials embedded in code, environment variables, or build artefacts can be reused long after the function is deployed.
These risks are especially sharp in cloud-native environments because the same design patterns that improve velocity can also spread trust too widely. The OWASP Non-Human Identity Top 10 is useful here as a lens on secret sprawl, overprivilege, and lifecycle gaps in machine-to-machine access, while NIST Cybersecurity Framework 2.0 gives a broader way to organise governance across protect, detect, respond, and recover.
Monitoring, dependency risk, and operational blind spots
Serverless applications depend on package libraries, event triggers, managed services, and cloud telemetry. That dependency chain can hide vulnerabilities, make provenance harder to validate, and reduce visibility into what a function did at runtime. Teams should expect security decisions to include monitoring and detection design, not just deployment hardening.
Because application logic is still customer-owned, the quality of observability becomes part of the shared model. If logs are incomplete or function-to-function relationships are unclear, teams may miss abuse patterns, failed authorisation checks, or unusual invocation spikes until after impact. Supply-chain and runtime integrity concerns are also relevant when dependencies are pulled into functions from external sources, which is why guidance such as SLSA is often helpful for build provenance, and NIST CSF 2.0 remains useful for organising detection and recovery expectations.
Risk and Threat Considerations
Serverless shifts attackers toward configuration mistakes, excessive permissions, stolen tokens, exposed secrets, and insecure event paths. The most damaging failures often occur when a small logic flaw in a function combines with broad cloud permissions or reused credentials, turning a single invocation path into access across data stores and dependent services.
Failure mechanism: A function is deployed with more access than it needs, or its secret material is exposed through code, logs, environment variables, or a build pipeline, allowing an attacker or an unintended caller to reach downstream systems through the function’s trust relationship.
Impact: The result can be data exposure, service abuse, unauthorized actions, lateral movement into connected cloud services, or persistence through reused access material that survives ordinary code changes.
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 addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | Serverless functions depend on tightly scoped permissions for runtime access. |
| DE.CM-01 — Network, Physical, and Software Monitoring | Serverless needs runtime visibility to detect abuse, failures, and unusual invocation patterns. | |
| Recommendation — Apply least-privilege access to each function and its downstream service permissions. Instrument function invocations and downstream calls for continuous monitoring. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Serverless trust boundaries are driven by scoped permissions and constrained execution roles. |
| IA-5 — Authenticator Management | Serverless workloads rely on secrets, tokens, and keys that must be protected and rotated. | |
| Recommendation — Restrict function permissions to the minimum required for each workflow. Manage and rotate function credentials and tokens throughout their lifecycle. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Serverless functions commonly depend on exposed secrets, tokens, and API keys. |
| NHI-05 — Overprivileged NHI | Serverless runtime identities can accumulate permissions that exceed function needs. | |
| NHI-07 — Long-Lived Secrets | Serverless deployments often fail when static credentials persist across releases. | |
| Recommendation — Prevent secrets from being embedded in code, logs, or build artefacts. Right-size function permissions and remove unnecessary downstream access. Replace long-lived function secrets with short-lived, rotated credentials. | ||
| SLSA | Supply-chain integrity | Serverless functions depend heavily on third-party packages and build provenance. |
| Recommendation — Verify build provenance and dependency integrity before deploying function code. | ||
Practitioner Guidance
Governance implication: Treat serverless security as a boundary-management problem, not a hosting problem. Ownership should explicitly cover function permissions, secret handling, dependency provenance, and logging quality, because these are the controls that most directly determine whether the shared model is actually safe.
What to watch for: Overly broad execution roles, hard-coded secrets, opaque third-party dependencies, and missing invocation telemetry are the recurring signs that the customer side of the shared model is carrying too much risk.
Practitioner takeaway: If the platform owns the servers, you still own the trust decisions.
Related resources from NHI Mgmt Group
- Shared Responsibility Model
- Why does the shared responsibility model create security gaps in serverless container environments?
- Who is responsible for securing cloud workloads in a shared responsibility model?
- How should security teams secure Microsoft Azure workloads in a shared responsibility model?
