Secure Your Data: Implementing FIPS 140-2 Compliance in SQL Server 2014

Updated: 11 Jul, 2025 • 0 • min read

Table of Contents

FIPS 140-2 Compliance SQL Server 2014

This article provides a comprehensive guide on the Federal Information Processing Standard Publication 140-2 (FIPS 140-2) and details how to configure and operate Microsoft SQL Server 2014 in a FIPS 140-2-compliant mode. Understanding and implementing FIPS 140-2 compliance is crucial for organizations, particularly those working with government agencies or handling sensitive data requiring robust cryptographic protection. By following these instructions, administrators can ensure their SQL Server 2014 deployment adheres to these stringent security requirements.

What is FIPS?¶

Federal Information Processing Standard (FIPS) refers to a set of standards developed to ensure the security and interoperability of computer systems used by the U.S. federal government. These standards are developed collaboratively by two key government bodies: the National Institute of Standards and Technology (NIST) in the United States and the Communications Security Establishment (CSE) in Canada. FIPS standards cover a wide range of IT security topics, but FIPS 140 specifically focuses on cryptographic modules.

Compliance with FIPS standards is often recommended or explicitly mandated for IT systems operated by federal government entities in both the United States and Canada. While primarily a government standard, FIPS compliance is also frequently required for private-sector organizations that handle sensitive government data or operate systems on behalf of government agencies. Furthermore, many industries, such as healthcare and finance, often adopt FIPS standards as a best practice for protecting sensitive information due to their recognized rigor.

What is FIPS 140-2?¶

FIPS Publication 140-2 is a specific standard titled “Security Requirements for Cryptographic Modules.” It defines the requirements that cryptographic modules must meet for use in protecting sensitive but unclassified information within computer and telecommunications systems. The standard covers aspects such as cryptographic algorithm validation, key management, physical security, operational requirements, and the overall design and implementation of the cryptographic module.

Importantly, FIPS 140-2 specifies which encryption algorithms and hashing algorithms are approved for use and how cryptographic keys are to be generated, protected, and managed throughout their lifecycle. The standard defines various security levels (Level 1 through 4), increasing in stringency based on the sensitivity of the data and the environment in which the module is deployed. Compliance often requires the use of specific, validated implementations of approved algorithms, not just the algorithms themselves.

What is the Difference Between FIPS 140-2 Compliant and FIPS 140-2 Certified?¶

The distinction between FIPS 140-2 certified and FIPS 140-2 compliant is fundamental. A cryptographic module (which can be hardware, software, firmware, or a combination) is FIPS 140-2 certified after it has been rigorously tested and validated by an accredited laboratory and approved by the Cryptographic Module Validation Program (CMVP), jointly run by NIST and CSE. This certification confirms that the module itself meets the standard’s requirements at a specific security level.

FIPS 140-2 compliant, on the other hand, describes a system or application that uses FIPS 140-2 certified cryptographic modules in a manner consistent with the FIPS 140-2 standard. A complex application like SQL Server 2014 cannot be certified itself, as it is not solely a cryptographic module. Instead, it can be configured and operated to be compliant by ensuring that whenever it performs encryption or hashing for security purposes requiring FIPS validation, it exclusively calls upon underlying operating system components (like the Windows CryptoAPI) that are FIPS 140-2 certified. Running SQL Server 2014 in a compliant mode relies heavily on the underlying operating system providing the necessary certified cryptographic functions.

Which Application Products Can Be FIPS 140-2 Compliant?¶

Any application product that performs cryptographic operations (encryption, decryption, hashing, digital signatures, etc.) can potentially be FIPS 140-2 compliant if it runs on an operating system that provides FIPS 140-2 certified cryptographic modules. The key requirement for such an application is to utilize only these certified modules for cryptographic functions that fall under FIPS scope. This is typically achieved by using standard operating system cryptographic libraries or APIs, such as the Windows CryptoAPI or CNG (Cryptography API: Next Generation).

Beyond just using certified algorithms, a compliant application must also adhere to FIPS 140-2 requirements regarding key generation, key management, and secure handling of cryptographic parameters. While using the OS-provided key management functions simplifies this, applications can also implement their own key management provided it meets the standard. It’s important to note that an application can be FIPS-compliant even if it contains non-compliant cryptographic operations for purposes not requiring FIPS validation (e.g., internal, non-security-sensitive hashing) or if it handles data that is subsequently encrypted by a compliant process.

Is SQL Server 2014 Always FIPS 140-2 Compliant?¶

No, SQL Server 2014 is not inherently or always FIPS 140-2 compliant out of the box. While SQL Server 2014 contains cryptographic functionality, its compliance is conditional. It can be operated in a FIPS 140-2 compliant manner, but this requires specific configuration of the underlying operating system and potentially specific configurations within SQL Server itself, particularly concerning features that allow users to choose encryption methods.

To achieve FIPS 140-2 compliance, SQL Server 2014 must be installed on an operating system version that provides FIPS 140-2 certified cryptographic modules, and the FIPS mode must be explicitly enabled on the operating system. When the operating system’s FIPS mode is enabled, SQL Server 2014 is designed to use the Windows CryptoAPI, which in turn accesses the certified cryptographic functions. If the FIPS mode is not enabled on the operating system, SQL Server may use algorithms or implementations that are not FIPS 140-2 certified, rendering the overall system non-compliant.

How Can SQL Server 2014 Be Configured to Be FIPS 140-2 Compliant?¶

Configuring SQL Server 2014 for FIPS 140-2 compliance involves meeting requirements at both the operating system and SQL Server levels. The process ensures that SQL Server utilizes the certified cryptographic modules provided by the Windows operating system whenever cryptographic operations are necessary for security purposes covered by FIPS 140-2. This configuration must be performed carefully to avoid disrupting functionality and to ensure compliance is genuinely achieved.

Operating System Requirement¶

The foundational step for FIPS 140-2 compliance in SQL Server 2014 is installing it on a supported operating system that provides FIPS-validated cryptographic libraries. For SQL Server 2014, the following operating systems are suitable platforms because they contain FIPS 140-2 certified cryptographic modules that SQL Server can leverage:

Windows Server 2012
Windows Server 2012 R2
Windows 8
Windows 8.1
Windows 10

It is imperative that SQL Server 2014 is installed on one of these, or later compatible, operating systems. Running SQL Server 2014 on an older operating system that does not provide FIPS 140-2 certified cryptographic modules will make FIPS compliance impossible, regardless of other configuration steps. The operating system provides the necessary certified “building blocks” for SQL Server to use for its cryptographic functions.

Windows System Administration Requirement¶

Once SQL Server 2014 is installed on a suitable operating system, the FIPS mode must be enabled at the operating system level. This is typically done via a local security policy or Group Policy setting. This setting forces the system-wide use of FIPS-validated algorithms for encryption, hashing, and signing when using the Windows cryptographic libraries. SQL Server reads this setting upon startup to determine whether it should operate in FIPS-compliant mode.

To set the FIPS mode on the operating system where SQL Server 2014 is installed, follow these steps:

Log on to the Windows system using an account with administrative privileges.
Open the Start menu.
Type “Control Panel” and select it from the search results.
In the Control Panel, find and select Administrative Tools. You may need to switch the view to “Large icons” or “Small icons” to easily locate Administrative Tools.
Within Administrative Tools, double-click on Local Security Policy. This action opens the Local Security Settings window, which allows configuration of various security policies for the local computer.
In the left-hand navigation pane of the Local Security Settings window, expand Local Policies, and then select Security Options. This displays a list of security policies in the right-hand pane.
Scroll through the policies in the right-hand pane and double-click on the policy named “System cryptography: Use FIPS-compliant algorithms for encryption, hashing, and signing”. This opens a dialog box for configuring this specific policy setting.
In the policy dialog box, select the Enabled option. This enforces the system-wide use of FIPS 140-2 validated cryptographic algorithms via the Windows CryptoAPI. After selecting Enabled, click Apply to stage the change.
Click OK to confirm the change and close the policy dialog box.
Close the Local Security Settings window.

After enabling this policy, the change takes effect upon the next system restart or, more relevantly for SQL Server, the next time the SQL Server service is started. It is crucial to restart the SQL Server service after enabling the FIPS policy for SQL Server to detect the setting and operate in compliance mode.

SQL Server Administrator Requirement¶

For SQL Server 2014 to fully operate in FIPS 140-2 compliant mode, it must detect that the operating system’s FIPS policy is enabled upon startup. When the SQL Server service initializes and detects the enabled FIPS mode, it logs specific messages in its error log and potentially the Windows event log, confirming that it is operating in compliance mode for certain features.

You can verify that SQL Server has successfully detected the FIPS mode and is operating in compliance by checking the SQL Server error log after restarting the service. Look for the following message, particularly if you are using Service Broker or Database Mirroring endpoints:

Service Broker transport is running in FIPS compliance mode.

Additionally, you might find a similar message in the Windows event log related to Database Mirroring if configured:

Database Mirroring transport is running in FIPS-compliance mode.

The presence of these log entries signifies that SQL Server has acknowledged the operating system’s FIPS setting and will enforce the use of FIPS-compliant algorithms for relevant internal operations and configurable features. For example, when dialog security is used between services (Service Broker), the encryption will use the FIPS-certified instance of Advanced Encryption Standard (AES) if FIPS mode is enabled. Conversely, if FIPS mode is disabled, SQL Server might default to less secure or non-FIPS algorithms like RC4 for these features.

Furthermore, if configuring a Service Broker endpoint while SQL Server is running in FIPS mode, the administrator must explicitly specify “AES” as the encryption algorithm for the endpoint. Configuring the endpoint to use RC4 or allowing the default (which might resolve to RC4 when FIPS is off) will cause SQL Server to generate an error when trying to start the transport layer, preventing the endpoint from functioning. This explicit requirement for AES in FIPS mode ensures that only a FIPS-approved algorithm is used for this sensitive communication channel.

How is SQL Server 2014 Operated in FIPS 140-2 Compliant Mode?¶

When SQL Server 2014 is configured and running in FIPS 140-2 compliant mode (meaning the Windows FIPS policy is enabled and SQL Server has detected it), its behavior changes in specific ways to ensure compliance. This affects both internal SQL Server processes and how certain configurable security features function. The primary mechanism SQL Server uses is relying on the Windows CryptoAPI to perform cryptographic operations, thereby utilizing the underlying FIPS 140-2 certified modules.

Automatic Compliance for Internal Operations: For many internal cryptographic operations where SQL Server performs encryption or hashing and the user or administrator has no direct choice in the algorithm used, SQL Server 2014 will automatically utilize the Windows CryptoAPI. With the Windows FIPS mode turned on, CryptoAPI is constrained to use only the FIPS 140-2 certified instances of approved algorithms. This ensures that core SQL Server functions requiring cryptography adhere to the standard without requiring specific user configuration for each instance.
Compliance Enforcement for Configurable Features: For features where the user or administrator can specify encryption settings, SQL Server enforces compliance when FIPS mode is enabled. This means that if a feature supports FIPS-compliant encryption, SQL Server will only allow the configuration of FIPS-approved algorithms (like AES). If a feature offers non-compliant encryption options or defaults to one, SQL Server will either disable the non-compliant option or prevent the operation entirely with an error message. This ensures that administrators cannot inadvertently configure SQL Server to use non-compliant cryptography for sensitive features like Service Broker or Database Mirroring endpoints.
Developer and User Responsibility: While SQL Server handles compliance for its built-in features, developers creating custom applications or scripts that interact with SQL Server and perform their own encryption or hashing must also ensure their code is FIPS 140-2 compliant. This means they should not implement cryptographic algorithms themselves but instead use the Windows CryptoAPI or CNG. Furthermore, they must select only those algorithms that are specifically approved by FIPS 140-2 (e.g., AES for encryption, SHA-2 family for hashing). For the official list of FIPS 140-2 approved cryptographic algorithms, developers should consult Annexes A, C, and D in the NIST Cryptographic Module Validation Program documentation. Adhering to these guidelines for custom code is essential to maintain end-to-end FIPS compliance within the application ecosystem.

Supporting Media: Compliance Flow Diagram

Here is a simplified diagram illustrating the flow of cryptographic operations in SQL Server 2014 under FIPS compliant mode:

```mermaid
sequenceDiagram
participant User as User/Administrator
participant OSAdmin as OS Administrator
participant Windows as Windows OS
participant SQLServer as SQL Server 2014
participant CryptoAPI as Windows CryptoAPI
participant CertifiedModules as FIPS Certified Cryptographic Modules

OSAdmin->Windows: Enable FIPS Policy
Windows->Windows: Set System-wide FIPS Flag (Registry)
User->SQLServer: Start SQL Server Service
SQLServer->Windows: Read System FIPS Flag on Startup
alt FIPS Flag Enabled
    SQLServer->SQLServer: Enter FIPS Compliance Mode
    SQLServer->SQLServer: Log FIPS Compliance Message
    SQLServer->CryptoAPI: Request Cryptographic Operation (e.g., Encrypt Service Broker Msg)
    CryptoAPI->CertifiedModules: Use Only FIPS 140-2 Validated Algorithms
    CertifiedModules-->CryptoAPI: Perform Operation (e.g., AES Encryption)
    CryptoAPI-->SQLServer: Return Result
else FIPS Flag Disabled
    SQLServer->SQLServer: Operate in Standard Mode
    SQLServer->CryptoAPI: Request Cryptographic Operation (May use non-FIPS algorithms)
    CryptoAPI->CertifiedModules: Use Available Algorithms (May include non-FIPS)
    CertifiedModules-->CryptoAPI: Perform Operation
    CryptoAPI-->SQLServer: Return Result
end

```

This diagram visually represents how enabling the FIPS policy on Windows directs SQL Server, via the CryptoAPI, to exclusively use the certified cryptographic functions provided by the operating system when performing operations requiring FIPS compliance.

What is the Effect of Running SQL Server 2014 in FIPS 140-2-Compliant Mode?¶

Running SQL Server 2014 in FIPS 140-2 compliant mode has several key effects, primarily related to the enforcement of FIPS-approved cryptographic standards. These effects ensure that cryptographic operations align with regulatory requirements but may also impose certain limitations or require specific configurations for some features.

Performance Implications: Utilizing stronger, FIPS-validated encryption algorithms, such as AES, may introduce a minor performance overhead compared to less robust or non-validated algorithms like RC4, which might be used when FIPS mode is disabled. However, on modern server hardware, the impact of this difference is often negligible for typical database workloads. The performance effect is more likely to be noticeable in scenarios involving very high volumes of encrypted network traffic (like Service Broker or Database Mirroring with encryption enabled) or extensive use of cryptography in custom applications. For most standard database operations and storage encryption (like Transparent Data Encryption, which relies on Windows encryption functions), the performance difference is minimal.
SSIS Package Encryption: SQL Server Integration Services (SSIS) packages have an option (UseEncryption=True) to encrypt the package itself, protecting sensitive information like connection strings. The default encryption method used by SSIS for this purpose is not FIPS 140-2 compliant. When SQL Server’s environment is running in FIPS mode, attempting to save an SSIS package with this non-compliant encryption option enabled will generate an error message. This error prevents the saving of the package with non-compliant encryption, effectively disabling this specific feature to maintain overall compliance. To securely store SSIS packages in a FIPS-compliant environment, alternative methods like encrypting the file system or storing sensitive data separately (e.g., in SQL Server itself with appropriate security) must be used.
Legacy DTS Package Encryption: Data Transformation Services (DTS) is a legacy technology superseded by SSIS. DTS packages also have encryption options, but these methods are not compliant with FIPS 140-2. Importantly, the DTS runtime does not check the Windows FIPS mode setting. This means that even if the operating system is configured for FIPS compliance, DTS will still allow the user to select and use non-compliant encryption. Therefore, to maintain FIPS compliance when working with legacy DTS packages, it becomes the explicit responsibility of the user or administrator to ensure that package encryption is not used.
General Impact: For most standard SQL Server 2014 operations, running in FIPS 140-2 compliant mode has little to no negative effect on usage or performance. Features that rely on Windows encryption for secure communication or data storage (like TLS/SSL for connections, or the underlying encryption used by TDE master keys if not using an Extensible Key Management provider) will automatically use the FIPS-validated algorithms provided by the OS. The primary impact is on specific legacy or optional features that have built-in non-compliant encryption methods, which are either disabled or require the user to manually avoid non-compliant options.

Supporting Media: Feature Impact Table

Here is a table summarizing the impact of FIPS 140-2 compliant mode on specific SQL Server 2014 features mentioned:

Feature	Default/Non-FIPS Encryption Option	FIPS Compliant Method Required / Used	Effect in FIPS Mode
Service Broker Endpoint	RC4 (If not specified)	AES (Must be explicitly specified)	RC4 endpoint configuration fails; AES is required. Transport runs in FIPS mode.
Database Mirroring Endpoint	RC4 (If not specified)	AES (Must be explicitly specified)	RC4 endpoint configuration fails; AES is required. Transport runs in FIPS mode.
SSIS Package Encryption	Non-FIPS Compliant Method	N/A (Encryption option disabled)	Saving package with encryption enabled generates an error. Encryption is prevented.
Legacy DTS Package Encryption	Non-FIPS Compliant Method	N/A (User must avoid)	DTS doesn’t check FIPS mode; user responsibility to not use encryption.
TLS/SSL Connections	Relies on OS	Uses OS FIPS-validated crypto	Automatically uses FIPS-validated algorithms if configured for TLS/SSL.
TDE Master Key Encryption	Relies on OS CryptoAPI	Uses OS FIPS-validated crypto	Encryption of the Database Encryption Key (DEK) via Service Master Key uses FIPS crypto.

This table provides a quick reference for administrators to understand how enabling FIPS mode affects key security features within SQL Server 2014.

Verifying FIPS 140-2 Compliance¶

Beyond checking the SQL Server error log for the FIPS compliance message, administrators can take additional steps to confirm that the environment is configured correctly. The most direct method is verifying the Windows security policy setting itself, either through the Local Security Policy editor (secpol.msc) or by checking the corresponding registry value. The policy “System cryptography: Use FIPS-compliant algorithms for encryption, hashing, and signing” corresponds to the registry value Enabled under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy. A value of 1 indicates that the policy is enabled.

While checking the policy and the SQL Server log message are the primary verification steps documented, advanced users could potentially use tools to monitor API calls made by the SQL Server process (sqlservr.exe) to confirm it is using CryptoAPI functions restricted to FIPS-approved algorithms. However, this level of verification is complex and typically unnecessary once the policy is enabled and the SQL Server log confirms detection. The reliable use of the Windows CryptoAPI for FIPS compliance is a fundamental aspect of the Windows operating system’s design when the policy is active.

Importance of FIPS 140-2 Compliance for SQL Server 2014¶

Implementing FIPS 140-2 compliance for SQL Server 2014 is not just a technical configuration step; it is often a critical requirement driven by regulatory mandates and security policies, particularly in government and highly regulated industries. Organizations handling sensitive government data, participating in federal contracts, or subject to regulations like HIPAA (Health Insurance Portability and Accountability Act) or PCI DSS (Payment Card Industry Data Security Standard) may find FIPS compliance is a necessary part of their overall security framework.

By ensuring SQL Server 2014 operates in a FIPS 140-2 compliant mode, organizations demonstrate a commitment to using validated and standardized cryptographic methods for protecting sensitive information. This reduces the risk of data breaches due to cryptographic weaknesses and helps meet external compliance audits and requirements. Although SQL Server 2014 is an older version, maintaining its compliance posture is vital for systems where upgrades are not immediately feasible but regulatory requirements persist.

Limitations of FIPS 140-2 Compliance in SQL Server 2014¶

While configuring SQL Server 2014 for FIPS 140-2 compliance enhances its security posture significantly, it’s important to understand the inherent limitations. Compliance relies entirely on the underlying Windows operating system providing FIPS 140-2 certified cryptographic modules. If there are issues with the OS certification or configuration, SQL Server’s compliance is impacted.

Furthermore, as noted with SSIS and DTS, not all features within SQL Server 2014 were designed with FIPS compliance in mind from the outset, especially legacy components. While the main database engine functionalities and core security features leverage the OS CryptoAPI, certain optional or older features might use non-compliant internal implementations that are either disabled or must be actively avoided by the user when in FIPS mode. Administrators must be aware of these specific limitations to ensure holistic compliance across their entire data platform usage.

Where Can I Learn More About FIPS 140-2?¶

For more in-depth information about the Federal Information Processing Standard Publication 140-2, the authoritative source is the National Institute of Standards and Technology (NIST). The full standard document provides detailed security requirements for cryptographic modules.

The NIST Cryptographic Module Validation Program (CMVP) website is also an invaluable resource for understanding the validation process and accessing the official lists of FIPS 140-2 approved algorithms and certified cryptographic modules.

NIST Publication FIPS 140-2 (PDF): Security Requirements For Cryptographic Modules

Conclusion¶

Implementing FIPS 140-2 compliance in SQL Server 2014 is a critical step for organizations operating in environments requiring adherence to stringent cryptographic standards, particularly those dealing with government data. By configuring the underlying Windows operating system to enforce FIPS-validated algorithms and ensuring SQL Server detects and operates in this mode, administrators can significantly enhance the security posture of their database systems. While certain features may behave differently or be restricted in FIPS mode, the standard SQL Server functionalities leverage the robust, certified cryptographic modules provided by the operating system. Understanding the distinction between compliance and certification, correctly applying the necessary configurations, and being aware of feature-specific behaviors are key to successfully operating SQL Server 2014 in a FIPS 140-2 compliant manner, thereby meeting regulatory requirements and strengthening data protection.

What are your experiences with implementing FIPS compliance for database systems? Share your thoughts and challenges in the comments below!

Computacionvinchi