LaunchDarkly credentials: Revoke, rotate and contain a leaked key

A leaked LaunchDarkly credential can expose every feature flag rule in an environment or, worse, let an outsider change what production code does without a deploy. LaunchDarkly holds release logic, targeting rules, segments and sometimes kill switches for security controls, so its credentials are operational keys, not just configuration. This guide explains what each LaunchDarkly credential type reaches, which ones are actually secret, the signals that suggest misuse, the exact revoke and rotate steps from LaunchDarkly's own documentation, and the controls that stop the next leak. It is written for platform, DevOps and security engineers who own LaunchDarkly or respond to secret scanning alerts for it.

Key takeaways

• Know which value leaked first. Server-side SDK keys and REST API access tokens are secrets; mobile keys and client-side IDs are designed to be public and do not need rotation for secrecy.
• API access tokens are the high-impact case. A token with a Writer, Admin or Owner role can change flags, roles, members and other tokens through the REST API, and LaunchDarkly shows its value only once.
• SDK keys leak rule logic. A server-side SDK key gives read-only access to the full ruleset for every flag in one environment, including targeting rules that may name customers, segments or internal user IDs.
• Rotation without an outage is built in. You can create a second SDK key, move clients, set an expiration date on the old one or delete it; a deleted API token returns 401 Unauthorized at once.
• Change history is your evidence. LaunchDarkly records each change with member, resource, environment and diff, filterable by resource types such as Service token, Member, Role and Relay Proxy, but retention depends on plan.

How identity and access work in LaunchDarkly

LaunchDarkly separates human access to the application from machine credentials. People sign in to the web app (with optional single sign-on through SAML, SCIM provisioning and multi-factor authentication). Machines use two families of credentials: SDK credentials, which let applications evaluate flags, and REST API access tokens, which let automation manage the account. The difference matters in an incident because the blast radius and the fix are different for each.

Two details shape triage. First, LaunchDarkly rejects requests made with the wrong type of key for an SDK, so a leaked mobile key cannot be used as a server SDK key. Second, flags exposed to client-side or mobile SDKs are already visible to anyone who runs your app; if a mobile key or client-side ID appears in a public repository, the real question is whether sensitive flags were wrongly marked as available on those SDKs, not whether the key must be replaced.

Admin roles and privileged access

Every API access token carries a role. The choice made at creation is the single largest factor in how bad a leak is.

• Base roles: Reader, Writer, Admin and Owner. A leaked Reader token exposes configuration; a Writer token can change flag targeting in any environment it can reach; Admin and Owner tokens can change members, roles and tokens, which gives an intruder persistence.
• Custom roles and inline policies: on plans that include custom roles you can give a token a custom role or an inline policy that applies only to that token. Editing a custom role changes the permissions of every token that uses it, which is useful for containment: tightening one role narrows all its tokens immediately.
• Personal tokens follow the member: they can never exceed the member's permissions, shrink if the member's permissions shrink, and are deactivated when the member is removed. They stay valid after an email change. Removing a departing engineer therefore breaks their integrations, which is a common reason teams keep over-privileged personal tokens alive.
• Service tokens follow nobody: they are independent of any profile and their permissions cannot be edited after creation. They cannot exceed the role of their creator at creation time. Treat them as non-human identities with a named owner.
• Who can mint tokens: by default any member can create tokens up to their own permissions. Custom role actions let you restrict this. The token actions on resource member/*:token/* (personal) and service-token/* (service) are createAccessToken, deleteAccessToken, resetAccessToken, updateAccessTokenName, updateAccessTokenDescription, updateAccessTokenExpiry and, for personal tokens only, updateAccessTokenPolicy.
• Who can see SDK keys: SDK keys live under resource proj/*:env/*:sdk-key/* with actions viewSdkKey, createSdkKey, updateSdkKey, updateSdkKeyPayload and deleteSdkKey. Limit viewSdkKey on production environments to the people who deploy services there; the older environment actions updateApiKey and updateMobileKey are deprecated.

Account Owners deserve the same protection as cloud root accounts: few of them, SSO with MFA, and no automation running as an Owner token. See the Service Account Security Guide for the general pattern.

Integrations, API tokens and service accounts

LaunchDarkly credentials spread to more places than teams expect. The rotation procedure in LaunchDarkly's own documentation starts with an inventory of everywhere a key is used, and lists applications, services, Kubernetes secrets, CI/CD tools and the Relay Proxy. Typical locations to search during an incident:

• Application configuration: .env files, Helm values, Kubernetes Secrets and container images holding server-side SDK keys. See the Secrets in Container Images Guide.
• Infrastructure as code: Terraform providers and scripts that manage flags and projects with API access tokens, often with Writer or Admin roles because they create environments.
• CI/CD: pipeline variables used to create flags, run code references scans or toggle flags during release. A compromised action or runner can print these into logs.
• Relay Proxy: manually configured proxies use only the default SDK and mobile key per environment; automatic configuration uses its own Relay Proxy configuration key, managed through the relay-proxy-config/* resource with a resetRelayAutoConfiguration action. Multiple keys per environment need Relay Proxy 8.21.0 or later with automatic configuration or offline mode, and the proxy rejects view-scoped keys.
• Third-party tools: observability, chat and ticketing integrations that call the API, plus outbound webhooks whose signing secret sits in the receiver's configuration.

Personal tokens used by shared automation are the most common design flaw: the token stops working when its owner leaves, so teams avoid removing the owner, and the token outlives its purpose. Move shared automation to service tokens where your plan allows, with one token per integration and a recorded owner.

Leak response: revoke and rotate

Use this order when a secret scanner, a researcher or a log review reports a LaunchDarkly value outside where it should be. It follows the Leaked Credential Response Playbook and adds the LaunchDarkly specifics.

1. Classify the value. An sdk- prefix means a server-side SDK key; mob- means a mobile key; a dashless alphanumeric value used by a JavaScript SDK is a client-side ID. Anything else used against the REST API is an access token. Find it under Organization settings, Authorization, Tokens, or Organization settings, Security, SDK keys, and note the project, environment and role.
2. For an API access token, delete it now unless that would stop a safety-critical process. In Organization settings, Authorization, Tokens, open the three-dot menu and choose Delete token. LaunchDarkly states that calls made with a deleted token return 401 Unauthorized. If you need continuity, choose Clone token first to create a replacement with the same permissions, deploy it, then delete the original. Setting an expiration date (7, 30, 60 or 90 days, or a custom date) is for planned rotation, not for a confirmed public leak.
3. For a server-side SDK key, rotate in place. In Security, SDK keys, select the project and environment, click New SDK key, name it and generate it. Update every application, Kubernetes Secret, pipeline and the Relay Proxy (restart a manually configured proxy; an automatically configured proxy picks up the new default key). Confirm clients connect, then delete the old key. Both keys work until the old one is deleted or expires, and an environment must always keep at least one active server-side SDK key.
4. For a mobile key or client-side ID, review flag exposure instead. Check which flags have "Available on mobile SDKs" or "Available on client-side SDKs" switched on, and turn it off for any flag whose rules or variations should not be public.
5. For a webhook signing secret, edit the webhook, supply a new secret, and update the receiver so it rejects payloads signed with the old one.
6. Scope what the attacker could have done. In change history, filter by the affected environments and by resource types Flag, Segment, Member, Role, Service token, Webhook and Relay Proxy for the exposure window. Look for flag changes nobody owns, new members or tokens, new webhooks pointing outside your estate and role edits. Restore flags from their previous version where needed.
7. Remove the leak at source. Purge the value from the repository history, logs, tickets or images where it appeared, and resolve the secret scanning alert with a note of what was rotated.

The order matters because a public token is usually found by automated scanners within minutes. The 230 Million AWS Cloud Environments campaign harvested tokens for many SaaS providers from exposed .env files, which is exactly where server-side SDK keys and API tokens tend to sit.

Logging and detection

LaunchDarkly's change history (formerly called the audit log) is a per-environment record of changes to flags and other resources. Each entry shows who made the change, the resource, the environment, the date and a diff, and the REST API returns the specific actions. Entries can be pulled programmatically with GET /api/v2/auditlog, which accepts date ranges, resource specifiers and a full-text query. Retention depends on plan: the Developer plan keeps the last 30 days, Foundation keeps account-change events for 30 days, and unlimited history is available on select plans. If you need longer evidence, pull entries into your SIEM on a schedule.

Useful measures for the programme: number of API tokens with Admin or Owner roles (target zero for automation), share of tokens with an expiration date, share of tokens with no use in 90 days, mean time from secret scanning alert to token deletion, and number of production environments where more people hold viewSdkKey than deploy there. For detection content patterns see the NHI Detection Engineering Guide.

Hardening baseline

Prevention outside LaunchDarkly carries equal weight: store SDK keys and tokens in a secrets manager and inject them at runtime, enable push protection so values are blocked before they reach a remote repository, and scan images and logs. See the Secrets Management Guide and the Secret Push Protection Guide.

Framework mapping

Common misconfigurations

• Owner or Admin tokens in Terraform and CI. Infrastructure pipelines get broad roles "to make it work", so any runner compromise becomes account takeover. The tj-actions/changed-files compromise printed CI secrets into public workflow logs, a route that would expose such tokens.
• Shared automation on a personal token. The token dies when its owner leaves, so offboarding is delayed and the token keeps the owner's full permissions in the meantime.
• Server-side SDK key used in a client app. Shipping an sdk- key inside a browser bundle or mobile app publishes the full ruleset of the environment.
• Sensitive flags exposed to client-side SDKs. Flags carrying customer lists, internal identifiers or security toggles marked "Available on client-side SDKs" are readable by anyone running the app, no leak needed.
• Tokens with no expiry and no owner. The Home Depot token exposure shows how a single leaked token can stay valid for more than a year when nobody tracks it.
• Change history not retained. On plans with 30-day account-change retention, an incident found late has no evidence unless entries were exported.

Practitioner checklist

• List every API access token with role, owner, expiry and "Last used", and delete those unused for 90 days.
• Replace Owner and Admin tokens used by automation with custom roles or inline policies scoped to the projects involved.
• Move shared automation from personal tokens to service tokens where your plan supports them.
• Restrict createAccessToken and production viewSdkKey with custom roles.
• Issue one named SDK key per service per environment so rotation and attribution are per consumer.
• Enable the API token IP allowlist if your plan includes it.
• Review which flags are available to client-side and mobile SDKs each quarter.
• Export change history to your SIEM and alert on new tokens, members, roles and webhooks.
• Enable secret scanning and push protection on every repository and keep a tested rotation runbook for SDK keys.

Standards and references

• LaunchDarkly: API access tokens
• LaunchDarkly: SDK credentials
• LaunchDarkly: Client-side, server-side and edge SDKs
• LaunchDarkly: Using actions in custom roles
• LaunchDarkly: Change history
• LaunchDarkly: IP allowlist
• MITRE ATT&CK: T1552.001 Credentials In Files
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Leaked Credential Response Playbook · Secrets Management Guide · Secrets Rotation Runbook Template · OWASP NHI Top 10 NHI2 Secret Leakage Guide