TL;DR: Feature flag platforms sit inside the production control plane, so misconfigurations, deletions, or account compromise can alter availability and user experience immediately, according to ControlMonkey. The real governance problem is that release logic has become an identity-governed control surface, not just a configuration backup target.
NHIMG editorial — what this means for NHI practitioners
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
Questions worth separating out
Q: How should security teams govern feature flag platforms as part of IAM and PAM?
A: Teams should treat feature flag administration as privileged production access.
Q: Why do feature flags create identity and access risk beyond application code?
A: Feature flags change what users see and what code paths execute, so the configuration layer becomes a production control surface.
Q: What breaks when recovery focuses only on backup and not on access governance?
A: A backup can restore the same bad permissions, stale targeting, or unsafe admin rights that caused the incident in the first place.
Practitioner guidance
- Classify feature-flag administrators as privileged identities Map LaunchDarkly administration to PAM and NHI review processes, including least privilege, separation of duties, and named owner approval for high-risk rollout changes.
- Version and test restore paths for release configuration Validate that backups cover flags, segments, and views, then rehearse restoration into a non-production environment so you know the known-good snapshot is actually usable.
- Restrict AI-assisted workflows from broad flag administration Limit agent and service account permissions to specific environments or flag groups, and block blanket admin rights unless there is a documented operational need.
What's in the full announcement
ControlMonkey's full blog post covers the operational detail this post intentionally leaves for the source:
- Snapshot and backup behaviour for LaunchDarkly feature flags, segments, and views across environments
- Restore workflow details for recovering configuration from a known-good snapshot in minutes
- Dashboard views for tracking disaster recovery readiness and configuration protection coverage
- Examples of the specific LaunchDarkly objects that can be protected and restored
👉 Read ControlMonkey's post on LaunchDarkly disaster recovery for feature flags →
LaunchDarkly disaster recovery: what it means for feature flag governance?
Explore further