Start with the published guidance and its boundary
The Department's 2022 Zero Trust Strategy established 91 target-level activities within a broader set of 152, with a target-level goal by fiscal year 2027. It moved the focus toward protecting resources through explicit access decisions instead of granting trust simply because a requester is inside a network.
The separate Zero Trust for Operational Technology Activities and Outcomes guide lists 84 target and 21 advanced activities. The published guide adapts security to physical processes, legacy equipment and the priority placed on reliable operation. Crucially, its scope extends to the boundary of weapon systems as defined by the mission owner. It gives the example of an electrical distribution system supplying a weapon, while excluding the weapon's internal targeting or firing systems. The document says separate guidance will address weapon systems and defense critical infrastructure.
That boundary matters. A platform team cannot establish compliance merely by applying an OT checklist to every embedded component. It needs the applicable system requirements, authorization boundary and mission-specific security and safety evidence.
September 2026 review update: The April 29 interagency guide on adapting zero trust to OT reinforces the need to account for operational constraints, legacy systems and physical safety. It supports careful integration of security into mission systems; it does not erase the distinctions among the governing requirements.
Disconnection is a design condition
A surface vessel or unmanned aircraft may lose access to a central identity provider, monitoring service or update repository. Security controls that depend on an immediate cloud response can then become a mission dependency of their own.
Published Department capability guidance already recognizes local support for disconnected functions in denied, disrupted, intermittent and limited communications environments, within an enterprise identity-management approach. The engineering work is to specify what remains locally enforceable, how long the supporting information remains useful and how the platform reconciles changes when connectivity returns.
Consider a routine maintenance action. A technician may be authorized to inspect diagnostic data without being authorized to change mission software. That distinction should remain meaningful during an outage. A platform also needs to recognize the difference between a permitted local action and an old permission that has expired or should have been revoked.
Useful design questions include:
- Which identities can the platform validate locally, and how are their privileges limited?
- Which decisions require fresh information from another system?
- What happens when a credential, policy or trusted time source becomes unavailable or stale?
- Which functions continue, which are restricted and which require operator intervention?
- What records are retained locally, and how are they reconciled after reconnection?
The answers depend on the mission. A uniform “always stop” or “always continue” rule can create unacceptable safety or security consequences.
Keep corporate security and platform assurance distinct
CMMC addresses the protection of specified information in the assessed contractor environment. It is not a certification that an autonomous platform's flight control, targeting software or subsystem interfaces are safe and secure for their intended use. System authorization and mission assurance require their own evidence. Risk-management requirements also extend beyond the handling of controlled unclassified information.
Current procurement context: The Department suspended CMMC Phase II in July 2026 while retaining Phase I self-assessment requirements. Contractors should follow the requirements in their applicable solicitation or contract and the implementing direction. That change does not remove the need to secure a delivered platform or satisfy its system-specific requirements.
For a program office, the useful artifact is a boundary map. It should show the contractor environment, development and update path, platform subsystems, external connections and the authority responsible for each. That makes it harder to mistake a positive assessment in one area for assurance across the entire mission.
Engineer controls that fit the platform
Several approaches deserve evaluation early in design:
- Device and workload identity: Protect credentials using hardware-backed facilities where appropriate, and test enrollment, replacement and recovery rather than assuming the key store solves the entire lifecycle.
- Subsystem boundaries: Limit communication to the functions each component needs. Verify that a compromised maintenance or payload function cannot acquire unrelated privileges through an overlooked interface.
- Software and firmware integrity: Establish trusted update paths, configuration records and recovery procedures. A software bill of materials helps identify dependencies; it does not prove that the software is free of vulnerabilities.
- Local monitoring: Use operational baselines to help identify unexpected behavior, while testing benign changes and sensor faults that could also generate alerts.
- Safe containment and reconnection: Exercise restrictions and recovery with platform engineers and operators so that a security action does not create an unsafe physical state.
These are architectural options and review priorities, not claims that a single published guide prescribes the same implementation for every autonomous system. Controls should be assessed together: tighter segmentation can affect timing, additional telemetry consumes resources and a recovery procedure can depend on power or communications that are unavailable during the incident.
Make the demonstration include the outage
A connected demonstration should be followed by the conditions the platform is expected to survive. Remove central services, introduce a benign fault, present an unauthorized request and then restore the connection. Observe both the security decision and the physical behavior of the system.
The resulting evidence should explain the supported operating period, limits, operator actions and unresolved risks. This is where resilient edge design becomes reviewable: the program can see what remains protected and what mission capability remains available.
Sources and further reading
- Department of Defense: 2022 Zero Trust Strategy
- Department CIO: Zero Trust for OT Activities and Outcomes, including scope and activity counts
- Department capability activities: local support for disconnected identity functions
- CISA and partner agencies: April 2026 OT zero-trust guidance announcement
- Department CIO: current CMMC program status
- Department CIO: implementing the CMMC Phase II suspension
Spartan X brings edge-AI engineering and cybersecurity into the same design conversation, connecting local operation, explicit authority and recovery evidence to the conditions autonomous systems must face.
