Notifications
Clear all
Topic starter
09/06/2026 11:04 pm
TL;DR: Feature flags and authorization both shape what users can see or do inside applications, but they solve different problems, according to Cerbos’ webinar recap with Flagsmith. The important distinction is that feature flags manage release flexibility while authorization enforces access decisions, and mixing them too loosely creates governance drift rather than security.
NHIMG editorial — based on content published by Cerbos: a webinar recap on feature flags and authorization
Questions worth separating out
Q: How should teams separate feature flags from authorization controls in applications?
A: Treat feature flags as release governance and authorization as access governance.
Q: What breaks when feature flags start controlling access decisions?
A: Auditability breaks first, because reviewers can no longer tell whether a user was blocked by release logic or by entitlement policy.
Q: How do teams know if feature-flag governance is creating technical debt?
A: Look for growing numbers of dormant flags, duplicated conditions across services, and access-related logic embedded in rollout code.
Practitioner guidance
- Separate rollout control from access policy Keep feature flag decisions in a release-management layer and authorization decisions in an identity policy layer, with clear ownership for each.
- Audit application paths for hidden entitlement logic Search for if-statements and SDK calls that gate sensitive actions based on flag state, environment, or user segment.
- Retire stale flags on a defined schedule Track every feature flag with an owner, expiry target, and removal plan so dormant toggles do not become permanent policy exceptions.
What's in the full article
Cerbos's full webinar recap covers the operational detail this post intentionally leaves for the source:
- The live demonstration of how feature flags are managed across environments without redeploying code.
- The combined Cerbos and Flagsmith example showing how authorization decisions change based on flag state.
- The SDK discussion covering how integrations behave across JavaScript, React Native, and iOS applications.
- The deployment discussion for running the tooling inside Kubernetes or other customer-controlled infrastructure.
👉 Read Cerbos's webinar recap on feature flags and authorization →
Feature flags and authorization: are your controls overlapping too much?
Explore further
10/06/2026 1:16 am
Feature flags are not a substitute for authorization, and treating them as one creates control drift. The webinar’s core lesson is that release flexibility and access governance solve different problems even when they both appear as toggles in code. When teams blur them, they lose the ability to prove who can do what and why, which weakens auditability across IAM and application governance. Practitioners should keep rollout logic and entitlement logic distinct.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
A question worth separating out:
Q: What should security and engineering teams review before using feature flags for sensitive features?
A: They should review whether the feature still requires server-side authorization, whether direct API access bypasses the UI toggle, and whether the flag has a planned retirement date. If the feature affects data access, the flag should never be the only barrier. The permission model must remain the source of truth.
👉 Read our full editorial: Feature flags and authorization: where the control boundary lies
