FIPS Mode: What It Is, Why It Matters, and How to Enable It

Most IT administrators encounter Federal Information Processing Standard (FIPS) compliance as a line item in a government contract or an audit finding. Knowing what FIPS mode actually does, and what it does not do, prevents gaps and unnecessary disruption when you flip that switch.

This article explains the FIPS 140 standard, what FIPS mode means in practice, the four security levels, and how to enable FIPS mode on Windows. It also covers the compatibility considerations that catch organizations off guard.

What Is FIPS Mode?

FIPS mode is a configuration state in which a system restricts itself to cryptographic algorithms that have been validated under FIPS 140, a federal security standard.

When FIPS mode is enabled, two things happen:

1. The system’s cryptographic libraries run self-tests before performing any operation.
2. They block any algorithm not on the NIST-approved list.

Non-approved algorithms like RC4 and MD5 stop working regardless of what an application requests.

FIPS 140 is one of the Federal Information Processing Standards (FIPS), a series developed by the National Institute of Standards and Technology (NIST). It sets the minimum security requirements for cryptographic modules used in federal computer systems.

One distinction matters before going further: FIPS mode is not the same as FIPS compliance.

A FIPS-validated module has passed testing and certification by an accredited laboratory under the Cryptographic Module Validation Program (CMVP), run jointly by NIST and the Canadian Centre for Cyber Security (CCCS).

Running in FIPS mode means configuring your system to use those validated modules correctly — it’s the operational step, not the certification itself.

FIPS 140-2 vs. FIPS 140-3: Understanding the Standards

FIPS 140 has gone through two major versions, and knowing which one applies to your environment matters for both contracts and deployments.

FIPS 140-2, “Security Requirements for Cryptographic Modules,” was published on May 25, 2001. It covers eleven areas of cryptographic module design, including:

• Specification
• Ports and interfaces
• Roles and authentication
• Physical security
• Key management
• Self-tests

NIST approved FIPS 140-3 on March 22, 2019, and it became effective September 22, 2019. It supersedes FIPS 140-2 and, rather than defining all requirements directly, aligns with the ISO/IEC 19790:2012 and ISO/IEC 24759:2017 international standards. Testing against FIPS 140-2 ended on September 22, 2021.

FIPS 140-3 also tightened the technical requirements in a few key ways:

• Removal of the “Allowed” algorithm tier: FIPS 140-2 permitted certain algorithms under an “Allowed” category; 140-3 recognizes only NIST-Approved algorithms, forcing replacement of legacy options like Triple-DES before a module can validate.
• Side-channel testing at every level: Resistance to attacks like power and timing analysis was tested only at Levels 3 and 4 under 140-2. FIPS 140-3 requires it across all four levels.

Many organizations still reference FIPS 140-2 in contracts and compliance frameworks because validated module certificates under that version remain on the CMVP active list. For new deployments, FIPS 140-3 is the current standard.

The Four Security Levels

Both versions of FIPS 140 define four increasing levels of security for cryptographic modules:

• Level 1: Requires production-grade equipment and externally tested algorithms. No physical security mechanisms beyond the components themselves are required. Software cryptographic libraries running on general-purpose operating systems typically qualify at this level.
• Level 2: Adds tamper-evidence requirements, such as coatings or seals, and role-based authentication. Software must run on an operating system meeting Common Criteria at Evaluation Assurance Level 2 (EAL2) or higher.
• Level 3: Requires physical tamper-resistance (active mechanisms that zeroize sensitive parameters when attacked) and identity-based authentication, adding to the tamper-evidence requirements of Level 2.
• Level 4: The highest level, intended for use cases requiring the strongest physical protection. Modules at this level must resist sophisticated attacks including environmental attacks (voltage, temperature extremes) that could compromise security.

Most enterprise IT environments work with Level 1 and Level 2 modules. Levels 3 and 4 are typically used in hardware security modules (HSMs) and specialized government systems.

Who Must Enable FIPS Mode?

The following are required to use FIPS-validated cryptography under the Federal Information Security Modernization Act (FISMA):

• Federal agencies
• State agencies administering federal programs — unemployment insurance, student loans, Medicare, and Medicaid
• Private contractors holding or processing federal government data

FIPS compliance is also a prerequisite for FedRAMP authorization. The Federal Risk and Authorization Management Program (FedRAMP) relies on the NIST SP 800-53 controls, including SC-13, which mandates FIPS-validated or NSA-approved cryptography.

Outside of those compliance obligations, FIPS mode is commonly adopted in healthcare organizations handling protected health information, financial institutions subject to regulatory oversight, and any organization whose security policy calls for a cryptographic assurance baseline.

FIPS standards do not apply to national security systems as defined under FISMA. Those systems use NSA-approved algorithms and separate validation programs.

How to Enable FIPS Mode on Windows

Windows has supported FIPS mode for many Windows generations and maintains validated cryptographic modules for Windows 10, Windows 11, and Windows Server releases.

When FIPS mode is active, the Cryptographic Primitives Library (bcryptprimitives.dll) and the Kernel Mode Cryptographic Primitives Library (CNG.sys) run self-tests and enforce approved-algorithm restrictions.

Two methods are available for enabling FIPS mode: Group Policy and the registry editor.

Method 1: Group Policy (Recommended for Domain Environments)

Group Policy is the preferred approach for domain-joined systems because it can be deployed centrally and enforced through existing policy infrastructure.

1. Open the Group Policy Management Console by running gpedit.msc.
2. Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.
3. Locate the policy named “System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing.”
4. Set the policy to Enabled.
5. Restart the system for the change to take effect.

The Group Policy Editor is available on Windows Professional, Enterprise, and Education editions. Home editions do not include it.

Method 2: Registry Editor (Home Editions and Scripted Deployments)

For Windows Home editions or automated deployments, the registry path achieves the same result.

1. Open Registry Editor by running regedit.exe.
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy.
3. Set the Enabled DWORD value to 1 (enabled) or 0 (disabled).
4. Restart the system.

To verify that FIPS mode is active without rebooting, run the following PowerShell command:

[System.Security.Cryptography.CryptoConfig]::AllowOnlyFipsAlgorithms.

A return value of True confirms FIPS mode is enabled.

Walk through the platform on your own terms.

Explore how SecureW2 certificate-based authentication fits a FIPS-aligned network at your own pace — with a self-guided product tour, no sales call required.

Take a Free Product Tour →

FIPS Mode and Application Compatibility

Enabling FIPS mode is a system-wide restriction. Any application that calls a cryptographic function not on the FIPS-approved list will either fail or produce an error. This catches organizations off guard more than almost any other aspect of FIPS deployments.

Applications that commonly surface compatibility issues include:

• Legacy VPN clients
• Older versions of remote desktop tools
• Any software that still uses MD5 or SHA-1 for integrity checks

Consumer applications may not have been developed with FIPS compliance in mind and may explicitly prompt you to disable FIPS mode.

Always test FIPS mode in a staging environment before deploying to production. Run the full application stack against a FIPS-enabled system and resolve any failures before rolling out broadly.

If you are enabling FIPS mode to meet a compliance requirement, coordinate with your application vendors to confirm that each product uses FIPS-validated cryptographic modules in a compliant manner.

For 802.1X network authentication, FIPS mode requires using cipher suites and EAP methods that are FIPS-approved. EAP-TLS with AES encryption is the strongest available option and is fully compatible with FIPS mode requirements. PEAP-MSCHAPv2, by contrast, relies on MS-CHAPv2 authentication which is not considered FIPS-approved, making EAP-TLS the correct path for FIPS-compliant wireless deployments.

Benefits and Limitations of FIPS Mode

Understanding both sides helps IT teams make informed decisions about whether and where to apply FIPS mode.

Benefits

• Validated algorithm assurance: FIPS mode enforces the use of cryptographic algorithms that have been independently tested and certified by an accredited laboratory, removing the risk of deploying weak or deprecated encryption methods.
• Compliance baseline: For organizations operating under FISMA, FedRAMP, or government contract requirements, enabling FIPS mode is a concrete, auditable step toward satisfying cryptographic control requirements.
• Reduced attack surface: Blocking non-approved algorithms eliminates legacy cryptographic paths that attackers sometimes exploit when they can negotiate weaker cipher suites.

Limitations

• Application compatibility: Applications that depend on non-FIPS-approved libraries may break or behave unexpectedly after FIPS mode is enabled.
• Not a complete security solution: FIPS mode validates cryptographic modules, not the security of the entire system. Authentication weaknesses, misconfigured access controls, and unpatched software are outside its scope.
• Performance overhead: FIPS-mandated self-tests and the restriction to certain algorithm parameters can add minor overhead to cryptographic operations, though this is rarely noticeable on modern hardware.
• Restricted algorithm set: Some modern cryptographic research has produced algorithms not yet on the FIPS-approved list. Organizations running in FIPS mode cannot use those algorithms until they receive formal validation.

FIPS Mode, PKI, and Certificate-Based Network Authentication

Network access environments that must meet federal cryptographic standards benefit from combining FIPS mode with certificate-based authentication. Digital certificates issued by a FIPS-validated certificate authority (CA) and validated through a FIPS-compliant RADIUS server create an end-to-end cryptographic chain that satisfies both the letter and intent of FIPS 140 requirements.

Certificate-based authentication using EAP-TLS eliminates reliance on passwords. Every authentication event produces a cryptographically-signed assertion that can be audited and traced to a specific device and user identity.

Certificate-based EAP-TLS removes passwords from the authentication exchange entirely. Passwords aren’t cryptographic artifacts and carry no FIPS-relevant assurance — a certificate does, tying every authentication to a specific device and user.

This approach aligns with the continuous trust access model: network access is tied to a hardware-bound certificate, not a reusable credential that could be phished or stolen.

For organizations managing certificate lifecycles at scale, automated issuance and renewal through protocols such as the Simple Certificate Enrollment Protocol (SCEP) or the Automated Certificate Management Environment (ACME) protocol reduces the operational burden while keeping the cryptographic stack FIPS-aligned.

How JoinNow Dynamic PKI Supports FIPS-Compliant Environments

For organizations that need certificate-based authentication in environments where FIPS compliance is a requirement, JoinNow Dynamic PKI provides a managed public key infrastructure (PKI) built on strong, modern cryptographic standards.

Combined with JoinNow Cloud RADIUS, it delivers:

• Full certificate lifecycle management: Issuance, renewal, and revocation of X.509 certificates without on-premises CA infrastructure
• FIPS-aligned network authentication: Certificate validation using FIPS-aligned cipher suites, supporting EAP-TLS for wired and wireless 802.1X
• Real-time identity enforcement: Access policies driven by live signals from Entra ID, Okta, and other identity providers, so only devices with valid certificates reach sensitive segments

If your organization is working toward FISMA compliance, FedRAMP authorization, or simply needs to close the gap between your current authentication stack and a FIPS-aligned baseline, schedule a demo to see how the JoinNow Platform simplifies certificate deployment and network authentication without adding infrastructure complexity.

---

Frequently Asked Questions

What does FIPS mode do?

FIPS mode configures a system’s cryptographic subsystem to use only algorithms and modules that have been validated under the FIPS 140 standard. When enabled on Windows, the Cryptographic Primitives Library and the Kernel Mode Cryptographic Primitives Library run self-tests before each cryptographic operation and reject requests that use non-approved algorithms. It does not validate the security of the overall system or application, only the cryptographic layer.

Is FIPS mode required for all organizations?

FIPS mode is a regulatory requirement for U.S. federal agencies, state agencies administering federal programs, and private contractors handling federal government data under FISMA. It is also required for FedRAMP-authorized cloud services. Organizations outside those categories are not legally required to use FIPS mode, though regulated industries such as healthcare and finance may find FIPS-validated cryptography beneficial for meeting their own compliance frameworks.

Does enabling FIPS mode make Windows more secure?

FIPS mode restricts Windows to a set of independently validated cryptographic algorithms, which reduces the risk of using deprecated or weak encryption. However, it does not address authentication controls, application vulnerabilities, or configuration errors outside the cryptographic layer. Enabling FIPS mode should be one component of a broader security program, not a substitute for it.

Can I disable FIPS mode after enabling it?

On Windows, disabling FIPS mode is technically possible by reversing the Group Policy or registry change and rebooting. However, some systems and applications may reach an inconsistent state if FIPS mode is toggled after data has been written or keys have been generated under FIPS constraints. On Linux systems that use a tool such as fips-mode-setup, reverting FIPS mode without a full reinstallation is generally not recommended and may leave the system in an unsupported configuration.

Does FIPS mode work on Linux and macOS, or only Windows?

FIPS mode isn't Windows-specific. Most enterprise Linux distributions offer a FIPS mode: Red Hat uses the fips-mode-setup tool, while Ubuntu enables it through Ubuntu Pro (the pro enable fips command) along with the fips=1 boot parameter. macOS includes FIPS-validated cryptographic modules that operate in an approved mode as part of the operating system's core cryptography. The specifics differ by platform, but the underlying principle — restricting the system to FIPS 140-validated algorithms — is the same everywhere.

Will enabling FIPS mode break my applications?

It can. FIPS mode is a system-wide restriction, so any application that calls a non-approved cryptographic function will fail or error out. The usual culprits are legacy VPN clients, older remote desktop tools, and software still using MD5 or SHA-1. This is why testing in a staging environment before production rollout isn't optional; it's the step that catches these failures before your users do.

Is FIPS mode the same as being FedRAMP compliant?

No. FIPS-validated cryptography is one requirement within FedRAMP, not the whole of it. FedRAMP authorization rests on the full set of NIST SP 800-53 controls, of which cryptographic protection (control SC-13) is a single item. Enabling FIPS mode helps satisfy that specific control, but FedRAMP compliance also requires access control, incident response, continuous monitoring, and dozens of other controls.