What CMMC Level 2 Actually Requires of Your Hardware

Most CMMC guidance is written for the people who write policies. This guide is written for the people who buy, build and maintain the systems those policies apply to.

CMMC Level 2 requires a contractor to implement all 110 security requirements of NIST SP 800-171 for every system that stores, processes or transmits Controlled Unclassified Information (CUI). A lot of those requirements are procedural — training, incident response plans, access reviews. But a meaningful fraction come down to what your hardware can and cannot do, and to decisions that are made at purchase time. Get those decisions wrong and you either fail the assessment or spend the next year compensating for them.

Below is a walk-through of the requirement families that land on hardware, in the order they tend to matter.

1. Scoping: which machines are in the assessment at all

Before any control applies, you have to decide which assets are in scope. The DoD’s Level 2 scoping guidance sorts assets into five categories, and the category drives what an assessor will look at:

• CUI Assets — anything that stores, processes or transmits CUI. Fully assessed against all 110 requirements.
• Security Protective Assets — firewalls, SIEMs, authentication servers. Assessed against the requirements relevant to what they protect.
• Contractor Risk Managed Assets — systems that could handle CUI but are prevented from doing so by policy. Documented, not assessed in detail.
• Specialized Assets — government-furnished equipment, IoT/OT devices, restricted information systems, test equipment. Documented in the System Security Plan and included in the inventory, but not assessed against the other requirements.
• Out-of-scope assets — physically or logically separated; not assessed.

For a hardware buyer, two points follow. First, a server that never touches CUI is a far cheaper server to own, so the network design that keeps it out of scope is worth more than any feature on the spec sheet. Second, many deployed systems — sensor processors, mission computers, test rigs — may fall under Specialized Assets. That does not mean they can be ignored, but it does mean the paperwork requirement (inventory, SSP entry, risk-based handling) is different from the full 110-control treatment. Knowing which category a system belongs to before it is purchased avoids re-architecting later.

2. Configuration Management: baselines and inventory (CM.L2-3.4.1 – 3.4.9)

Requirement 3.4.1 asks for baseline configurations and inventories of organizational systems — hardware, software, firmware and documentation — throughout the system lifecycle. In practice an assessor wants to see that you know exactly what hardware you own, what firmware and BIOS versions it runs, and that it was set up from a controlled baseline rather than by hand.

This is where working with a systems integrator rather than a box shipper starts to pay. When a system arrives already imaged to your golden baseline, with BIOS settings applied, unnecessary ports and services disabled (3.4.6, “least functionality”) and the exact configuration recorded, the baseline exists on day one. NCS delivers all of these as part of its integration process: BIOS/UEFI configuration to your specification, imaging to your baseline, asset tagging, as-built configuration records, and serial and firmware manifests.

3. Identification & Authentication: hardware roots of trust (IA.L2-3.5.x)

Multifactor authentication (3.5.3) is usually solved in software and directory services, but it depends on hardware in two places: a Trusted Platform Module (TPM 2.0) to anchor device identity and disk-encryption keys, and smart-card / CAC readers where DoD PKI is in use. If a workstation or server ships without a TPM — still common on some industrial and rugged boards — the encryption and device-identity requirements become much harder to satisfy. Discrete TPM 2.0 is standard across the NCS rugged server line.

4. Media Protection: encryption, marking and sanitization (MP.L2-3.8.1 – 3.8.9)

This is the family that hardware buyers most often underestimate.

• 3.8.1 / 3.8.2 — protect and limit access to media containing CUI. Removable drives, backup tapes and portable storage all count.
• 3.8.3 — sanitize or destroy media before disposal or reuse. Every drive that ever held CUI has to be sanitized to NIST SP 800-88 standards (or destroyed) before it leaves your control. That includes RMA returns, lease returns and retired systems. If a supplier’s warranty process requires the drive to be sent back, you need either a keep-your-drive arrangement or a sanitization step first.
• 3.8.6 — cryptographic protection of CUI on digital media during transport, unless otherwise physically protected. Self-encrypting drives and full-disk encryption on removable storage are the usual answer.
• 3.8.7 / 3.8.8 — control and restrict use of removable media, and prohibit portable storage with no identifiable owner.

Purchasing implications: prefer removable drive canisters on systems that will be deployed or serviced in the field (the drive stays with the program even when the chassis goes for repair); specify self-encrypting or FIPS-validated drives where CUI will live at rest; and agree a sanitization or drive-retention process with the supplier before the first system ships. NCS offers all of these: removable drive options and self-encrypting or FIPS 140-validated drives across the rugged mission systems line, drive retention by the customer on warranty return (keep-your-drive), and NIST SP 800-88 sanitization or a certificate of destruction as a lifecycle service, performed by a specialist third party.

5. System & Communications Protection: FIPS-validated cryptography (SC.L2-3.13.11)

Requirement 3.13.11 is short and unforgiving: “Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.” It is one of the most commonly failed requirements in Level 2 assessments, because “uses AES-256” is not the same thing as “runs a FIPS 140-validated cryptographic module in FIPS mode.” The validation attaches to a specific module and version, listed on NIST’s CMVP site.

For hardware this means: if you rely on a drive’s built-in encryption, that drive’s cryptographic module needs a FIPS 140-2 or 140-3 validation; if you rely on the operating system’s disk encryption, the OS must be running in its validated FIPS mode; and network gear that terminates encrypted CUI sessions needs the same. Ask suppliers for the CMVP certificate number, not a brochure statement.

6. Physical Protection (PE.L2-3.10.1 – 3.10.6)

Limit physical access to systems and equipment (3.10.1), escort visitors (3.10.3), keep physical-access logs (3.10.4), control physical access devices such as keys and badges (3.10.5). For data-center systems this is a facilities question. For hardware that leaves the building it becomes a hardware question — which is the subject of the next page, Protecting CUI on rugged and tactical systems.

7. Audit & Accountability, System Integrity (AU, SI)

Hardware’s role here is mostly capacity and capability: enough storage and performance to retain audit logs for the required period (3.3.1), out-of-band management that can be logged and restricted, and firmware that supports measured/secure boot so that system integrity (3.14.x) can be verified rather than assumed.

This is also where NCS offers something few integrators can: Power Fingerprinting (PFP), an embedded cyber resilience option that works below the operating system, on the bare metal. PFP monitors a device’s power consumption from outside the device (out of band) and uses machine learning to learn what normal operation looks like for that specific chip, board or system. Any deviation from that fingerprint is flagged. Because it watches physical behaviour rather than software, it can detect tampering, counterfeit parts, malware and supply-chain attacks that signature-based tools have never seen, and it does so continuously, without proprietary tools on the protected device, from individual chips up to complete systems. For a CMMC program that means system integrity (3.14.x) and supply-chain risk management can be verified on an ongoing basis, in support of DFARS and related requirements, rather than assumed at delivery.

What to put in the RFQ

If you take one thing from this guide: The most cost-effective time to address CMMC hardware requirements is during the initial procurement phase. A short checklist for any system that will be a CUI Asset:

1. TPM 2.0 present and enabled.
2. Drives: self-encrypting or FIPS 140-validated; removable canisters if the system will be deployed or field-serviced.
3. Firmware supports secure/measured boot; BIOS configurable to disable unused ports and boot devices.
4. Supplier delivers an as-built configuration record (hardware, firmware, BIOS settings, serials).
5. Supplier’s RMA/warranty process supports keep-your-drive or sanitization before return.
6. Supplier can document its own supply-chain and security posture (see the companion page What to require from your hardware supplier).

NCS builds and integrates servers, workstations and storage to these requirements every day, and holds its own CMMC Level 2 C3PAO certification. If you are working through a scoping or procurement question, contact our team.

---

More in this series: Protecting CUI on rugged and tactical systems · What to require from your hardware supplier · NCS and CMMC Level 2