TL;DR: The partnership with Raglan combines software-defined vehicle architecture and operational technology monitoring to harden military and government vehicles against cyber and electronic warfare threats, according to Shift5, extending security into vehicle control systems and mission platforms. The important shift is that fleet security now has to cover trusted control logic, telemetry and resilience as well as traditional vehicle hardening.
At a glance
What this is: Shift5 and Raglan describe a partnership aimed at combining software-defined vehicle control with operational technology monitoring for military and government fleets.
Why it matters: It matters because vehicle fleets now behave more like cyber-physical systems, so IAM, access control and monitoring decisions increasingly extend into mission-critical transport and control layers.
Context
Military vehicle security is no longer just a protection problem around armour, communications, or physical access. As software-defined control systems and monitoring become part of the vehicle stack, the governance question shifts to who can change vehicle behaviour, who can observe it, and how those changes are detected across mission use. This is a cyber-physical identity problem as much as it is a platform problem.
For fleets used in defence and government settings, the control boundary now includes software updates, remote diagnostics, operator access, and telemetry integrity. That makes operational technology identity and access relevant because vehicle systems inherit many of the same access and segmentation issues seen in industrial environments, only with a mobility and mission-assurance constraint.
Key questions
Q: How should defence fleets govern software-defined vehicle control paths?
A: Treat the control path as privileged infrastructure. Separate who can update software, who can change configuration, and who can approve those changes. In military and government fleets, the governance model has to cover not just the vehicle but the interfaces that shape behaviour, because control drift can become a mission and safety issue before traditional security monitoring sees a breach.
Q: What happens when vehicle telemetry cannot be trusted during operations?
A: Operators lose confidence in the vehicle’s state, which can be as damaging as a direct compromise. If telemetry is incomplete or manipulated, teams may miss tampering, misread readiness, or make unsafe decisions under pressure. The practical response is to validate telemetry against independent records and design monitoring that assumes contested conditions.
Q: Why do software-defined fleets need OT-style access control?
A: Because the systems now include maintenance, diagnostics, and control interfaces that can change physical behaviour. Those interfaces need segmentation, approvals, and least privilege in the same way industrial systems do. Without that governance, the fleet inherits the risk of privileged misuse across both operational and mission support functions.
Q: What is the difference between vehicle hardening and vehicle monitoring?
A: Vehicle hardening reduces the ways an attacker can alter the platform, while monitoring detects when the platform behaves unexpectedly. Both matter in connected fleets, but they answer different questions. Hardening is preventive, while monitoring is about maintaining operational awareness when the system is already deployed and changing in real time.
Technical breakdown
How software-defined vehicle control changes the trust boundary
Software-defined vehicles move decision-making from fixed mechanical systems into software layers that can be updated, monitored, and integrated with external tooling. That expands the trust boundary from the vehicle itself to its control software, update path, diagnostics, and telemetry feeds. In practical terms, security is no longer only about protecting the asset from intrusion. It is about preserving the integrity of the control logic that governs propulsion, mission systems, and safety-related functions while those systems remain maintainable in the field.
Practical implication: Treat software-defined vehicle control paths as privileged infrastructure and govern them with segmented access and change control.
Why operational technology monitoring matters in mobile platforms
Operational technology monitoring in vehicles is about observing behaviour that has direct physical consequences, such as unexpected configuration changes, anomalous command patterns, or degraded system performance. Unlike office IT, these environments can tolerate far less ambiguity because a bad command or compromised subsystem can affect movement, readiness, or mission safety. The monitoring function therefore has to combine detection, baselining, and safety-aware alerting rather than rely only on standard endpoint-style telemetry. See the Endpoint Security Guide.
Practical implication: Build alerting around behavioural drift and unauthorized change, not only malware signatures or generic log events.
How cyber and electronic warfare concerns intersect in vehicle fleets
The article frames both cyber and electronic warfare as threats to military and government vehicles, which reflects the reality that digital control and signal integrity are now intertwined. A vehicle can be targeted through software pathways, but also through interference that disrupts navigation, command confidence, or communications assumptions. That means resilience has to cover both authenticated control and operating conditions where systems may lose reliable external support. The security model must therefore assume contested conditions and degraded visibility.
Practical implication: Design fleet controls to remain safe and observable when external signals, links, or support systems are unreliable.
NHI Mgmt Group analysis
Software-defined vehicle security is becoming a governance problem, not just a vehicle engineering problem. Once control logic, diagnostics, and monitoring are software-mediated, the security boundary shifts to access governance over the functions that can change behaviour. That means fleet programmes need to treat vehicle software paths as controlled operational assets rather than passive embedded systems. The practitioner implication is to govern software-defined control with identity-aware change control.
Vehicle telemetry is now part of the trust fabric. When monitoring is used to prove that fleet systems remain mission-ready, the integrity of telemetry becomes as important as the integrity of the vehicle itself. A false or incomplete picture can be operationally dangerous because it masks drift, tampering, or failure in a mobile environment. The practitioner implication is to validate what telemetry can and cannot prove before relying on it for readiness decisions.
Cyber and electronic warfare converge at the level of control confidence. The article is really about preserving trustworthy command, not just blocking malware. In defence fleets, a disruption does not have to destroy systems to be effective; it only has to reduce confidence in their behaviour at the wrong moment. The practitioner implication is to align fleet security, resilience, and operational assurance as one control problem.
Operational technology identity and access is the missing lens for connected fleet programmes. As vehicles become software-defined, access to maintenance interfaces, update channels, and control software starts to resemble privileged access in industrial environments. That creates a direct need for operational technology identity and access discipline, especially where multiple operators, vendors, and mission teams interact with the same platform. The practitioner implication is to extend privileged access governance into vehicle lifecycle operations.
Read next: OT and ICS Identity and Access Guide
What this signals
Control-plane drift: As software-defined vehicles expand, the security problem shifts from device protection to the governance of the functions that can change vehicle behaviour. Defence and government programmes should expect more overlap between vehicle safety, operational technology access, and privileged change control, especially where multiple teams touch the same platform.
A fleet that can be updated and monitored is also a fleet whose trust assumptions can fail in subtler ways. The programme question is no longer whether vehicles are connected, but whether the control surfaces remain observable, segmented, and recoverable when conditions are contested.
For practitioners
- Define software-defined vehicle trust boundaries Map which vehicle functions are safety critical, which are updateable, and which teams or systems can change them. Require explicit approval paths for changes that affect propulsion, mission systems, or telemetry integrity.
- Segment maintenance and control access Separate diagnostics, fleet management, and mission operation access so that no single account or interface can alter control logic without oversight. Apply least privilege to every remote and local interface that can affect the vehicle state.
- Baseline vehicle behaviour under contested conditions Record normal command, sensor, and performance patterns so that drift can be detected when external signals or links degrade. Use those baselines to distinguish mission disruption from expected operational variation.
- Treat telemetry integrity as a security control Validate that monitoring data cannot be altered, suppressed, or selectively exposed by the same path used to operate the vehicle. Correlate platform logs with independent operational records where possible.
Key takeaways
- Software-defined vehicle programmes create a new governance problem because control logic, diagnostics, and telemetry now sit inside the security boundary.
- The relevant risk is not only compromise of the platform but loss of confidence in what the vehicle is doing, which can affect mission readiness and safety.
- Defence and government fleets need segmented access, behavioural baselines, and telemetry validation to keep connected vehicle systems trustworthy.
Related NHI Mgmt Group resources: OT and ICS Identity and Access Guide · Endpoint Security Guide · Firewall Management Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Vehicle control and maintenance access need explicit authorization boundaries. |
| Recommendation — Apply PR.AA-05 to restrict who can change vehicle control functions and telemetry paths. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Fleet maintenance and diagnostic access should be limited to the minimum required scope. |
| Recommendation — Enforce AC-6 on vehicle support interfaces and remote control channels. | ||
| CIS Controls v8 | CIS-5 — Account Management | Shared fleet accounts and operator access must be lifecycle-managed across programmes. |
| Recommendation — Use CIS-5 to manage and review accounts that can reach vehicle systems. | ||
| MITRE ATT&CK | TA0004;TA0008 — Privilege Escalation; Lateral Movement | The threat model centers on gaining and extending control across vehicle platforms. |
| Recommendation — Map fleet threats to privilege escalation and lateral movement paths in connected vehicle environments. | ||
| ISO/IEC 27001:2022 | A.8.2 — Privileged Access Rights | Connected vehicle operations need controlled privileged access to update and diagnostic tooling. |
| Recommendation — Apply A.8.2 to govern privileged access to vehicle software and support systems. | ||
Key terms
- Software-defined vehicle: A software-defined vehicle is a vehicle whose features, controls, and updates are increasingly managed through software and connected digital systems. It depends on centralized compute, remote updates, and supplier-integrated tooling, which makes access control and containment more important than in traditional vehicle architectures.
- Operational Monitoring: Operational monitoring tracks the health and performance of AI systems through signals such as latency, token usage, cost, and error rates. It shows whether requests ran successfully, but it does not determine whether the response was accurate, relevant, compliant, or safe enough for production.
- Telemetry integrity: Telemetry integrity is the confidence that logs, metrics, and traces accurately reflect what happened. If an attacker can alter, redirect, or suppress telemetry, the security team may still see data, but it can no longer trust that data for investigation, detection, or compliance evidence.
- Contested environment: An operating context in which systems must perform while communications, signals, or support assumptions may be degraded, interfered with, or actively opposed. Security and resilience planning in such environments has to assume partial visibility and reduced trust in external dependencies.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners build the access discipline that modern cyber-physical platforms increasingly depend on.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org