CUI in CAD Systems: A Practical CMMC Scoping Guide

A CAD file can carry Controlled Unclassified Information long after it leaves the engineering workstation. A drawing may sit in a PDM vault, move through Microsoft 365, appear in a backup, or pass through a managed service provider’s monitoring tools.

For DoD contractors, CUI CAD systems require more than an application inventory. I scope the people, devices, services, and connections that touch controlled technical data or protect the environment where it lives.

The goal is a defensible CMMC Level 2 boundary that reflects how engineering work actually happens.

Key Takeaways

• CAD software is only one part of the CMMC scope when it creates, stores, processes, or transmits CUI.
• Engineering workstations, PDM or PLM platforms, file storage, identity services, backup, and endpoint tools often belong in scope.
• A managed service provider may be a Security Protection Asset when it administers or monitors in-scope systems.
• Data-flow mapping exposes hidden CUI paths, including exports, email attachments, print queues, local caches, and cloud sync folders.
• A clear system security plan, asset inventory, and responsibility map make assessment evidence easier to produce and defend.

Why CAD Files Create a Wider CMMC Boundary

A mechanical model, technical drawing, manufacturing specification, or bill of materials can contain Defense Controlled Technical Information. The National Archives CUI Registry identifies Defense CUI categories and helps contractors determine how a contract marks and handles information.

I start with the contract, task order, technical data package, and flow-down requirements. CUI is not defined by the file extension. A .DWG, .SLDPRT, .STEP, PDF, spreadsheet, or email can all carry CUI when the content meets the applicable category and contract conditions.

That distinction matters because a CAD application alone does not define the boundary. Autodesk AutoCAD, Autodesk Vault, SOLIDWORKS, SOLIDWORKS PDM, PTC Creo, Windchill, Siemens NX, and Teamcenter can be part of the environment. However, surrounding systems may also process or protect the same data.

For example, an engineer may open a controlled model from a Windows file share. The workstation syncs OneDrive, resolves access through Microsoft Entra ID, sends telemetry to endpoint detection software, and backs up the file server overnight. Each component needs a scoping decision.

If an asset handles CUI or provides a security protection function to an asset that handles CUI, it deserves attention during CMMC scoping.

The CMMC Program rule in 32 CFR Part 170 establishes the framework for CMMC assessments. For Level 2, the assessment scope must account for CUI Assets and Security Protection Assets. The exact contractual requirement and assessor interpretation still matter, so I document the reasoning behind each inclusion or exclusion.

A narrow scope built around a CAD workstation may look efficient at first. It often breaks down once an assessor follows the data to storage, identity, backup, and support systems.

The Asset Categories That Matter in CMMC Level 2

CMMC scoping works best when I classify assets by what they do, not by where they sit on a network diagram. The Department of Defense identifies several asset categories for Level 2 assessment scoping.

Asset category	CAD environment examples	Typical scoping decision
CUI Assets	CAD workstations, PDM servers, file shares, VDI desktops, engineering laptops	In scope because they process, store, or transmit CUI
Security Protection Assets	MFA services, firewalls, EDR, SIEM, backup platforms, identity systems	In scope when they provide security functions for CUI Assets
Specialized Assets	Manufacturing equipment, test systems, operational technology, certain IoT devices	Documented in scope, with assessment treatment based on CMMC guidance
Contractor Risk Managed Assets	Segmented systems that cannot process, store, or transmit CUI	Must meet applicable conditions and remain separated from CUI
Out-of-Scope Assets	Independent guest Wi-Fi, unrelated public website hosting	Excluded only when they have no CUI or security-protection role

The table provides a starting point, not a shortcut. A system’s role can change quickly. A backup server becomes a CUI Asset when it stores recoverable CAD files. A remote monitoring platform becomes a Security Protection Asset when it delivers endpoint alerts or administrative access for in-scope devices.

CUI Assets in an Engineering Workflow

CUI Assets include the obvious equipment: engineering desktops, laptops, shared project folders, PDM repositories, and approved cloud tenants. Yet engineers often create additional copies during normal work.

Local autosave files, temporary rendering folders, plot files, print spools, export directories, and CAD collaboration caches may hold controlled content. A laptop used for field design reviews also enters the boundary if it downloads or displays those files.

I also include systems that transmit CUI, even when they don’t retain it. A secure file-transfer service, a virtual private network concentrator, or an email relay may only move the data. It still affects confidentiality and requires documented control.

Security Protection Assets Are Not Optional Extras

Security Protection Assets often create the largest gap between a proposed CMMC boundary and the real environment. These assets support confidentiality, integrity, availability, authentication, or access control for CUI systems.

Common examples include:

• Microsoft Active Directory, Microsoft Entra ID, domain controllers, MFA services, and privileged access tools.
• Endpoint Security platforms, EDR consoles, vulnerability scanners, patch-management systems, and mobile device management.
• Firewalls, secure remote-access appliances, DNS filtering, email security, and network monitoring platforms.
• Backup software, immutable backup storage, recovery consoles, log collectors, SIEM platforms, and time-synchronization services.
• Remote support tools used by internal IT staff or a managed service provider.

A security tool does not fall out of scope because its console stores alerts rather than drawings. If that tool protects the CAD workstation or file repository, it can affect the CMMC control environment.

Map CUI Data Flows Before Drawing the Boundary

An asset list is necessary, but it doesn’t reveal the whole story. I map how one controlled file moves from receipt through design, review, release, retention, and recovery.

Start with a real project file, not an idealized diagram. Trace its route from the DoD customer or prime contractor to the person who opens it. Then record each system that stores, transmits, or protects the file.

A typical path may include a secure portal, an email notification, an engineer’s workstation, a PDM vault, a network share, a cloud collaboration site, a backup appliance, and a recovery copy. If an engineer sends a PDF to a supplier or prints a drawing for a shop-floor review, that path belongs on the map too.

The NIST SP 800-171 Revision 2 publication frames the safeguards that protect CUI in nonfederal systems. Its requirements cover access control, audit and accountability, configuration management, identification and authentication, incident response, media protection, and other areas that depend on more than CAD settings.

Questions That Expose Hidden Scope

I ask process owners questions that uncover data paths technical teams may miss:

1. Where do engineers receive controlled technical files, and who approves access?
2. Can CAD users save to local folders, USB media, OneDrive, SharePoint, Dropbox, or personal email?
3. Which platform hosts PDM or PLM data, and where do its database and file-store backups reside?
4. Does an outside IT provider use remote tools, privileged accounts, or monitoring agents on in-scope endpoints?
5. How are retired engineering devices sanitized, retained, or destroyed?
6. Can production systems, CNC programming tools, test equipment, or quality systems import controlled drawings?

The answers establish a credible boundary. They also reveal process changes that may reduce unnecessary CUI movement. For instance, limiting controlled files to an approved engineering repository can remove risky desktop copies and unapproved sync paths.

CMMC Level 2 Controls That Affect CAD Operations

CMMC Level 2 aligns with the 110 requirements in NIST SP 800-171 Revision 2. The DoD CMMC information portal provides current program material, while contract language determines when an organization must achieve a particular assessment status.

Engineering teams feel these requirements in everyday tasks. Access control affects who can open a model, export it, or administer a PDM vault. Identification and authentication requires unique accounts and multi-factor authentication where required. Configuration management governs workstation baselines, CAD plug-ins, drivers, and change approval.

A capable CAD workstation may need elevated privileges for certain installation or licensing tasks. That does not justify permanent local administrator access. Device Hardening should separate standard engineering work from privileged administration through controlled accounts, approval workflows, and audit records.

Control Areas That Commonly Need Evidence

Access reviews should show who has access to engineering repositories and why. Permission groups need a business owner, especially when project teams include temporary staff, subcontractors, or external partners.

Endpoint controls need more than antivirus installation. I look for documented Endpoint Security coverage, supported operating systems, patch status, disk encryption, screen lock settings, removable-media rules, and alert response procedures. A CAD workstation that can’t run a standard agent needs a documented exception and compensating protections.

Backups require the same attention. A successful backup job does not prove recovery. Teams need to know whether protected files restore correctly, whether restoration access is restricted, and whether recovery testing produces evidence. Those records support both system availability and Business Continuity & Security planning.

Logging also becomes difficult in engineering environments. A useful audit trail may include repository access, privileged changes, remote support sessions, security alerts, failed logons, and backup administration. Retention periods and review procedures should match the contract, SSP, and organizational risk decisions.

Cloud, Microsoft 365, and External Support Providers

Cloud services complicate CMMC scoping because data can move through several connected platforms. Cloud storage, identity, email, Teams, device management, backup, and security reporting may all participate in one engineering workflow.

An Office 365 Migration deserves a CUI impact review before files move. SharePoint permissions, Teams guest access, OneDrive sync, retention policies, sensitivity labels, conditional access, and mobile-device rules can all affect controlled data. A commercial Microsoft 365 tenant does not automatically meet the needs of a CUI workflow.

Microsoft describes GCC High and DoD service environments and their intended government customer use cases. The correct tenant, licensing, configuration, and contractual commitments depend on the contractor’s requirements. I treat the tenant choice as one decision within a larger secure design, not a compliance stamp.

External cloud service providers that process, store, or transmit CUI require close review. DFARS 252.204-7012 includes cloud security requirements tied to FedRAMP Moderate equivalency for covered defense information. The organization should verify provider commitments, service boundaries, logging options, incident notification duties, data residency, and subcontractor arrangements.

When a Managed Service Provider Enters Scope

A managed IT firm may have no business need to open a drawing. Yet its technicians could still manage domain accounts, patch engineering endpoints, operate backups, respond to EDR alerts, or access a remote-support console. Those actions can make the provider and its tooling relevant to the CMMC boundary.

I require clear answers to several questions:

• Which provider personnel can access in-scope systems, and how do they authenticate?
• Where do remote-support logs, tickets, screenshots, and configuration backups reside?
• Which provider tools deliver security protection functions?
• What incident-response, breach-notification, and subcontractor terms apply?
• Can the provider produce evidence for control operation during the assessment period?

A Business Technology Partner should make those answers available early. The provider’s own security practices, access model, documentation, and escalation process affect the evidence a contractor can present.

A Practical Scoping Plan for Small Contractors

Small organizations often believe they need to place every computer and business system inside the CMMC boundary. That approach raises cost and creates more controls to operate. A better approach keeps CUI in a defined, defensible engineering enclave where practical.

The boundary may include a limited group of approved engineering users, hardened workstations, a protected file or PDM platform, managed identity, approved collaboration tools, endpoint monitoring, and isolated backups. Finance, HR, marketing, and unrelated point-of-sale systems can remain outside if they don’t handle CUI or protect CUI Assets.

This separation must be real. Network segmentation, access restrictions, routing rules, shared-service decisions, and administrative boundaries need documentation. An office computer is not out of scope merely because nobody intends to store drawings on it.

For a manufacturer that also operates a cafeteria or hospitality venue, Restaurant POS Support and Kitchen Technology Solutions should remain separate from the CUI environment. The same principle applies to badge systems, building controls, public Wi-Fi, and unrelated SaaS tools. If shared identity, shared administration, or shared monitoring connects them to the engineering boundary, the scoping decision changes.

Build the Evidence as You Build the Boundary

I connect scoping work to the documents and records an assessor will expect to review. The system security plan should describe the in-scope environment, authorization boundary, responsible roles, network architecture, external services, and requirement implementation.

The assessment-ready package should include:

• An asset inventory with owner, location, category, operating system, and CUI or security role.
• Data-flow diagrams that identify engineering repositories, cloud services, backups, remote access, and external transfers.
• A responsibility matrix for internal staff, cloud providers, and managed service providers.
• Policies, procedures, tickets, access reviews, vulnerability records, backup-restoration evidence, and incident-response records.
• A plan of action and milestones where permitted, with ownership and dates tied to the actual remediation work.

The NIST SP 800-171A assessment procedures offer a useful model for examining evidence, interviewing personnel, and testing control operation. CMMC Level 2 uses its own assessment requirements, so I align evidence to the current CMMC assessment materials and the contract’s expectations.

Turning Scope Into an IT Plan That Holds Up

A successful scope becomes an operating plan. I begin with Small Business IT realities: limited staff, mixed hardware ages, urgent project deadlines, and outside support relationships. Then I set priorities around CUI handling and CMMC evidence rather than broad technology wish lists.

Cloud Infrastructure should separate controlled engineering data from casual file sharing. Cloud Management should track identities, configurations, logs, storage, backups, and provider responsibilities. A documented Secure Cloud Architecture makes it easier to show where CUI goes and who can reach it.

For organizations without a full internal security team, Managed IT for Small Business can cover patching, monitoring, backup verification, and technical documentation. However, services must fit the CMMC boundary and support evidence collection. Generic support tickets aren’t enough when an assessor needs proof of access reviews or incident handling.

My Technology Consulting work ties technical decisions to contracts, business processes, and assessment objectives. That work may include Infrastructure Optimization, identity cleanup, PDM access redesign, Office 365 Migration planning, and Data Center Technology decisions for on-premises engineering workloads.

Cybersecurity Services should support the controls that the contractor operates every day. That includes Endpoint Security, Device Hardening, vulnerability management, logging, backup testing, and incident response. These are practical safeguards, not documents that sit untouched after a readiness review.

The result is an IT Strategy for SMBs that treats CMMC as part of normal operations. Innovative IT Solutions and Tailored Technology Services only matter when they reduce uncontrolled CUI paths, clarify ownership, and give the organization evidence it can produce under review.

A Defensible CAD Scope Starts With the File Path

CUI in a CAD environment follows the file, the identity, and the security controls around them. A compliant-looking CAD workstation cannot carry the assessment burden alone.

I build the scope around real engineering behavior, then document each connected asset that stores, transmits, or protects CUI. That approach gives DoD contractors a clearer boundary, stronger evidence, and a more workable path to CMMC Level 2 readiness.