System Architecture Diagram
The diagram below illustrates the complete TrikTraks OTA Security Gateway model, showing information flow, trust boundaries, and security enforcement points.
🎯 Component Legend
Vendor Zone: Manufacturer's firmware development environment (external, untrusted)
Operator-Controlled Zone: TrikTraks OTA Security Gateway (trust boundary enforced)
Fleet Network: Distribution infrastructure for authorized updates
Vehicle Zone: Individual vehicles with TrikTraks Secure Agent on edge compute modules
🛡️ Security Architecture Highlights
✓ Dual-Signature Verification: Both vendor signature AND operator signature required
✓ No Manufacturer Backdoors: Direct manufacturer-to-vehicle communication is blocked
✓ Hidden SIM Protection: Even if manufacturer installs hidden connectivity, signature verification prevents unauthorized updates
✓ Operator Sovereignty: Fleet operator maintains complete control over what gets deployed
✓ Policy Enforcement: Updates validated against operator-defined security and operational policies
✓ Comprehensive Eligibility Checks: 7+ validation criteria before deployment (health, connectivity, safety, location, timing)
✓ Tamper-Evident Logging: All installation attempts recorded and reported back to operator
✓ Progressive Rollout: Canary deployments and phased rollouts minimize fleet-wide risk
✓ Immobility Requirements: Updates only when vehicle is stationary, engine off, in safe location
✓ Audit Trail: Complete chain of custody from vendor submission to vehicle installation
Building OTA Infrastructure That Operators Can Trust
How TrikTraks is Designing an OTA Mechanism That Eliminates Remote-Control Risks
Recent investigations in Europe revealed a troubling reality across multiple electric bus fleets. Remote connectivity channels that were originally intended for diagnostics and software updates were also capable of reaching battery and power-management systems. This meant that a manufacturer, or anyone able to impersonate the manufacturer, could theoretically render a vehicle inoperable. The finding was not a failure of engineering. It was a failure of governance, transparency, and control.
This is the problem TrikTraks is designing its OTA system to prevent. The goal is simple. A connected fleet should never depend on blind trust in a vendor. Operators must retain final authority over what enters their vehicle networks and when. The OTA mechanism must therefore be engineered around operator sovereignty, cryptographic control, and transparent observability.
Below is how this is being approached.
1
Operator-Held Authorization Keys
Nothing executes unless the operator explicitly allows it.
The most critical safeguard removes the possibility of a vendor pushing code or commands directly into a vehicle. TrikTraks uses a two-party signing workflow.
The manufacturer still signs firmware with its own key to prove authorship. However, the update cannot be applied until the operator signs a separate authorization package with a private key controlled by the fleet owner or their designated security office.
This closes the door on undisclosed remote channels and prevents the scenario exposed in Norway where a roaming SIM could reach battery management systems without the operator's knowledge.
2
Network Segmentation
The OTA mechanism is being developed with a strict network-segmentation model. Even if a manufacturer embeds a telematics unit or connectivity module, it is treated only as a data endpoint. It cannot communicate with drive-train or battery systems without passing through a policy-enforced gateway.
This gateway performs several functions:
• It enforces authenticated message types
• It blocks any message outside the approved schema for a specific subsystem
• It maintains audit trails for every accepted or rejected request
This ensures that even if a device attempts to communicate unexpectedly, the message cannot hop from telemetry to propulsion without being intercepted and logged.
3
Zero-Trust Validation
The goal is to make unsafe updates impossible to deploy at scale.
Every update undergoes a series of validations before it is approved for distribution to a vehicle or device.
• File integrity is checked against vendor signatures
• Security scanners evaluate the package for vulnerabilities
• Dependency trees are analyzed for tampering or unexpected behavior
• Version histories are verified to prevent rollbacks or forced downgrades
Only after this sequence passes does the operator even review the package for authorization. The goal is not just to allow safe updates. The goal is to make unsafe updates impossible to deploy at scale.
4
Transparent Communication
A major issue highlighted by the European case was that buses attempted to contact networks unknown to the operator. TrikTraks addresses this by exposing every communication channel in a fully auditable registry.
Operators can see:
• Which domains a device communicates with
• Which ports are used
• How often packets are transmitted
• Whether traffic is inbound, outbound, or both
• Whether traffic is encrypted
• Which subsystem initiated the communication
With TrikTraks, the visibility is real-time and continuous. A fleet owner should never discover a remote connection only after driving a vehicle into a mine.
5
Operator-Controlled Platform
The OTA mechanism is not a direct link between a manufacturer and a vehicle. Updates flow through an operator-controlled OTA server that sits inside the fleet's security perimeter. This server distributes packages to vehicles based on defined maintenance windows and operational constraints.
• Manufacturers can submit software
• Operators decide what enters the fleet
• Vehicles only trust updates from the authorized OTA server
This architecture preserves vendor innovation while protecting public infrastructure from unauthorized remote influence.
6
Cryptographic Attestation
Every significant action in the OTA pipeline produces a tamper-evident record. These include:
• Vendor submission logs
• Package validation logs
• Operator approval logs
• Vehicle installation logs
• Subsystem post-installation checks
Each record is cryptographically chained so that removal or alteration would be immediately detectable. This ensures long-term accountability and allows investigators, regulators, or auditors to reconstruct exactly what occurred, when it occurred, and who authorized it.
7
Air-Gapped Updates
Some operators may require enhanced controls. TrikTraks therefore supports a fully offline update mode. In this mode, vehicles accept updates only when a technician physically connects an update device that holds pre-authorized, pre-signed packages.
This mode is particularly relevant for defense fleets, critical infrastructure vehicles, and any operation where air-gap requirements are mandated.
8
Mixed Fleet Framework
One of the challenges highlighted in the recent bus investigation is that fleets increasingly consist of vehicles from multiple manufacturers. Each vendor implements OTA differently, often with different assumptions about trust.
TrikTraks is being built to standardize this inconsistent landscape. The OTA platform enforces the same security rules and approval workflow for any vendor, any device class, and any model year.
This allows operators to apply uniform security practices without rewriting their entire procurement strategy.
The Goal is Not to Eliminate Connectivity.
The Goal is to Eliminate Blind Trust.
Remote connectivity is essential for diagnostics, predictive maintenance, energy optimization, and operational efficiency. The issue raised in Europe is not that buses were connected. The issue is that operators did not control the connection.
TrikTraks is being developed to ensure that modern fleets can remain connected without surrendering operational sovereignty. The result is an OTA mechanism designed for transparency, accountability, and secure operator control.
As public and private transportation systems become increasingly software-defined, these principles must become standard practice. The lesson from recent events is clear: Connectivity without governance is a vulnerability. Connectivity with operator-held control is an asset.
