The Elevated Credentials topic covers what to expect day to day. This is the full technical version: exactly what gets checked, what's structurally impossible to check, and the schedule in detail.

What "elevated" means: an editable table, not a hardcoded idea

Security.ElevatedRoleDefinition is the admin-editable answer to "which fixed SQL Server/database roles count as elevated." It's not derived or inferred -- it's a flat allowlist of (RoleScopeCode, RoleName) pairs, each with its own IsElevated bit, editable from the Elevated Roles admin tab. Seeded starting opinion:

Scope Checked (elevated) Not checked by default
Server role sysadmin, serveradmin, securityadmin, processadmin, setupadmin, bulkadmin, diskadmin, dbcreator, public (every fixed server role is checked out of the box)
Database role db_owner, db_securityadmin, db_accessadmin, db_ddladmin db_backupoperator, db_datareader, db_datawriter, db_denydatareader, db_denydatawriter, database-scope public

Every fixed server role is checked from day one, including bare public membership. Only the higher-privilege fixed database roles are checked; ordinary read/write/backup access is treated as non-elevated by default. All of it is editable after install.

Unchecking a role doesn't retroactively touch anything until the next scan runs: the findings cache only ever holds a row for a role that was elevated at the time that sweep ran. Re-scan after unchecking a role and matching findings disappear, same as if that role had never been elevated at all.

What the scan actually checks

For every active credential that can actually authenticate to a SQL Server directly (SqlLogin or WindowsUser only -- see below) times every active target server:

  1. Opens a real connection as that credential to the target server (impersonating a WindowsUser credential the same way a job step's own execution does -- this is not a simulated or inferred check).
  2. Runs IS_SRVROLEMEMBER(role) = 1 against every server role on the elevated list, in master.
  3. Enumerates every currently-online database and runs IS_ROLEMEMBER(role) = 1 against every database role on the list, once per database.
  4. Deletes every existing finding for that exact (credential, server) pair, then inserts a fresh row per role actually held right now.

A finding is never a stale opinion -- every sweep is a full replace, not an incremental update, for every pair it successfully reaches.

What it deliberately doesn't check, and why

  • AzureServicePrincipal and SmtpAuth credentials are skipped entirely. Neither ever authenticates to a SQL Server -- there's no connection to open and nothing to ask a role-membership question of.
  • OS-level Windows local-admin is never checked. This is the one gap the scan is structurally unable to close: SQL Server role membership queries can't answer "is this Windows account also a local administrator on the box," regardless of which SQL Server roles that account holds. This is why the manual "Elevated (Windows local admin)" checkbox still exists for WindowsUser credentials -- see Elevated Credentials.
  • A database this credential can't reach is silently skipped for that one database -- not surfaced as an error or a finding. Failing to get into one database on an otherwise-reachable server isn't noteworthy across a whole fleet sweep.
  • An unreachable target server is skipped entirely for that credential -- one bad connection doesn't stop the rest of the sweep, and doesn't produce a false "not elevated" finding either.
  • A credential that fails to decrypt is skipped, same fail-open reasoning.

How often it runs

Two triggers, both landing on the same poll:

  1. On a TTL, every 6 hours by default -- a sweep only starts if the last one is older than the TTL, or never ran at all.
  2. On demand -- the Credentials page's Refresh Now button queues an immediate sweep regardless of the TTL, and the page polls for real completion (capped at 5 minutes) rather than just claiming "requested" and leaving it there.

Either way, the whole sweep (every active credential x every active target server x every online database on each) runs as one unit -- there's no partial/incremental sweep, and no way to scan just one credential or one server on demand today.

What's still open

  • Domain-level Windows permissions aren't checked at all -- only local-box SQL Server role membership (automatic) and a hand-set "local admin on this box" flag (manual). A Windows account that's elevated by domain group membership isn't detected by either mechanism today.
  • AzureServicePrincipal credentials have no elevated-access check of any kind. Checking Azure RBAC role assignments would need a genuinely new code path. Both items are on the v.next backlog, not in progress.

See also: Elevated Credentials, Elevated Roles, Glossary.