An application identity still needs database permissions

An application identity still needs database permissions.

The mechanism

A supported managed identity can obtain a token for Azure SQL without the application storing a SQL password. The database still needs the corresponding principal and appropriate permissions, and the connection needs a supported authentication configuration.

Why this changes the decision

A workload should not inherit broad administrator authority merely because it needs to connect. Authentication establishes identity; authorization limits what that identity can do. The design review must include the actual client, supported identity configuration and database permission scope.

An identity answers who; permissions answer what

Consider an application on an Azure VM connecting to Azure SQL Database. Removing an application-stored SQL password can be valuable, but the connection still needs a supported identity and client configuration, a database principal and the permissions required for its work. A token is not an administrator grant. This distinction is the story in the film: the application’s ability to identify itself and its authority to perform an operation must remain separate decisions. The example is not universal passwordless support for every SQL Server deployment.

Start with the actual application operations. Which data must the workload read or change, and which actions should remain outside its authority? Keep bootstrap and human administration separate from routine application access. The managed identity belongs to the VM resource in the illustrated host-identity scenario; applications sharing that host do not automatically receive isolated per-process identities. That boundary deserves assessment when several workloads use the same environment. Eliminating one stored secret also does not remove every platform credential, network control or operational security responsibility.

Review the complete access path

A useful proposed assessment records the client and supported authentication mode, the selected resource identity, the corresponding database principal and its effective permissions. Consider inherited memberships and ownership rather than reviewing one explicit grant in isolation. Keep network, firewall and TLS requirements attached to the connection design. A successful token request and a successful authorised database operation are different observations. No role assignment, user creation or permission change is performed by this article, and the illustrated read-versus-schema distinction is not a production permission script.

For acceptance, agree representative operations that should succeed and operations that should not be allowed, using an authorised test scope. Record the identity and environment so another reviewer can interpret the result. If the required boundary cannot be demonstrated, preserve that finding instead of calling the workload secure because it no longer carries a SQL password. The executive takeaway is that identity modernization and permission design work together: the connection can identify the workload through a supported mechanism, while the database still needs an explicit, reviewable answer about what that workload is permitted to do.

Three checks before a change

• Inventory connection identities.
• Configure supported identity and client.
• Test minimum required database permissions.

Keep the scope clear

Azure VM host identity to Azure SQL Database example, not universal passwordless support for every SQL Server deployment. Processes sharing a VM do not automatically have isolated managed identities. Network access, a compatible client, administrative provisioning and effective database permissions remain separate requirements.