What’s the issue?
Every SQL Server database contains a built-in guest user, which exists to provide access for logins that have no explicitly mapped user in that database. The user cannot be dropped, but its ability to be used is controlled by whether it holds CONNECT permission on the database, which is disabled by default in all user databases.
When guest has CONNECT permission, any login that can authenticate to the instance can enter that database without an explicit user mapping, inheriting whatever permissions have been granted to the guest user or to the public role within it.
This finding identifies user databases where the guest user holds CONNECT permission, detected by querying sys.database_permissions for a grant of CONNECT to the guest principal.
Why is this a problem?
Guest access defeats the normal database access model. Access is meant to be granted deliberately by creating a user in the database and mapping it to a login, and enabling guest bypasses that entirely by making the database reachable to every authenticated principal on the instance, including service accounts, vendor accounts, and any login added in the future.
The exposure compounds with permissions granted to the public role, since guest users are members of public and inherit everything granted to it. A database with guest enabled and non-default public grants can expose considerably more than the team realizes.
The condition also undermines access review. Reviewers examining the users in a database will not see the full set of principals who can actually reach it, because the guest path grants access to logins that appear nowhere in the database’s user list.
What should you do about this?
Identify affected databases by querying sys.database_permissions joined to sys.database_principals for CONNECT granted to guest, and review what permissions the guest user and the public role hold in each one to understand the actual exposure.
Revoke the permission with REVOKE CONNECT FROM guest; in each affected database. Note that guest is enabled by design in master, msdb, and tempdb and should be left alone there, since removing it breaks expected instance functionality.
Before revoking, confirm no application or process is relying on guest access, and create explicit users mapped to the appropriate logins where legitimate access is required.