StealthTech
Most defense contractors who touch engineering data know it only as “the drawings” or “the TDP.” A prime or a DoD program office sends a technical data package, someone moves it into the CAD system or a shared drive, and the engineering team gets to work. The compliance question doesn’t come up until a CMMC assessment puts it directly on the table, and by then, that drawing has usually spread far beyond the one folder anyone thought to secure.
This is worth its own deep dive because CAD files, bills of materials, and technical drawings behave differently than most of the CUI a general compliance guide describes. They don’t sit quietly in a document repository. They get checked out, versioned, cached locally, emailed to vendors, exported to lightweight formats for a supplier who doesn’t have your CAD license, and printed for a shop floor that doesn’t have a workstation nearby. Every one of those normal engineering behaviors is a place CUI can leave the boundary your CMMC program is supposed to control.
Engineering and manufacturing organizations also tend to have a harder scoping problem than a typical professional services contractor, simply because design work generates so many derivative artifacts from a single source file. One controlled assembly drawing can spawn a dozen downstream files: a simplified export for a supplier, a PDF for a shop traveler, a spreadsheet extracting dimensional data for a quality check, a lightweight viewer file for a program review. Each of those derivatives carries the same CUI designation as the source, and each one is a separate opportunity for the data to end up somewhere your compliance program never accounted for.
Controlled Technical Information: The Category That Actually Applies
The specific CUI category that governs most engineering drawings has a name most contractors have never heard, even when they’re already living inside its requirements: Controlled Technical Information, or CTI. It’s not a narrow subcategory that applies to a small slice of the defense industrial base. It’s the baseline data type for the majority of DoD contracts involving engineering, manufacturing, testing, or technical support. If your work produces or consumes technical information with a military or space application, CTI applies to your organization, whether or not anyone has used that specific term internally.
Covered defense information under DFARS 252.204-7012 explicitly includes controlled technical information by name, which means the obligation to protect it under NIST SP 800-171 predates CMMC itself and has applied since December 2017. CMMC didn’t create a new requirement for engineering data. It added independent, third-party verification on top of an obligation that was already binding, which is exactly why it catches organizations off guard: they assumed the absence of an assessor meant the absence of a requirement.
Distribution Statements: The Marking That Decides Everything
There’s a specific, concrete test for whether a given drawing or technical data package is CTI, and it’s worth every engineering lead knowing it directly rather than relying on IT or compliance staff to catch it after the fact. Documents carrying a Distribution Statement B, C, D, E, or F are, by that marking alone, CTI and therefore CUI. There’s no minimum volume threshold and no exception for a document that seems too minor to matter. A single controlled drawing sitting on a single engineer’s workstation brings that workstation into your CMMC assessment boundary, full stop.
This is where scoping conversations go wrong most often. Organizations know where their formal project files live, the folder structure everyone was trained to use for a given program. What they consistently underestimate is how far a controlled drawing spreads through completely normal business operations: technical data packages arrive as email attachments and get saved locally before anyone applies consistent handling, engineers download a drawing to a laptop for offline access during a site visit, a shop floor supervisor asks for a PDF export to reference during a production run. None of those actions feel like a security decision. Every one of them is.
Where CAD Files Actually Live, Move, and Leak
Mapping the actual data path for engineering files means looking well beyond the obvious project folder. CAD applications create temporary files and local caches on the workstation by default, often in locations the user never sees and IT never audits. CAD and PLM/PDM systems can lose the protection a repository provides the moment a file is checked out for editing, since a locally cached copy on a laptop doesn’t inherit the access controls and audit logging the PDM database enforces. Files downloaded from an ERP system for a bill of materials or a parts list carry the same exposure, and they’re frequently overlooked because a spreadsheet of part numbers doesn’t feel as sensitive as a full assembly drawing, even when it reveals the same underlying design information in a different format.
External sharing multiplies this risk. Drawings and technical data packages move constantly between primes, subcontractors, and specialty suppliers who need a specific view of a design without full CAD access. A lightweight export sent through a standard email attachment, a consumer file-sharing link, or an unmanaged cloud drive moves that CUI outside any boundary your CMMC program controls, even when the original file in your PDM system is protected correctly.
Two Different Compliance Problems: Self-Contained Files vs. PDM Environments
Not every organization working with CAD faces the same compliance architecture, and conflating the two most common scenarios leads to either overbuilt or dangerously incomplete programs. A manufacturer that opens a self-contained drawing file to run a CNC job has a materially different challenge than a design team collaborating on a large assembly through a shared PDM database, and recognizing which scenario applies to your organization is the first real scoping decision in a CAD-heavy CMMC program.
For organizations working with self-contained CAD files, individual drawings that don’t depend on a live connection to a shared database, the compliance boundary is comparatively contained: secure the endpoints where those files are opened and edited, encrypt storage at rest, and control how files move in and out.
For organizations running a PDM or PLM server, the compliance boundary extends to that server itself, which needs multi-factor authentication for all users, encryption at rest on the hosting server, audit logging of every database access and modification, vulnerability scanning and patching on its own schedule, and network segmentation isolating it from non-CUI systems. Treating a PDM-connected environment with the same controls as a self-contained file scenario, or vice versa, is one of the more expensive mismatches we see in engineering-heavy CMMC programs.
ITAR and CUI Are Related, But They Are Not the Same Requirement
Manufacturing and engineering organizations that have maintained export control compliance for years often assume, reasonably but incorrectly, that their existing ITAR program satisfies CMMC Level 2. It doesn’t, and treating the two as equivalent is one of the fastest paths to an assessment finding. ITAR governs who is allowed to access defense-related technical data across national and organizational boundaries, restricting transfers to foreign nationals and foreign entities.
CMMC governs how that data is technically and procedurally protected, covering access control, audit logging, configuration management, and multi-factor authentication in ways ITAR simply doesn’t address. An organization can be fully ITAR-compliant on jurisdiction and still fail CMMC Level 2 because its audit logs aren’t retained correctly or its CAD workstations don’t enforce MFA.
The practical implication is that an ITAR-compliant manufacturer walking into a CMMC gap assessment for the first time should expect meaningful remediation findings, not a formality. The earlier that assessment happens, the more runway there is to close gaps before they become a scheduling problem ahead of a contract deadline.
Protecting the Bill of Materials, Not Just the Drawing
Engineering data protection conversations tend to fixate on the drawing itself, the CAD file, the assembly model, the schematic. Bills of materials, part specification sheets, and test and acceptance procedures carry the same CTI designation and deserve the same protection, even though they often live in a completely different system than the CAD environment. A BOM sitting in an ERP or MRP platform, disconnected from whatever access controls protect the PDM server, is frequently the weakest link in an otherwise well-secured engineering environment, precisely because nobody thought of a parts list as “the sensitive file.”
This matters because a bill of materials, on its own, can reveal nearly as much about a design’s capability and function as the drawing it accompanies. An assessor evaluating your CUI boundary will ask where BOMs live, who can access them, and how that access is controlled, and a System Security Plan that accounts for CAD files but never mentions the ERP system generating parts lists reads as an incomplete scoping exercise, not a passing one.
Common Gaps: Local Caches, Cloud Sync, and Personal Devices
A handful of patterns account for most of the engineering-data findings we see in CMMC assessments. Personal cloud sync tools, Dropbox, personal OneDrive, Google Drive, get installed on an engineering workstation for entirely legitimate reasons, usually to work around a slow file transfer, and quietly begin syncing local CAD caches to consumer infrastructure that was never brought into the compliance boundary. Engineers working from home push drawings to a personal laptop for a deadline crunch, and that device was never enrolled in the organization’s device management or encryption policy. A supplier who needs a quick reference view of an assembly gets it emailed as a lightweight export, because the alternative, provisioning them proper access to the PDM environment, feels like more friction than the situation seems to warrant.
None of these behaviors come from bad intent. They come from engineering teams solving a real workflow problem the fastest way available, without a clear, well-communicated alternative that’s actually as convenient as the workaround. Building that alternative, not just writing a policy prohibiting the workaround, is what actually closes the gap.
Print and physical media create a parallel version of the same problem that’s easy to overlook in an otherwise digital-first compliance program. A controlled drawing printed for a shop floor reference, a USB drive used to move a large assembly file to an offline workstation, or a paper copy left on a desk overnight all carry the same CTI designation as the digital original, and CMMC’s media protection requirements apply to them just as directly. Manufacturing environments in particular tend to have more physical media touchpoints than a typical office environment, which makes a documented media handling and destruction process a genuinely practical necessity rather than a paperwork exercise.
Training Engineers, Not Just IT Staff
Most CMMC training programs are written for a general office workforce: don’t click suspicious links, use strong passwords, report lost devices. Engineering teams need training that speaks their actual workflow, because the behaviors that create the most exposure in a CAD environment aren’t the ones a generic security awareness module covers. An engineer needs to know specifically that exporting a drawing to a lightweight format for a supplier is a CUI handling decision, not a file-format convenience. A designer needs to know that a personal laptop used during a business trip needs the same device controls as their primary workstation the moment a controlled drawing gets opened on it.
This kind of role-specific training matters more in engineering environments than almost anywhere else in a typical CMMC program, because the people making CUI handling decisions throughout the day are rarely the people who wrote the security policy or who will be in the room during an assessor interview about access control. An engineering lead who can explain, in their own words, why a given drawing carries a Distribution Statement and what that means for how it’s shared is exactly the kind of control owner who reassures an assessor that the practice described in your documentation is actually how the organization operates day to day.
Building a Compliant Engineering Data Environment
Organizations that get this right start with an honest map of where CTI actually lives and moves, not where it’s supposed to live according to the org chart. That includes the PDM or PLM server, every workstation where CAD files get opened or edited, the ERP or MRP system hosting BOMs and part specifications, and every external sharing channel used to move files to primes, subcontractors, and suppliers. From there, access needs to be scoped by role rather than granted broadly, with Microsoft Entra ID and Intune or an equivalent identity platform enforcing multi-factor authentication and device compliance on every endpoint that touches engineering data, including remote and field devices.
Backup and recovery infrastructure for the PDM environment deserves the same rigor as anything else in the CUI boundary, since a corrupted or ransomed engineering database can halt production as effectively as a stolen drawing exposes a design. Our overview of data backup and disaster recovery covers what that looks like for CMMC-scoped environments generally, and the same standard applies directly to a PDM or PLM server holding CTI. For organizations with genuine operational technology alongside their engineering environment, production equipment, industrial control systems, shop floor terminals, that OT layer needs explicit attention in the compliance program rather than being scoped out by default, which is a gap general cybersecurity advisors without manufacturing experience consistently miss.
This is exactly the kind of environment where sector-specific experience shows up in the quality of the compliance outcome. We’ve worked directly with engineering teams on exactly this problem: streamlining secure CAD file access, eliminating the local-cache and personal-device workarounds that created exposure, and getting design teams back to work without the friction that drives people toward unmanaged shortcuts in the first place. You can read the details in our co-managed IT case study on exactly this kind of engagement.
Where to Start
For most engineering and manufacturing organizations, the starting point isn’t a technology purchase. It’s an honest inventory: where do Distribution Statement B through F documents actually live today, which systems generate or store bills of materials, and which of those systems were scoped into the last compliance conversation versus quietly excluded because nobody thought to ask. A CMMC gap assessment scoped specifically to include CAD infrastructure, PDM/PLM environments, and OT systems, not just standard IT, is the fastest way to find that gap before an assessor does. Our guide to choosing the right CMMC consultant covers specifically what to look for in a provider with genuine manufacturing and engineering experience, since that sector-specific pattern recognition is what separates a program that survives assessment from one that only looks complete on paper.
Stealth Technology Group secures CAD environments, PDM/PLM systems, and engineering data for defense manufacturers pursuing CMMC certification. If your engineering and manufacturing teams need to protect CAD files, drawings, and BOMs without slowing design work down, visit our compliance services page, or contact Stealth Technology Group today at (617) 903-5559 to talk with a specialist.
