The Rust Cross-Platform FIPS Mirage: rustls, Linkers, and the Mandatory DLL

I recently set out to do something that sounded entirely reasonable: build a fully statically linked, FIPS-compliant Rust binary using rustls that works on both Linux and Windows. The goal was simple on paper. Drop a single, self-contained executable onto a target machine, satisfy the compliance auditors, and move on.

As it turns out, depending on your target OS, this is structurally impossible. Here is what I learned after digging into cryptographic provider architectures.

Windows Goes Out the Window

Let’s start with the hard constraint: fully static, FIPS-compliant binaries are impossible* on Windows.

The blocker isn’t in rustls or Rust itself; it's a fundamental limitation of how FIPS 140 module design works. FIPS requires a cryptographic module to compute an HMAC of its own code at initialization and compare it against a known-good value to prove it hasn't been tampered with.

On Linux (ELF), libraries like AWS-LC and BoringSSL achieve static FIPS builds through an arcane process. They compile the C sources into a single unit using position-independent code (-fPIC), then run it through a specialized "delocator" script to merge assembly and eliminate relocations. This script computes the hash and injects it back into the binary. Details for nerds are well documented here.

That delocator toolchain is entirely Linux/ELF-specific. There is no equivalent for Windows PE/COFF formats. So, on Windows, FIPS mode inherently forces a shared library boundary (the .dll) to perform this integrity check.

The rustls Backends

Since version 0.22, rustls supports pluggable providers, which gives us a path to FIPS compliance. Let’s talk about it.

AWS-LC

AWS-LC inherits BoringSSL’s self-contained integrity mechanism. Because the HMAC check is computed and injected into the binary during the build process, you can build a functionally compliant module from source.

On Linux, you can statically link this. On Windows, as established, it forces a FIPS_SHARED mode. You must ship aws_lc_fips_*_crypto.dll alongside your executable. Because this DLL relies on dynamic C-runtime libraries, you also inherit a dependency on vcruntime140.dll . You can theoretically link vcruntime statically, but it’s buggy¹ — the bug is present in the latest FIPS compliant iteration, 2.0, as well as the version currently in NIST review, 3.0 — the future compliant version².

SymCrypt

Sike — SymCrypt is not FIPS certified. Despite the README acting like it is and despite being the de-facto cryptographic backend for Cryptographic Primitives Libraries (bcryptprimitives.dll and cng.sys) which have gone through multiple FIPS 140 validations³, SymCrypt itself has only been submitted to the ~18 month long process of NIST validation recently (April 23, 2026) — it’s nowhere near to be certified at the time of writing.

Once SymCrypt does get FIPS certified — you are anyway going to need to ship the symcrypt.dll alongside your Rust binary on Windows — we are not circumventing the core issue of the missing deallocator toolchain. But at least you are not also shipping vcruntime140.dll .

The Bottom Line

If you need FIPS compliance in Rust, abandon the dream of a universal static binary. On Linux, you can pull it off with aws-lc-rs. On Windows, you are shipping a .dll

Oh, you are still here?

*The secret option: rustls-cng-crypto

If the idea of shipping 12 DLLs in a trench-coat on Windows makes you throw up, there is a secret option.

[rustls-cng-crypto](https://github.com/tofay/rustls-cng-crypto) is a third-party provider that does for Windows exactly what the OpenSSL backend does for Linux. It intercepts all of rustls's cryptographic math and delegates it directly to Windows' native Cryptography API: Next Generation (CNG) that’s already FIPS certified.

The mechanism here is wonderfully pragmatic. When a Windows machine is configured in FIPS mode, its underlying system crypto primitives (bcrypt.dll and ncrypt.dll) operate strictly inside Microsoft's validated FIPS boundary. By passing the cryptographic heavy lifting down to CNG via this crate (which even has a dedicated fips feature flag), you are effectively outsourcing your compliance headache to the OS. And because Windows already owns and maintains those system DLLs natively, you don't have to bundle a single piece of extra runtime baggage with your executable.

The caveat? You are relying on a relatively niche, community-maintained bridge crate (if a single man can be called a community). It doesn’t have the enterprise support of Microsoft, AWS or Google behind it and it shows. I’d refrain from using it for any enterprise purposes to avoid your InfoSec department from tearing their hair out.

But hey, maybe your company can be the enterprise that can give this library the enterprise support it needs.

Footnotes

• [1] kind author was unable to workaround this bug
• [2] as of May 6, 2026
• [3] https://techcommunity.microsoft.com/blog/microsoft-security-blog/microsofts-quantum-resistant-cryptography-is-here/4238780