On September 22, 2026, the U.S. National Institute of Standards and Technology (NIST) moved all Federal Information Processing Standards (FIPS) 140-2 certificates to its Historical List. Those cryptographic modules no longer hold active validation status and should not be included in new U.S. federal procurements. Existing systems may continue using historical modules, subject to the agency’s assessment of their use and risk.
For file transfer administrators supporting U.S. federal agencies or contractors handling sensitive government data, the transition raises practical questions: Can you continue using your existing server? Will its cryptography meet the requirements of a future contract? How do you demonstrate to a federal contracting officer or security reviewer which module protects your transfers?
This guide answers common questions about the FIPS 140-3 transition and explains what Cerberus FTP Server administrators should verify in their deployments. It includes links to NIST guidance and supporting documentation for security reviews. For background on the standards, start with our overview of the differences between FIPS 140-2 and FIPS 140-3.
What changed with FIPS on September 22, 2026?
The Cryptographic Module Validation Program (CMVP) is jointly operated by NIST and the Canadian Centre for Cyber Security. It validates cryptographic modules submitted to the program against FIPS requirements, using test results from independent, accredited laboratories. It does not validate every encryption product on the market.
The transition from FIPS 140-2 to FIPS 140-3 included three key milestones:
| Date | Milestone |
| September 22, 2020 | The CMVP began accepting submissions for FIPS 140-3 validation. |
| April 1, 2022 | The CMVP stopped accepting submissions for new FIPS 140-2 validation certificates. |
| September 22, 2026 | All remaining FIPS 140-2 certificates moved to the Historical List. |
Source: NIST FIPS 140-3 transition schedule
Only FIPS 140-3 module validations now remain on the active list. That makes the distinction between a historical certificate and an active certificate important when reviewing an existing system or selecting a new solution.
Can you still use FIPS 140-2 modules after the FIPS 140-3 transition?
Yes, in existing systems. NIST’s transition guidance explicitly supports the purchase and use of historical FIPS 140-2 modules for existing systems. Historical status does not automatically mean that a server must be shut down or replaced.
However, continued use and eligibility for a new procurement are different questions. NIST’s historical certificate notices state that historical modules should not be included in new federal procurements. Agencies may assess whether continued use is appropriate based on where and how a module is deployed.
For administrators, there are three practical considerations:
- Future bids and new systems: Review the cryptographic requirements in each solicitation. An existing deployment’s acceptance does not establish that the same configuration will satisfy a future contract. If a procurement requires an active validation, a historical FIPS 140-2 certificate will not meet that condition.
- Security reviews: Document the module in use, its certificate status and any agency-approved basis for continued use. Confirm the applicable requirements with the contracting officer or security reviewer.
- Maintenance and patching: Validation does not replace vulnerability management. For federal cloud environments, the FedRAMP cryptographic module policy explains how providers should weigh validation status against the risks of leaving known vulnerabilities unpatched.
Why did NIST transition from FIPS 140-2 to FIPS 140-3?
The transition modernized the cryptographic module standard and aligned it with international requirements. NIST explains that FIPS 140-3 references ISO/IEC 19790 for module security requirements and ISO/IEC 24759 for testing, with supporting NIST publications defining additional requirements.
FIPS 140-3 addresses the secure design, implementation and operation of cryptographic modules, including authentication, software and firmware security, self-tests, sensitive security parameter management and life-cycle assurance.
The move to the Historical List was a scheduled standards transition. It does not, by itself, establish that a particular FIPS 140-2 module is vulnerable. Equally, a validation certificate does not guarantee that an implementation will remain free of vulnerabilities throughout its life. Administrators need to review both validation status and security updates.
What types of data make FIPS-validated cryptography relevant?
FIPS 140 establishes requirements for cryptographic modules rather than assigning a classification to individual files. In the U.S. federal context, it applies to cryptographic systems used to protect sensitive information, including systems operated for an agency under contract.
A particularly relevant category for file transfer administrators is Controlled Unclassified Information (CUI). This is information that requires safeguarding or dissemination controls under applicable law, regulation or government-wide policy, but is not classified.
The National Archives’ CUI Registry identifies categories that may include:
- Controlled technical information, such as qualifying engineering drawings, specifications or technical reports
- Export-controlled information
- Certain privacy, financial and proprietary business information
These categories do not mean every engineering document, financial record or customer file is CUI. Administrators should use the applicable agency guidance, contract requirements and information designations to determine what protection is required.
For example, a defense contractor exchanging controlled technical drawings should determine whether those files are covered defense information and which safeguarding requirements apply to the systems transferring them. A financial institution should separately establish its regulatory or contractual requirements rather than assuming that every financial file falls under a federal FIPS mandate.
FIPS 140 validated or compliant: Which do you need?
Vendors use both terms, but they do not provide the same assurance:
- FIPS compliant: A vendor asserts that its implementation meets the requirements. The claim alone does not establish that the module has completed CMVP validation.
- FIPS validated: A specific cryptographic module has completed the validation process and holds a certificate number that can be checked with NIST.
NIST’s CMVP FAQs explain that using approved algorithms alone is not equivalent to using a validated module. They also distinguish a validated module from a product that embeds it: the surrounding product cannot claim that it is separately validated simply because it includes the module.
For a concrete example, requirement 3.13.11 of NIST SP 800-171 Rev. 2 requires FIPS-validated cryptography when cryptography is used to protect CUI confidentiality.
Where included in a defense contract, DFARS 252.204-7012 establishes safeguarding requirements for covered contractor information systems. The applicable NIST SP 800-171 revision depends on the solicitation and any contracting officer authorization, so confirm the requirements governing your contract.
To verify a module, use the CMVP Validated Modules Search. Check its certificate number, standard, status, module version, sunset date and security policy, including the approved operating conditions.
Which FIPS modules and versions does Cerberus support?
Cerberus FTP Server by Redwood uses embedded validated cryptographic modules. Its support documentation and FIPS 140-3 overview identify the Server modules below. The release notes also document when FIPS 140-3 support was added to Gateway.
| Component | Version | FIPS support |
| Cerberus FTP Server | 11.3.1–12.10.1 | KeyPair FIPS Object Module, certificate #3503, FIPS 140-2, historical |
| Cerberus FTP Server | 12.11.0 through releases before 2026.1 | OpenSSL FIPS Provider, certificate #4282, FIPS 140-2, historical |
| Cerberus FTP Server | 2026.1 and later | OpenSSL FIPS Provider, certificate #4985, FIPS 140-3 |
| Cerberus Gateway | FIPS 140-3 support introduced in 2026.3 | Review the Gateway version and its configuration as part of your deployment assessment |
NIST currently lists certificate #4985 as active, with a sunset date of March 10, 2030. Its validation applies when the module operates in approved mode.
If your deployment includes Gateway, include it in your inventory and upgrade plan. Do not assume that checking the Server version or changing the Server’s FIPS setting establishes Gateway’s configuration. Obtain the applicable Gateway configuration and module evidence from Cerberus documentation or support.
Does the OpenSSL 3.5.7 upgrade change Cerberus’s FIPS validation?
An OpenSSL library upgrade does not, by itself, establish a change to the validated FIPS provider. These are related but distinct components:
- The OpenSSL library provides cryptographic and connection functionality and receives maintenance updates.
- The FIPS provider is the specific cryptographic module covered by the validation certificate.
Cerberus 2026.3 upgraded its embedded OpenSSL library from 3.0.20 to 3.5.7, as documented in the release notes. Cerberus’s current FIPS documentation identifies certificate #4985 for Server versions 2026.1 and later.
OpenSSL’s validation announcement explains that the validated OpenSSL 3.1.2 FIPS provider is compatible with OpenSSL library versions 3.0 through 3.5. The library’s version number and the validated provider’s version number therefore do not have to match.
For a security review, retain the Cerberus build information, the applicable certificate and the module’s security policy. A library version number alone is not sufficient evidence of approved FIPS operation.
How do you turn on FIPS 140-3 mode in Cerberus FTP Server?
Use a current Cerberus release that supports FIPS 140-3. Cerberus FTP Server introduced support in 2026.1, while Gateway support was added in 2026.3.
For Cerberus FTP Server, the documented steps are:
- Open the Cerberus interface or Web Administration.
- In Server Manager, open the Security tab.
- Under General, select Enable FIPS 140-3.
- Restart the Cerberus FTP Server Windows service for the change to take effect.
- Record the installed version, FIPS setting and applicable module certificate in your system documentation.
Cerberus’s FIPS transition guidance states that an existing enabled FIPS 140-2 setting is migrated automatically during the upgrade. Verify the resulting setting and test your connections rather than assuming the upgrade requires manually enabling it again.
For deployments that include Gateway, review its configuration separately using the applicable Gateway guidance or Cerberus support.
What stops working in Cerberus’s FIPS mode?
FIPS mode limits Cerberus to approved cryptographic operations, so some options that work in standard mode aren’t available. These include:
- ChaCha20-Poly1305 ciphers
- Ed25519 and Ed448 key types
- Certain legacy SSH algorithms, including 3DES-CBC, SHA-1-based SSH MACs and the ssh-rsa host key signature algorithm
The last point requires an important distinction: ssh-rsa uses SHA-1 signatures, but an RSA key can also be used with supported RSA-SHA2 signature algorithms. An RSA key is not automatically incompatible simply because ssh-rsa is unavailable.
A connection can fail if the client and Server cannot agree on permitted algorithms or if the client relies on an unsupported authentication key. A client that offers ChaCha20 alongside supported AES options may still connect using AES, so the presence of a disabled option does not necessarily mean the entire client is incompatible.
Before changing production:
- Inventory partner connections, automated jobs and client software.
- Check the configured host keys, authentication keys, ciphers, key exchange methods and MACs.
- Where necessary, use supported RSA keys of at least 2048 bits or supported ECDSA P-curve keys.
- Test representative transfers in staging, including authentication and automated workflows.
See Cerberus’s security settings documentation and FIPS 140-3 transition guidance for the documented restrictions and supported alternatives.
Your Cerberus FIPS 140-3 transition checklist
- Identify the agency, contract or organizational requirements that apply to your transfers.
- Record the installed versions of Cerberus FTP Server and any Cerberus Gateway instances.
- Verify the applicable cryptographic module certificates and security policies.
- Plan upgrades for deployments that need active FIPS 140-3 validation.
- Test clients, authentication keys, ciphers and automated transfers in staging.
- Confirm FIPS mode in Cerberus FTP Server and restart the service if you change the setting.
- Review Gateway’s configuration separately.
- Update your system security documentation with the installed versions, settings and applicable certificate evidence.
- Record certificate #4985’s current March 10, 2030 sunset date and periodically recheck its status.
- Confirm that the resulting configuration meets any relevant procurement or contract requirements.
Move to FIPS 140-3 with confidence
Your customers and federal security reviewers need evidence of how sensitive files are protected. Cerberus FTP Server by Redwood supports FIPS 140-3 validated cryptography for secure file transfers, and Cerberus Gateway now also supports FIPS 140-3.
With the appropriate versions, configuration and documentation, you can demonstrate the cryptographic module used by your deployment and address the transition as part of your broader security requirements.
Start your free 25-day trial or learn more about Cerberus’s FIPS 140-3 support.
Sources and further reading
NIST and U.S. government guidance
- NIST’s FIPS 140-3 transition schedule and existing-system guidance: Explains the transition milestones and continued use of historical modules.
- FIPS 140-3 cryptographic module security requirements: Describes the standard’s scope and security requirements.
- NIST’s cryptographic module validation FAQs: Explains validation, compliance claims and products that embed validated modules.
- NIST’s validated module search: Lets you check module certificates and their status.
- OpenSSL FIPS Provider certificate #4985: Lists the Server module’s validation status, operating conditions and security policy.
- The National Archives’ CUI Registry: Identifies categories of controlled unclassified information.
- NIST SP 800-171 Rev. 2 requirements for protecting CUI in nonfederal systems: Includes the FIPS-validated cryptography requirement discussed in this guide.
- Defense contract safeguarding requirements, DFARS 252.204-7012: Explains covered defense information and applicable contractor security obligations.
- FedRAMP’s cryptographic module selection and use policy: Addresses validation and vulnerability management in federal cloud environments.
Cerberus and OpenSSL resources
- Cerberus’s explanation of FIPS 140-2 and FIPS 140-3: Provides background on the standards.
- Cerberus Server’s cryptographic modules and FIPS configuration: Identifies legacy modules and the Server’s FIPS setting.
- Cerberus’s FIPS 140-3 validation overview: Identifies the embedded validated module used by Server versions 2026.1 and later.
- Cerberus’s FIPS transition and client compatibility guidance: Covers setting migration and algorithm restrictions.
- Cerberus release notes: Documents Server and Gateway FIPS updates and library changes.
- OpenSSL’s FIPS provider validation announcement: Explains certificate #4985 and compatibility with OpenSSL library versions.