Notifications
Clear all
Topic starter
12/06/2026 9:26 pm
TL;DR: The governance issue is not speed alone but avoiding authorization drift when policy decisions are scattered across functions, according to Cerbos. Cerbos now supports running its PDP inside AWS Lambda as either a standalone function or an extension layer, with Cerbos Hub managing policy and audit logs centrally for consistent authorization across serverless, container, and VM workloads.
NHIMG editorial — based on content published by Cerbos: Serverless architectures bring speed and agility, but authorization often remains a weak point
Questions worth separating out
Q: How should security teams implement centralized authorization for serverless applications?
A: Security teams should separate policy management from application code and use a shared decision layer for all Lambda functions that need the same access rules.
Q: Why do Lambda-based applications often suffer from authorization drift?
A: Authorization drift happens when each function or service embeds its own access logic, causing rules to diverge over time.
Q: What do security teams get wrong about externalized authorization in serverless?
A: Teams often assume externalized authorization is only about reducing code duplication, but the governance benefit is broader.
Practitioner guidance
- Separate policy from application code Move entitlement logic out of individual Lambda handlers and into a centrally managed policy plane so rule changes do not require redeploying every function.
- Select the Lambda deployment pattern by control objective Use the standalone function model when shared enforcement matters more than local latency, and use the extension layer when low-latency, in-context decisions are the priority.
- Track authorization drift across workload types Compare decisions for the same principal and resource across serverless, container, and VM environments to confirm that policy bundles produce identical outcomes.
What's in the full article
Cerbos' full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step deployment guidance for running the PDP as a Lambda function or as an extension layer.
- Memory, cold-start, and concurrency considerations for production serverless authorization.
- Implementation examples for /v1/check/resources and /v1/plan/resources in AWS Lambda environments.
- Cerbos Hub policy distribution and audit-log handling across mixed serverless and container estates.
👉 Read Cerbos' guide to running authorization policy in AWS Lambda →
Cerbos in Lambda: what changes for serverless IAM teams?
Explore further
12/06/2026 11:30 pm
Serverless authorization drift is the core governance problem, not Lambda itself. The article shows that teams lose control when authorization logic is duplicated inside functions instead of managed as a shared policy plane. That pattern creates inconsistent decisions, weak traceability, and hard-to-audit exceptions across workloads. For IAM and workload identity programmes, the real question is whether policy intent survives distribution across execution contexts.
A few things that frame the scale:
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: Who is accountable when policy decisions are inconsistent across Lambda and containers?
A: Accountability sits with the identity or platform governance owner, because inconsistent decisions usually reflect a broken operating model rather than a single application defect. The framework must define who owns policy authorship, who approves exceptions, and who validates that the same rule behaves the same way everywhere.
👉 Read our full editorial: Cerbos in AWS Lambda changes serverless authorization governance
