Notifications
Clear all
Topic starter
08/06/2026 4:31 pm
TL;DR: B2B SaaS feature flags increasingly function as entitlement controls, with org-level claims embedded in access tokens and used to switch features on for specific customers, support cases, and phased rollouts, according to WorkOS. The governance issue is not the toggle itself but the lifecycle of customer-specific access, which must stay aligned to contracts, environments, and cleanup.
NHIMG editorial — based on content published by WorkOS: How to enable B2B SaaS features for specific customers
Questions worth separating out
Q: How should security teams govern organization-level feature flags as access controls?
A: Treat organization-level feature flags as entitlement-bearing controls, not just release toggles.
Q: Why do token-backed feature flags create governance risk?
A: Token-backed flags turn access state into a claim that the application trusts at runtime.
Q: What breaks when rollout flags are left in place after launch?
A: Unused rollout flags create code-path clutter, obscure which access is intentional, and increase the chance that old experiment settings keep influencing production behaviour.
Practitioner guidance
- Classify flags by entitlement type Separate long-lived customer entitlement flags from short-lived rollout flags, and assign each type a distinct owner, review cadence, and retirement rule.
- Reconcile flag state with contract data Tie feature enablement to CRM or billing events so upgrades, downgrades, and beta participation update access without manual drift.
- Audit token-backed feature claims regularly Review the feature_flags claim and the downstream logic that consumes it, especially where session refresh determines when changes take effect.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step configuration of feature flags in the WorkOS dashboard for specific organizations and environments
- JWT claim examples showing how feature flags are delivered inside the access token at runtime
- Express session refresh code that updates the sealed session after access changes
- Best-practice guidance for naming, auditing, and retiring long-lived entitlement flags
👉 Read WorkOS's guide to organization-level feature flags for B2B SaaS →
Organization-level feature flags: what IAM teams should watch?
Explore further
08/06/2026 6:12 pm
Organization-level feature flags are entitlement governance, not just release engineering. Once a flag determines who gets access to a product capability, the control becomes part of the identity model. That means contracts, approval paths, and removal rules matter as much as code implementation. Practitioners should stop treating feature exposure as a purely product-side decision and govern it like a lifecycle-controlled entitlement.
A few things that frame the scale:
- 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.
- 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: How do you know if feature flag governance is actually working?
A: You should be able to answer which flags are long-lived entitlements, which are temporary rollouts, who owns them, when they were last reviewed, and which customer agreements they reflect. If that inventory is missing or inconsistent, the governance model is not functioning as a control.
👉 Read our full editorial: Organization-level feature flags expose the real entitlement problem
