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. 2022 strategy.
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. OT activities and scope.
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.
The April 29, 2026 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. Interagency announcement.
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. Capability activities.
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. CMMC program scope.
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. Phase II suspension direction.
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.
Preserve the distinction between a permission and a capability
A system may be technically able to perform a maintenance function while the person requesting it lacks the relevant authorization. Conversely, an authorized person may lack the tools or information needed to complete the work. The support model should account for both, rather than treat successful authentication as the entire maintenance process.
The receiving organization needs an approved description of the tasks its personnel can perform, the evidence those tasks require, and the support available when a task cannot proceed. This is particularly useful where a product depends on a supplier service that may not always be reachable.
The objective is to make the boundary understandable to the people responsible for the equipment. A control that produces an unexplained denial can encourage confusion and improvised workarounds. Clear procedures and appropriate support give the organization a better way to resolve the underlying issue within its authority.
Include the support burden in the security decision
A protective feature can add value while creating recurring work in configuration, credential management, monitoring, or recovery. The program should identify who performs that work and whether the receiving organization can sustain it.
A sophisticated control without the necessary support may be less useful than a more bounded approach the team can maintain. That does not justify ignoring applicable requirements. It means the acquisition plan should include the resources needed to meet them, rather than assuming they arrive with the product.
Before accepting a new security capability, review the associated documentation, training, and supplier responsibilities alongside its technical evidence. Identify which activities are routine, which require specialists, and how the arrangement changes when the product or mission configuration evolves.
This makes resilience a continuing delivery obligation. The customer receives both a protective function and a realistic means of keeping it effective within the approved operating model.
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.
