Assessor Response: 

When it comes to CMMC, the Department of Defense (DoD) and CMMC Accreditation Body recognize that not every system or device within an organization — especially research institutions or labs — can be fully hardened or configured to meet every technical requirement.

The key is proper classification, risk management, and documentation.

Certain organizational systems qualify as Specialized Assets under the CMMC Level 2 Scoping Guidance. These are devices that, due to design, function, or vendor restrictions, cannot be fully configured to meet all CMMC or NIST SP 800-171 security requirements. Examples include laboratory instruments, manufacturing equipment, test benches, or other operational technology (OT) systems that are essential to business operations but not traditional IT assets.

Where able, contractors should apply compensating and risk-based controls to protect these assets. Regardless, in these cases, the contractors should perform the following:

• Document in the asset inventory

• Document in the network and data flow diagrams

• Document asset treatment in the SSP

  • Show these assets are managed using the contractor's risk-based security policies, procedures, and practices

  • Document in the network diagram of the CMMC assessment scope.

• Risk or exception register

  • Record deviations from standard controls.

  • Include risk rating, mitigation measures, approval, and review cadence.

  • Reference specific CMMC controls (e.g., AC.L2-3.1.20 for remote access restrictions).

• Compensating Control Worksheet (CCW)

  • Describe how alternate or procedural controls meet the intent of the requirement.

  • Tie the rationale to risk reduction, not convenience.

While these assets might not meet every control directly, best practice is to apply compensating or alternative protections, including but not limited to:

• Isolate or segment the system (network segmentation, VLANs, firewalls) 

• Restrict logical and physical access (least privilege, badges, dedicated workstations)

• Limit data exposure (no direct CUI processing or storage, or move CUI off-device promptly)

• Monitor activity (logging and alerting for anomalous connections)

• Establish procedural controls (manual review, documented change procedures, or supervision)

When the contractor goes through CMMC Level 2readiness and/or assessment, some considerations include:

• The assessor will verify that specialized assets are properly identified and managed,

• Review your risk documentation and compensating controls,

• Ensure the SSP, POA&M, and risk register are consistent, and

• Confirm there’s no uncontrolled CUI exposure through these devices.

On a periodic basis, the contractor should review and revalidate whether the limitation still applies. While during so, the compensating measures should be assessed to ensure those measures remain effective and document these reviews in continuous monitoring documentation. Additionally, all users should be trained on identifying and properly handling CUI on a periodic basis. 

Ultimately, the contractor is to treat specialized systems as known exceptions, not ignored risks, and maintain clear traceability between identified risks and documented mitigations.

When lab or specialized equipment is shared across projects, and only some of those projects involve CUI, the goal is to prevent CUI contamination of systems and data while maintaining operational flexibility.

It’s important to define and document the data boundaries for each of these assets within the System Security Plan (SSP). Clearly establish whether the equipment itself handles CUI, or if it only supports research that uses CUI elsewhere; and if possible, ensure CUI processing happens outside the shared system (e.g., in a secure enclave or analysis workstation).

Next, it’s important to implement logical and procedural segmentation, where possible. Access control is a strong and key component to the protection of CUI and disclosure to the appropriate personnel. Some best practices include:

• Use separate user accounts or project profiles for CUI and non-CUI projects

• Utilize role-based access controls to restrict who can access systems containing CUI, including the use of authentication mechanisms

• Establish procedures to guide users on how to treat and handle CUI (i.e. CUI data exports are to only go to approved, encrypted storage locations)

Additionally, segregation of storage and processing of CUI vs non-CUI can aid with the protection of CUI. All CUI data should be stored within a secure, compliant repository (such as a protected file share or CUI enclave), not directly on shared equipment, when possible. If available, use equipment for data collection or generation, then transfer to secure storage for analysis.

Lastly, training is equally as important as technical measures. Be able to provide researcher-specific training on handling CUI in shared environments just can include:

• Don’t mix CUI and non-CUI results on the same media.

• Don’t leave CUI files on shared drives.

• Don’t connect the equipment to non-secure cloud storage.

Frazier & Deeter Responses