Framework Reference

GNSS receivers can be tricked by counterfeit satellite signals broadcast from nearby transmitters, causing the platform to believe it is in a different place or time. A resilient design detects anomalies (signal strength, RAIM, multi-constellation cross-check) and falls back to inertial navigation (INS) or alternative sources without aborting the mission silently.

The command-and-control link is the most direct path to take over a USV. Mutual authentication (both sides prove identity), replay protection (recorded packets cannot be reused), and scheduled key rotation prevent hijack even if an attacker records traffic for later attack.

When the C2 link drops, the USV must enter a predictable, pre-rehearsed state — e.g. hold position, return to recovery point, or surface and beacon — rather than continue the last command or behave unpredictably. The matrix should cover every fail trigger and be verified on hardware-in-the-loop.

Many subsystems (crypto, logging, sensor fusion) depend on accurate time. GNSS-borne time attacks can desync subsystems and break replay protection or correlation. Holdover oscillators, drift monitoring and alarms ensure the platform can detect and tolerate time tampering.

If GNSS is denied or spoofed, the mission must continue safely. Alternative navigation (INS holdover, bathymetric matching, celestial, visual landmarks) must be designed in, sized for realistic mission length, and rehearsed by operators — not added as an afterthought.

Secure boot anchored in hardware (TPM, secure element) ensures that only signed firmware/software runs from the very first instruction. Measured boot logs allow detection of tampering after the fact. Without this, an attacker with brief physical access can persist below the OS.

Real missions degrade gradually — one sensor fails, comms drop, a node reboots. A documented degradation policy defines what capabilities remain, what is suspended, and when human intervention is required, so the platform behaves predictably instead of crashing or pushing through unsafely.

A total power blackout must not leave the platform in an undefined state where safety interlocks are bypassed or actuators driven uncontrolled on restart. Recovery is deterministic, repeatable and tested, with state-of-charge accounted for.

Sweep results and contact reports drive operational decisions; a forged sonar frame could falsely declare an area clear. Cryptographically binding sensor frames to the originating device (signed at the sensor, verified at the consumer) prevents in-line tampering.

Influence sweep generators output high-power magnetic/acoustic fields. If their command path is reachable from general IT, a compromised laptop could trigger them at the wrong place or time. Strict network segmentation and one-way data diodes where possible are required.

Underwater acoustic channels (incl. NATO JANUS) are inherently broadcast, low-bandwidth and prone to injection. Authentication, rate-limiting and anomaly monitoring prevent an attacker on a small boat from issuing commands or replaying captured frames.

Launch-and-recovery and the manned↔unmanned handover are the moments where a wrong command can injure crew or damage the platform. Physical interlocks (mechanical) and logical interlocks (software state machine) together must make unsafe sequences impossible, not just discouraged.

Even mechanical sweep equipment (cable cutters, paravanes) is now electrically actuated. A dedicated control path with an independent emergency-stop that physically breaks power ensures the equipment can be stopped even if the main control computer is compromised.

Mine-setting, target-simulation and mine-jamming are operations with strategic consequences if misused. Signed mission profiles ensure only authorized parameter sets run, and dual-operator approval prevents a single rogue or coerced operator from issuing them.

Mission data (sweep tracks, sonar contacts, sensor logs) is evidence — both for operational debrief and for any later forensic or legal review. Sealing with hashes on return and maintaining chain-of-custody prevents undetected modification or accusations of tampering.

Degaussing and magnetic-signature management subsystems both influence the platform's own detectability and are attractive sabotage targets. Network isolation plus tamper sensors ensure changes are intentional and detected.

A Software Bill of Materials lists every open-source and third-party component (and version) inside a build. Without it you cannot answer 'are we affected by CVE-X?' in hours. SBOMs must cover firmware and embedded artefacts, not just server software.

Every firmware/software update must be cryptographically signed by a controlled key, and the device must verify the signature before accepting it. This blocks the classic 'malicious update' supply chain attack — the highest-impact path into deployed equipment.

FPGAs are reconfigured from a bitstream that defines their hardware behavior. Unverified bitstreams can implement hidden backdoors invisible to software analysis. Origin verification, encrypted bitstreams and lockbit settings make unauthorized reconfiguration practically impossible.

If the build toolchain (compiler, linker, signing tools) is tampered with, every binary it produces is suspect — the classic Ken Thompson attack. Reproducible builds let independent parties verify that source code maps deterministically to the released binary.

AI/ML models (automatic target recognition, autonomy) inherit risks from their training data and pipeline. Tracking model versions, dataset hashes and training environment lets you reproduce a model, investigate misbehavior and respond to data-poisoning disclosures.

Risk is rarely at the integrator level — it is in the chip foundry, the sensor crystal supplier, the open-source library two layers deep. Disclosure of Tier-2/3 sub-suppliers for safety- and mission-critical parts lets the buyer assess country-of-origin and concentration risk.

New vulnerabilities are disclosed daily. A defined SLA for triage (is this CVE applicable?), patching, and re-validation (does the patched firmware still meet safety requirements?) prevents both 'unpatched for years' and 'rushed patch breaks the platform' failure modes.

Build infrastructure and signing keys are the crown jewels. If a build server is on the corporate intranet with email access, a phishing email can compromise every product the company ships. Isolation, MFA, and audit logging are non-negotiable.

ATR and autonomy models can be fooled by inputs crafted to evade detection (adversarial patches, acoustic shapes) or by long-term data-poisoning of public training sets. Red-team testing against these attack classes must happen before deployment, not after an incident.

Third-party payloads (additional sensors, communication modules) plug into the platform. Without an authenticated, schema-validated bridge, a malicious or buggy payload can inject commands, exfiltrate data, or cause faults in the host platform.

Without telemetry there is no monitoring. The SOC must receive signed (tamper-evident) operational and security telemetry, and must be staffed and tooled for OT analysis — IT-only SOCs miss protocol-level and physical-process anomalies entirely.

Generic IT threat intelligence misses maritime-specific actors, malware families and TTPs. Maritime-focused CTI fed into detection rules at a defined cadence keeps detections relevant against the actual threat environment.

A cyber compromise is not only an IT incident; it is a mission-assurance event that can affect whether the platform can complete its task safely. The incident playbook must include mission-side decisions (continue / abort / hand back) alongside technical containment.

OT anomalies look different from IT anomalies — a valid-looking command at the wrong time, a slow set-point drift, an unexpected mode change. Detection rules must encode operator and process knowledge, not just signature matching.

An alert with no defined escalation path or abort criteria is noise. Operators need a clear workflow: who acknowledges, who escalates, at what threshold the mission is aborted, and how that decision is recorded.

Detections that have never been tested against a realistic attacker are assumptions. Annual purple-team or detection-coverage exercises against maritime scenarios are the only way to know whether the SOC actually sees what it claims to see.

Without an enforceable right-to-audit clause that flows down to sub-suppliers, security claims are unverifiable. The clause must allow on-site visits, document inspection and follow-up audits, not just self-attestations.

If suppliers are not contractually required to deliver SBOMs, test reports and attestations at defined milestones, you will not receive them. The evidence register lists exactly what is due, by when, and the acceptance criteria.

If a critical component comes from a jurisdiction that becomes hostile (export ban, sanction, sabotage risk), the platform is grounded unless a substitution plan exists. The plan names alternatives, qualification effort and lead-time per component.

If only the original vendor can sign firmware, and that vendor disappears or refuses to patch a vulnerability, the buyer is stuck. Source escrow plus custody of signing keys (or a co-signing arrangement) preserves the buyer's ability to patch.

Security clauses written between the buyer and Tier-1 do nothing if Tier-1's contracts with Tier-2/3 are silent. Mandatory flow-down with sub-supplier acknowledgements is the only way to extend the security regime to the actual risk locations.

Source code escrow without the build toolchain and signing keys is often useless — you cannot reproduce the binary the device accepts. Escrow must cover all three, with documented release triggers (vendor bankruptcy, refusal to patch, etc.).

Suppliers learn about incidents and vulnerabilities affecting their products before customers do. A contractual disclosure window (e.g. 72 hours for incidents, defined CVE disclosure rules) ensures the buyer can act before exploitation spreads.

Electronics have shorter lifecycles than platforms. Without a contractual EOL plan (last-time-buy notice, re-design support, security-patch tail beyond active production), the platform becomes unmaintainable and insecure mid-life.