SQL Server 2025 raises the bar for enterprise data protection with a suite of powerful, built-in security enhancements. From eliminating client secrets through managed identity authentication to adopting stronger encryption standards and enforcing stricter connection protocols, this release is designed to help organizations stay ahead of evolving threats. With these updates, SQL Server 2025 simplifies compliance and strengthens data security—right out of the box.
Crypto updates
PBKDF2 for password hashes by default
Beginning with SQL Server 2012, SQL Server and Azure SQL DB used a SHA-512 hash combined with a 32-bit random and unique salt. This method made it statistically infeasible for attackers to deduce passwords.
SQL Server 2025 introduces an iterated hash algorithm, RFC2898, also known as a password-based key derivation function (PBKDF). This algorithm still uses SHA-512 but hashes the password multiple times (100,000 iterations), significantly slowing down brute-force attacks. This change enhances password protection in response to evolving security threats and helps customers comply with NIST SP 800-63b guidelines.
This enhancement applies to:
- CREATE LOGIN WITH PASSWORD
- CREATE USER WITH PASSWORD
- CREATE APPLICATION ROLE
OAEP support for certificates and asymmetric keys
Encryption hierarchy
SQL Server encrypts data with hierarchical encryption and key management infrastructure. Each layer encrypts the layer below it by using a combination of certificates, asymmetric keys, and symmetric keys. Asymmetric keys and symmetric keys can be stored outside of SQL Server in an Extensible Key Management (EKM) module. The following illustration shows that each layer of the encryption hierarchy encrypts the layer beneath it, and displays the most common encryption configurations.
New encryption algorithm for certificates and asymmetric keys
Azure SQL and SQL Server use the RSA algorithm for asymmetric encryption. The RSA algorithm cannot be used in its "pure" form as it lacks semantic security and is not secure against chosen plaintext attacks or ciphertext attacks due to its deterministic nature. Encrypting the same message twice produces the same ciphertext. To achieve security, messages require padding. Currently, data is encrypted with RSA using the PKCS #1 v1.5 padding scheme. Newer versions of PKCS#1 v1.5 describe a new padding type called Optimal Asymmetric Encryption Padding (OAEP), which uses a hash function to add significant internal redundancy, making it improbable for a random string to match the padding format. OAEP introduces some hashing between the RSA encryption and the padding check. The hashing from OAEP significantly alters the attacker's ability to understand what they see.
From SQL Server 2025 onwards, OAEP-256 support for RSA-based encryption was introduced for encryption by certificate or asymmetric key. Switching to OAEP padding mode is driven by the database compatibility level. This feature is available for databases at the 170 level of database compatibility or higher.
Securing data in transit with TDS 8.0 and TLS 1.3 support
With the release of SQL Server 2025, Microsoft is enhancing database security by introducing support for Tabular Data Stream (TDS) 8.0 and Transport Layer Security (TLS) 1.3. TDS 8.0 enforces strict encryption protocols to secure data in transit, aligning with today’s encryption standards and customer expectations for secure-by-default configurations.
TDS 8.0 and TLS 1.3 improvement
In previous versions of SQL Server, encryption was optional and negotiated after the initial connection setup. TDS 8.0 changes that by enforcing encryption from the very beginning of the connection. With TLS 1.3, SQL Server 2025 ensures that all communication is encrypted end-to-end, reducing the attack surface and aligning with industry best practices.
The new connection sequence now looks like this:
TCP handshake → TLS handshake → TDS prelogin (encrypted) → Authentication (encrypted) → Data exchange (encrypted)
This is a significant improvement over the previous model, where the TDS prelogin phase was optionally encrypted depending on client and server settings. With TDS 8.0, encryption is enforced from the start of the connection, including the prelogin phase, ensuring end-to-end protection by default.
SQL Server feature support for TDS 8.0
TDS 8.0 and TLS 1.3 support is being rolled out across SQL Server 2025 features and utilities with the following updated and currently available:
- Database Mail
- SQL Writer/VSS
- sqlcmd.exe
- bcp.exe
Additional SQL Server 2025 features will be updated to support TDS 8.0 post-GA:
- Availability Groups & Failover Clusters
- Linked Server
- Log Shipping
- PolyBase
- SQL Agent
Other security enhancements
Security cache improvements
The security cache of SQL Server stores permissions for a user or a login for various securable objects in a database or server. One of the benefits is that it speeds up query execution. Before SQL Server executes a query, it checks if the user has the necessary permissions for different database securables, such as schema-level permissions, table-level permissions, and column permissions.
Various scenarios can trigger security cache invalidations at either the database or server level. When an invalidation occurs, all current cache entries are invalidated. All future queries and permission checks follow the full "No cache" workflow until the caches are repopulated. Invalidation can significantly impact server performance, especially under high load, as all active connections need to rebuild the cached entries. Repeated cache invalidations can make this impact worse. Invalidations in the master database are treated as server-wide invalidations, affecting the caches in all databases on the instance. The table below lists all security DDL actions that invalidate the security cache.
| Action | Subject | Scope |
| CREATE/ALTER/DROP |
APPLICATION ROLE SYMMETRIC KEY ASYMMETRIC KEY AUTHORIZATION CERTIFICATE ROLE SCHEMA USER | Specified database |
| DROP | Any object that appears in sys.all_objects or any securable listed in the database or schema-scoped securable list. | Specified database |
| GRANT/DENY/REVOKE | Any permission to securable contained by database or schema. | Specified database |
| CREATE/ALTER/DROP |
LOGIN (SERVICE) MASTER KEY | SQL Server instance |
| ALTER | DATABASE | Specified database |
SQL Server 2025 introduces a feature that invalidates caches for only a specific login. This means that when security cache entries are invalidated, only those entries belonging to the impacted login are affected. For instance, if you grant login L1 a new permission, the tokens for login L2 remain unaffected. As an initial step, this feature applies to the CREATE, ALTER and DROP login scenarios, and permission changes for individual logins. Group logins continue to experience server level invalidation.
Support custom password policy on Linux
For years, SQL Server on Windows has leveraged Active Directory (AD) to enforce password policies—ensuring consistency with enterprise-wide security standards. However, this level of control was missing in SQL Server on Linux. That changes with SQL Server 2025 where we introduce Custom Password Policies for SQL Server on Linux. This new feature empowers administrators to enforce fine-grained password rules—even in environments without AD integration. Whether you're running in a hybrid setup or a fully cloud-native deployment, you can now apply password complexity, expiration, and history requirements directly within SQL Server on Linux.
In environments where policy management is centralized in an AD server, domain administrators can define and manage password policy values directly in AD. For this to work, the Linux host running SQL Server must be joined to the Windows domain. You can then use the adutil tool to fetch the AD-defined password policy and write it to the mssql.conf file—enabling centralized, consistent policy enforcement across your SQL Server environment.
Alternatively, if your Linux host isn’t domain-joined or you don’t have access to a domain controller, you can configure password policies manually. Simply update the relevant parameters in the mssql.conf file using mssql-conf. This method offers simplicity and direct control, making it ideal for standalone or non-domain environments.
This new functionality closes a long-standing security gap and bringing Linux deployments in line with enterprise-grade password governance.
Entra authentication in Arc enabled SQL Server 2025
SQL Server 2025 introduces a significant advancement in secure authentication by supporting managed identity authentication through Azure Arc integration. This new capability allows SQL Server to authenticate securely without relying on traditional credentials such as client secrets or passwords.
With managed identity enabled, SQL Server can now establish outbound connections to Azure services—such as Azure Blob Storage—using its own managed identity. This means that operations like backing up databases to Azure Blob Storage can be performed securely and seamlessly, without the need to store or manage sensitive credentials.
In addition, this feature also supports inbound authentication scenarios, enabling external users and services to connect to SQL Server using Azure Active Directory identities. This enhances security, simplifies identity management, and aligns with modern best practices for cloud-connected environments.
By leveraging managed identities, organizations can reduce the risk of credential leakage, streamline access control, and improve compliance with security policies.
More detailed information can be found on Entra Authentication in Arc enabled SQL Server 2025 - Windows.
Learn more
Microsoft
