How to Rotate Azure AI Services Keys Without Breaking Production

Ask an Australian business when they last rotated the keys on their Azure AI Services resources and you'll usually get one of two answers. Either a slightly nervous "we haven't" or a confident "we don't need to, they're in a vault". Both answers are a problem, and the second one more than the first, because it's wrong with confidence.

Key rotation is one of those unglamorous operational disciplines that never feels urgent until the morning it becomes the only thing that matters. A developer leaves. A key ends up in a log file. A repo gets set to public by accident. When any of those happen, "we can rotate our keys cleanly and quickly" is the difference between a five-minute non-event and a scramble that takes down your AI features for a day. Microsoft documents the mechanics of rotating keys clearly enough, so this post is about the practice: how to do it without downtime, how often is actually sensible, and how to stop it being a task that depends on someone remembering.

Why there are two keys

Every Azure AI Services resource, and that includes Azure OpenAI, Speech, Language, Vision and the rest, gives you two subscription keys: key 1 and key 2. People often assume one is a backup for the other, like a spare tyre. That's not what they're for. They're for zero-downtime rotation.

Here's the logic. If you only had one key and you needed to change it, there'd be an unavoidable window where the old key is dead and the new one hasn't been deployed everywhere yet, and during that window your app is broken. Two keys removes the window entirely. Because your application can run on either key, you always have one "live" key in use and one you're free to regenerate. Regenerating the idle key never affects anything, because nothing is using it.

That single insight is the whole rotation strategy. Everything below is just the choreography.

The zero-downtime rotation dance

Say your application is currently running on key 1. The clean rotation goes like this.

First, switch your application to key 2. Whatever holds your key, ideally a secrets store, gets updated to key 2, and your app picks it up. Now key 1 is idle. Nothing is using it.

Second, regenerate key 1 in the Azure portal or via CLI. This takes a couple of seconds. Because your app is happily running on key 2, this has zero impact. Key 1 is now a fresh, unknown-to-anyone value.

Third, and this is optional but tidy, switch your application back to the freshly regenerated key 1, which leaves key 2 idle again and ready for next time. Some teams skip this and just alternate which key is "primary" each cycle. Either works. What matters is that at every step, the key being regenerated is the one nothing is using.

The command to regenerate, if you like doing it from the CLI:

az cognitiveservices account keys regenerate \
  --name my-ai-resource \
  --resource-group my-rg \
  --key-name Key1

The failure mode to avoid is regenerating the key your application is currently using. Do that and every request starts failing immediately with a 401, and you'll be frantically redeploying config while your chatbot returns errors to customers. The rule is simple: never regenerate the live key. Move traffic off it first, always.

How often should you actually rotate?

Here's where I'll give you an opinion rather than a policy template, because the compliance frameworks tend to say "regularly" and leave you to guess.

For keys sitting properly in a secrets store, read at startup and never exposed, a rotation every 90 days is a reasonable rhythm. It's frequent enough to limit the blast radius of a leak you didn't know about, and infrequent enough not to be a burden. Quarterly aligns nicely with a lot of other review cadences too.

But rotation frequency is the wrong thing to obsess over. Two situations should trigger an immediate, unscheduled rotation regardless of your calendar, and these matter far more than the routine cadence:

The first is any suspicion a key has been exposed. A key in a git commit, a key in an application log, a key pasted into a chat message, a laptop lost, a contractor offboarded who had access. In every one of these cases, treat the key as compromised, because you cannot prove it isn't, and rotate immediately. The cost of rotating unnecessarily is basically zero. The cost of not rotating a leaked key can be a five-figure consumption bill run up by whoever found it, because an AI Services key is, functionally, permission to spend your money at volume.

The second is personnel changes. Anyone who has ever seen the key should be assumed to still have it, because humans copy things. When someone with access to production keys leaves, rotate. This is the rotation people most often skip and most often regret.

If routine 90-day rotation feels like too much to keep on top of manually, that's a signal to automate it, not to skip it. Which brings us to the better answers.

Automate it, or better, remove the keys

Rotation that depends on a human remembering is rotation that won't happen. The version I'd actually recommend for anything production-grade is to take the human out of it.

The pattern we build most often uses Azure Key Vault to store the keys, with a scheduled Azure Function or Automation runbook that performs the rotation dance on a timer: read which key is live, regenerate the idle one, update the vault, done. Key Vault even has a rotation-notification event through Event Grid, so you can trigger the rotation off an expiry event rather than a naive timer. Your applications read the key from Key Vault at startup, so when the vault value changes they pick it up on their next restart or refresh with no code change. This is standard secrets hygiene and it's not exotic, we set it up as part of most Azure AI landing-zone work our Azure AI consulting team delivers.

But here's my real opinion, the same one I'll give anyone who asks: for most Azure AI services, the best key rotation strategy is not having keys at all.

Azure OpenAI and most of the AI Services family support Microsoft Entra ID authentication directly. Instead of a key, your application's managed identity is granted the Cognitive Services User role on the AI resource, and the SDK authenticates straight to the endpoint with no key anywhere in the picture:

var client = new AzureOpenAIClient(
    new Uri("https://my-resource.openai.azure.com/"),
    new DefaultAzureCredential());

There is no key to store, leak, or rotate. Entra ID handles the token lifecycle for you, with short-lived tokens refreshed automatically. The entire category of "we need to rotate our keys" simply disappears. You can go further and set the disableLocalAuth property on the resource to switch key-based access off entirely, which turns "someone found our key" from an incident into an impossibility. For organisations working towards Essential Eight uplift or under APRA CPS 234, that one setting closes a whole line of audit findings.

I wrote more about the vault-versus-Entra decision in an earlier piece on using Key Vault with Azure AI Services, and the short version holds: Entra ID where you can, Key Vault where you can't, keys in plain config never. Rotation is the discipline you need for the keys you couldn't eliminate.

The honest caveats

Entra auth isn't universal yet, and I'd be misleading you if I pretended otherwise. Some third-party tools, low-code connectors, and older SDK samples still want a key and only a key. When you're stuck with those, keys and rotation are your reality, and that's fine, that's exactly what the two-key system and the automated vault rotation are for.

There's also a subtle gotcha with rotation and caching. If your application caches the key aggressively and never re-reads it, rotating the vault value won't help, because the app is still holding the old key in memory. Make sure whatever fetches your key can actually pick up a change, whether that's a restart, a periodic refresh, or the built-in Key Vault references in App Service and Container Apps that handle this for you. We've diagnosed more than one "we rotated but it broke" incident that turned out to be an app cheerfully using a cached copy of the key it was told to stop using.

And send your AI resource's diagnostic logs to Log Analytics before you need them. When a key looks compromised, you want to see what it was used for and from where, and that trail only exists if you turned it on in advance.

Where to start

If you take one thing from this: go and check when your production AI keys were last rotated, and whether anyone who's left the business ever had them. If the answer to either is uncomfortable, rotate this week using the two-key dance above, it's a ten-minute job with zero downtime when done in the right order.

Then decide whether keys need to exist for you at all. For most greenfield Azure AI work, the answer is no, and moving to Entra ID authentication is one of the highest-value, lowest-effort security improvements you can make. It's a standard part of the architecture reviews our Azure AI Foundry consultants run, and it's cheap to get right early and genuinely painful to retrofit once you've got a dozen integrations depending on a shared key. If you'd like someone who's done this a few dozen times to look over your setup, get in touch.