Is G-Code CUI? When CNC Programs Count as Controlled Technical Information Under DFARS G-code is not automatically Controlled Unclassified Information just because it drives a machine tool. But a CNC program can become CUI when it contains, or was derived from, controlled technical information tied to a Department of Defense contract.

That distinction matters more than most machine shops realize. A single program might travel from a CAM workstation to a DNC server, onto a USB drive, into a machine controller, through a backup routine, and back out again for inspection. Each stop creates a new question about who can access the file and how it needs to be protected.

This article walks through a practical decision framework: contract context, source data, technical content, markings, data flow, and the controls that hold it all together. It's educational, not legal advice. When classification is uncertain, your contracting officer, prime contractor, or compliance counsel should make the final call.

Key Takeaways

  • CUI status follows origin and contract context—not file extension or G-code syntax.
  • Toolpaths from controlled defense drawings still carry protection requirements.
  • Document each program’s full lifecycle: receipt, storage, transfer, access, and destruction.
  • If classification is unclear, confirm with the prime or contracting officer—unmarked does not mean unrestricted.

What CUI and Controlled Technical Information Mean for CNC Data

Controlled Unclassified Information is a specific legal category, not a catch-all for "sensitive" files. The National Archives CUI Registry defines CUI as information that a law, regulation, or government-wide policy requires or permits an agency to safeguard, and which has been formally approved and listed by the CUI Executive Agent. Classified information is excluded entirely. It is governed by separate authorities. Within that Registry sits Controlled Technical Information (CTI), a Defense category. CTI covers technical data with military or space application that carries restrictions on access, use, or distribution, marked with Distribution Statements B through F. For a manufacturing shop, that typically includes:

  • Engineering drawings and 3D models
  • Technical data packages and specifications
  • Process sheets and work instructions
  • Test reports and design analyses
  • Executable or source code tied to a defense article

DFARS and CUI Handling Obligations

DFARS 252.204-7012 ties contract performance to CUI safeguarding, but the exact obligations depend on the specific contract. The clause defines "covered defense information" as unclassified CTI or other CUI-Registry information that is marked or identified in the contract. It also covers information provided by, developed for, or handled on behalf of DoD during performance. Always verify the current clause language against your actual contract. Do not assume a single boilerplate reading applies.

One File, Multiple Control Regimes

A CNC program isn't limited to a single classification. The same file could simultaneously involve:

  • CUI/CTI under the defense category
  • ITAR-controlled technical data, if it relates to a defense article on the U.S. Munitions List
  • EAR-controlled information, for dual-use technology
  • Trade secrets or customer-confidential data, under separate contractual terms None of these turn on file format, filename, storage location, or a CUI banner alone. An unmarked .NC file on a shared drive is not automatically clear, and a banner does not make a file CUI by itself. Content, source, and the governing contract decide the outcome.

How to Determine Whether a G-Code Program Is CUI

Work through this source-first test before you label any program.

  1. Trace the origin. Was the G-code built from a defense drawing, 3D model, tolerance scheme, controlled process spec, or contract work instruction? If yes, the program inherits the source's protections.

  2. Evaluate what the program reveals. Not every G-code file exposes its full source data. Ask whether it discloses:

    • Part geometry or critical dimensions
    • Tolerances tied to a defense article's performance
    • Machining sequence or special processes
    • Material requirements specific to the contract

    A rough facing operation might reveal little. A finish pass on a mission-critical bore, taken straight from a controlled tolerance stack, is a different story.

  3. Check the contract and customer instructions. Look for CUI categories, distribution statements, flow-down clauses, and prime-contractor handling rules. If the paperwork conflicts or is incomplete, get clarification before you assume a status.

  4. Account for derivative data. Converting a CAD model into toolpaths changes the format, not necessarily the sensitivity. A file that began as an engineering drawing and ended as machine instructions can still carry the same protection requirements it had on day one.

Four-step CNC G-code CUI classification decision framework

A Simple Outcome Framework

Situation Recommended action
Derived from controlled defense data, classification uncertain Treat as potentially CUI while investigating
Source, contract, content, and instructions all support a non-CUI conclusion Document that determination in writing
Not CUI but touches a defense article Check ITAR, export controls, trade secrets, and confidentiality terms separately

That last row matters. A file can clear the CUI bar and still be legally restricted under an entirely different regime.

DFARS, Data Lifecycle, and System Scope

Think through where a program actually travels. A typical path looks like this:

  1. A customer drawing or model arrives at engineering.
  2. A programmer builds a CAM file and generates post-processed G-code.
  3. The file is approved and moved into a program library.
  4. It transfers to the machine, via a DNC connection or removable media.
  5. The machine executes it, and inspection confirms the result.
  6. The program is backed up, archived, and eventually retired.

Every stop on that path is a potential point of exposure, and each one may fall inside your compliance scope. Likely in-scope components include:

  • Engineering and CAM workstations
  • Shared drives and file servers
  • DNC servers and machine controllers
  • Removable media and operator interfaces
  • Cloud storage and backup systems
  • Connected inspection or ERP platforms

Scoping isn't just about who looks at the original drawing. The CMMC Level 2 Scoping Guide requires an asset inventory, a system security plan, and a network diagram that reflects actual data flows, not assumptions.

Assets that process, store, or transmit CUI are assessed against all applicable requirements. Assets that only provide supporting security functions are evaluated for relevant controls. Anything genuinely out of scope must be physically or logically separated, not just labeled as separate.

This is where documentation earns its keep. If your DNC server routes a controlled program to six machines, all six, plus the server itself, are part of the picture. Guessing at boundaries after an assessment starts is a bad position to be in.

CMMC CNC data flow scope map showing DNC server and machines

How to Protect G-Code and Related CNC Data

Once a program is treated as CUI, or you're still investigating, put controls in place. Build a program inventory. Track, for each file:

  • Source (drawing, model, or specification)
  • Contract or customer
  • Classification decision and who made it
  • Owner and approved users
  • Storage locations and transfer method
  • Retention period and disposal process Control access deliberately. Individual accounts, least-privilege permissions, and role-based access for programmers versus operators are the baseline. Remove access promptly when someone changes roles, and keep audit records of downloads, edits, approvals, and transfers. Lock down transfer paths. DNC connections, USB drives, portable computers, and offline programming stations all need attention under NIST SP 800-171 media protection and access control families. That includes sanitizing media before reuse and controlling removable-storage use on external systems. Research the specific controls that apply to your environment rather than improvising a checklist. Manage versions and approvals. An operator running an outdated program creates both a compliance risk and a scrap risk. Tying execution to a single authoritative, engineering-approved file reduces both problems at once. Plan for the full lifecycle. Retention, backups, incident response, and sanitization all need documented procedures, including for obsolete programs, decommissioned machines, and old setup sheets. Legacy controllers that can't support modern security controls may need documented compensating controls, like network isolation, instead.

Five CNC data protection controls from inventory to lifecycle management

Applying the Analysis in a CNC/DNC Workflow

Here's how this plays out on an actual shop floor. A defense drawing arrives in engineering. A programmer builds the CAM file, generates post-processed G-code, and gets it approved.

The DNC system sends the approved file to a specific machine controller. The machine executes it, and inspection records confirm the part meets spec.

Every handoff in that sequence is a control decision:

  • Who approved the file before it left engineering?
  • Which system holds the authoritative version?
  • Can an operator save an uncontrolled copy locally?
  • Who's authorized to revise or retransmit the program?

Mapping those handoffs, and knowing which system holds the "real" file, cuts down on the ambiguity that creates compliance gaps.

Controlink Systems builds CNC/DNC communication tools for shops managing this workflow, including systems that route the latest engineering-approved file directly to a machine control and log the transfer. That infrastructure helps organize program transfers and reduce uncontrolled copies on the shop floor.

To be clear: connecting your machines through a DNC system doesn't establish DFARS, NIST, or CMMC compliance by itself. It's infrastructure that supports the documentation and control decisions your compliance program requires, not a substitute for making those decisions.

Frequently Asked Questions

What are two types of CUI?

Manufacturing shops most often encounter two CUI types: Controlled Technical Information and export-controlled information. Both appear in the federal CUI Registry’s categories and subcategories. Always verify the exact category against your contract and source documents.

Can you give me an example of CUI?

A defense-contract engineering drawing, a manufacturing specification derived from it, or a CNC program generated from that specification can all qualify as CUI. Classification depends on the contract terms and the technical content involved, not the document type alone.

Is G-code automatically considered CUI?

No. G-code isn't CUI simply because of its format. It becomes CUI when its source data, technical content, and defense-contract context meet the CUI Registry's criteria for controlled technical information.

Does DFARS apply to CNC programs?

It depends on the applicable contract clauses and the information the program contains. A CNC program derived from controlled technical data may fall within a protected data flow under DFARS 252.204-7012. Verify the specific clause and flow-down requirements with your contracting officer.

How should a machine shop protect CUI in CNC files?

Classify files first, then apply access controls, approved-version discipline, and secure DNC or removable-media transfers. Document system boundaries, keep backups, train employees, and maintain incident-response and disposal procedures.