Notifications
Clear all
Topic starter
09/06/2026 11:28 pm
TL;DR: Authorization emerges as the next step after authentication, with the React Round Up discussion covering policy design, stateful versus stateless models, testing, observability, and deployment patterns for cloud-native applications, according to Cerbos. The core issue is not tooling polish but whether teams can govern access control logic cleanly enough to scale, satisfy enterprise buyers, and support regulatory scrutiny.
NHIMG editorial — based on content published by Cerbos: an episode of the React Round Up podcast on authorization, policy testing, and cloud-native access control
Questions worth separating out
Q: How should teams implement policy-based authorization in cloud-native applications?
A: Start by separating decision logic from application code, then express access rules as versioned policies that can be tested before deployment.
Q: What is the difference between stateful and stateless authorization for IAM teams?
A: Stateful authorization stores decision context between requests, while stateless authorization evaluates each request from current inputs and policy rules.
Q: How do security teams know if authorization policies are actually working?
A: Look for policy tests in the release pipeline, clear decision telemetry in production, and a consistent trail from request context to allow or deny outcome.
Practitioner guidance
- Separate policy from application logic Move authorization decisions into centrally managed policies so access rules can be reviewed, versioned, and reused across services without code duplication.
- Test policies in CI/CD Add unit tests for allow and deny paths, then validate derived roles and conditional rules before deployment to production.
- Instrument decision telemetry Log authorization decisions, matched policy paths, and request context so security and platform teams can trace why access was granted or denied.
What's in the full article
Cerbos' full podcast discussion covers the operational detail this post intentionally leaves for the source:
- Cerbos playground workflow for building and testing authorization policies in an online editor
- Google CEL conditions for policy logic and contextual decision making
- Derived role examples that show how runtime access decisions can be structured
- Deployment patterns, including sidecar use, for teams moving authorization out of application code
👉 Listen to Cerbos' React Round Up discussion on cloud-native authorization →
Cloud-native authorization logic and policy testing: what teams need?
Explore further
10/06/2026 1:48 am
Authorization is becoming a governance layer, not a code detail. As applications decompose into specialised services, access decisions move out of the application core and into reusable policy logic. That changes the identity problem from 'who authenticated' to 'how every service decides, proves, and revises access'. The practitioner consequence is that authorization now sits alongside IAM as a control surface that needs lifecycle management and auditability.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why policy and implementation often drift apart in production environments.
A question worth separating out:
Q: Why do cloud-native applications need separate authorization governance?
A: Cloud-native systems split functionality across services, which means access decisions are no longer confined to one codebase or one authentication event. Separate authorization governance lets teams control, test, and evidence decisions consistently across the environment. Without that layer, access logic drifts as services change.
👉 Read our full editorial: Authorization logic for cloud-native apps: what Cerbos changes
