Assessment Scope Guide · Aerospace & Defense

CMMC Level 2 for Aerospace & Defense Manufacturers: What Counts as CUI on Your Shop Floor

Technical drawings, CNC programs, inspection records, and ERP data all touch your production environment. Understanding which of them are in scope for CMMC assessment is the first problem most aerospace manufacturers get wrong.

Last updated: December 26, 2025

The scoping problem What is CUI Shop floor data ERP and networks Out of scope System boundary Assessment prep FAQ

The Scoping Problem Most Manufacturers Underestimate

Aerospace and defense manufacturers have a compliance instinct shaped by years of quality systems, ITAR controls, and export license management. When CMMC arrives, the natural assumption is that the existing controlled areas cover everything. They usually do not.

CMMC Level 2 scoping is not about physical access. It is about where Controlled Unclassified Information flows electronically and who can reach it. A shop floor workstation running MasterCAM connected to the same network segment as your engineering file server has brought that workstation into scope whether or not the operator ever opens a drawing. A tablet used to record first-article inspection results that syncs to a cloud-based quality system may have taken your entire production environment out of scope entirely, because it moved CUI to a system you do not own. Both situations create assessment findings. Neither is obvious without deliberate analysis.

The scoping exercise should precede every other piece of CMMC work. Contractors who skip it, or who scope by intuition rather than documented data flow analysis, consistently encounter surprises during C3PAO assessment that add months to their certification timeline.

What CUI Actually Means in a Manufacturing Context

Controlled Unclassified Information is defined by the CUI Registry maintained by the National Archives. For aerospace and defense manufacturers, the categories that appear most frequently are Technical Data under the Defense category, Export Controlled information under International Traffic in Arms Regulations, and Controlled Technical Information as defined in DFARS 252.204-7012.

The working definition that matters for scoping: if the information was generated under a DoD contract, if it describes how a defense article or system is designed, manufactured, or tested, and if it requires distribution controls on the deliverable document, it is almost certainly CUI. The government does not need to explicitly mark every file. If the contract includes DFARS 252.204-7012, you have CUI obligations regardless of what appears on individual documents.

Key scoping trigger
The presence of DFARS 252.204-7012 in your contract is the trigger that establishes CUI obligations. The absence of CUI markings on individual files does not release you from those obligations. Assessors verify the contract clause, not the document headers.

For manufacturers operating under both commercial and defense programs, the challenge is segmentation. CUI obligations attach to the program, not the facility. A machine shop that produces components for both a commercial aviation customer and an Air Force program may need to demonstrate that the defense program data does not commingle with the commercial environment, or that the entire combined environment meets CMMC requirements.

What Is in Scope on the Shop Floor

The following categories of data routinely qualify as CUI in aerospace manufacturing environments. Each one represents a potential scope trigger that brings the systems containing it into the CMMC assessment boundary.

Engineering Drawings and Models

Model-based definition files, 2D drawings, assembly drawings, and interface control documents received from a prime contractor under a defense contract are CUI. This includes CATIA, STEP, IGES, and DXF files stored on engineering workstations, shared drives, or PDM systems. The distribution statement on the drawing determines whether it is export controlled, but the absence of a statement does not remove CUI status if the underlying contract requires it.

Where this becomes an assessment issue: many manufacturers store defense program drawings in the same PDM system used for commercial programs. The system is in scope. Assessors will ask how access is controlled, how the system is backed up, and where the data goes when a drawing is exported for production use on the floor.

CNC Programs and Manufacturing Instructions

G-code programs derived from defense contract drawings are CUI because they encode the geometric and tolerance information from those drawings. A CNC program for a structural frame component contains the intellectual content of the engineering drawing in a different format. It is in scope.

The path that CNC data takes from engineering to the machine tool is a common scope expansion vector. If programs move from an engineering workstation to a machine controller via USB drive, that USB drive is in scope and must be managed under CMMC media protection requirements. If programs transfer over a network connection to a DNC server, that server is in scope. If the machine controller itself stores programs, the controller is in scope and must be addressed in the System Security Plan, even if it runs an embedded operating system that cannot support traditional endpoint controls.

First Article Inspection and In-Process Records

Inspection records for defense contract deliverables that reference drawing dimensions, tolerances, or acceptance criteria are CUI. This includes first article inspection reports, in-process inspection records, and final acceptance documentation. The same is true for non-conformance reports that contain part numbers, dimensions, or specification references tied to defense programs.

Quality management systems are frequently overlooked in scoping. If your QMS stores inspection records for defense contract parts, the QMS is in scope. If the QMS is a cloud-hosted SaaS platform, you have introduced an external system processing CUI, which requires a separate analysis under CMMC scoping guidance and may require a flow-down agreement with the SaaS vendor.

Process Specifications and Work Instructions

Internally generated process specifications that implement prime contractor or government requirements, including special process approvals, surface treatment procedures, and material certifications tied to defense contract requirements, are CUI when they contain or derive from controlled technical information. Work instructions that translate engineering drawing notes into shop floor operations inherit the CUI classification of the source drawing.

Common misclassification
Manufacturers frequently treat internally generated work instructions as proprietary business data rather than CUI. If those instructions implement a prime contractor-supplied process specification, or if they were developed to meet a government requirement specified in the contract, they are CUI and bring the systems containing them into scope.

ERP Systems, Networks, and the Data That Connects Them

Enterprise resource planning systems are where the scoping conversation gets complicated for aerospace manufacturers. ERP systems contain procurement data, scheduling data, supplier information, and cost data. Most of that is not CUI. But ERP systems in a defense manufacturing environment frequently also contain contract numbers, CAGE codes, line item descriptions tied to controlled part numbers, material certifications, and subcontractor information that references defense programs.

The standard applied by assessors is whether the system stores, processes, or transmits CUI, not whether the system's primary purpose is CUI management. An ERP module that houses the bill of materials for a defense contract part is processing CUI. That module, and the database server that supports it, and the workstations that access it, are in scope.

Manufacturers who cannot cleanly separate defense contract data from commercial data within their ERP will typically find that the entire ERP environment is in scope. Segmenting defense contract data to a separate ERP instance or a separate database schema with access controls is technically possible but operationally demanding. The easier path for most manufacturers is to bring the full ERP environment into compliance rather than attempting a segregation that assessors will scrutinize.

Network Architecture and the Shop Floor Boundary

Modern aerospace manufacturing environments are increasingly connected. Machine tool controllers pull programs from network shares. Coordinate measuring machines upload inspection results to quality databases. Vision systems capture images that are stored for traceability. Each connection is a potential scope expansion.

The CMMC scoping guidance distinguishes between systems that process CUI and systems that provide security services to those systems. A network switch in a segregated defense manufacturing segment is in scope because it carries CUI traffic. A firewall that filters traffic between the defense segment and the rest of the network is in scope because it enforces the boundary that protects CUI. Assessors will ask for network diagrams showing these boundaries, and they will verify that the documented segmentation is actually implemented.

What Is Typically Out of Scope

Not everything in a manufacturing facility touches CUI. Understanding what is out of scope is as important as identifying what is in scope, because scope reduction directly reduces compliance cost and complexity.

Commercial program data, customer-proprietary data not subject to government distribution controls, and purely administrative systems that have no access to CUI environments are candidates for exclusion. The payroll system that does not share a network segment with engineering is out of scope. The security camera system in the parking lot is out of scope. The conference room scheduling software is out of scope.

Physical production equipment that has no electronic connectivity to CUI-containing systems is also out of scope. A manual milling machine does not have a CUI problem. A legacy CNC controller that runs programs loaded from a standalone programming unit that is never connected to the network is out of scope if that isolation is real, documented, and verifiable by an assessor. If the same controller connects to a DNC server once a month for program transfer, it is in scope.

Defining and Documenting the System Boundary

The System Security Plan is the document that formally captures your system boundary. For CMMC assessment, the SSP must describe every system component in scope, how CUI flows through those components, and how each of the 110 NIST SP 800-171 requirements is implemented across that boundary.

For aerospace manufacturers, the SSP system boundary description needs to address several things that generic compliance templates overlook. It must account for operational technology: the DNC server, the machine controllers, the CMM software, and any SCADA or industrial control system components that are part of the manufacturing environment. It must document how portable media is managed when CNC programs move between engineering and the floor. It must explain what happens to CUI when a defense contract ends and the associated drawings, programs, and records are retained for contractual or regulatory reasons.

One practical technique that helps in assessment: create a data flow diagram that traces a single engineering drawing from receipt at the customer interface through engineering review, translation to CNC program, transmission to the machine controller, execution, and archival. Every system that drawing touches, and every person who can access it, is in your boundary. Every system that can access the systems that touch it is also in your boundary unless a documented and tested control prevents that access.

Data Type Typical Location CUI Status Scope Impact
Engineering drawings (defense programs) PDM system, shared drives CUI — Technical Data PDM server, workstations, network in scope
CNC programs derived from defense drawings DNC server, machine controllers CUI — Technical Data DNC server, connected controllers in scope
First article inspection records QMS, shared drive, paper CUI when referencing controlled dimensions QMS server or cloud instance in scope
ERP bill of materials (defense programs) ERP database CUI — program-dependent ERP server and workstations with access in scope
Commercial program drawings PDM system (often shared) Not CUI unless government contract In scope if co-located with CUI data
Administrative HR and payroll data Separate system, no CUI access Not CUI Out of scope if network-isolated

What Assessors Focus On in Aerospace Manufacturing

C3PAO assessors conducting CMMC Level 2 assessments at aerospace manufacturers consistently probe a small set of high-risk areas. Knowing what they examine helps prioritize preparation.

Access control for engineering data is the first area. Assessors verify that access to CUI is limited to users who need it for their role, that access is granted through a formal provisioning process, that former employees are terminated promptly, and that privileged access is separately managed and logged. In a manufacturing environment, this often means examining who has access to the PDM system and DNC server, whether that access is documented, and whether there are any shared accounts or generic credentials in use on shop floor equipment.

Media management is consistently finding-prone in manufacturing. USB drives used to transfer CNC programs, external hard drives used for engineering backups, and optical media used for archiving are all regulated under CMMC media protection requirements. Assessors expect a documented media management policy, physical controls over removable media, and evidence that media sanitization occurs before disposal or reuse.

Maintenance of legacy equipment is the third focus area. Aerospace manufacturers often run machine tool controllers and metrology systems that are a decade or more old. Many run operating systems that are no longer supported. Assessors understand that replacing a $2 million five-axis machining center because the controller runs Windows XP is not a practical option. What they look for instead is compensating controls: network isolation, application whitelisting where the OS supports it, enhanced monitoring, and documented justification for why replacement is not feasible. The absence of any documented compensating control for unsupported systems is an assessment finding.

Frequently Asked Questions

We receive drawings from our prime contractor marked ITAR, not CUI. Are they the same thing?

They are related but not identical. ITAR controls govern export and transfer of defense articles and related technical data to foreign persons and governments. CUI is the federal information handling standard that governs how information is safeguarded within domestic systems. Information can be both ITAR-controlled and CUI. When a drawing is received under a defense contract that includes DFARS 252.204-7012, the CUI obligation applies regardless of whether the document is also ITAR-controlled. For CMMC purposes, the relevant question is whether the data qualifies as Controlled Technical Information under the CUI Registry, and ITAR-controlled technical data for defense systems almost always does.

Our machine tool controllers run embedded OS versions that cannot support endpoint security software. What does CMMC require?

CMMC does not require the same controls to be implemented identically on every system. The standard permits compensating controls and documented exceptions for components that cannot support a required control due to operational or technical constraints. For legacy machine tool controllers, assessors typically look for network isolation that limits connectivity to only the minimum necessary, documented justification for why the compensating control approach is used, and enhanced monitoring at the network boundary. The compensating control must be documented in the SSP and reviewed by the assessor. Undocumented legacy systems with no compensating controls are findings.

We are a Tier 2 supplier. Our prime has not told us specifically what is CUI. How do we proceed?

The obligation to identify and protect CUI does not depend on the prime explicitly labeling each piece of data. If your contract includes DFARS 252.204-7012, you are obligated to protect Controlled Technical Information. The reasonable approach is to treat all technical data received under that contract as CUI until you can affirmatively confirm it is not, and to contact your prime contractor for clarification on their marking and handling expectations. This is also a conversation worth documenting, because it demonstrates good-faith effort if a question about compliance arises later.

Our ERP system is cloud-hosted. Does that put us out of compliance?

Not automatically, but it requires careful analysis. Cloud-hosted systems that process CUI must meet the same NIST SP 800-171 requirements as on-premises systems, or they must be FedRAMP Moderate authorized, which is treated as equivalent. If your cloud ERP vendor is not FedRAMP authorized and the system processes CUI, you need to either migrate defense contract data to a compliant environment, work with the vendor to establish that they meet 800-171 requirements through their own attestation, or remove CUI from that system. A vendor's SOC 2 report does not satisfy CMMC requirements.

Your SSP. Not a template.

1TEN generates your System Security Plan from your actual documented control implementations. C3PAO-ready.

Request a Demo