What’s the issue?
An application role is a database principal that carries its own password and is activated within a session using sp_setapprole. Unlike a database role, it has no members. Instead, any connection that supplies the correct password takes on the application role’s permissions for the remainder of the session.
Activation replaces rather than supplements the connected user’s security context. Once the role is active, the session loses the permissions it had as the original user and operates entirely under the application role’s permissions, including within the public role of that database.
This finding identifies databases containing application roles, detected by querying sys.database_principals for principals of type A.
Why is this a problem?
Application roles activate with a password, and that password has to live somewhere the application can reach it. In practice it ends up in configuration files, connection code, or deployment scripts, where anyone who can read those artifacts can activate the role from any client and acquire its permissions directly.
The context switch also breaks auditing. After activation, the session operates as the application role, so functions such as USER_NAME return the role rather than the original caller. Activity recorded during the session cannot be attributed to the person or process that initiated it unless the application captures the original identity separately.
Application roles are also a legacy pattern that predates better alternatives. Module signing, EXECUTE AS on stored procedures, and dedicated least-privilege service accounts all achieve the same goal of granting an application specific permissions, without a shared password and without discarding the caller’s identity.
What should you do about this?
Find any application roles by querying sys.database_principals for type A in each database, and review the permissions granted to each one along with the applications that activate them. Confirm with the application owners whether each role is still in use.
Drop any roles that are no longer activated by a current application using DROP APPLICATION ROLE [RoleName];. For roles still in use, evaluate whether the same access can be provided through a dedicated service account with explicit grants, or through signed stored procedures that elevate only for specific operations.
Where an application role must remain, rotate the password on a defined schedule, store it in a secrets management system rather than in configuration files, and grant the role only the specific permissions the application actually needs.