Every flag has a default value used when the flag service cannot be reached. For flags that guard security behaviour, set the default to the safer state, not the convenient one. Keep a local cache of last known values, and test the fallback by blocking the flag service in staging.
Where defaults come from
Most flag SDKs ask your code to pass a default when you read a flag. If the service is down, the SDK has not started, or the flag does not exist, that default is what you get. Because it is written at the call site, it is easy to copy and paste, and easy to get wrong without anyone noticing.
Check your SDK documentation for the exact behaviour, since details differ between providers.
Two kinds of flag, two defaults
Flags that turn a risky or new feature on. Default to off. If the service is down, the feature stays off, which is the safe outcome. This is the normal pattern for gradual rollouts.
Flags that turn a protection on. Examples: stricter validation, an extra authorisation check, a block on a risky action. Default to on. If the call defaults to off, an outage of the flag provider silently disables the protection, which is a failure open.
Kill switches are the awkward third. A kill switch that disables a feature when flipped should default to the feature being enabled only if you accept the feature running when the flag service is down. For high-risk features, consider the opposite: default off, so a flag outage disables it. See kill switch flags: designing a safe off button.
Use a last known value
Many SDKs can keep the last values received, in memory or on disk. That is usually better than a hardcoded default, since it reflects what you chose last. Combine both: cached value first, hardcoded safe default for flags never seen.
Set a maximum age for the cache that matches how fast you need an incident change to take effect.
Startup behaviour
A common bug is reading flags before the SDK has initialised, which returns defaults for everything. Wait for initialisation with a timeout, then fall back. Log when you fall back, so you can see it happen.
Test it
- Block outbound access to the flag service in staging.
- Restart one instance and exercise each security-relevant flag.
- Confirm each behaves in the intended safe state.
- Check that an alert or log shows the fallback.
This is a short experiment from the five first security chaos experiments approach. Flags are production configuration, as discussed in feature flags are production config, so review defaults in code review.
Quick check
Can the default differ per call site?
Yes, and that is a trap. Define one named constant per flag so the default is the same everywhere.
Should every flag have a documented default?
Yes. Put the default and its reason in the flag's description.
Last reviewed: 19 October 2026.
