Almost every Azure project I work on still has classic SQL authentication hanging around somewhere. Usually it's a legacy app, an old management script, or that one test database nobody dares to touch. Microsoft now puts the "Support only Microsoft Entra authentication" switch directly in the Azure portal (SQL server → Settings → Microsoft Entra ID), so I don't see a good reason to keep SQL logins enabled on an Azure SQL Database or Managed Instance anymore. Switching to Azure SQL Entra-only authentication reduces your attack surface. It also gives you one place to manage identities, proper auditability and actual control over who gets in.

The Entra admin group has to be in place before you flip the switch

Start by configuring a Microsoft Entra admin group for each SQL server. I always use a dedicated group rather than individual accounts, because it keeps administration and break-glass access cleaner and easier to audit. As soon as you turn on Entra-only in the portal, every classic SQL authentication login on that server stops working. The official docs cover the finer points (here). After the switch, the server only accepts sign-ins through Microsoft Entra ID, whether from users, service principals or managed identities. Before the cutover, I always check the following:

  • An Entra admin is set, and members of the group can actually connect
  • Every production database has at least one Entra-based contained SQL user (created via CREATE USER [AppName] FROM EXTERNAL PROVIDER)
  • Documentation and monitoring are updated, so nobody gets caught off guard

Apps and managed identities connect with access tokens by default

If an app or tool uses current libraries, moving it to Entra-only authentication is usually painless. What matters is that it gets an access token from Microsoft Entra ID, through a managed identity or a service principal, and uses that token for the connection. Azure App Services, Functions and other managed workloads already support this. The app requests a token (often with DefaultAzureCredential) and sets it as the access token on the SQL client.

This C# snippet connects from an Azure app with a system-assigned managed identity:

using Azure.Identity;
using Microsoft.Data.SqlClient;

var credential = new DefaultAzureCredential();
var token = credential.GetToken(
  new Azure.Core.TokenRequestContext(new[] { "https://database.windows.net/.default" })
).Token;

using var conn = new SqlConnection(connectionString);
conn.AccessToken = token;
conn.Open();

On-premises and legacy workloads are harder, particularly when they can't use Entra ID or modern libraries at all. In those cases you may need to refactor, or bridge the gap with Azure App Proxy. I wrote more about choosing app identities and securing managed identities in Workload identities in Entra ID: Managed identities, app registrations and securing your applications.

A simple diagram shows the authentication paths in Entra-only mode

The authentication flow changes once Entra-only is active. This diagram shows what connects to what:

flowchart TD
  User["Entra user"] --> Token["Access token"]
  ManagedIdentity["Managed identity"] --> Token
  ServicePrincipal["Service principal"] --> Token
  Token --> SQLServer["Azure SQL server"]
  SQLServer --> DBUser["Entra user in database"]

Figure: Authentication paths in Azure SQL Entra-only mode

Azure Policy enforces Entra-only authentication at scale

Governance belongs in the plan too. Azure Policy can enforce "Support only Microsoft Entra authentication for this server" across your whole environment (details here). You can audit non-compliant SQL servers or remediate them automatically, so nobody turns SQL logins back on by accident, or on purpose.

Assign the policy, let it scan, and look at the results before you enforce anything:

Practical tip: "I always run Azure Policy in audit mode first and go through the findings. No migration plan survives first contact with forgotten legacy apps. Not disrupting users matters more to me than enforcing the setting overnight."

Legacy apps and break-glass access need a migration plan

For most apps, the technical side of moving to Azure SQL Entra-only authentication is simple. The problems show up in the details. These are the ones I run into most often:

  • Old tools (e.g. SSMS before 18.5, third-party clients) without Entra authentication support
  • SQL credentials hardcoded in pipelines, scripts or monitoring tools
  • Thin documentation on Entra admin membership and disaster recovery

This migration plan has worked well for me:

  1. Find the applications and users that still rely on SQL logins (check SQL logs for connection attempts)
  2. Create an Entra-based contained user for each app (CREATE USER ... FROM EXTERNAL PROVIDER)
  3. Test modern authentication end-to-end
  4. Only then flip the Entra-only switch and assign the policy

Pay particular attention to break-glass access. Make sure your Entra admin group contains cloud admins you can rely on, ideally with JIT access and MFA. Once Entra-only is enabled, you can no longer fall back on a classic SQL login as a backdoor.

Entra-only authentication has become my new default

Azure SQL Entra-only authentication is now my baseline, especially in regulated environments. The migration takes some work up front, but you get less exposure, simpler management and better audit trails in return. Work through it methodically, keep the documentation current, and take your time with critical workloads. I haven't yet met an organization that regretted making the switch. Microsoft's overview has more technical background (here).