SQL Server 2025 Security Hardening Checklist for Windows Server

In short

A secure SQL Server 2025 deployment needs more than a strong sa password. Before production, restrict network exposure, verify encrypted client connections, use least-privilege logins, enforce an intentional password policy, keep unnecessary features disabled, enable SQL Server Audit, protect backups, and apply current SQL Server updates. SQL Server 2025 adds stronger security capabilities, including TDS 8.0/TLS 1.3 support and PBKDF2 password hashing, but they do not remove the need for deliberate hardening.

SQL Server 2025 hardening checklist

Use this as the production baseline before an application starts using the instance.

This guide follows the SQL Server 2025 installation guide. If the instance is not installed yet, build it cleanly first, then harden it before production data or public-facing applications are added.

Secure the authentication model first

Authentication mistakes create a larger attack surface than most tuning mistakes.

Prefer Windows authentication where the environment supports it

For domain-managed or otherwise controlled Windows environments, Windows authentication can reduce the number of standalone SQL passwords you need to manage.

SQL authentication is still valid when an application requires it, but each SQL login becomes another credential that needs rotation, storage, monitoring, and least-privilege permissions.

A useful production rule is:

Human administrators
→ Windows authentication where practical

Applications that require SQL authentication
→ dedicated SQL login per application
→ minimum database permissions
→ no shared sa credential

Disable sa after verifying another sysadmin

Do not disable sa before confirming that another administrator can recover and manage the SQL instance.

Check current server-role membership:

SELECT
    sp.name,
    sp.type_desc,
    sp.is_disabled,
    IS_SRVROLEMEMBER('sysadmin', sp.name) AS IsSysadmin
FROM sys.server_principals AS sp
WHERE sp.type IN ('S','U','G')
ORDER BY sp.name;

Then verify a separate administrative login through SSMS or sqlcmd before disabling sa:

ALTER LOGIN sa DISABLE;

Verify:

SELECT name, is_disabled, modify_date
FROM sys.sql_logins
WHERE name = 'sa';

Renaming sa can reduce noise from unsophisticated username guessing, but renaming is not a substitute for disabling an unnecessary privileged login, restricting network access, and monitoring authentication attempts.

SQL Server 2025 password policy needs an operational decision

Google Search Console shows this page already receiving visibility for sql server 2025 password policy, so it is worth separating the actual SQL Server controls from generic password advice.

For a SQL login, Microsoft exposes two important options:

• CHECK_POLICY = ON — applies the Windows password policy to the SQL login.
• CHECK_EXPIRATION = ON — applies password-expiration behavior.

For an interactive administrator login, both may fit the organization's policy. For an unattended application credential, blindly enabling password expiration can create an outage if the application cannot rotate the credential safely.

A more defensible rule is:

CHECK_POLICY = ON
+
credential rotation designed for the workload
+
secrets stored outside source code
+
expiration enabled only when the application and rotation process support it

Example application login:

CREATE LOGIN app_raffapp01
WITH PASSWORD = 'REPLACE-WITH-A-UNIQUE-SECRET',
     DEFAULT_DATABASE = RaffApp01,
     CHECK_POLICY = ON,
     CHECK_EXPIRATION = OFF;

CHECK_EXPIRATION = OFF above is not a recommendation to keep a password forever. It illustrates the difference between automatic Windows password expiry and an application-managed rotation process. If your application supports safe automated rotation, use the policy that matches your security standard.

SQL Server 2025 uses PBKDF2 for SQL-authentication password hashes

SQL Server 2025 uses PBKDF2 (RFC 2898) with SHA-512 and 100,000 iterations for password-based authentication. This makes offline password-hash cracking more expensive than the older single-pass approach.

It can also add a small CPU/login-latency cost, especially in environments that repeatedly create new SQL-authenticated connections instead of using connection pooling. That is another reason to use modern drivers and sensible connection pooling rather than reconnecting for every database operation.

Least-privilege application logins reduce blast radius

Do not solve application permission errors by granting sysadmin or db_owner permanently.

Create a login, map it only to the database it needs, and grant the smallest set of permissions required by the application.

Example:

CREATE DATABASE RaffApp01;
GO

CREATE LOGIN app_raffapp01
WITH PASSWORD = 'REPLACE-WITH-A-UNIQUE-SECRET',
     DEFAULT_DATABASE = RaffApp01,
     CHECK_POLICY = ON;
GO

USE RaffApp01;
GO

CREATE USER app_raffapp01 FOR LOGIN app_raffapp01;
ALTER ROLE db_datareader ADD MEMBER app_raffapp01;
ALTER ROLE db_datawriter ADD MEMBER app_raffapp01;
GO

Verify that the login is not a server administrator:

SELECT
    sl.name,
    sl.default_database_name,
    sl.is_policy_checked,
    sl.is_expiration_checked,
    IS_SRVROLEMEMBER('sysadmin', sl.name) AS IsSysadmin
FROM sys.sql_logins AS sl
WHERE sl.name = 'app_raffapp01';

For applications that need schema changes during deployment, separate deployment/migration permissions from the long-running runtime identity. A deployment identity can receive the DDL rights the migration process needs, while the runtime identity stays narrower.

Encrypted SQL Server connections require both protocol and certificate planning

One of the biggest corrections to older SQL Server 2025 guidance is this:

SQL Server 2025 supports TDS 8.0 and TLS 1.3, but that does not mean every client connection automatically uses strict TLS 1.3 encryption.

Microsoft documents multiple connection modes:

• Encrypt=Strict uses TDS 8.0 and requires encryption.
• Encrypt=Mandatory / true uses TDS 7.x with encryption.
• Encrypt=Optional / false uses TDS 7.x and can remain optional unless the server requires encryption.

SQL Server Configuration Manager also distinguishes Force Encryption from Force Strict Encryption.

Use strict encryption only after client compatibility is validated

For clients and features that support TDS 8.0, Encrypt=Strict or server-side Force Strict Encryption provides the strongest current protocol path. TLS 1.3 is available in the strict/TDS 8.0 path when the operating system and client stack support it.

Do not enable strict mode blindly on a production instance without testing:

• application drivers;
• SQL Server Agent;
• SSMS/sqlcmd versions;
• linked servers;
• replication;
• Always On components;
• monitoring and backup agents;
• any vendor application that owns the connection string.

Use a trusted certificate with the correct server identity

Encryption and certificate validation are separate concerns. A client can encrypt a connection while still bypassing certificate validation if TrustServerCertificate=True is used.

For production remote connections, prefer a certificate whose identity matches the DNS name clients use to reach SQL Server and whose issuing chain the clients trust.

After connecting, inspect whether the current SQL connection is encrypted:

SELECT
    session_id,
    net_transport,
    protocol_type,
    encrypt_option,
    auth_scheme,
    client_net_address
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

encrypt_option = TRUE confirms that the connection is encrypted. It does not by itself prove that the client validated the intended certificate identity, so verify the driver/connection-string settings as well.

Restrict SQL Server network exposure

If every application component runs on the same Windows VM, you may not need remote SQL connectivity at all.

If another VM or administrator workstation needs to connect, enable TCP/IP deliberately and restrict who can reach the port.

In the original Raff test environment, the tested default-instance Custom installation had TCP/IP disabled until it was enabled manually. Treat that as a lab observation, not a guarantee for every SQL Server installation path.

You can inspect the protocol state for the tested default-instance path with PowerShell:

$tcpKey = 'HKLM:\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL17.MSSQLSERVER\MSSQLServer\SuperSocketNetLib\Tcp'
Get-ItemProperty -Path $tcpKey | Select-Object Enabled, ListenOnAllIPs, DisplayName

After enabling TCP/IP through SQL Server Configuration Manager or the appropriate supported configuration process, restart the SQL Server service and verify the intended port.

Do not expose TCP 1433 to the whole internet

A production SQL Server should normally be reached through one of these patterns, in descending preference for many small deployments:

1. private networking between application and database VMs;
2. VPN-based administrative access;
3. tightly scoped source-IP allowlisting;
4. public SQL access only when a real application requirement makes it unavoidable.

Example firewall rule for a known trusted source:

New-NetFirewallRule `
    -DisplayName 'SQL Server TCP 1433 - Trusted Source' `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 1433 `
    -RemoteAddress '203.0.113.10/32' `
    -Action Allow

203.0.113.10 is an RFC 5737 documentation address. Replace it with the real trusted source.

Avoid an inbound rule that effectively allows:

TCP 1433
RemoteAddress = Any

For a Raff deployment with separate application and database VMs, prefer private Windows VM networking over exposing the database port publicly when the architecture permits it.

Keep risky SQL Server features disabled unless they are required

SQL Server's attack surface grows when powerful features are enabled only for convenience.

xp_cmdshell is disabled by default and should usually remain disabled:

SELECT name, value, value_in_use
FROM sys.configurations
WHERE name = 'xp_cmdshell';

Expected production baseline when the workload does not require it:

value = 0
value_in_use = 0

If a vendor product explicitly requires a powerful feature, document:

• why it is required;
• which identity can invoke it;
• what network/filesystem access it creates;
• how it is monitored;
• whether it can be disabled again after a one-time administrative task.

The goal is not “disable every SQL feature.” The goal is do not enable privileged surface area without a workload reason.

SQL Server Audit should record security-sensitive activity

SQL Server Audit is available in SQL Server 2025 across Enterprise, Standard, and Express for server and database auditing capabilities documented by Microsoft.

A useful baseline records authentication and permission changes without trying to log every query in the system.

Create a dedicated audit directory:

New-Item -ItemType Directory -Path 'C:\SQL\Audit' -Force

Then create the server audit and specification:

CREATE SERVER AUDIT Raff_SecurityAudit
TO FILE (
    FILEPATH = 'C:\SQL\Audit\',
    MAXSIZE = 100 MB,
    MAX_ROLLOVER_FILES = 10,
    RESERVE_DISK_SPACE = OFF
)
WITH (
    QUEUE_DELAY = 1000,
    ON_FAILURE = CONTINUE
);
GO

CREATE SERVER AUDIT SPECIFICATION Raff_SecurityAudit_Spec
FOR SERVER AUDIT Raff_SecurityAudit
ADD (FAILED_LOGIN_GROUP),
ADD (SUCCESSFUL_LOGIN_GROUP),
ADD (SERVER_ROLE_MEMBER_CHANGE_GROUP),
ADD (DATABASE_ROLE_MEMBER_CHANGE_GROUP),
ADD (SERVER_PERMISSION_CHANGE_GROUP),
ADD (DATABASE_PERMISSION_CHANGE_GROUP),
ADD (SERVER_PRINCIPAL_CHANGE_GROUP),
ADD (DATABASE_PRINCIPAL_CHANGE_GROUP),
ADD (SCHEMA_OBJECT_CHANGE_GROUP)
WITH (STATE = ON);
GO

ALTER SERVER AUDIT Raff_SecurityAudit
WITH (STATE = ON);
GO

Verify:

SELECT name, type_desc, is_state_enabled, create_date
FROM sys.server_audits;

And inspect recent audit records:

SELECT TOP (50)
    event_time,
    action_id,
    succeeded,
    server_principal_name,
    client_ip,
    application_name,
    statement
FROM sys.fn_get_audit_file('C:\SQL\Audit\*.sqlaudit', DEFAULT, DEFAULT)
ORDER BY event_time DESC;

In production, local rolling files are only the first layer. Decide how long the organization needs audit data, who can delete it, and whether logs need to be copied or forwarded to a separate security boundary or SIEM.

Protect data at rest and backup files according to the edition

Do not assume every SQL Server edition supports the same encryption features.

Microsoft's current SQL Server 2025 edition matrix documents:

Developer editions are development/test editions that expose the feature set of their corresponding paid edition; they are not normal production licenses.

TDE protects database files, not every security problem

TDE protects data files and log files at rest. It does not replace:

• access control;
• encrypted client connections;
• least privilege;
• backup policy;
• audit logging;
• application-layer security.

If you use TDE, the certificate/key recovery process is part of the backup strategy. Losing the required recovery material can make an encrypted database backup impossible to restore elsewhere.

Backup encryption needs off-server key recovery planning

For supported editions, backup encryption is a strong control when .bak files can leave the SQL VM.

But an encrypted backup is only useful if the organization can restore it. Keep certificate/private-key recovery material and its secret outside the SQL Server VM and test the restore procedure on a separate instance.

For full/differential/log schedules, retention, restore chains, and off-server copies, use the SQL Server backup strategy guide.

Patch SQL Server 2025 before production

Do not leave a new installation on RTM simply because setup succeeded.

As of September 9, 2026, Microsoft's SQL Server 2025 build list identifies CU8 (KB5104822), build 17.0.4075.5, released August 13, 2026 as the latest cumulative update.

Check the installed build:

SELECT
    SERVERPROPERTY('ProductVersion') AS ProductVersion,
    SERVERPROPERTY('ProductLevel') AS ProductLevel,
    SERVERPROPERTY('ProductUpdateLevel') AS ProductUpdateLevel,
    SERVERPROPERTY('Edition') AS Edition;

Then compare it with Microsoft's current SQL Server 2025 build list rather than permanently hard-coding CU8 into your operations runbook. A newer CU or GDR can appear after this article is published.

A production patch process should include:

1. review the current CU/GDR and known issues;
2. test the update against a representative non-production workload when practical;
3. take and verify the required backups;
4. schedule the maintenance window;
5. apply the update;
6. verify services, database health, application connectivity, jobs, and backups afterward.

A practical SQL Server 2025 hardening verification

A hardening checklist is useful only if you can verify the resulting state.

Run the following checks after the configuration changes.

Verify sa, password policy, and privileged SQL logins

SELECT
    name,
    is_disabled,
    is_policy_checked,
    is_expiration_checked
FROM sys.sql_logins
ORDER BY name;

SELECT
    sp.name AS LoginName
FROM sys.server_principals AS sp
JOIN sys.server_role_members AS srm
    ON sp.principal_id = srm.member_principal_id
JOIN sys.server_principals AS rolep
    ON srm.role_principal_id = rolep.principal_id
WHERE rolep.name = 'sysadmin';

Review every SQL-authenticated sysadmin. Each one should have a documented operational reason.

Verify high-risk configuration

SELECT name, value, value_in_use
FROM sys.configurations
WHERE name IN (
    'xp_cmdshell',
    'Ole Automation Procedures',
    'Ad Hoc Distributed Queries'
)
ORDER BY name;

Do not automatically change a setting merely because it appears in this output. Investigate whether the workload requires it first.

Verify current connection encryption

SELECT
    session_id,
    net_transport,
    encrypt_option,
    auth_scheme,
    client_net_address
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Verify SQL Server Audit

SELECT name, is_state_enabled
FROM sys.server_audits;

SELECT
    sas.name,
    sas.is_state_enabled,
    sasd.audit_action_name
FROM sys.server_audit_specifications AS sas
JOIN sys.server_audit_specification_details AS sasd
    ON sas.server_specification_id = sasd.server_specification_id
ORDER BY sas.name, sasd.audit_action_name;

Verify network exposure from Windows

Get-NetTCPConnection -State Listen |
    Where-Object LocalPort -eq 1433 |
    Select-Object LocalAddress, LocalPort, OwningProcess

Get-NetFirewallRule -Enabled True -Direction Inbound -Action Allow |
    Get-NetFirewallPortFilter |
    Where-Object LocalPort -eq 1433

If TCP 1433 is listening, confirm the associated inbound rule is actually restricted to the intended source addresses or private network.

Tested on Raff

Original live test: SQL Server 2025 Standard Developer, build 17.0.1000.7 RTM, on Windows Server 2025 Standard build 26100, 4 vCPU / 8 GB RAM / 120 GB storage in Raff us-east, tested April 30, 2026 by Serdar Tekin.

The test verified: disabling sa after confirming alternate admin access; a least-privilege application login with password-policy controls; SQL Server Audit with login, role, permission, and schema-related action groups; audit-file capture of failed/successful login activity; TCP/IP enabled for the tested default-instance Custom installation; a tightly scoped Windows Firewall rule using an RFC 5737 documentation IP; and xp_cmdshell remaining disabled.

Not live-tested in that session: production certificate replacement, TDE, and encrypted-backup recovery. Those sections are based on current Microsoft documentation and are not presented as Raff test evidence.

The September 9, 2026 refresh revalidated SQL Server 2025 protocol, edition-feature, password-hashing, and update guidance against current Microsoft documentation. It does not claim a new end-to-end hardening lab run.

Frequently asked questions

What are the most important SQL Server hardening steps?

Start with network restriction, least-privilege authentication, removal of unnecessary privileged logins, encrypted client connections with proper certificate validation, security auditing, supported encryption for data/backups, current patching, and tested recovery procedures.

Should the sa account be disabled?

If another tested administrative login can manage and recover the instance, disabling sa reduces exposure to a well-known privileged SQL login. Do not disable it before verifying an alternate sysadmin and recovery path.

Does SQL Server 2025 force TLS 1.3 for every connection?

No. SQL Server 2025 supports TDS 8.0 and TLS 1.3, but strict encryption depends on server and client configuration. Encrypt=Strict / Force Strict Encryption uses the TDS 8.0 strict path; mandatory or optional modes can use TDS 7.x and TLS 1.2 depending on configuration.

Does SQL Server Express support TDE and encrypted backups?

No. Microsoft's SQL Server 2025 edition matrix lists TDE and backup encryption for Standard and Enterprise but not Express. SQL Server Audit remains available on Express.

Should application SQL logins use password expiration?

Use CHECK_POLICY = ON and design a real credential-rotation process. CHECK_EXPIRATION = ON is appropriate only when the application and operations process can rotate the credential safely without causing outages.

What is the latest SQL Server 2025 cumulative update?

As of September 9, 2026, Microsoft lists CU8, build 17.0.4075.5, released August 13, 2026. Always check Microsoft's current build-version page because that answer changes over time.

What's next

• Install SQL Server 2025 on Windows Server VPS
• SQL Server Backup Strategy: Full, Differential & Log Backups
• SQL Server 2025 Licensing Guide
• Windows Server 2022 vs 2025
• SQL Server hosting

Sources

• Microsoft Learn — Securing SQL Server
• Microsoft Learn — TDS 8.0
• Microsoft Learn — Connect to SQL Server with strict encryption
• Microsoft Learn — Configure TLS 1.3 on SQL Server
• Microsoft Learn — Password policy
• Microsoft Learn — SQL Server 2025 known issues
• Microsoft Learn — SQL Server Audit
• Microsoft Learn — Editions and supported features of SQL Server 2025
• Microsoft Learn — Transparent Data Encryption
• Microsoft Learn — Backup encryption
• Microsoft Learn — SQL Server 2025 build versions
• Sources verified: 2026-09-09

Microsoft, Windows Server, SQL Server, and SQL Server Management Studio are trademarks of Microsoft Corporation. Raff Technologies is an independent infrastructure provider and is not affiliated with, sponsored by, or endorsed by Microsoft Corporation.