A secret is only a secret if you can replace it in one place, right now, without asking anyone for permission. A key hardcoded into a mobile app fails that test. Revoking it breaks every installed copy at once, and the repair waits on an app store review. That gap between the attack and the fix is the blast radius.
The attacker cost four hours. Rotating the key cost three days.
Everyone repeats “do not hardcode keys”. Almost nobody explains what happens on the day you have to undo it.
What happens when you revoke a hardcoded API key?
The key is inside the shipped app, so it is inside every installed copy. The moment you revoke it to stop the attacker, all of those copies start failing at the same second. You did not have a security incident and then fix it. You had a security incident, and then you caused an outage.
And the repair goes through an app store: new build, submission, review, release. Then you wait for people to update. Some never will.
The rule
A secret is only a secret if you can replace it in one place, right now, without asking anyone for permission.
How does Azure Key Vault shrink the blast radius?
- The app holds no service key. It holds a user token from Microsoft Entra ID that expires in about an hour.
- Your API holds the relationship with Azure, and reads secrets from Azure Key Vault at runtime with a managed identity.
- Rotation becomes a Key Vault operation. New version, done. The app never knew the key existed, so it does not care that it changed.
az keyvault secret set --vault-name msdev-kv \
--name OpenAiKey --value <new-key>No build. No store review. No waiting.
This is the same split the secret-in-the-APK article arrives at from the attacker’s side, and the one the five-layer request flow places behind Front Door.
Better still: no key at all
For Azure-to-Azure calls, use managed identity and skip keys entirely. Azure SQL, Storage, Service Bus, Cosmos DB and Azure OpenAI all support it. A key you never created cannot leak. It never needs rotating either.
The cost side people underestimate
A stolen key is rarely used to delete things, because deletion gets noticed. It gets used quietly. On consumption services like Azure OpenAI, that shows up as a bill, not an alert.
Set a budget alert on the subscription and a cost anomaly alert on the resource before you need them. Otherwise your first signal is the invoice.
If you find a leaked key today, in this order
- Check whether it is already in use: Azure Monitor logs, grouped by caller IP.
- Ship the version that no longer needs the key, or put an API in front of it.
- Switch traffic to the secondary key. Most Azure services issue two for exactly this reason.
- Regenerate the primary. Then repeat for the secondary.
Doing step 4 first is what turns an incident into an outage. Write the order down somewhere your team can find it at 3am. Do not reconstruct it from memory during one.
Key takeaways
- A key hardcoded into a mobile app cannot be rotated without breaking every installed copy. The fix and the outage are the same event.
- A secret that needs an app store release to replace does not meet the bar for “secret”.
- Key Vault plus managed identity makes rotation a one-line command users never notice.
- Stolen keys on consumption services usually surface as a billing anomaly first. Set a budget alert and a cost anomaly alert in advance.
- When responding to a leak, switch to the secondary key before regenerating the primary.
