CMMC-Compliant Robotics Development: 800-171 in Practice

Posted: May 2, 2026 to Robotics.

Short answer: CMMC-compliant robotics development means treating every machine, every git repo, every model artifact, every teleoperation session, and every sim-to-real pipeline as part of an in-scope information system that must satisfy the 110 controls of NIST SP 800-171 Revision 3 when Controlled Unclassified Information (CUI) touches the work. Petronella Technology Group built this guide for defense robotics teams, SBIR Phase II builders, and prime-contract suppliers who need to ship working hardware while keeping a clean audit trail under 32 CFR Part 170. The mistake most early teams make is scoping their dev environment as if it were a generic IT shop. It is not. Robotics development pipelines have ROS 2 transports, training-run logs, simulation seeds, and physical hardware that all need to be reasoned about as in-scope assets when CUI is in play.

Who Should Read This

This guide is written for three audiences. The first is the defense robotics team, often inside a prime contractor or a sub-tier supplier, that has been told it now needs to satisfy CMMC Level 2 before the next contract option year. The work is real. The robots exist. The CUI handling, on the other hand, has historically been informal: a research lead with admin on the lab Linux box, a graduate student with push rights to a shared GitHub organization, simulation scenes shared as zip files over corporate email. None of that survives a C3PAO assessment.

The second audience is the SBIR Phase II builder. You won the Phase I award, you produced a prototype, and the topic is going to expect a Phase II deliverable that includes CUI-tagged technical drawings, kinematics, or mission profiles. Government program managers are increasingly aware of CMMC posture during Phase II evaluation. Walking in with a clean System Security Plan and a believable Plan of Action and Milestones (POA&M) is now part of the bid posture, not just a contract clause to deal with later.

The third audience is the prime contractor evaluating a robotics development partner. You need to know which questions to ask a vendor that says it can do CMMC-aligned robotics work. There are real questions, and there are box-checking questions, and the difference matters when your own scoring is on the line through flow-down clauses in DFARS 252.204-7012. Reading this guide will give you both the architecture vocabulary and the checklist you need to evaluate a partner credibly.

An honest note on Petronella's position. We are a 23-year-old cybersecurity, compliance, and digital forensics firm headquartered in Raleigh, North Carolina, accredited as a CMMC-AB Registered Provider Organization (RPO #1449) with a verified record at the Cyber AB. Robotics development is a new practice area for us, anchored on a Reachy Mini in our Raleigh lab and our private NVIDIA Elite Partner Channel GPU fleet. We are not claiming a portfolio of completed CMMC-assessed robotics deliverables yet. What this guide presents is the application of well-trodden CMMC architecture patterns to the robotics development pipeline, drawing on our existing CMMC consulting work in adjacent fields. Read it as a methodology document grounded in published standards, not as a case-study writeup.

Background: What CMMC Levels 1, 2, and 3 Actually Require

The Cybersecurity Maturity Model Certification (CMMC) program, codified in 32 CFR Part 170 by the Department of Defense in October 2024, is the contractual mechanism that the DoD uses to verify that defense contractors and subcontractors are protecting information that flows down from federal contracts. The program defines three levels.

CMMC Level 1 applies to organizations that handle Federal Contract Information (FCI) but do not handle Controlled Unclassified Information (CUI). It maps to the 17 controls drawn from FAR clause 52.204-21 and is satisfied by an annual self-attestation. Most pure-play robotics development work outgrows Level 1 quickly because robotics deliverables to the DoD typically include CUI such as Specified Performance Requirements, technical drawings, mission profiles, or itemized capability claims that fall under the CUI category list maintained by the National Archives.

CMMC Level 2 applies to organizations handling CUI. It maps to the 110 controls of NIST SP 800-171 Revision 3, which the DoD has adopted as the working baseline. Most defense robotics development engagements live here. Level 2 splits into self-assessment and third-party (C3PAO) assessment, with the latter required for any contract where the contracting officer determines that CUI sensitivity warrants it. In practice, the DoD is moving toward C3PAO assessment as the default for any prime contract over a relatively low dollar threshold, and flow-down clauses ensure subcontractors generally need the same posture.

CMMC Level 3 applies to organizations handling CUI in the most critical national security programs and adds a subset of the controls from NIST SP 800-172 Update 1. NIST 800-172 was written specifically to address advanced persistent threat (APT) actors and includes controls focused on penetration-resistant architectures, damage-limiting operations, and resilience against an attacker who has already penetrated the perimeter. Level 3 is uncommon in early-stage robotics work but appears in defense humanoid programs, autonomous combat systems, and tactical robotics platforms where the threat model includes nation-state-level adversaries. Petronella consults at all three levels and considers Level 3 architecture work as part of a regular practice, not a special exception.

Why has robotics development historically been excluded from CMMC scoping conversations? Three reasons. First, the early CMMC dialogue centered on traditional IT environments, and robotics development looked like a research science problem to most compliance professionals. Second, robotics teams have often used unmanaged dev environments, like research-lab Linux boxes and shared GitHub organizations, that nobody had to defend in front of an auditor. Third, the boundaries between dev, test, sim, and field deployment were fuzzy in a way that ordinary IT scoping documents did not capture. None of those reasons survive contact with the current CMMC Final Rule. Once CUI is in play, the development pipeline that creates, tests, and packages CUI-bearing artifacts is in scope. The robots themselves, the simulation environments, the training-run artifacts, the teleoperation pipes, and the build chain that generates firmware are all in scope.

The DoD's DFARS 252.204-7012 clause underlies all of this. DFARS 7012 is the regulatory mechanism that flows CUI safeguarding obligations through the supply chain. When you sign a prime contract or a subcontract that includes 7012, you are committing to NIST 800-171 control implementation, to 72-hour cyber incident reporting through the DoD's DIBNet portal, and to flowing the same obligations to any of your subcontractors that handle CUI. The CMMC program is the verification layer on top of that contractual commitment.

For a robotics development team, the practical effect is this. If your contract or subcontract includes DFARS 7012 and CUI handling is realistic for the work, you owe the contracting officer a System Security Plan that describes how each of the 110 NIST 800-171 r3 controls is implemented inside your dev environment, your build environment, your test environment, your simulation stack, your hardware lab, and any teleoperation infrastructure. The artifact is not optional. The implementation is not optional. The audit is increasingly not optional.

Core Analysis: NIST 800-171 r3 Applied to the Robotics Development Pipeline

The next six sections walk through the NIST 800-171 r3 control families that most often surprise robotics teams during a first-time gap analysis. The framework counts 17 control families in total, but these six carry the bulk of the architectural impact on the robotics dev workflow. We treat each family with the same shape: what the family requires in plain language, the robotics-specific failure mode we see most often, and the minimum-viable architecture that satisfies the family for a CUI-handling robotics dev shop.

3.1 Access Control: Repo, Cluster, Hardware Lab

Access Control under 800-171 r3 requires the organization to limit information system access to authorized users, processes, and devices acting on behalf of authorized users; to enforce approved authorizations for logical access; to control the flow of CUI in accordance with approved authorizations; to separate the duties of individuals; and to employ the principle of least privilege.

The robotics-specific failure mode is the assumption that the lab Linux box is a personal machine. It is not. The lab GPU server, the workstation that runs the Reachy Mini SDK, the bench top with the simulation environment, and the development laptop that pushes to the firmware repo are all information systems if CUI ever transits any of them. The minimum-viable architecture treats every developer, every robotics engineer, and every visiting researcher as a uniquely identified principal, with role-based access control on the GitHub or self-hosted Git server, on the GPU cluster scheduler, on the simulation host, and on physical access to the hardware lab.

Concretely, a CUI-handling robotics dev environment we would design would have three repository tiers. Tier zero is open-source infrastructure code: ROS 2 packages, simulation glue code, generic utility libraries. This tier sits on a public Git host and can be cloned by anyone. Tier one is internal but not CUI: project-specific scaffolding, internal tooling, integration tests against simulation. This tier sits on an internal Git server with mandatory single sign-on and multi-factor authentication, accessible only to the project team. Tier two is CUI: any code, configuration, dataset, or model artifact derived from CUI inputs or specifying CUI-bearing capabilities. This tier sits on a hardened, audited Git server inside a CUI enclave with separate authentication, separate logging, encrypted storage, and a documented inbound and outbound flow control. Movement between tiers requires explicit review and a documented data-handling decision. The principle of least privilege means a developer needing tier-zero access does not automatically have tier-two access, and the burden of proof falls on the request, not on the policy.

The cluster side mirrors this. Training jobs that touch CUI inputs run on a separately scheduled queue with separate identity, separate logging, and separate output paths. Simulation runs that exercise CUI scenarios are similarly isolated. Hardware lab access requires badge-controlled entry with logged events, and the bench-top configuration that pairs to a Reachy Mini for a CUI-tagged demonstration uses a clean profile with no residual CUI from prior sessions.

3.3 Audit and Accountability: Training-Run and Teleop Logs

Audit and Accountability requires the organization to create and retain system audit records and reports to enable the monitoring, analysis, investigation, and reporting of unauthorized system activity; to ensure that the actions of individual system users can be uniquely traced; and to alert on inappropriate or unusual activity. In a normal IT shop, this means SSH session logs, sudo usage, file access, and so on. In a robotics dev shop, the audit surface is bigger and weirder.

The robotics-specific failure mode is treating training-run logs and simulation-run logs as research artifacts rather than audit artifacts. They are both. A training run that consumed a CUI-derived dataset and produced a model artifact creates an audit obligation: who launched the run, against which dataset hash, on which compute node, with which random seed, producing which checkpoint, signed by which key. The same applies to teleoperation sessions: who teleoperated the robot, from which workstation, against which CUI mission profile, with which session recording, retained for how long, and with which integrity protection.

The minimum-viable architecture extends standard cluster audit logging with three robotics-specific surfaces. First, every training run emits a structured manifest to an append-only log: run ID, dataset checksum, container image digest, code commit hash, hyperparameters, output checkpoint path and hash, signed by the cluster scheduler. Second, every teleoperation session captures a session manifest: operator identity, robot identity, mission profile reference, start and end timestamps, and the integrity-protected video and command-channel record. Third, every simulation run that serves as evidence (for example, a regression suite proving safe behavior under specified scenarios) emits the same kind of manifest. All three surfaces feed into the same SIEM or audit pipeline that the rest of the IT environment uses, and retention is at least three years for runs that touch CUI, longer if a contract specifies.

The non-obvious benefit of this discipline is operational, not just compliance. When a model regresses or a teleop session goes sideways, you have the manifests to reconstruct exactly what happened. Many robotics teams discover, after they implement audit-grade logging, that their reproducibility improves materially.

3.4 Configuration Management: Hardware, Firmware, and the Software Bill of Materials

Configuration Management requires the organization to establish and maintain baseline configurations and inventories of organizational systems, including hardware and software, to track configuration changes, and to enforce least-functionality settings. Robotics adds a wrinkle: the configuration surface includes physical hardware, firmware, and the open-source dependency tree of the software stack on top.

The robotics-specific failure mode is treating the robot itself as outside the configuration management envelope. The robot is in scope. A Reachy Mini paired to a Linux host runs firmware on the Raspberry Pi 4 (in the wireless variant), runs Python SDK code on the host, runs ROS 2 nodes on whatever bridges the team has built, and depends on a sprawling tree of open-source packages. A CMMC assessor will reasonably ask what version of each component is deployed, when it was last updated, who approved the update, and where the software bill of materials lives.

The minimum-viable architecture treats every robot, every host, and every cluster node as a managed configuration item. Hardware inventory includes serial numbers, firmware versions, last update dates, and the chain of custody from receipt through current deployment. Firmware updates are reviewed, tested in a non-production lab profile, and deployed through a documented change management process. The host operating system uses a baseline image with documented hardening; deviations are tracked. The Python and ROS 2 dependency trees are pinned, and a software bill of materials in CISA-aligned SBOM format is generated for every release artifact. Vulnerability scanning runs against the SBOM, not just against the binary.

For the Reachy Mini specifically, this means tracking the Python SDK version (the Pollen Robotics open-source SDK), tracking the LeRobot version (the Hugging Face open-source robotics library, with 12,000-plus stars at the April 2025 acquisition mark, growing rapidly since), tracking whatever ROS 2 bridge code we author, and tracking the host operating system separately. The Reachy Mini software stack is fully open source, which makes the SBOM tractable; what it does not do is excuse you from generating and maintaining one.

3.5 Identification and Authentication: Teleop Operators, Build Servers, Robots

Identification and Authentication requires unique identification of users, processes, and devices, and authentication of those identities before granting access. The robotics-specific failure mode is using shared accounts on the lab workstation, the simulation host, or the build server, and treating the robot as an unauthenticated peripheral.

The minimum-viable architecture identifies and authenticates four kinds of principals. Human users of the dev environment authenticate against the central identity provider with multi-factor authentication. Build servers and CI runners authenticate using short-lived workload identity tokens issued by the identity provider. Cluster nodes authenticate to the scheduler and to the storage layer using mutually authenticated TLS with rotating certificates. Robots authenticate to the network and to the control workstation using device certificates, with revocation procedures documented and tested.

Teleoperation deserves specific attention. A teleoperation session is, in essence, a remote control link between an authenticated operator workstation and an authenticated robot. The session establishes a mutually authenticated TLS or DTLS channel, the operator authenticates with multi-factor, the robot validates the operator's authorization for that mission profile, and the entire session is logged under both identities. If the robot is doing CUI-bearing work (rehearsing a CUI-tagged mission, manipulating a CUI-tagged object representation), the teleoperation channel is in CUI scope and inherits all of the CUI-handling obligations described in the rest of this guide.

3.13 System and Communications Protection: Hardening ROS 2 Transport

System and Communications Protection requires monitoring, controlling, and protecting communications at the external and key internal boundaries of the system, and employing architectural designs and configurations that promote effective information security. The robotics-specific failure mode is leaving ROS 2 transport in its default configuration on a network that touches CUI.

ROS 2 ships with a Data Distribution Service (DDS) transport that supports authentication, access control, and encryption through the DDS Security specification. The default profile, however, in many development setups is permissive, and many teams never enable the security profile because they run on an isolated lab network and the security profile is a nuisance during early development. That is fine for tier-zero work. It is not fine when CUI is in play.

The minimum-viable architecture turns on DDS Security for any deployment that crosses a CUI boundary. Each ROS 2 node has a unique identity and a signed identity certificate, the discovery process is authenticated, topic-level access control is enforced, and the wire is encrypted. Cross-machine ROS 2 traffic, which is common in a research environment with a teleoperation workstation talking to a robot and a logging server, all happens over a hardened DDS profile. Bridges between ROS 2 and other systems (for example, a bridge between a custom Python SDK node and the broader DDS network) are reviewed for whether they preserve or break the security profile.

Network architecture supports the same control. The CUI-handling segment of the lab is on a separate VLAN with documented ingress and egress rules. Outbound traffic from a CUI-handling robot or workstation does not transit the public internet without explicit, reviewed exception. Inbound remote teleoperation, if permitted, comes through an authenticated VPN or zero-trust access path. Wireless is treated as a hostile medium, which means CUI-bearing traffic does not ride the corporate Wi-Fi without a VPN tunnel inside it.

3.14 System and Information Integrity: Sim-to-Real Artifact Provenance

System and Information Integrity requires identifying, reporting, and correcting system flaws in a timely manner, providing protection from malicious code, monitoring system security alerts and advisories, and updating defenses. In a robotics dev shop, the most interesting application of this family is artifact provenance across the sim-to-real boundary.

The robotics-specific failure mode is shipping a model from simulation to a physical robot without a clear chain of custody for the model artifact. Sim-to-real transfer is one of the recurring technical patterns in robotics machine learning: a policy is trained in simulation against domain-randomized environments, then deployed to a real robot for fine-tuning or direct execution. If the simulation training environment touched CUI scenarios and the deployed model therefore carries CUI-derived knowledge, the artifact moving from sim to real is a CUI artifact and must be handled accordingly.

The minimum-viable architecture signs every model checkpoint with the keys of the cluster scheduler, records the training-run manifest, and requires a verified signature before a checkpoint can be loaded into the deployment pipeline. Deployment to the physical robot requires the same verification: the robot's control workstation refuses to load an unsigned or unverifiable checkpoint. Vulnerability scanning of the robot host extends to the inference runtime: PyTorch, ONNX Runtime, TensorRT, or whatever the team is using for inference, all need timely patching just like any other production software stack.

Malware protection on the robot host and on the cluster matters for a non-obvious reason. The robotics development pipeline pulls heavily from open-source ecosystems: LeRobot, the Pollen Robotics SDK, ROS 2 packages, simulation tools, dataset libraries. Every external pull is a supply-chain risk. The SBOM-and-scan discipline introduced in 3.4 carries forward here: each release is scanned against current vulnerability feeds before it ships to a robot, and runtime integrity tools watch for unexpected modifications to deployed binaries.

Petronella's Lens: How We Walk Into a CMMC Robotics Engagement

This section is a methodology block, not a case-study writeup. We have not yet shipped a CMMC-assessed robotics deliverable as a closed engagement. What we present here is the work product structure we use on adjacent CMMC engagements, applied to a robotics scope. When a defense robotics team brings us in, the engagement walks through three artifacts and one runbook.

The architecture document table of contents we use opens with a system boundary and asset inventory specific to robotics. We list the robots themselves, with serial numbers and firmware baselines. We list the dev environment hosts and the simulation hosts. We list the cluster nodes and the storage tiers. We list the teleoperation workstations and any remote-access paths. We list the build servers and the CI runners. We list the network segments and the Wi-Fi posture. We list the physical lab spaces and the badge-access logging. The boundary diagram shows where CUI may flow, where it stops, and where each network and identity boundary sits. The data flow section walks each CUI input through its lifecycle: where it enters, where it is stored, where it is processed, where it transits across boundaries, where its derivatives live (training datasets, model checkpoints, simulation traces, teleoperation recordings), and where each derivative ultimately disposes.

The security plan template structure follows the NIST 800-171 r3 control family ordering verbatim, with three parts per control: the requirement statement, the implementation description, and the evidence pointer. The implementation description is plain language: this is how the access control on the dev Git server works, this is how the cluster scheduler authenticates jobs, this is how the teleoperation channel is authenticated and encrypted. The evidence pointer is a path: a link to the configuration file in the audit-tracked configuration repository, a link to the policy document, a link to the runbook section, a link to the ticket where the change was reviewed. The structure is dull on purpose. A C3PAO assessor reading the document should never have to chase across systems to verify a claim.

The handoff runbook outline covers what an internal compliance lead or an incoming security operations team needs to know to keep the program running after the engagement closes. It includes the daily tasks, the weekly tasks, the monthly tasks, and the quarterly tasks. It includes the incident-response decision tree specific to robotics: what counts as a reportable cyber incident under DFARS 7012 when the artifact at issue is a model checkpoint or a teleoperation recording. It includes the escalation contact tree, the C3PAO assessment readiness calendar, and the change-management process for adding new robots, new datasets, new external collaborators, or new contract scopes to the environment.

Underneath these three artifacts sits the reusable evidence library that Petronella maintains across CMMC engagements. We do not start a CMMC robotics engagement from a blank page. We start with a templated set of policies, control narratives, and runbook sections that have been refined across more than two decades of cybersecurity and compliance consulting. The robotics-specific work is to overlay the platform realities onto that templated baseline and to author the robotics-specific control narratives that the generic baseline does not cover.

How to Scope a CMMC-Compliant Robotics Engagement

This is the decision framework we use when a defense robotics team asks where to start. Walk it in order. Skipping steps is the most common reason early engagements stall.

1. Confirm the contract or anticipated contract has DFARS 252.204-7012 and a CMMC Level 2 (or Level 3) requirement. Pull the contract clause list. Read each occurrence of 7012 carefully. Note any flow-down obligations to your subcontractors. If you are pre-bid, talk to the contracting officer or the prime contractor's compliance lead about expected scope.
2. Identify every CUI input and CUI-derived artifact in scope of the work. CUI categories that show up in defense robotics include Specified Performance Requirements, Privileged Information, Information Sharing Agreements material, and several technical drawing categories. Walk the project deliverables list and tag each artifact with its CUI status.
3. Map the in-scope information system around those artifacts. Every host, network segment, application, repository, dataset, model artifact, robot, and teleoperation path that touches a CUI artifact is in scope. The in-scope perimeter is broader than most teams initially expect.
4. Run a NIST 800-171 r3 gap analysis against the in-scope perimeter. All 110 controls. Mark each control implemented, partially implemented, or not implemented, with evidence. Treat partial as not implemented for planning purposes.
5. Author the System Security Plan and the Plan of Action and Milestones. Use the architecture and security-plan templates described above. The POA&M should have realistic dates and ownership for every gap.
6. Stand up the controls in priority order: identity and access first, audit logging second, configuration management third, communications protection fourth, integrity controls fifth. The other twelve families fold around these five. Avoid trying to land all 110 controls in parallel; the program will collapse under its own weight.
7. Schedule the C3PAO pre-assessment readiness review with at least 90 days of buffer before the formal C3PAO assessment. The pre-assessment will surface remaining gaps. Build the buffer in.
8. Document continuous monitoring and incident response procedures specific to robotics. The incident-response runbook for a robotics-bearing CUI environment differs from a pure-IT runbook because the assets and the failure modes differ.
9. Conduct the formal C3PAO assessment, remediate findings, and complete the assessment. Plan for at least one round of remediation between initial assessment and final certification.

Common Pitfalls and Honest Caveats

Dual-use export controls. Some robotics work, particularly in defense or autonomous systems, falls under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR) in addition to CMMC and DFARS 7012. ITAR scoping changes who can be in the room (United States persons only, in many cases), which complicates international collaboration on open-source robotics projects. Petronella works inside an ITAR-aware posture but is not an ITAR consultancy; complex export-control questions warrant a specialist export-control attorney in addition to the CMMC engagement.

Mixed CUI and non-CUI repositories. The hardest discipline to maintain is the segregation between CUI-tagged code and non-CUI code in a development environment that pulls heavily from open-source ecosystems. The temptation to mix is constant. The recovery cost when CUI leaks into a public repository is severe: reportable spillage, contract risk, potential debarment. The architectural discipline is to default every new repository to non-CUI tier and require an explicit, reviewed decision to elevate, never the reverse.

Contractor and employee identity boundaries. Many robotics development teams blend full-time employees, contractors, graduate-student researchers, and visiting collaborators. Each population has different background-check status, different access entitlement, and different legal relationships to the company. The identity provider must reflect those differences. Terminations, contract endings, and visiting-scholar departures are revocation events; testing those revocations on a regular cadence is part of the program.

Supply-chain risk in open hardware. Open-source hardware, including platforms like the Reachy Mini, comes with a different supply-chain story than closed hardware. The benefit is that the design is auditable. The cost is that the manufacturing and component-source provenance is whatever the open-source originator chose, which may or may not satisfy a defense-grade supply-chain risk management bar. We treat open hardware in CUI environments as needing the same SBOM, vulnerability tracking, and incoming-inspection discipline as closed hardware, with the additional benefit that we can inspect the design itself when needed.

Partial-application risk. CMMC Level 2 is not a buffet. You do not get partial credit for landing 90 of the 110 controls cleanly. The C3PAO assessment is binary on each control, and the program-level outcome depends on the full set. Teams that try to optimize for the controls they think auditors will look at, while neglecting the others, generally pay for that optimization later.

The novelty disclosure. Petronella's robotics development practice is new. The cybersecurity, compliance, and CMMC consulting practice underneath it is not: 23 years of operational work, RPO #1449 on the Cyber AB roster, and a team of CMMC-RPs. We are upfront about that distinction with every prospective client. The CMMC architecture in this guide is well-trodden across our consulting engagements; what is new is the application to a robotics-specific platform.

Frequently Asked Questions

Does CMMC Level 2 require a C3PAO assessment for robotics development work?

For most defense robotics development work that touches Controlled Unclassified Information, yes. The CMMC Final Rule (32 CFR Part 170) sets the framework, and the contracting officer determines on a per-contract basis whether self-assessment or C3PAO assessment applies at Level 2. The DoD's stated direction is toward C3PAO assessment for prime contracts that involve CUI, with flow-down to subcontractors. Teams should plan for C3PAO assessment as the default and treat self-assessment as an exception only when a specific contract's terms permit it.

How long does a CMMC Level 2 readiness program typically take for a robotics dev shop?

Six to twelve months from contract signature is a realistic working range for an organization that does not already have a NIST 800-171 baseline. Teams with mature IT compliance practices but new robotics scopes often run on the shorter end because the architectural patterns are familiar, and the work is to extend them to robotics-specific assets. Teams that are starting cold often run on the longer end and benefit from a phased approach that lands identity, access control, and audit logging early so that the rest of the program has a foundation to build on.

Can we use cloud GPUs for robotics training under CMMC Level 2?

Cloud GPU usage for CUI-bearing robotics training requires a FedRAMP Moderate (or High) baseline cloud service, configured and used in a way that satisfies the relevant 800-171 r3 controls. Several major cloud providers offer FedRAMP-authorized GPU services. The architectural challenge is that the dataset, the training pipeline, the model artifacts, and the supporting tooling all need to live inside the FedRAMP boundary, and the boundary needs to be auditable end-to-end. Petronella's default recommendation for sovereignty-sensitive robotics work is on-premises GPU compute on the client's own NVIDIA Elite Partner Channel hardware, both for compliance simplicity and for data-sovereignty reasons. Hybrid architectures are workable when business requirements demand them, but they add audit complexity.

Is the Reachy Mini a CMMC-compliant robot?

A robot, on its own, is not CMMC-compliant or CMMC-noncompliant. CMMC compliance attaches to the organization and its information system, not to a hardware platform. The Reachy Mini, as an open-source desktop humanoid platform, can be deployed inside a CMMC-Level-2-compliant information system if the organization implements the relevant access control, audit, configuration management, identification and authentication, communications protection, and integrity controls around it. The fact that the Reachy Mini software stack is fully open source actually helps the SBOM and configuration management work, because the dependency tree is auditable. Petronella operates a Reachy Mini in our Raleigh lab as part of our research into robotics development practices.

Do open-source robotics dependencies need to be tracked in a Software Bill of Materials?

Yes, when the resulting software ships into a CUI environment. The CISA-aligned SBOM practice covers all dependencies regardless of license, and open-source dependencies are typically the dominant component of the dependency tree for a robotics development project. ROS 2, LeRobot, the Pollen Robotics SDK, simulation libraries, and the broader Python ecosystem all show up in the SBOM. Vulnerability scanning runs against the SBOM, and patching practice is governed by the configuration management plan.

What about CMMC Level 3 for autonomous combat platforms?

CMMC Level 3 layers a subset of NIST SP 800-172 enhanced controls on top of the Level 2 baseline and applies to organizations handling CUI in the most critical national security programs. For autonomous combat or weapons-adjacent platforms, Level 3 is increasingly the working assumption. Petronella consults at all three CMMC levels and treats Level 3 architecture work as a regular practice. We are explicit that Petronella does not build weapons systems or combat-platform integration ourselves; we deliver the cybersecurity, compliance, and development practice underneath teams that do.

How do we get started with a CMMC-aligned robotics development engagement at Petronella?

Call (919) 348-4912 or use the contact form to schedule an initial scoping conversation with our compliance team. The first conversation is free and covers your contract scope, your CUI handling, the current state of your dev environment, and a rough sizing of the readiness work. From there, we propose a phased engagement: scoping and gap analysis first, then architecture and policy authoring, then control implementation and runbook handoff. Engagements are billed on a custom-quote basis, and we match the team to the level (Level 1, Level 2, or Level 3) appropriate to your contract. See the CMMC compliance pillar for our full practice description.

Where can I learn more about Petronella's robotics practice and the Reachy Mini in your Raleigh lab?

The robotics overview walks through our practice, and the related pages cover specifics: the robotics prototyping engagement, the defense robotics industry posture, and the Reachy Mini specifications. For the broader cybersecurity foundation underneath the robotics practice, see cybersecurity services and private AI solutions.

About the Author

This guide was authored by Craig Petronella, founder of Petronella Technology Group (Raleigh, NC, founded 2002). Craig holds the CMMC Registered Practitioner credential issued by the Cyber AB, is an NC Licensed Digital Forensics Examiner (DFE #604180, listed on the NC Office of Indigent Defense Services registry), holds CCNA and CWNE network certifications, and is a CMMC-RP on a team of CMMC-RPs. Petronella Technology Group is a CMMC-AB Registered Provider Organization, RPO #1449 verified at the Cyber AB, BBB A+ since 2003, headquartered at 5540 Centerview Dr., Suite 200, Raleigh, NC 27606. Craig contributes the cybersecurity column at Attorney at Law Magazine and has authored cybersecurity titles available on Amazon. Connect on LinkedIn.

Last updated: 2026-05-02. This article is educational and reflects the application of NIST SP 800-171 r3 and the CMMC Final Rule (32 CFR Part 170) to robotics development environments as of the publication date. Specific control language, assessment procedures, and CUI category determinations are governed by the contract, by the contracting officer, and by the assessor of record. Confirm current requirements against the published standards and your legal and compliance counsel before acting on any guidance in this guide.

Cited references:

• NIST SP 800-171 Revision 3, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
• NIST SP 800-172 Update 1, Enhanced Security Requirements for Protecting CUI
• CMMC Final Rule, 32 CFR Part 170, Federal Register, 2024-10-15
• DFARS 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting
• CISA Software Bill of Materials (SBOM) practice
• Cyber AB, the CMMC accreditation body
• Petronella Technology Group, RPO #1449 verification at the Cyber AB

Petronella Robotics / Lead

Get the Secure Robotics Development Brief

Tell Petronella Technology Group about your robotics project. We will reply within 4 business hours with a CMMC-RP led scoping conversation and the early-access edition of our Secure Robotics Development Brief covering CUI handling, on-prem AI inference for robotics, and CMMC-aligned development practices. No obligation. No sales pressure.

Name * Work Email * Organization Use Case Defense / DIB / SBIR Research University Lab Healthcare / Biomedical Research Manufacturing / Industrial R&D Other / Exploring Phone

Get the Robotics Brief →

CMMC-RP team. We reply within 4 business hours. Privacy policy. Or call (919) 348-4912.

Call (919) 348-4912 Full Contact Page