Most SQL Server security reviews start in the wrong place. Teams check whether TDE is enabled, confirm backups are encrypted, and call it done — while the permission structure underneath has been accumulating risk for years through inherited roles, stale service accounts, and "temporary" access grants nobody ever revoked.
A real security posture isn't one control. It's the layered combination of identity, encryption, monitoring, and network design working together — and most enterprise environments are missing at least a few of the twelve below.
1. Move Off SQL Authentication Where You Can
SQL Server authentication stores credentials inside the database engine itself, which means every SQL login is a credential an attacker can target independent of your broader identity infrastructure. Microsoft Entra ID (formerly Azure AD) authentication ties database access to your centralized identity provider — so conditional access policies, MFA, and deprovisioning workflows apply to your database the same way they apply to everything else. If SQL authentication has to stay for legacy application support, isolate those logins and rotate their credentials on a defined schedule rather than treating them as permanent.
2. Apply Least Privilege at the Permission Level, Not the Role Level
The common shortcut — adding a user to db_owner because it's faster than figuring out the exact permissions they need — is the single most common over-privileging pattern in production environments. SQL Server 2022 introduced granular server-level permissions specifically to close this gap, letting you grant narrow capabilities instead of falling back to broad, all-or-nothing role membership. Audit existing role membership against actual usage; if nobody can explain why a login is in sysadmin, that's the finding.
3. Encrypt Data at Rest — and Verify It's Actually Working
Transparent Data Encryption (TDE) protects the physical database files, but enabling it isn't the same as verifying it's protecting what you think it's protecting. Confirm TDE certificates are backed up separately from the database itself — a lost TDE certificate means a database you can't restore — and check that tempdb is also encrypted, since query intermediate results land there regardless of the source database's settings.
4. Use Always Encrypted for Genuinely Sensitive Columns
TDE protects against someone stealing the physical files. It does nothing to stop a DBA, a compromised application account, or a malicious insider from simply querying sensitive columns in plaintext. Always Encrypted keeps specific columns — SSNs, payment data, health records — encrypted in memory and in query plans, decryptable only by the application with the right key, not by SQL Server itself.
5. Turn On SQL Server Audit, Not Just Default Trace
Default trace and the SQL Server error log were never designed as security audit tools — they're operational logs that happen to capture some relevant events. SQL Server Audit (or Extended Events, for lighter-weight needs) lets you capture permission changes, failed logins, and schema modifications at the granularity compliance frameworks actually require.
6. Run Vulnerability Assessment on a Schedule, Not Just Once
Microsoft Defender for SQL's Vulnerability Assessment scans for misconfigurations against a rule set Microsoft updates as new risks emerge. A one-time scan at deployment tells you the state at that moment. Configuration drifts — recurring scans catch what one-time assessments miss entirely.
7. Harden the Service Account
SQL Server service accounts running as Local System or, worse, a Domain Admin account, turn a SQL Server compromise into a domain compromise. Use a dedicated, least-privilege Managed Service Account (gMSA) scoped to exactly what the SQL Server service needs — nothing more.
8. Disable What You're Not Using
xp_cmdshell, ad hoc distributed queries, and legacy linked server configurations are frequently enabled by default or left on from a long-resolved troubleshooting session — and each one is a documented path for privilege escalation once an attacker has any foothold in the database layer.
9. Apply Row-Level Security for Multi-Tenant or Role-Based Data Access
When different users or tenants should see different subsets of the same table, application-layer filtering is fragile. Row-Level Security enforces the restriction at the database engine level, so even a query that bypasses your application logic still can't see data it shouldn't.
10. Segment the Network Around the Database Tier
Database servers reachable from broad network segments turn any compromised workstation into a direct path to your data. Private endpoints (in Azure) or VLAN segmentation (on-premises) restrict SQL Server connectivity to known, authorized sources.
11. Test Backup Restores, Not Just Backup Completion
An encrypted backup that fails to restore isn't a security control — it's an unverified assumption. Confirm backup jobs are completing successfully and confirm, on a real schedule, that those backups actually restore to a usable database.
12. Review Permissions Quarterly, Not at Onboarding Only
Permission sprawl happens gradually. A quarterly permission audit — comparing current grants against current job function — is the control that keeps every other control on this list from quietly degrading over time.
Where Most Environments Actually Stand
In practice, most enterprise SQL Server environments have items 1, 3, and 7 covered, partial coverage on 5 and 6, and gaps on 2, 4, 9, and 12 — the controls that require ongoing process rather than a one-time configuration change.
If you want a clear picture of where your own environment stands against this list, request a SQL Server Security Assessment — the same assessment framework used across enterprise SQL Server and Azure SQL environments.