Secure, sovereign robotics built inside your compliance boundary

Custom robotics development is the engineering practice of taking a real-world task that a human, a fixed-function machine, or no automation currently performs and producing a robotic system that performs it well enough to evaluate, deploy, or scale. It spans hardware selection, mechanical adaptation, sensor integration, perception software, motion planning, learned policies, teleoperation surfaces, simulation, safety analysis, and the operational documentation that lets the system survive the handoff to an operating team. It is not a product purchase. It is a project.

The label "robotics" gets stretched in the market to cover everything from fixed industrial cobots to autonomous vehicles to surgical platforms to humanoid demos. To be useful, the practice has to be scoped. Petronella's robotics practice deliberately stays inside prototyping, research-and-development, and demonstration builds for organizations whose data is regulated. We do not ship industrial cobot integration as a turnkey deliverable, autonomous vehicles, surgical robotics, weapons platforms, or humanoid manufacturing. Inside the lane we do operate, the work is a custom build, not a configured purchase, and the cybersecurity overlay is built in on day one rather than bolted on at the end.

Why this is the right way to frame it

Off-the-shelf robotics products are designed for the broadest customer cross-section the vendor can find. Their data, integration, network, and security assumptions all default to "internet-connected, cloud-backed, vendor-telemetered." That default is fine for an unregulated commercial deployment. It is wrong, on day one, for a Controlled Unclassified Information workload, a HIPAA-covered research project, or any IP-sensitive engineering build. The cheapest way to use a regulated dataset with a vendor's default product is usually not to use the product at all, because the moment the product phones home with a sample of the input, the regulated boundary has been crossed.

Custom development re-asserts the boundary. The hardware platform may still be a vendor product (Reachy Mini, an open-hardware arm, an off-the-shelf manipulator); the software, the data plane, the model weights, and the operational posture are built around the boundary, not against it. That is what "sovereign robotics" means in practice, and it is what this pillar describes how to do.

The taxonomy a buyer should know

When a procurement team or research PI starts scoping a robotics build, the first useful step is a clear taxonomy of what they are buying. Three categories cover most of what we are asked about:

• Fixed-function robotic systems. A catalog cobot or industrial arm running a configured program for a known task. Off-the-shelf, low custom engineering, deployed by an integrator. This is not what custom robotics development is for.
• Application-specific custom builds. A robot platform combined with custom perception, custom control, custom interfaces, and custom data pipelines for a task no off-the-shelf product solves. This is the bulk of what serious R&D and prototyping engagements look like, and it is where Petronella plays.
• Foundational research. Robotics work whose purpose is to extend the field, produce papers, train models, or generate datasets. Our role here is implementation partner to a research lab or PI, not principal investigator. Our compliance and infrastructure foundation is the value-add.

A custom robotics development engagement is several streams of work that converge: a hardware stream (platform selection, mounts, end-effectors, sensors, power, networking), a software stream (perception, control, behavior code, simulation, evaluation), a data stream (teleoperation captures, learning datasets, policy weights, evaluation sets), a security and compliance stream (audit logging, access control, secrets handling, data residency), and an operations stream (runbook, on-call posture, documentation, handoff). Underspecify any one stream and the prototype either does not run, does not pass review, or does not survive the first staff change.

ROS 2 replaced the original ROS with a Data Distribution Service (DDS) transport, a tier-1 design goal of security, and a real-time-friendly architecture. The security work product is SROS 2 (Secure ROS 2), which layers DDS-Security on top of the default transport to provide authentication, access control, encryption, and audit logging between ROS nodes. The reference is the ROS 2 DDS-Security design article and the ros2security tutorial. None of that ships on by default. A ROS 2 prototype built with the documentation's quick-start commands is unauthenticated, unencrypted, and trivially intercepted on any network it shares.

That is the threat surface most ROS 2 robotics codebases ship with. The published academic literature on ROS security (the original Alias Robotics audits, the work by McClean and Stavrou, and the ongoing Robot Vulnerability Database) catalogs the resulting failure modes. The same failure modes show up across prototypes that were never meant to be public-facing but ended up on a network reachable from a corporate VLAN.

How we harden a ROS 2 build

For every ROS 2 prototype we deliver, the default development environment ships with SROS 2 configured against a project-specific certificate authority, DDS-Security access-control governance and permissions files generated from a policy template, ros2 launch files that refuse to start in permissive mode, and a CI step that re-validates the security configuration on every commit. That is not "we wrote a hardening doc." That is the build template the engagement starts from, derived from the published ROS 2 security tutorials and bounded by the relevant compliance frame (CMMC L2, HIPAA Security Rule, or the institution's research-data policy).

If the build calls for a non-ROS stack (a LeRobot-only prototype talking directly to a Reachy Mini, a custom DDS-free message bus, a serial-over-USB control loop for a Koch arm), the equivalent threat model still gets written down and the equivalent hardening still ships. The point is not "we use SROS 2 everywhere." The point is that the security overlay is part of the build deliverable, not a deferred ticket.

The Cybersecurity and Infrastructure Security Agency (CISA) and the Department of Commerce have been steadily formalizing supply-chain expectations for cyber-physical systems. Their ICT Supply Chain Security guidance is the federal anchor; on the technical side, the CISA SBOM program sets the expectation that any software dependency in a regulated system has a machine-readable bill of materials. For robotics, the same expectations apply to firmware, FPGA bitstreams, and model weights.

Four supply chains to keep visible

• Silicon and compute. The Jetson, the onboard Pi, the GPU on the training rig. We source NVIDIA hardware through the NVIDIA Elite Partner Channel, document the procurement chain, and avoid grey-market resellers whose units may have had unknown firmware exposure.
• Sensors. Cameras, lidars, IMUs, force-torque sensors, and microphones each carry their own firmware, sometimes their own cloud-callout default. Every sensor in a build gets a firmware review and a "disable telemetry" pass before it goes into a regulated dataset capture.
• Mechanical and electromechanical assemblies. Motors, servos, gearboxes, end-effectors. The risk is less malicious and more about country-of-origin for export-controlled programs, plus traceable lot numbers for safety-relevant components.
• Software and weights. The ROS 2 package set, the LeRobot library, the Python dependency tree, container base images, and policy weights. Every external dependency lands in the project SBOM with a license and a version pin. Weight files are treated as binary artifacts and signed.

For Defense Industrial Base work, this is non-optional

For DIB builds, the NIST SP 800-161 r1 supply-chain risk management practices are the binding reference, and the relevant CMMC L2 controls in the 800-171 r3 family cover supply-chain provenance, vendor risk, and software integrity. The robotics build inherits all of it. We do not treat the BOM as a project-management spreadsheet. It is an audit artifact.

The opt-in / opt-out questions to ask every vendor

For every component a build pulls in, the procurement-and-security checklist is the same short set of questions: Does this device or library phone home by default, and to where? What is the upgrade and signing model? What is the country-of-origin and the export-control status? What is the patch cadence and the end-of-support horizon? If the vendor goes out of business or is acquired, who controls the update path? Those questions are routine in mature IT supply-chain reviews and routinely skipped in robotics builds because the buyer thinks of the robot as one thing rather than a stack. The discovery phase output (described later) is partly there to surface those answers in writing.

Anyone who has tried to land a research robot on a university IT network, or stand up a DIB prototype inside a corporate environment that already runs SCADA and PLC infrastructure, has hit the OT/IT seam. The corporate IT side wants identity, mobile device management, endpoint detection, and centralized logging. The OT side wants the robot to keep running, no agents, no surprise reboots, no Windows Updates at 3am, and ideally no internet access at all. Both sides are right. The job is to build the seam so both can hold.

NIST SP 800-82 r3 is the canonical reference

For any robotics build that touches an industrial environment, the canonical reference is NIST SP 800-82 Revision 3, Guide to Operational Technology (OT) Security. Published in September 2023, 316 pages, the OT-specific overlay to NIST 800-53 controls, with explicit guidance on network segmentation, remote access, supply chain, and the recovery-time-objective conversation that OT engineers actually have. For DIB robotics work, the 800-82 r3 controls map alongside 800-171 r3 (CMMC L2) and 800-172 (CMMC L3) for the controlled-data side.

The seven seam questions worth answering on day one

• Network placement. Which VLAN does the robot live on? Does it have its own segment with a one-way data diode to the corporate IT side, or a stateful firewall, or a flat-network exception?
• Identity. Does the robot authenticate against the corporate directory, a project-local identity provider, or a static credential set? Where do operator credentials rotate?
• Patching and update path. Who applies operating-system patches, ROS package updates, model weight updates, and firmware updates? On what cadence? With what test window?
• Remote access. How does an off-site engineer reach the robot for maintenance? Bastion host, jump server, vendor-portal VPN, or some combination? Logged and reviewed?
• Monitoring. Does the robot ship telemetry to the corporate SIEM, to a project-local logging stack, or both? Who reads the alerts?
• Backup and recovery. What is the recovery posture for the operating system, the ROS workspace, the trained model, and the captured datasets? Where do snapshots live?
• Decommissioning. When the robot is retired, what happens to the captured datasets, the model weights, the SSDs, and the embedded credentials? The end-of-life plan is part of the build.

None of those questions is robotics-specific. All of them are routine in mature OT and IT environments. What is missing in most robotics deployments is that the answers were never written down because the robot was treated as a research toy rather than a deployed asset. Petronella's job on the seam is to write those answers down inside the existing OT and IT governance, in the language those teams already use.

Petronella has been a Raleigh, NC cybersecurity practice since 2002. The firm holds CMMC-AB Registered Provider Organization #1449, an A+ BBB rating since 2003, and operates a private AI cluster from our facility for regulated workloads.

When we started the robotics practice, the cybersecurity, compliance, and infrastructure substrate was already there. Robotics is a new application of a 23-year-old foundation, not a new firm. That ordering matters because most custom robotics development firms approach security and compliance as an afterthought. They build a working prototype, then bolt on the audit story when the client's compliance officer reviews the engagement. We do the inverse. We assume the engagement is regulated until proven otherwise, sign the appropriate engagement letter (CMMC-aligned, HIPAA business associate agreement, or research data use agreement) before any controlled data enters scope, and design the development environment around the data class on day one.

What "cyber-first" means in practice

It means we do not build a robotics prototype on a developer laptop that is also reading personal email. The development environment runs on hardware we operate, with audit logging on by default, access scoped to named identities, secrets managed in a vault rather than committed to a repository, and a software bill of materials produced for every external dependency the build pulls in. That is not robotics-specific. It is what cybersecurity practice looks like applied to a robotics codebase. The penetration testing pillar describes the testing posture we apply to any prototype before it leaves the lab; the incident response pillar describes what happens if a deployed prototype is implicated in an active event.

What "compliance-first" means in practice

It means before we write a line of perception code that has to read sensor data from a regulated source, the data flow has been mapped against the relevant compliance frame:

• Defense Industrial Base work: NIST SP 800-171 r3 and the CMMC Final Rule, with appropriate DFARS 252.204-7012 handling for any covered defense information that surfaces. ITAR-controlled programs add an additional export-control overlay we work to alongside the prime's empowered official.
• Research-university work that touches human subjects: the Common Rule and the institution's IRB.
• Healthcare R&D that touches PHI: the HIPAA Security Rule.
• Industrial deployments: NIST SP 800-82 r3 (above) plus the relevant sector overlay (FDA Part 11 for life sciences research, IEC 62443 for industrial control adjacency).

These are not obstacles to robotics work. They are the boundary inside which the work has to happen.

Sovereignty as the default deployment posture

The third piece of our approach is data sovereignty. Robotics builds today are LLM-adjacent, vision-model-adjacent, and dataset-adjacent in a way they were not five years ago. A learned manipulation policy is trained on a dataset, fine-tuned on the client's own captures, and run on inference hardware. If any of those steps quietly route through a public AI vendor, the regulated data class has just left the boundary. Petronella's robotics builds default to running on our private GPU fleet, sourced through the NVIDIA Elite Partner Channel, or on hardware we operate inside the client's facility. Public-cloud AI APIs are not in the default path. They are an opt-in for non-regulated workloads only.

For a deeper read on how the private-AI substrate works, see our private AI solutions pillar. The robotics practice is what happens when you point that substrate at a robot.

Reachy Mini, in our Raleigh lab

Petronella operates a Reachy Mini in our Raleigh, NC lab. Reachy Mini is the open-source desktop expressive humanoid built by Pollen Robotics (acquired by Hugging Face in April 2025) and launched in July 2025. The unit is 28 cm tall when active, 1.5 kg, with a 6-DOF head, full body rotation, 4 microphones, a wide-angle camera, a 5W speaker, and animated antennas. Reachy Mini ships in two variants: the $299 Reachy Mini Lite, which pairs to a Mac or Linux host, and the $449 Reachy Mini Wireless, which carries an onboard Raspberry Pi 4, Wi-Fi, and a battery.

Pricing and specifications are sourced from the Hugging Face Reachy Mini launch announcement and verified against the Pollen Robotics organization on Hugging Face Hub. The Reachy Mini is open-source on the software side and Pollen has stated CAD files for the hardware are pending release. The Python SDK is published at github.com/pollen-robotics/reachy_mini and the platform integrates with the Hugging Face LeRobot stack and the broader Hugging Face Spaces ecosystem of robot behaviors. The default privacy posture is documented by Hugging Face: "no personal data stored, transmitted, or processed by default; camera and microphone use fully user-controlled." That posture aligns with the regulated-deployment frame the regulated buyers we serve work inside.

Why the Reachy Mini is the right anchor platform

For a custom robotics prototyping practice, the platform anchor matters. The Reachy Mini was chosen for four reasons. First, it is open-source, which means the code, the platform integration patterns, and the underlying community work are accessible without a vendor approval cycle. Second, it sits on the LeRobot stack, which lets a Reachy Mini prototype reuse models, datasets, and tooling that work on a wide set of supported platforms (the LeRobot documentation lists SO-101, SO-100, Koch v1.1, LeKiwi, Hope Jr, Reachy 2, Unitree G1, Earth Rover Mini, OMX, OpenArm, Aloha, ViperX). Third, the price point ($299 to $449 per unit) makes fleet experimentation tractable for prototyping. Fourth, the platform's expressive form factor is well-suited to conversational AI, perception research, teleoperation studies, and human-robot-interaction pilots, which are the categories of prototyping our regulated clients ask about.

Private GPU fleet

The training and inference side of our robotics practice runs on a private GPU fleet operated from our Raleigh datacenter. The fleet is a mix of NVIDIA DGX, HGX, and RTX PRO systems sourced through the NVIDIA Elite Partner Channel. The same fleet underwrites our private AI cluster and is sized for regulated mid-market workloads: large enough to host meaningful LeRobot policies, vision-language-action models, and simulation runs, small enough to preserve the per-customer attention that hyperscaler help desks cannot offer. For workloads that exceed our cluster's local capacity, we deploy and operate dedicated GPU hardware in the client's colocation facility or on-premises rack under the same operations model. See our AI workstation hardware page for the underlying systems specification.

What we explicitly do not run on

For regulated robotics builds, we do not route training, fine-tuning, or inference through a public-cloud AI API by default. The default path is local hardware. Public-cloud AI is an opt-in for non-regulated workloads, with an explicit data-flow approval. The same posture applies to the perception side: we do not push client camera feeds through a third-party hosted perception service unless the client's compliance officer has explicitly approved the data flow. This is why "private GPU fleet" is the operative phrase, not "we use the cloud."

How the hardware combines into a build

A typical regulated prototype combines a Reachy Mini (or, for builds that need locomotion or arm dexterity, a different LeRobot-supported platform sourced for the project) with a perception and policy stack running on the private GPU fleet. The Reachy Mini Wireless variant runs onboard inference for low-latency expressive behaviors via its Raspberry Pi 4. Heavy training, fine-tuning, simulation, and large-scale evaluation runs land on the GPU fleet. The teleoperation interface, dataset capture, and policy-evaluation harness all run inside the client's compliance boundary. That topology is what "sovereign robotics prototyping" looks like in practice.

What the LeRobot stack gives us, concretely

The Hugging Face LeRobot stack is more than a library; it is a working set of models, datasets, hardware integrations, and evaluation harnesses that lets a small team produce a useful prototype in weeks rather than quarters. The publicly documented hardware support list spans SO-101, SO-100, Koch v1.1, LeKiwi, Hope Jr, Reachy 2, Unitree G1, Earth Rover Mini, OMX, OpenArm, Aloha, and ViperX, with camera support for OpenCV USB and built-in cameras, ZMQ network cameras, Intel RealSense depth cameras, and Reachy 2 cameras. For a prototyping practice, the practical effect is that a client's specific hardware ask rarely lands outside the supported set, which means time on the build phase goes into the client-specific work (perception, policy, integration, security overlay) rather than into porting to a non-standard platform. When the client's preferred platform does fall outside the supported set, that is a Phase 1 finding worth surfacing before the build phase commits.

The Petronella robotics practice is organized around three layers: a hardware spoke that documents the platform we operate, a solutions spoke that documents the engagement model, and a set of industries spokes that document how the practice maps to defense, research-university, healthcare-research, and industrial contexts. Every spoke links back here; this pillar links down to all of them. Use whichever entry point matches how you are evaluating us.

Defense and the Defense Industrial Base (cleared work, ITAR-aware framing)

Defense robotics work for prime contractors, sub-tier suppliers, and SBIR/STTR-funded programs is the natural home for our practice. The work is custom by definition, the data class is CUI by default, and the compliance frame is the CMMC Final Rule, NIST SP 800-171 r3, and DFARS 252.204-7012. Our CMMC-AB RPO #1449 standing means the engagement letter is written by people who write engagement letters for a living, not adapted from a generic master services template at the last minute.

For programs with ITAR or EAR export-control exposure, our standard posture is to work to the prime contractor's or research institution's empowered official under their established Technology Control Plan. We do not assert ITAR authority unilaterally; the empowered official is the authority, and our role is to keep the engineering inside the boundary they define. For cleared programs that require facility clearance or personnel clearance, we collaborate as a non-cleared partner inside the unclassified boundary the prime has authority to extend; classified-tier work happens inside the prime's cleared facility, not ours. Typical work in this lane includes:

• Perception prototypes for defense logistics
• Teleoperation interfaces for stand-off applications
• Dataset curation pipelines for ML-driven defense AI
• Demonstration builds for program-of-record evaluation
• Secure ROS 2 hardening for an existing prototype that needs to move into a regulated environment

We do not do weapons platforms, autonomous combat systems, or anything that conflicts with the practice's documented exclusions. See the defense robotics page for the full scope.

Research universities and federally funded labs

Research universities with NSF Foundational Research in Robotics, NSF AI Institute, NIH BRAIN Initiative, or DARPA-funded grants need a robotics implementation partner who can move at the pace of grant timelines. The partner has to integrate with the lab's existing ROS 2 codebase, work alongside graduate students without becoming the bottleneck, and respect the institution's IRB and research-data-management policies. We come from the cybersecurity side, which is unusual in the robotics-services space, and that turns out to matter for cyber-physical research where the lab's own data security posture is part of the grant deliverables. See the research university robotics page for the full scope.

Healthcare research and academic medical centers (FDA + HIPAA)

Healthcare research robotics is a deliberately narrow lane for us. We do not build FDA-regulated Software as a Medical Device, surgical robotics, or any clinical-decision-support system that requires regulatory premarket review. We do support healthcare R&D groups, academic medical center engineering teams, and rehabilitation-research labs that need a robotics implementation partner who already speaks HIPAA, already understands the Common Rule and IRB process, and can build a perception or interaction prototype on infrastructure that does not push PHI through a public-cloud AI vendor.

For research environments that occasionally generate FDA Part 11 records (electronic signatures, audit-trail integrity for research data), we work to the institution's Part 11 posture, the same way we work to a DIB prime's empowered official for ITAR. The exclusions are explicit on the healthcare research robotics page; the inclusions are equally explicit.

Industrial robotics (NIST SP 800-82 r3 framework)

Industrial robotics deployments (manufacturing R&D, research-and-development pilots inside an operating plant, autonomous mobile robot trials inside a warehouse environment) live where OT and IT cross. Our role here is not turnkey cobot integration; it is the cybersecurity and compliance overlay that lets an industrial robotics pilot survive a security review and a plant-engineering safety review at the same time. We design the network placement, identity, monitoring, and decommissioning posture against NIST SP 800-82 r3 and the relevant sector overlays. For sites that operate Purdue-Model-segmented OT networks, we work inside the existing zone and conduit design, not against it. For sites whose OT side is still flat, the engagement output usually includes a recommended segmentation plan as a deliverable.

Verticals we deliberately do not serve

Industrial cobot integration on a factory floor as a turnkey deployment, autonomous vehicles for on-road deployment, surgical robotics, defense weapons platforms, humanoid manufacturing at scale, and consumer robotics products are all out of scope. Several of those are fine markets; they are not our markets. Stating the lane sharply lets the firms that should pick us actually pick us, and lets the firms that need a different practice find it without a wasted call.

Where the rest of the Petronella stack lives

The robotics practice rides on top of pillars we have been operating since 2002. Defense robotics builds inherit our CMMC 2.0 readiness program and the supporting compliance framework hub. Healthcare-research builds inherit the HIPAA compliance pillar. Every prototype runs against our private AI services on the same GPU hardware we deploy for clients. Pre-deployment security validation is run by our penetration testing practice. If a build hits an active incident, our incident response team and our digital forensics group are in the same building.

1. Phase 1 - Discovery and scoping. A two-to-three-week engagement to convert a task description into a written scope. We map the data flows, the regulatory frame, the success criteria, the integration surfaces, and the production constraints. Output: a written scope, a candidate platform shortlist, an evaluation harness sketch, and a go or no-go recommendation. The point of Phase 1 is to retire risk before either party signs a build contract. Roughly half of discovery engagements result in a recommendation that is something other than "build this." That is a feature, not a bug.
2. Phase 2 - Architecture and prototype. A four-to-eight-week sprint that produces a working robotics prototype on the agreed platform, with the perception, control, learned policy, and integration plumbing scaffolded. The prototype runs against a small, real evaluation set. We instrument the run with telemetry from day one. Output: a working demo, a code repository under your account or ours per the agreement, an evaluation report against the agreed criteria, and a written architecture document that the team can read after the engagement.
3. Phase 3 - Hardening and compliance overlay. A two-to-six-week phase that turns the prototype into something that can survive a real review. This is where the security overlay lands properly: SROS 2 configuration where ROS 2 is in scope, secrets management, audit logging, access scoping, software-bill-of-materials production for every external dependency, threat model documentation, and penetration-test-equivalent review against the deployed prototype. The compliance frame (CMMC L2 controls, HIPAA Security Rule controls, NIST 800-82 r3 overlays, IRB documentation) is mapped onto the build with evidence artifacts. Output: a hardened prototype, the compliance artifacts, the runbook, and a written go-or-no-go for the production decision.
4. Phase 4 - Handoff and operations. A two-to-four-week phase that hands the work to your team or to a Petronella managed engagement, depending on where you want to land. We document the operational posture, train the receiving team on the runbook, fix the things that surface in the first week of use, and define the on-call boundary going forward. Output: a stable operational footprint with a clear ownership model. We do not "throw it over the wall." If you want us to keep operating it under managed engagement, we do; if you want it to live entirely inside your team, it does. The choice is yours.

Phase gates, not phase suggestions

The boundary between phases is a written go-or-no-go, signed by both sides, that points at the deliverable produced in the previous phase. A phase that does not produce its deliverable does not graduate to the next phase. That sounds bureaucratic on the page; in practice it is what stops a build from drifting into the "scope creep until the budget runs out" pattern that kills most regulated prototyping engagements. Each phase gate is also where the client's procurement, legal, security, and program teams have a concrete artifact to review (a written scope, a working demo plus architecture document, a hardened prototype plus compliance evidence pack, an operational runbook) rather than an in-flight build that nobody outside the room can evaluate. We set the gate language in the master engagement letter on day one, so the cancellation right and the cost ceiling per phase are bilateral and explicit. That is what makes the methodology safe to run inside a regulator-watched program.

Why four phases rather than two

The honest answer is that "scope it and build it" engagements consistently underdeliver in regulated robotics work. The compliance overlay is not optional, the handoff is not optional, and treating both as side effects of the build phase is how a working prototype turns into an unreviewable artifact that nobody can operate. Splitting the engagement into four phases lets each phase succeed or be cancelled on its own merits, lets the client's procurement team write a smaller initial commitment, and lets us produce a written deliverable per phase that survives staff turnover. The four-phase pattern is what we run on private-AI engagements as well; the methodology is shared because the discipline is shared.

CMMC Levels 1, 2, and 3

For Defense Industrial Base work, the relevant frame is the CMMC Final Rule (32 CFR Part 170). CMMC L1 governs Federal Contract Information (FCI) handling at the FAR 52.204-21 baseline, applicable to the majority of DIB suppliers. CMMC L2 maps to NIST SP 800-171 r3 and applies to most CUI-handling work. CMMC L3 raises the bar to NIST SP 800-172 protections and applies to a smaller cohort of high-priority programs. Petronella consults at all three levels. For robotics builds in this lane, we treat the development environment, the dataset stores, the GPU fleet, and the prototype itself as in-scope assets, mapped to the relevant control families on day one. See the CMMC compliance pillar for our full compliance methodology.

NIST SP 800-171 r3 and DFARS 252.204-7012

Defense robotics work that touches CUI is governed by NIST SP 800-171 r3 (the CMMC L2 baseline) and DFARS 252.204-7012, which mandates safeguarding covered defense information and 72-hour cyber incident reporting. We map robotics-specific data flows (sensor captures, teleoperation logs, training datasets, policy weights, evaluation artifacts) to the 800-171 control set during Phase 1 discovery and produce the System Security Plan section that covers the prototype as part of Phase 3 hardening.

NIST SP 800-82 r3 (OT security)

For industrial robotics deployments and any prototype that crosses into operational technology, NIST SP 800-82 r3 is the overlay we map against. The OT-specific controls cover network segmentation, remote access, supply chain, recovery-time-objective conversations, and Purdue-zone placement decisions that a general 800-171 mapping does not, by itself, surface. The two frameworks are designed to be applied together and we apply them together.

HIPAA Security Rule

For healthcare research robotics, the frame is the HIPAA Security Rule. We sign the appropriate Business Associate Agreement before any PHI enters scope. The development environment, the dataset stores, and the inference path are inside the BAA boundary. The Reachy Mini's documented default privacy posture (no personal data stored, transmitted, or processed by default; camera and microphone use fully user-controlled, per Hugging Face) is an additional layer; the operational layer is what we add.

Common Rule and IRB

For research-university and academic-medical-center work involving human subjects, we operate inside the institution's IRB process under the Common Rule (45 CFR 46). The IRB is the PI's; we are the implementation partner. Our role is to keep the data flows and consent posture documented and auditable in a way the IRB will accept.

NIST SSDF, SBOM discipline, and NIST 800-161 supply chain

For every robotics codebase we produce, we map the build to NIST SP 800-218 SSDF practices and produce a CISA-aligned Software Bill of Materials for every external dependency. Supply-chain provenance, vendor risk, and software integrity controls trace to NIST SP 800-161 r1. This is what allows the receiving team to update the prototype safely after the engagement and what lets a security-officer review or a third-party auditor see exactly what is inside the build.

The point is not that we recite frameworks. The point is that we build robotics prototypes that pass the review the framework was written to require. That is what the compliance posture is for.

None of those differentiators is "we have built 100 robots." We have not. The claim that we hold a verifiable CMMC-RPO standing, run a verifiable private GPU fleet, and operate a verifiable Reachy Mini in our lab is the claim a regulated buyer can underwrite.

The named Petronella team holding CMMC-RP credentials reflects what we say we sell: a Petronella robotics engagement is led by people who write CMMC-aligned engagement letters for a living. The full team is CMMC-RP certified and works under RPO #1449 in good standing. For research and program-management partnerships, we work alongside the client's PI, IRB administrator, or contracting officer and treat their authority chain as authoritative.