Microsoft Defender for Cloud · Azure Cosmos DB
Azure Cosmos DB accounts should use Microsoft Entra ID as the only authentication method
Written and reviewed by Emnode · Last reviewed
What does the recommendation "Azure Cosmos DB accounts should use Microsoft Entra ID as the only authentication method" check?
Flags any Cosmos DB account where 'disableLocalAuth' is still false, meaning the account's primary and secondary keys and resource tokens are accepted alongside Microsoft Entra ID. When local auth is enabled, anyone holding a key has full data-plane access regardless of Entra role assignments, and the read-only keys are no safer because they still expose every record in the account. This control only governs the authentication method on the account: it does not check whether your Entra data-plane role assignments are scoped correctly, nor does it cover network restrictions, firewall rules or private endpoints, which are separate controls. It applies to the account as a whole across all APIs, including NoSQL, MongoDB, Cassandra, Gremlin and Table.
Why does "Azure Cosmos DB accounts should use Microsoft Entra ID as the only authentication method" matter?
Account keys are long-lived, shared, god-mode credentials that bypass Entra entirely: a single leaked key in a config file, log or repository hands an attacker read and write access to every database in the account with no MFA, no conditional access and no per-user audit trail. Because keys are rarely rotated, the exposure window is effectively permanent until someone notices. Disabling local auth forces every request through Entra ID, so access can be granted per identity, revoked instantly and traced to a real principal, which is what your auditors and incident responders need.
How do I fix "Azure Cosmos DB accounts should use Microsoft Entra ID as the only authentication method"?
- In the Azure portal, open the Cosmos DB account, go to the Security tab, and under Key-based authentication select Disable. Before doing this, assign the relevant Cosmos DB data-plane roles to your applications' managed identities so they keep working.
- To apply it from the command line, run: az resource update --resource-group <rg> --name <account> --resource-type 'Microsoft.DocumentDB/databaseAccounts' --set properties.disableLocalAuth=true. In Bicep, set disableLocalAuth: true in the account's properties block so new accounts ship locked down.
- Enforce it at scale with the built-in policy. Look the definition up by display name rather than pasting a GUID: pid=$(az policy definition list --query "[?displayName=='Configure Cosmos DB database accounts to disable local authentication'].name" -o tsv); az policy assignment create --name cosmos-no-localauth --policy "$pid" --scope <scope> --location <region> --mi-system-assigned. The audit-only counterpart is 'Cosmos DB database accounts should have local authentication methods disabled' if you want to report before remediating.
Remediation script · bash
# 1. Establish the Entra path FIRST: provision a SQL Entra admin (an Entra group is best).
gid=$(az ad group show --group "sql-admins" --query id -o tsv)
az sql server ad-admin create \
--resource-group rg-data \
--server-name sqlprodcust \
--display-name "sql-admins" \
--object-id "$gid"
# 2. Switch the Synapse workspace to Microsoft Entra ID Only (local SQL admin disabled).
az synapse workspace update \
--resource-group rg-data \
--name synprodanalytics \
--use-microsoft-entra-only-authentication true
# 3. Disable the Cosmos DB account key ONLY after clients use a managed identity (NoSQL API).
az resource update \
--resource-group rg-data \
--name cosmosprodcust \
--resource-type "Microsoft.DocumentDB/databaseAccounts" \
--set properties.disableLocalAuth=true
# 4. Ratchet it shut: assign the built-in policy by its EXACT display name (look up its id, never hardcode a GUID).
pid=$(az policy definition list \
--query "[?displayName=='An Azure Active Directory administrator should be provisioned for SQL servers'].name" -o tsv)
az policy assignment create \
--name require-sql-entra-admin \
--policy "$pid" \
--scope "/subscriptions/00000000-0000-0000-0000-000000000000" Full walkthrough (console steps, edge cases and verification) in the lesson Require Microsoft Entra authentication.
Is "Azure Cosmos DB accounts should use Microsoft Entra ID as the only authentication method" a false positive?
An account that still relies on keys because a downstream tool or SDK version has no Entra support, such as certain analytics connectors, the bulk migration tooling or older drivers, will correctly flag while that dependency exists. This is a real exception, not a defect: track it as a documented risk acceptance, restrict the keys with network rules and a private endpoint in the meantime, rotate them on a schedule, and close the exception once the tool gains Entra support so you can disable local auth.