How to Disable Local Authentication on Azure AI Services and Why You Should

There is a setting on every Azure AI Services resource that most Australian businesses have never touched, and flipping it on would close off one of the most common ways their AI credentials get leaked. It is called disableLocalAuth, and when you set it to true, key-based access to that resource simply stops working. No key, no matter how valid, will authenticate. The only way in is Microsoft Entra ID.

I bang on about this with clients often enough that I thought it deserved its own post rather than a footnote in something about key rotation. Because rotating keys, while worth doing, is treating the symptom. Disabling local auth treats the cause. If there is no key to steal, there is nothing to rotate, nothing to leak, and nothing to find in a public repo six months from now.

Microsoft covers the mechanics in their documentation, which is worth a read. This post is about the decision and the rollout: what actually changes, what tends to break, and how to get there without taking your AI features down in the process.

What local authentication even is

Every Azure AI Services resource, and that family includes Azure OpenAI, Speech, Language, Vision, Document Intelligence and the rest, ships with two things you can use to prove who you are.

The first is a pair of subscription keys. These are long random strings, and whoever holds one can call the endpoint. That is it. The key does not know or care whether it is your production app calling, a developer testing locally, or a stranger who found the key in a screenshot. A key is a bearer credential in the purest sense: possession is authorisation. That is "local authentication".

The second option is Microsoft Entra ID. Instead of a shared secret, your application authenticates with an identity, usually a managed identity in production, and Azure role-based access control decides what that identity is allowed to do. Tokens are short-lived and refreshed automatically. Nobody copies a token into a config file, because there is nothing static to copy.

Both work out of the box. And that is the problem. Because keys are enabled by default and they are the path of least resistance, most projects reach for a key, wire it in, ship it, and never revisit the decision. The key ends up in an environment variable, then in a .env file, then accidentally in a commit, then in the shell history of a build agent. Every one of those is a place it can leak from, and every one of them is invisible until it goes wrong.

disableLocalAuth removes the entire category. Set it to true and the keys become inert. They still exist in the portal, but they authenticate nothing.

What actually breaks when you flip it

Here is the honest part, because this is where people get burned. Turning off local auth is not a no-op. Anything currently authenticating with a key will start failing the moment you make the change, usually with a 401. So the order of operations matters enormously.

The thing that trips teams up most often is not their own application. It is the long tail of tools that quietly depend on a key and that nobody remembers exists. A Logic App that calls the Speech service. A Power Automate flow wired up by someone in marketing eighteen months ago. A third-party monitoring tool. An old load-testing script. A Jupyter notebook a data scientist runs once a quarter. Each one is happily using a key, and each one will break the instant you disable local auth, and you will not find out until it fails.

So before you touch the setting, you need to know everything that talks to the resource. Diagnostic logs are how you find them. If you send your AI resource's logs to Log Analytics, you can query for authentications and see which callers are using keys versus tokens. If you have not been logging, that is the first job, and you will want a few weeks of data before you can trust the picture. This is the single most skipped step and the single biggest cause of "we disabled local auth and something we forgot about fell over".

The other common breakage is developer inner loop. Developers running code on their laptops often use a key because it is easy. Once local auth is off, they need to authenticate as themselves through Entra ID instead, typically via the Azure CLI login that DefaultAzureCredential picks up. That is a better setup anyway, but it is a change of habit and it needs to be communicated before the setting flips, not discovered after.

Moving your app to Entra ID first

The rollout that does not hurt is: get everything onto Entra ID, confirm nothing is using keys, then disable local auth as the final lock on a door you already closed.

For a .NET application talking to Azure OpenAI, the code change is small. Instead of constructing the client with a key, you pass a credential:

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

DefaultAzureCredential is the useful bit here. On a developer's machine it uses their Azure CLI or Visual Studio login. In production, running on App Service, Container Apps, a Function or AKS, it uses the managed identity you have assigned. Same code, different identity, no key in either environment. The identity then needs the right role on the resource, which for most AI Services work is Cognitive Services User, or Cognitive Services OpenAI User for Azure OpenAI specifically. Grant that at the resource scope and the SDK handles the rest.

Once your app is running on a token, prove it. Watch the logs. Confirm the key-based authentications drop to zero and stay there across a full business cycle, including whatever weekly and monthly jobs you have. Only when that count is genuinely zero do you disable local auth.

You can set it a few ways. In the portal it is under the resource's networking or identity settings depending on the service. Via the CLI or Bicep it is a property on the resource. In an ARM or Bicep template it looks like this:

resource aiResource 'Microsoft.CognitiveServices/accounts@2023-05-01' = {
  name: 'my-ai-resource'
  properties: {
    disableLocalAuth: true
  }
}

Putting it in your infrastructure-as-code is the version I would push for, because it means the setting is enforced on every deployment rather than being a manual toggle someone can quietly undo. A setting that lives only in the portal is a setting that drifts.

Why this matters more in regulated industries

For a lot of Australian organisations this is not just good hygiene, it is an audit line item. If you are working towards Essential Eight maturity, or you are a financial services business under APRA CPS 234, or you handle health data under the Privacy Act, "shared static secrets with standing access to a production service" is exactly the kind of thing an assessor circles in red.

Disabling local auth turns "we rotate our keys every 90 days and hope nobody leaked one in between" into "there are no keys, access is identity-based, time-limited and fully logged". That is a materially stronger story to tell an auditor, and it is one setting rather than a process that depends on people remembering to do a chore. We end up recommending it on nearly every Azure AI landing zone our Azure AI consulting team sets up, and it is far cheaper to bake in at the start than to retrofit once a dozen integrations are leaning on a shared key.

There is a governance angle too. When everything authenticates as an identity, your access logs actually tell you who did what. A key-based log says "someone with the key called this endpoint 40,000 times". A token-based log says "this specific managed identity, belonging to this specific application, made these calls". When you are investigating an incident or a surprise bill, that difference is the difference between an answer and a shrug.

The honest caveats

I would be misleading you if I pretended this is free of friction, so here are the real ones.

Not everything supports Entra ID cleanly yet. Some third-party tools, older SDK samples, and a few low-code connectors still assume a key and give you no other option. If you depend on one of those, disabling local auth will break it, full stop, and you either need to wait for the vendor to catch up, put a small proxy in front that does hold a credential, or accept that this particular resource keeps keys for now. In that case, isolate it. Do not let one stubborn tool keep local auth enabled on the resource your whole platform depends on. Give it its own resource with its own tightly watched key.

Managed identity setup has its own sharp edges, mostly around timing and scope. A freshly assigned identity can take a few minutes for role assignments to propagate, which produces confusing intermittent 401s right after deployment that resolve themselves and make you doubt your own setup. And people frequently grant the role at the wrong scope, usually too broad at the subscription level when it should sit on the resource. Neither is hard, both are annoying the first time.

And do not flip this on a Friday afternoon, or on any resource you have not fully instrumented. The failure mode when you have missed a caller is silent until that caller runs, which might be days later. Give yourself the logging, give yourself a window where you are watching, and have the one-line rollback ready just in case.

Where to start

If you take one action from this: turn on diagnostic logging for your Azure AI resources today, if it is not already on, and give it a fortnight. Then look at how many of your callers are using keys. For most businesses the honest answer is "more than we thought, and we are not sure what all of them are", and that discovery alone is worth the exercise.

From there, move your own applications to managed identity, confirm the key usage falls to zero, and set disableLocalAuth as the final act. It is one of the highest-value, lowest-effort security improvements available in the Azure AI stack, and unlike a lot of security work it makes your architecture simpler rather than more complicated.

If you would rather have someone who has done this across a few dozen environments plan the rollout with you, it is bread-and-butter work for our Azure AI Foundry consultants, and part of the broader identity and security posture we help teams get right through our business AI engagements. Happy to take a look at your setup: get in touch.