Usually, no. CMMC requires that when you use cryptography to protect CUI, that cryptography must be FIPS-validated — but the requirement attaches to the crypto module doing the protecting, not to your firewall specifically. Scope CUI tightly and handle the encryption with FIPS-validated software, and a good consumer or prosumer firewall (which is not FIPS-validated) can still do its real job: segmentation and logging. Most small shops never need a $30k FIPS firewall.
This is the question that sends small contractors down a $30,000 rabbit hole they usually didn't need to enter. Someone reads "FIPS-validated" in a requirements doc, panics, and starts pricing enterprise Fortinet appliances — when the actual requirement could have been satisfied with software they could stand up in a week. Let me untangle it, because the honest version of this answer is worth real money to you.
I'll give you the straight facts: what FIPS validation actually is, the difference between "validated" and the weasel words vendors use, when an assessor genuinely cares, and why the encryption boundary is almost always cheaper to solve with software than with a firewall. Then I'll show you the two tools I actually recommend to small shops for handling the crypto side without the enterprise price tag.
FIPS 140-2, and its successor FIPS 140-3, are U.S. government standards for cryptographic modules — the specific piece of software or hardware that does the encrypting. "Validated" means one exact thing: an accredited testing lab put that module through its paces, and NIST's Cryptographic Module Validation Program (CMVP) issued it a certificate with a number you can look up on a public list.
That last part matters more than anything else in this article. FIPS validation is not a quality vibe or a marketing tier. It's a certificate number on a NIST list. Either a module is on that list or it isn't. When a CMMC assessor is checking whether your encryption meets the bar, that's literally what they're doing — confirming the crypto you rely on to protect CUI traces to a real CMVP certificate.
NIST 800-171 ties this to control SC.L2-3.13.11, which requires FIPS-validated cryptography when cryptography is used to protect the confidentiality of CUI. Read that clause slowly. The requirement only bites where you're using encryption as the protection. That's the hinge the whole decision swings on.
Here's where shops get burned, and where a vendor's sales page will happily let you burn yourself.
I've watched a contractor buy a firewall specifically because the box said "FIPS" — only to find at assessment time that the model they bought was FIPS-capable, the validated firmware was a different build, and they'd never loaded it. The lesson isn't "buy more carefully." It's that chasing a FIPS firewall is a trap even when you do it right, because there's a cheaper path that sidesteps the whole minefield.
An assessor cares about FIPS validation in exactly the situations where encryption is the control you're leaning on to protect CUI. In practice that's three moments:
In each of those, the thing doing the protecting is a cryptographic module, and NIST wants that module FIPS-validated. Notice what's not on the list: segmentation, access control lists, physical protection, logging. When your firewall is doing boundary and segmentation work — walling the CUI machines off from the rest of the office, keeping the logs — it isn't the cryptographic module protecting CUI confidentiality. It's enforcing a boundary. FIPS validation of that firewall isn't what the assessor is checking, because encryption isn't the control it's providing.
This is the distinction that saves shops the most money. Your firewall's job and your encryption's job are two different controls, documented separately. Keep them separate on your diagram and your System Security Plan tells the truth — and you stop paying to "FIPS-validate" a box that was never the crypto boundary to begin with.
Straight, so you never write this wrong in your SSP.
None of this makes the consumer and prosumer boxes "bad." It makes them boundary tools instead of crypto modules. I recommend Firewalla, Protectli/pfSense, and UniFi all day for building a segmented CUI enclave — see the full comparison in Best Firewall for CMMC. Just don't ask them to be your FIPS-validated encryption. That's a different tool.
Here's the move that makes the FIPS-firewall question mostly disappear for a small shop. If you scope CUI into a tight enclave — a handful of machines, one storage location, controlled connections — you shrink the places CUI actually lives. And once CUI lives in a small, defined place, you can wrap encryption around that with FIPS-validated software, instead of trying to FIPS-validate your whole network boundary.
Think it through. If controlled data only ever sits in an encrypted file service and moves through encrypted email, then the FIPS-validated crypto is happening in that software — and your firewall is free to just be a good firewall. You've satisfied SC.L2-3.13.11 through the software layer, and the boundary hardware does the segmentation job it's actually good at. No enterprise firewall required.
That's the whole logic of scoping down, and it's the same lever that cuts total CMMC cost by 40 to 60 percent. I walk through building that enclave step by step in The CUI Enclave Method. Read it alongside this — the two questions are really one question: where does CUI live, and what encrypts it there?
So if the answer for most small shops is "FIPS-validated software, not a FIPS firewall," what software? These are the two I actually put in front of small contractors, because they solve the two places CUI encryption usually has to live: communication and credentials.
PreVeil gives a small shop end-to-end encrypted email and file sharing built specifically for CUI, using FIPS-validated cryptography — which is exactly the practical way to satisfy the encryption-boundary question without an enterprise firewall. Instead of trying to FIPS-validate your whole network, you route controlled communication and controlled files through a service where the validated crypto already lives. For a two-to-twenty-person contractor, this is the most direct honest path to meeting the "protect CUI confidentiality with FIPS-validated encryption" requirement at rest and in transit. It's the tool I'd reach for first.
The other place crypto has to be right is your credentials. Keeper is a FedRAMP High-authorized and FIPS 140-3 validated password and secrets vault, which means the encryption protecting your managed passwords traces to a real certificate — and it hands you the access logs and provisioning an assessor wants to see for the access-control and identification control families. Pair it with a hardware key and you've covered the identity side of the boundary with validated cryptography instead of hope. Genuinely the vault I recommend for a shop that needs its credential store to survive an assessment.
Between the two, you've put FIPS-validated cryptography exactly where the requirement actually lands — around the CUI itself and around the credentials that reach it — without buying an enterprise firewall to do a job it was never the right tool for. That's the honest, cheaper answer, and it's the one an assessor will accept because it maps the validated crypto to the control that requires it.
Understanding that you probably don't need a FIPS firewall saves you money. Writing it up correctly — SSP, the 20 required policies, a POA&M, and the per-control SPRS scorer that maps FIPS-validated crypto to SC.L2-3.13.11 — is what actually passes the assessment. The CMMC Level 2 DIY Compliance Kit is all of it, editable, built for a small shop doing this itself.
Usually not. CMMC requires that when you use cryptography to protect CUI, it must be FIPS-validated — but that requirement attaches to the cryptographic module doing the protecting, not specifically to your firewall. Most small shops scope CUI tightly and satisfy the FIPS-validated encryption requirement with software like PreVeil or a validated password manager, so a consumer or prosumer firewall stays in scope only for segmentation and logging, where FIPS validation is not the point.
FIPS 140-2 and its successor FIPS 140-3 are U.S. government standards for cryptographic modules. A product is FIPS-validated only when its specific crypto module has been tested by an accredited lab and issued a certificate on the NIST CMVP list. "FIPS-capable" or "FIPS-compliant" marketing is not the same as validated — an assessor checks for an actual certificate number, not a claim.
No. Firewalla, UniFi, and pfSense/OPNsense are not FIPS 140-2 or 140-3 validated cryptographic modules. They provide genuine value for network segmentation, boundary protection, and logging, but you should never document them as FIPS-validated. FIPS-validated firewalls come from vendors like Fortinet, SonicWall, and WatchGuard, and they cost accordingly.
An assessor cares when cryptography is the control you're relying on to protect CUI — encrypting CUI at rest, encrypting it in transit, or protecting the confidentiality of a remote session. In those cases NIST 800-171 requires the crypto to be FIPS-validated. Where you're relying on segmentation, access control, or physical protection rather than encryption, FIPS validation of the firewall is not what the assessor is checking.
By scoping CUI into a small enclave and using FIPS-validated software for the encryption itself. Tools like PreVeil provide end-to-end encrypted email and file sharing built for CUI using FIPS-validated cryptography, and a validated credential vault like Keeper covers the identity side. That approach satisfies the FIPS-validated encryption requirement without buying an enterprise FIPS firewall.
November 10, 2026 begins Phase 2, when Level 2 C3PAO third-party certification becomes a required condition of award on applicable DoD contracts. Self-assessment and affirmation requirements are already showing up in solicitations, so the encryption and scoping decisions behind your FIPS question should be settled well before that date.