What’s the issue?
SQL Server allows logins to be created from a certificate or an asymmetric key rather than from a Windows account or a password, using CREATE LOGIN [LoginName] FROM CERTIFICATE [CertName] or the asymmetric key equivalent. These logins cannot be used to connect to the instance. They exist only as a security context that code can execute under.
The primary legitimate use is module signing. A stored procedure or other module is signed with a certificate, a login is created from that same certificate, and permissions granted to the login are applied to the module when it executes. This provides a controlled way to give code elevated permissions without granting them to the calling user.
This finding identifies logins mapped to a certificate or asymmetric key, detected by querying sys.server_principals for principals of type C or K.
Why is this a problem?
These logins are frequently granted elevated permissions, because that is the point of the pattern. A certificate-based login often holds permissions such as CONTROL SERVER, IMPERSONATE ANY LOGIN, or membership in a high-privilege role, so that signed code can perform administrative work. Anyone who can execute the signed module inherits that authority for the duration of the call.
The permissions are also easy to overlook during review. Certificate-based logins do not appear in the places admins usually look when auditing access, and because they cannot log in directly they may be assumed to be harmless.
Ownership of the certificate matters as well. A principal who can access the certificate and its private key can sign additional modules with it, extending the elevated permissions to new code without any change to role membership or permission grants.
What should you do about this?
Enumerate these logins by querying sys.server_principals for types C and K, then review the permissions each one holds through sys.server_permissions and sys.server_role_members. Identify which modules are signed with each certificate so you know what code inherits the permissions.
Confirm with the team that each login is part of a current, documented module signing implementation. Drop any that are left over from retired code, along with the associated certificates, after verifying nothing still depends on them.
For those that remain, confirm the permissions are narrowly scoped to what the signed modules actually require, and restrict who can access the certificate and its private key.