CMMC-Certified Hardware Does Not Exist: What to Ask For Instead
CMMC certifies organizations, never products. The labels that do exist on a datasheet — CMVP-listed FIPS validation, Common Criteria, TAA country of origin, §889 screening — are checkable facts with issuing bodies behind them.
By Uniqcli Team · · 8 min read
Key takeaways
- CMMC certifies organizations, never products — there is no CMMC-certified switch, drive or firewall, and no issuing body that could make one.
- The product claims that do exist are checkable: CMVP FIPS validation (by certificate number), Common Criteria evaluation, TAA country of origin, and NDAA §889 screening.
- "FIPS validated" means CMVP tested the module and issued a certificate; "FIPS compliant" has no issuing body behind it. NIST 800-171 3.13.11 requires the validated kind.
- All remaining FIPS 140-2 certificates move to CMVP Historical status on September 21, 2026; 140-3 is the successor, so specify it on new purchases.
- Any vendor claiming to cover N of the 110 requirements is guessing — requirements are met by your implementation in your defined scope, not by a device in a box.
On this page
Compliance
CMMC certifies organizations. Datasheets certify something else entirely.
Search for CMMC-compliant hardware and you will get results. You will not get a product that is CMMC certified, because no such product can exist. CMMC is an assessment of an organization's implementation of security requirements, conducted against that organization's system, scope and documentation. A switch has no System Security Plan. A drive has no SPRS score. What a datasheet can legitimately carry is a different set of claims — cryptographic module validation, Common Criteria evaluation, country of origin, covered-equipment screening — each of which is a checkable fact with an issuing body and, usually, a certificate number behind it. This piece is about telling those apart, and about what to put to a vendor before the purchase order goes out. Our NIST 800-171 hardware checklist covers which of the 110 requirements land on equipment; this piece covers which vendor claims can honestly close them.
Why 'CMMC certified' cannot attach to a product
CMMC assesses an organization. Level 1 is 15 requirements from FAR 52.204-21, self-assessed and affirmed in SPRS, protecting Federal Contract Information. Level 2 is 110 requirements mapped one-to-one to NIST SP 800-171 Rev 2 and assessed against 320 objectives, self-assessed or certified by a C3PAO depending on what the solicitation specifies, protecting Controlled Unclassified Information. Level 3 adds 24 enhanced requirements from NIST SP 800-172, is assessed by the government through DIBCAC, and requires a Final Level 2 first. Every one of those is a statement about a company's environment: its boundary, its accounts, its policies, its evidence.
A product cannot hold any of them, and neither can a reseller sell one. What a product can do is make a specific requirement implementable in your environment — a switch that supports 802.1X makes an access-control decision enforceable, an encrypted drive with a CMVP-listed module makes encryption of CUI at rest satisfiable. That is a real and useful contribution, and it is also the whole of the contribution. No product purchase confers certification on its own; what hardware can do is make the controls implementable.
The distinction is not pedantic. The phrase has no meaning under the program — there is no certificate, no issuing body and no list to check a part number against — which is exactly why it survives on datasheets. When you see it, treat it as information about the vendor rather than information about the product.
Four product-level claims that exist — and how to check each
Each of these is falsifiable. That is what separates them from compliance adjectives: there is a list somewhere with a number on it, and either your part number is on it or it is not.
FIPS 140-2 / 140-3 validation
Issued through the Cryptographic Module Validation Program (CMVP). The proof is a certificate number on the CMVP validated modules list naming a specific module, version and tested operating environment. Ask for the number, then look it up. 'FIPS compliant' is not a substitute for 'FIPS validated.'
Common Criteria evaluation
An evaluation against a named Protection Profile, published on a certified-product list. Confirm that the exact model and firmware revision you are buying is the evaluated one, and against which Protection Profile — an evaluation of a sibling model is not an evaluation of yours.
TAA country of origin
A trade-agreements determination about where an item was substantially transformed. It is made per part number, it changes when a manufacturer moves a line, and it is a procurement-eligibility fact rather than a security one. It has to be confirmed against the specific part at quote time.
NDAA §889 covered-equipment screening
A check that the item — and the covered telecommunications or video surveillance components inside it — does not originate with a named covered entity, its subsidiaries or affiliates. The screen runs against the bill of materials, not the brand on the bezel.
FIPS is the label most often misread
NIST SP 800-171 3.13.11 requires FIPS-validated cryptography when cryptography is used to protect CUI. That word — validated — carries the whole requirement. A module is validated when CMVP has tested it and issued a certificate. A product that implements AES-256 correctly but has never been through CMVP is not validated, no matter how sound the implementation is, and 'FIPS compliant,' 'FIPS capable' and 'uses FIPS-approved algorithms' are all different claims from the one the control asks for.
Two structural details trip buyers up. First, validation attaches to a cryptographic module, not to a whole product: a laptop is not validated, the drive's or the operating system's crypto module is, within a tested operating environment. Second, plenty of validated products ship with the module disabled by default and require an explicit FIPS mode to be turned on — which means the certificate is necessary but not sufficient, and your assessment evidence needs a configuration record, not just a datasheet.
There is also a date on the calendar. All remaining FIPS 140-2 certificates move to CMVP Historical status on September 21, 2026; FIPS 140-3 is the successor standard. Historical status does not retroactively unplug hardware you already own, but it does change what a buyer should be specifying today. On a new purchase, ask for a 140-3 validated module. Where a 140-2 module is the only option for a category, understand that you are buying into a certificate with a known transition behind it, and plan the refresh accordingly.
Requirement family, then what you actually buy
Named by requirement number, because that is the level at which a hardware claim can be honest. A product supports a named requirement in your environment; it never covers a count of them.
3.1.x — Access control
Managed switches that can enforce 802.1X port authentication and VLAN segmentation; wireless controllers with per-user authentication and SSID isolation from guest traffic. The requirement is a capability, never a brand.
3.5.3 — Multifactor authentication
Replay-resistant authenticators for network and privileged access: PIV/CAC smart cards with readers, or FIDO2/WebAuthn security keys. SMS one-time codes are the common failure mode here, and they are worth their own piece.
3.13.1 — Boundary protection
Firewalls or security appliances positioned at every external interface, monitoring and logging at the boundary rather than only inside it. Segmentation on the switching is what makes the boundary mean anything.
3.13.11 — FIPS-validated cryptography
Modules with a current CMVP certificate, running in FIPS mode, everywhere cryptography protects CUI — in transit and at rest. The certificate number is the deliverable, not the marketing line.
3.13.16 — CUI at rest
Hardware-encrypted storage with a CMVP-listed module: encrypted portable drives, self-encrypting drives, and the key-management and recovery process around them. This is one of the deeper in-stock categories we carry.
3.8.x — Media protection
Control and sanitization of media carrying CUI: drives that support a genuine cryptographic erase rather than a soft delete, and a documented process that is actually run before reuse or disposal.
Where vendor claims go wrong
The overclaims fall into a few recognizable shapes. 'CMMC certified' or 'CMMC compliant' on a product is the clearest — there is no certificate behind it to ask for, and no issuing body that could produce one. 'Meets N of the 110 requirements' is the second: requirements are met by an organization's implementation within a defined scope, and no vendor can know how many of yours a product closes without reading your SSP.
'FIPS compliant' instead of 'FIPS validated' is the third, and the most consequential, because it is the one an assessor will catch. Ask for the CMVP certificate number. If the answer is a paragraph rather than a number, you have your answer.
The fourth is quieter: a claim that is true of a product family but not of the SKU on your quote — an evaluation against an older firmware revision, a validation covering a different capacity or interface, a country-of-origin determination made before the manufacturer moved a line. These are usually not lies. They are stale facts, and they need re-confirming per part number at quote time.
On our side, TAA and §889 screening is performed before the quote goes out, and where a part cannot be confirmed we say so plainly rather than guessing. What no supplier can do — us included — is sell you a level. We quote against the SSP you already have, not a generic bundle, and what ships is the capability behind the control — equipment, licensing and the work that puts them in service — never a Uniqcli certification.
Eight questions that separate a credential from an adjective
Put these to any vendor — including us — on anything sold into a CUI environment. Every one of them has a factual answer, which is the point.
- What is the CMVP certificate number for the cryptographic module in this exact part number, and which operating environment does the certificate cover?
- Is that module FIPS 140-3 validated, or a 140-2 certificate moving to CMVP Historical status on September 21, 2026?
- Does FIPS mode ship enabled, or does it require configuration — and what evidence can I capture to show an assessor it is on?
- If Common Criteria is claimed: against which Protection Profile, at what assurance level, and for which firmware revision?
- Is the evaluated or validated model the same SKU I am ordering, or a sibling in the same product family?
- What is the country of origin for this part number today, and when was that determination last confirmed?
- Has this item been screened against NDAA §889 covered entities at the component level, not just by brand name?
- Which specific 800-171 requirement does this product help implement, named by number — and what does my environment still have to do around it?
Frequently asked
Is there such a thing as CMMC-certified hardware?
No. CMMC certifies organizations against requirements implemented in a defined scope — Level 1 is 15 requirements from FAR 52.204-21, Level 2 is 110 requirements mapped to NIST SP 800-171 Rev 2 across 320 objectives, and Level 3 adds 24 enhanced requirements from NIST SP 800-172. None of those can attach to a product, and there is no issuing body a product-level CMMC claim could point to. Products carry different, real credentials: CMVP FIPS validation, Common Criteria evaluation, TAA country of origin, and NDAA §889 screening.
What is the difference between FIPS compliant and FIPS validated?
'Validated' means the Cryptographic Module Validation Program tested the module and issued a certificate you can look up by number. 'Compliant' is a marketing word with no issuing body behind it, and usually means the product implements FIPS-approved algorithms without having been through validation. NIST SP 800-171 3.13.11 requires FIPS-validated cryptography where cryptography protects CUI, so the distinction is the one that decides the finding.
Do I have to replace FIPS 140-2 gear before September 21, 2026?
Not automatically. On that date all remaining FIPS 140-2 certificates move to CMVP Historical status, with FIPS 140-3 as the successor standard. What changes immediately is what you should be specifying on new purchases — ask for 140-3 validated modules — and how you sequence refreshes for modules whose certificates are moving. Whether a Historical certificate remains acceptable for a given system is a determination for your security program and your assessor, not for a supplier.
Can a vendor tell me how many of the 110 requirements their product satisfies?
Not honestly. Requirements are met by your implementation within your defined scope, documented in your SSP and verified against evidence. A product can make a named requirement implementable — a CMVP-validated encrypted drive supports 3.13.16, a managed switch supports segmentation under 3.13.1 — but a coverage count is a function of your environment, not the datasheet. Ask which specific requirement a product touches, by number, and treat aggregate coverage claims as a red flag.
Keep reading
Related on compliance-driven sourcing
Send the part numbers. We'll come back with what each module actually holds.
Quotes get TAA and §889 screening performed before they go out — on the publisher of a software line as much as on the maker of a device — and we confirm the CMVP certificate on request where the module is the point. The capability behind the control, never a Uniqcli certification.