COVER

NODUS FORTIS

The Sovereign Black Box

An Australian-controlled hardware architecture that catches a faked GPS position and rejects the lie — the first hardware enforcement node on a machine's navigation path, for a world where the map can no longer be trusted.

Post-receiver detection · Pre-controller enforcement · Independent of host software

[PRE-HARDWARE · SIMULATION & RECORDED-DATA EVIDENCE] Detection demonstrated in closed-loop simulation and recorded-data testing; the first physical-board build is the next milestone.
Hardware-enforced navigation integrity for drones and autonomous systems operating in GPS-contested environments · Dual-use · Conceptually aligned to AUKUS Pillar II

Request a briefing
01 / The Problem

Machines that believe whatever they are told

Autonomous machines are multiplying — delivery drones, self-driving vehicles, aircraft, ships, satellites — and almost every one depends heavily on an input it cannot itself verify: the position handed to it by GPS. That position is typically accepted and acted upon with little independent challenge — an assumption underneath much of the autonomous economy, not independently checked before the machine acts on it.

GPS was never designed to be secure. The signal is broadcast from twenty thousand kilometres away, and by the time it reaches the ground it is weaker than the ambient noise of a city. Equipment costing a few hundred dollars can overwhelm it — or, more dangerously, counterfeit it. The cost of attacking is low, the number of exposed platforms is large, and dedicated protection is not widely fitted. What was once a laboratory curiosity is now a routine instrument of modern conflict, and its effects have spread well beyond the battlefield into civilian aviation, commercial shipping, and border regions across three continents.

In plain termsA machine's safety systems are built to detect failure. If GPS is lost, alarms are raised and the platform protects itself. Spoofing is not a failure — nothing breaks. A successful spoof can leave standard receiver and interface checks appearing normal, so false position data continues without an obvious loss-of-navigation alarm. The machine executes its mission with precision — against a world that is not there.
Jamming — drowning it outDenial
SIGNAL— healthy① signal healthy
What you are looking atThe attacker floods the frequency band with noise until the receiver can no longer resolve the satellite signal. The machine goes blind — but it knows it has gone blind. The sequence is visible in the trace: healthy signal, noise saturation, receiver occlusion. Because the platform can identify its own loss of position, it can respond honestly and invoke its failsafes.
Spoofing — counterfeiting itDeception
REPORTEDon course ✓TRUE POSITION0 m off
What you are looking atThe attacker supplies a position that satisfies every structural check but is false. No alarm is raised, because nothing appears wrong. The reported position (green) holds steady on the intended line while the true position (red) diverges. The machine remains confident, and entirely incorrect.

A jammed machine usually knows it is lost. A spoofed machine does not.

Deception is the harder problem, and the one a loss-of-signal failsafe cannot detect. It is the problem Nodus Fortis exists to address.

The missing decision Nothing between the receiver and the controller

Every autonomous machine acts on information it receives from outside itself. Almost none of them contain a place where that information is independently examined before it is allowed to influence control. The receiver reports; the controller acts. There is nothing between them whose job is to ask whether the report should be believed.

The principle: a machine should treat the position it is handed as a claim requiring verification, not a fact to be trusted — and the moment that claim fails to hold, the input should be rejected and the platform protected before the deception can continue to influence its behaviour.

That decision has to be made somewhere, and it has to be enforced by something the attacker cannot argue with. That place is what Nodus Fortis builds.

What the machine already knows It can feel its own motion

A drone is not blind without GPS. It already carries sensors that measure its own movement directly — the physical experience of accelerating, turning, tilting, holding a heading. That information does not arrive from the sky. It cannot be transmitted to, jammed or faked from the ground, because it is not a signal being received; it is the platform sensing itself.

A spoofer, however sophisticated, can lie about what the machine is told. It cannot reach inside and change what the machine feels. So a counterfeit position has to survive a second question: does it agree with what the platform can establish about its own motion? A true position always does. A fabricated one — if it is actually steering the platform somewhere it should not go — eventually cannot. The two accounts pull apart, and the contradiction becomes measurable. The attack fails not because the signal was blocked — it cannot be blocked — but because it was checked against something the attacker could not reach.

Why a deceived receiver is still trustedA receiver can continue to emit perfectly well-formed navigation messages while being entirely wrong. The flight controller has no basis on which to reject them: the data arrives through the same trusted interface it has always used. Nodus Fortis does not ask the deceived receiver whether it has been deceived. It independently assesses whether the reported position is physically credible, from a point after the receiver and before the controller.
The boundary What we do not claim

Nodus Fortis does not claim that every conceivable deception can be detected. A sufficiently resourced adversary can, at considerable expense, construct a counterfeit that contains no detectable inconsistency — and no consistency-based system can catch that, ours included. We do not claim to. (Timing-only attacks and key-custody compromise are separate boundaries, named in Section 02.)

What the architecture does is establish a boundary that forces an attacker to defeat more than the external position signal alone — an attack demanding far greater knowledge of the target, tighter coordination, and more sophisticated control of the counterfeit signal. The present detection boundary, and the evidence supporting it, are set out in Sections 07 and 08.

What this is The first enforcement node

Nodus Fortis is not building a single anti-spoofing device. It is establishing the hardware trust boundary around which autonomous machines can begin to defend themselves. The first essential decision has been demonstrated in simulation: a machine can challenge the position it is given and autonomously reject the lie. The Black Box is designed to turn that decision into a physical enforcement point — and everything else in this deck is built around it.

02 / The Threat Landscape

The principal ways satellite navigation can be denied or deceived

This is a practical map of the principal attack families against satellite navigation, anchored to published research and documented real-world events. Each attack is stated plainly first, then detailed for a technical reader.

The attacks fall into three families: drowning out the signal, counterfeiting it, and tampering from the inside.

Family 1 Drowning it out — denial

Broadband jamming

Loud

The bluntest attack: raw noise transmitted across the satellite frequencies until the receiver can no longer resolve the real signal. The machine goes blind — but it registers that it is blind.

overwhelming a faint sound with sheer volume.

The detail
ResearchPsiaki & Humphreys, GNSS Spoofing and Detection (Proceedings of the IEEE, 2016) — the foundational split between denial and deception.
What defines itThe ratio of jamming power to signal power — a contest of brute strength.
Real worldReported: sustained interference around the Baltic and Kaliningrad affected roughly 123,000 flights between January and April 2025 — GNSS interference and jamming, not confirmed spoofing.
Family 2 Counterfeiting it — deception · the dangerous family

Record-and-replay

Quiet

The simplest deception: record the genuine signal and rebroadcast it, delayed and amplified. The receiver resolves a position it held at an earlier moment.

replaying an earlier set of directions after the route has changed.

The detail
Also calledmeaconing.
ResearchPsiaki & Humphreys, 2016.
What defines itThe replay delay. Any delay creates a discrepancy; only a perfectly timed, perfectly placed replay avoids one.

The sudden jump

Quiet

A cruder counterfeit forces the receiver onto a false signal, so the reported position shifts discontinuously — present in one location, and a block away the next.

a position that relocates instantaneously — a movement no real platform could make, and therefore detectable.

The detail
ResearchHumphreys et al., Assessing the Spoofing Threat (ION GNSS 2008).
What defines itThe size of the jump, in metres.
Real worldReported: more than 5,600 GPS-spoofing occurrence reports logged in roughly two months in Cyprus's Nicosia flight-information region (Cyprus CAD, via OPSGROUP) — the most of any tracked airspace, some appearing as exactly these sudden errors.

The slow sideways drag

The initial target attack class
STEP① smooth takeoverOUTCOMEwatching…

Rather than a discontinuous jump, the attacker assumes control of the signal smoothly and eases the reported position sideways — a few centimetres at a time — slowly enough that no coarse alarm is triggered. Over a few minutes, a platform can be walked hundreds of metres off course while continuing to report full confidence.

being guided one lane across at a time, each step too small to notice, until the destination is wrong.

Why this attack matters mostLeft unprotected, a slow sideways drag can carry a drone well over a hundred metres off course with no alarm raised — in simulation, an unprotected drone was walked ~52 m off course at 2 m/s, and further at slower rates because the drift runs for longer (≈196 m at 0.5 m/s over a longer exposure window). It is quiet, patient, and highly effective — and it is the attack class the Black Box is built to detect. In closed-loop simulation it detects and rejects the faster (≈2 m/s) drag in seconds; the very slowest rates (≤1 m/s) are the stated detection boundary, addressed on the roadmap. The measured replay is in Section 03; the full results and boundary in Section 07.
The detail
ResearchHumphreys et al., 2008 (a counterfeit that "drags the tracking points off"); Tippenhauer et al., ACM CCS 2011 (the conditions for a seamless takeover).
What defines itThe walk rate — how fast the lie moves. Slower is stealthier, and harder to catch.
Real worldReported: smooth, large-scale position deception over the Eastern Mediterranean, and "circle spoofing" affecting ships near the Strait of Hormuz in 2025–26.

The slow forward-and-back nudge

Roadmap — requires separate validation

The same smooth takeover, but easing the platform forward or back along its own line of travel rather than sideways.

being told you are slightly further along your route than you are — a change that reveals almost nothing about your path.

The detail
Why it's hardA gentle nudge along the direction you're already going is the hardest quiet attack in the catalogue.
StatusAn along-track attack is a distinct case from the tested sideways drag and requires its own validation. It is a roadmap objective (Section 05).

The perfect shadow

The irreducible edge

The most sophisticated attack: hold the platform at a fixed false offset and advance it at exactly its true speed, so nothing about the motion ever appears inconsistent.

a shadow that tracks you perfectly — always the same distance away, moving exactly as you do.

The detail
Honest boundaryThis is the hard theoretical limit of a consistency check — a counterfeit that stays fully consistent leaves no contradiction to find. Bringing it inside the boundary requires additional independent witnesses; once those are added, the adversary is forced beyond a single-signal spoof into a coordinated attack demanding greater knowledge of the target, tighter synchronisation and control of multiple observations at once. Detecting that case is the job of a companion capability on the roadmap.
ResearchPsiaki, O'Hanlon, Powell et al., Two-Antenna Differential Carrier Phase (ION GNSS+ 2014).

The full orchestra

Nation-state grade

A coordinated attack that counterfeits several of the platform's information sources at once, in mutual agreement, so no single check finds a contradiction.

multiple witnesses independently telling the same false account, so cross-checking them reveals nothing.

The detail
Our answerForce the attacker to corrupt everything at once and keep every lie consistent — a cost that compounds with each source they must fake.
ResearchPsiaki & Humphreys, 2016 — no single check covers every mode, which is why coordinated defence matters.
Family 3 Tampering from the inside — infiltration

The wiretap

Inside the machine

The attacker is not in the airwaves at all, but inside the machine — on the wiring after the sensor, introducing a bias into the data as it flows.

altering the contents of a message after it has been sealed but before it is delivered.

The detail
ResearchFawzi, Tabuada & Diggavi (IEEE Transactions on Automatic Control, 2014) — secure state estimation under compromised sensor measurements, with recoverability limits under defined system assumptions.
Our lineThe architecture addresses manipulation on the navigation-data path. Deeper supply-chain compromise requires trusted, authenticated sensing hardware — a separate protection layer on the roadmap.

The stolen key

Key custody

If an adversary steals the secret cryptographic keys, any scheme that relies on those keys is beaten by definition.

the strongest lock provides no protection once the key has been copied.

The detail
Our lineThis is a key-management problem, and we treat it as one — hardware-rooted identity, secure provisioning and key destruction are addressed as a distinct protection layer, not folded into a claim that any single device removes the risk.

In summary: the Black Box detects the attacks that move a platform in ways which quietly contradict its own motion; it is designed to increase the knowledge, coordination and sensing control required for the harder, nation-state-grade attacks at the edge; and the small number that belong to a companion device or to key custody, it names explicitly. A defender able to state precisely what it stops and what it does not is one worth trusting.

03 / The Black Box, Today

The first enforcement node

A single compact circuit board — targeted for a business-card-class form factor (subject to PCB layout, thermal, power and interface validation) — designed for inline integration on the navigation path, between the machine's GPS receiver and the controller that acts on it. From that position it continuously checks the navigation feed against independent motion evidence, and when the accumulated evidence crosses the defined distrust threshold, it is designed to prevent the rejected receiver output from continuing through the navigation-data path. The design aims to avoid replacing the existing receiver or flight controller; physical installation, wiring and interface compatibility are still required and will be confirmed during hardware integration. This is the first physical node of the architecture in Section 01 — a place in the machine where external information is examined before it is allowed to influence control.

Where it sits, in plain termsA normal drone receives a position from its GPS receiver and passes it straight to its flight controller. If the receiver is deceived, the controller may act on the false position — nothing independent stands between them. Nodus Fortis is designed to occupy that missing position: it sits after the GPS receiver but before the controller, checks the position independently, and is designed to prevent an untrusted position from continuing down the navigation path.
What you're looking atA replay of the hero attack from Section 02, from Nodus Fortis's closed-loop simulation. Switch tabs to compare a clean flight, an unprotected drone walked 51.8 m off course with no alarm, and the same 2 m/s drag detected and its input rejected in ~8 seconds. Every figure shown is a measured simulation result [SIM] — it is not a claim about the physical board, which is pending bench validation. The full body of results is in Section 07.
What enters and leaves the boxIn: navigation data from the existing GNSS receiver, together with the independent motion evidence available to the Black Box. Out: trusted navigation data while the input remains credible, or a protected / fail-safe output once the navigation source is rejected. (Once rejected, the compromised position is not permitted to continue unchanged through the protected path. The precise protected output and host-interface behaviour — passthrough, substituted or flagged — plus electrical interface, update rate and latency budget, are platform-specific and defined in the technical specification, available under NDA.)
Three distinct measurements, kept separateDetection time: the simulation currently demonstrates detection and rejection of the ~2 m/s sideways drag in ~8 seconds; slower ≤1 m/s rates are the stated boundary (see Section 07). Isolation after decision: the hardware design is intended to enforce isolation immediately once the distrust threshold is crossed. Physical isolation latency: remains to be measured on the board. [HW PENDING]
What "hardware enforcement" meansSoftware-based protections make their decision inside the receiver, the navigation filter, or the host controller — so their response depends on that same software environment continuing to execute correctly, prioritising the warning and acting on it as intended. A software warning is, in effect, a request: the host may act on it, defer it, weigh it against other sensors, or treat it as advice.

Nodus Fortis is designed to place an independent enforcement point outside that decision environment. Once the defined distrust condition is reached, dedicated logic intervenes directly on the protected navigation-data path — at a boundary external to both the receiver's internal decision-making and the host controller's software trust domain. The host is not merely informed that the source is untrusted: the rejected receiver output is prevented from continuing unchanged through that path. The rejection is not a request.

To be precise: the device is not "software-free" — it uses programmed logic. The distinction is architectural — the decision and its enforcement are separated from both the receiver being assessed and the controller consuming its output. Physical isolation behaviour remains to be measured on the prototype.

Where the technology stands now — Tier 1:

Detection logic
Demonstrated in closed-loop simulation
Hardware design
Schematic + netlist complete; internally reviewed; PCB layout + fabrication package pending
Core method
Provisional patent application filed (Australia); technical material under NDA
Current evidence level
TRL 4 · simulation / lab-oriented stage
What TRL 4 meansTechnology Readiness Level 4 (TRL 4) means the core idea has been demonstrated in a realistic, closed-loop simulation — tested against the ArduPilot autopilot software used on operational drones, not a toy model — but nothing has yet been proven on physical hardware. The hardware design package has also undergone internal technical review against primary manufacturer documentation; an external review can be arranged, with its scope and findings made available to authorised parties under NDA. [DESIGN]

The core detection method has been demonstrated in closed-loop simulation and tested against recorded TEXBAT spoofing scenarios; the results show the underlying detection logic works under the conditions tested, and the boundary of those conditions is stated openly in Section 07. The next stage is physical: complete the PCB layout and fabrication package, build the board, and measure its behaviour under representative sensor, interface, timing and attack conditions — a stage that can reveal timing, signal-integrity, interface, power, environmental and fail-safe behaviour simulation cannot. We have demonstrated the decision; the next milestone is to embody it in hardware and measure its performance in the physical world.

04 / The Vision

From an enforcement node to a defensive architecture

The Black Box is not the end product. It is the first enforcement node of a sovereign trust architecture for autonomous machines.

The foundational decision mechanism has been demonstrated under defined simulation and recorded-data conditions: externally supplied navigation data can be challenged against an independent account of the platform's own motion, and trust withdrawn when the two no longer agree. The first hardware node is designed to enforce that decision on the navigation path; its physical enforcement behaviour remains the next validation milestone. What has been demonstrated is narrow by design. The architecture it enables is not.

What "sovereign" means hereThe trust decision can be controlled, inspected and enforced locally — without depending on a receiver vendor's internal software, a remote service, or an externally controlled decision authority.
How to read this sectionThe capabilities below are research and product directions, not capabilities of the current node. Several require companion sensing, cooperative platforms, or hardware beyond the first board. Each has been architected around the demonstrated decision mechanism and worked through in internal engineering analysis, and each remains subject to its own physical validation gate.
Roadmap — not a current product capability

1 · Bring more attacks inside the boundary

Roadmap

Section 02 names the attacks that remain outside the present line — the slow along-track nudge, the perfectly self-consistent counterfeit. Later capabilities are designed to draw more of that landscape inside, by adding independent observations that a counterfeit must also satisfy. The objective is to shrink the set of attacks capable of remaining consistent across every available source — not to claim that deception can be made impossible.Requires additional independent observations and, for the hardest cases, a companion device.

2 · Catch the attacker, not just the lie

Roadmap

Any jammer or spoofer must transmit, and a transmission is evidence. With companion sensing, and observations shared across multiple protected platforms, the architecture is designed to turn those transmissions into direction and location estimates — making the act of attacking a source of evidence against its origin.Requires companion RF sensing beyond the first board and, for position, cooperative geometry across platforms.

3 · Defend as a trusted fleet

Roadmap

The architecture is designed to let protected machines share what they detect. But a fleet system must do more than pass warnings — it must establish which members and which messages are trustworthy, so that a compromised unit is not automatically trusted and cannot, by itself, determine the group's response. Designed correctly, the fleet routes trust around the deception rather than automatically inheriting it: suspect observations are quarantined, corroborated detections are distributed, and the geographic extent of an attack becomes visible across the group.Requires a secure inter-platform link and an attestation scheme; not implemented in the first node.

4 · Designed to resist capture and cloning

Roadmap

Future variants are designed to bind sensitive material to individual hardware, protect device identity and cryptographic keys, and reduce the intelligence and replication value of a captured unit through tamper detection, secure storage and controlled key destruction. Where device identity, fleet messages or archived intervention records require long-term protection, future variants are intended to be cryptographically agile — including migration to post-quantum algorithms where the threat model and deployment lifetime justify it.Requires the device-identity and key-provisioning work scheduled for a later stage.

5 · Make the attack contribute to the defence

Roadmap

An attack is an emission, and an emission is energy. The architecture is designed to exploit hostile RF exposure in two bounded ways: as a passive threat stimulus capable of waking the security layer, and as an opportunistic contribution to an isolated reserve supporting low-duty security functions after primary power is removed. Core protection does not depend on hostile energy being present. The claim is narrower: energy captured during sufficient exposure may extend tamper evidence, protected logging and controlled secret-destruction after power loss. It is explicitly not a claim to power propulsion, navigation, or the platform itself. Internal analysis defines the exposure assumptions, storage limits and the security functions that fit within that budget.Requires companion hardware not present on the first board; supported by internal power-budget analysis.

6 · One principle, domain-specific variants

Roadmap

The core idea — never let an unverifiable external signal override what a machine can establish about itself — is designed to extend beyond drones: to ground vehicles, crewed aircraft, ships, and ultimately satellites. Each domain would bring its own sensing assumptions, interfaces, validation envelope and certification pathway. One principle, developed into variants. Not one universal board.Requires a separate development and qualification programme per variant.

Why these belong together Layers around one trusted decision

These are not six unrelated products. They are layers around the same trusted local decision. Additional observations strengthen the evidence on which that decision is made. Emitter sensing and cooperative platforms turn local detection into attribution. Fleet attestation lets trusted decisions be shared without automatically trusting every participant. Capture resistance protects the hardware identity, records and secrets on which that trust depends. Domain-specific variants carry the same architectural principle into machines with different sensors, interfaces and certification requirements.

Why the node is the right anchor: a decision made in dedicated hardware, outside the software being protected, is a decision the rest of the architecture can rely on. Attestation, evidence and fleet trust all require a point in the machine that can be trusted more than the machine around it. That is what the node is designed to be.

Not every later capability is proven by the foundational demonstration, and each has its own engineering and validation programme. What the demonstration establishes is the decision around which they are organised: external navigation information is no longer accepted by default — it must earn the right to influence control.

One demonstrated decision mechanism. One physical enforcement node. A defensive architecture built around it.

SubstantiationTechnical substantiation for the directions above — including the power, sensing and cryptographic requirements each would impose — can be made available to authorised government, defence and research parties under NDA.
05 / The Roadmap

From a demonstrated decision to a fielded trust architecture

The roadmap separates what has been demonstrated, what funding is being sought for now, how the node reaches the field, and what is built afterwards. Each stage carries its own dependencies and its own validation gate. Nothing later is assumed to work because something earlier did.

  • DemonstratedDecision foundation

    The decision mechanism demonstrated; the first hardware implementation designed

    The decision logic has demonstrated autonomous detection under defined conditions — in closed-loop simulation against the operational ArduPilot flight-control stack, and against recorded spoofing scenarios from the TEXBAT public benchmark. The digital logic has passed synthesis and timing closure on the target device.

    The schematic and netlist are complete and have undergone internal technical review against primary manufacturer documentation. PCB layout, design-rule verification and the final fabrication package remain outstanding before manufacture. No physical-board performance is claimed at this stage.

    Nodus Fortis presently self-assesses the decision-logic maturity at approximately TRL 4, based on closed-loop simulation, recorded-data evaluation and target-device digital implementation. The physical enforcement node has not been validated on a fabricated board. Formal maturity classification will be determined under the framework used by the relevant funding or procurement authority.

  • Funding sought nowThe first enforcement node

    Build and characterise the first boards

    Complete the PCB layout and fabrication package. Fabricate, assemble and test the first physical prototypes. Measure what simulation cannot: electrical interface behaviour, post-decision isolation latency, signal integrity, power consumption, real-sensor false-intervention behaviour, fail-safe transitions and preliminary EMI/EMC performance.

    Testing at this stage is conducted under an independently reviewed test plan, with the completion tests independently witnessed and the resulting evidence made available for external assessment.

    Completion gate
    The phase is complete when a functioning physical prototype:

    • executes the frozen decision logic and identifies the defined deception scenarios using live electrical interfaces and controlled, representative GNSS and motion inputs;
    • prevents rejected receiver data from continuing unchanged through the protected path within the specified post-decision latency budget (measured from the distrust decision, not from attack onset);
    • completes the defined clean and manoeuvring control suite without false intervention across that envelope, with every intervention and non-intervention recorded so a preliminary false-intervention rate can be reported;
    • enters the specified deterministic fail-safe output state after rejection;
    • generates a time-aligned intervention record sufficient for an independent evaluator to reconstruct what entered the device, why distrust was declared, and what output action followed;

    — with a documented go/no-go decision on progression to relevant-environment trials. This is what is being funded. The gate is the deliverable. Indicative programme duration, work packages and funding envelope are available to authorised parties.

  • NextRelevant-environment validation

    Move the first node from the bench into a representative platform

    Integrate the prototype with a representative receiver, motion-sensing suite and flight controller. Exercise the complete protected navigation path under controlled motion, representative RF conditions and defined spoofing scenarios. Characterise detection performance, false-intervention behaviour, interface latency, fail-safe transitions and recovery across the intended operating envelope. The purpose is not to add features — it is to determine whether the demonstrated decision mechanism and the physical enforcement node continue to perform under the timing, noise, motion, interference and integration conditions of a real platform.

    Completion gate
    Independently witnessed relevant-environment results, a documented protection envelope, identified residual failure modes, and a go/no-go decision for operational trials. The preferred pathway is a jointly defined trial with a government, defence, autonomous-systems or platform-integration partner whose operational scenario can establish the first product requirements.Requires completed prototype characterisation, representative platform access, controlled RF-test capability and an operational test partner.

  • NextExpanded protection envelope

    Widen the detection boundary

    Extend coverage below the currently demonstrated detection boundary — beginning with the slower sideways drags (0.5 and 1.0 m/s) that the frozen configuration does not presently detect, then the along-track cases, and then more self-consistent deception — through additional independent observations and companion sensing. This widens the envelope; it does not abolish the theoretical limit: a counterfeit that remains consistent across every trusted source leaves no contradiction to find.Requires additional independent observations; the hardest cases require a companion device.

  • NextFrom detection to attribution

    Locate the emitter

    Introduce companion RF sensing and cooperative geometry across protected platforms to estimate the direction and location of a jammer or spoofer.Requires companion RF sensing hardware and, for position, multiple participating platforms.

  • LaterCooperative defence

    Defend as a trusted fleet

    Allow protected platforms to exchange authenticated observations, identify the geographic extent of interference, and coordinate a response without relying on any single platform's report — with member attestation, so a compromised unit is not automatically trusted and cannot, by itself, determine the group's response.Requires a secure inter-platform link and an attestation scheme.

  • LaterProduction & security hardening

    Protect the architecture itself

    Protect device identity, cryptographic keys, intervention records and manufacturing provenance. Advance environmental, EMI/EMC, tamper-resistance and production-readiness work according to the intended deployment class. Bounded energy persistence for security-critical functions is carried here as a long-horizon research stream.Requires the device-identity and key-provisioning programme.

  • LaterDomain-specific variants

    Carry the principle into new machines

    Develop separately validated variants for aerial, ground and maritime platforms — each carrying the same enforcement principle into a different sensing environment, interface architecture and qualification pathway. Crewed aviation and orbital applications remain longer-horizon programmes with substantially different qualification requirements.Requires its own development and qualification programme per variant.

  • VisionThe intended end state

    A distributed navigation trust architecture

    A family of hardware-enforced, domain-specific systems designed to detect and isolate deceptive navigation, expose hostile emitters, support authenticated fleet response, and preserve independently checkable evidence of every intervention. The objective is to make practical deception substantially harder, more resource-intensive and more observable — while continuing to state the residual boundary plainly.

06 / Why Now

The threat is operational — and allied investment is accelerating

What was a laboratory curiosity is now a standing feature of modern conflict, bleeding into civilian life. The figures below are public reported figures, presented as reported.

122,607
flights reported affected by GNSS interference, Baltic region, Jan–Apr 2025
Reported — interference/jamming, not confirmed spoofing
5,600+
GPS-spoofing occurrence reports logged in ~two months in Cyprus's Nicosia flight-information region — the most of any tracked airspace
Reported: Cyprus CAD (via OPSGROUP)
Hormuz
commercial vessels near the Strait reported false GPS positions displaced from their true locations, 2025–26
Reported
€10M
joint NATO–Ukraine programme for resilient navigation, launched late 2025, with plans to scale
Reported figure

Allied investment is accelerating

When NATO and partner nations fund resilient navigation in GPS-denied and electronic-warfare conditions, it shows the broader capability category has moved from research concern to active defence priority — the category Nodus Fortis addresses.

Australia needs an Australian-controlled option

Resilient PNT is widely treated as a defence priority across allied nations, Australia included, and this technology is dual-use. Sovereign ownership would preserve Australian control of the core intellectual property — a provisional patent application covering the device has been filed in Australia — together with design authority, security architecture and future integration priorities, and could provide an Australian-controlled alternative to systems dependent on foreign cryptographic access or export-controlled integration pathways — while recognising that component-level supply-chain sovereignty requires separate qualification. It aligns conceptually with AUKUS Pillar II priorities in autonomy, electronic warfare and resilient systems — an alignment statement, not a claim of formal endorsement.

Funding now produces the decisive evidence

The decision logic has produced encouraging closed-loop and recorded-data results, and the hardware design has completed schematic and netlist with internal review; PCB layout and the fabrication package remain before manufacture. The next phase is bounded and measurable: fabricate the first prototypes, characterise their electrical and physical behaviour, test them with real sensors and representative attack inputs, and subject the results to independent observation. Targeted funding now converts a designed capability into evidence that government, defence and integration partners can evaluate.

A defined boundary is a testable capability

Nodus Fortis does not claim navigation deception can be made impossible. It states which attacks are inside its protection boundary, which remain outside it, and what evidence supports each. That boundary is operationally useful: it lets the capability be tested, compared and integrated against a known threat model rather than an advertised one.

The Black Box does not promise the impossible. The objective is not to stop every conceivable deception, but to reject practical attacks and force a successful adversary toward methods requiring greater knowledge of the target, tighter coordination, more sophisticated equipment and greater exposure. (Locating the transmitter is a roadmap capability, not part of the demonstrated current tier.) The hardware is the product; the clearly stated operating boundary is what makes it testable and trustworthy.

The immediate opportunity: Nodus Fortis is seeking funding for prototype fabrication and bench validation, together with an independent validation partner able to test interface behaviour, isolation latency, real-sensor false-intervention performance, fail-safe operation and preliminary EMI/EMC characteristics. Specific funding amount, duration and completion outputs are available on request.

Nodus Fortis · Australian sovereign navigation-resilience venture · Launceston, Tasmania, Australia
mia@nodusfortis.com · 0422 156 677
Technical test material, internal design-review material (an external review can be arranged) and protected capability details are available to authorised government, defence and research parties under NDA. Request a briefing
07 / Closed-Loop Evidence

The evidence behind the decision

The test results behind Section 03: the principal closed-loop attack result, the clean-flight control that anchors it, and a data-integrity test. Every figure is a measured result from software-in-the-loop simulation, run against the ArduPilot / ArduCopter autopilot software used on operational drones — not a claim about physical hardware. [SIM] · TRL 4 (Nodus Fortis self-assessment)

How to read each cardEach card identifies the test condition, what happens without protection, and how the Black Box responds — with the measured time-to-detect and how far the drone had moved when it was detected. Green = detected, or correctly silent. [SIM] · TRL 4 (self-assessment) — closed-loop software-in-the-loop simulation, single drone type; no bench-hardware result yet.

Test environment: ArduCopter SITL (Software-in-the-Loop) · EKF3 state estimator · multirotor model · an idealised sensor-noise model (a simplified representation of sensor behaviour that does not yet reproduce every imperfection, vibration, bias and environmental effect of physical sensors).
Principal result The sideways drag — caught in the closed loop

The sideways drag

Detected at 2 m/s

The attacker takes over the signal smoothly and eases the drone's apparent position sideways — a few centimetres at a time — slowly enough to avoid any crude discontinuity alarm.

a satnav nudging you one lane over, then another, so gently you never notice you've been driven to the wrong place.

Unprotecteda 2 m/s sideways drag walked the drone 51.8 m off course with no alarm — the drone's own ArduPilot failsafes never fired, because the receiver output stayed structurally valid.
Black Boxidentified the drag and flagged the receiver input as untrusted in ~8 seconds, with the drone roughly 9 m off its true position at that point. Within the simulation, the navigation path transitioned to its rejected-input state; the host autopilot then followed its own loss-of-GPS response.
Why the timing mattersFor this attack, being caught early is the whole value. Identified at ~9 m of drift — on an attack that would otherwise reach 51.8 m — the deception is flagged long before it can carry the platform to the wrong place. (This early-detection result applies to the tested 2 m/s rate; the slower rates are addressed below.)
Evidence boundaryOne tested geometry, one multirotor configuration, an idealised sensor-noise model. The frozen configuration produced a modelled rejection for the tested ~2 m/s drag; the tested 0.5 and 1.0 m/s drags remained below its threshold. Repetition across seeds, manoeuvres, environments and physical sensors remains future verification work.
The measured three-rate sweep — one frozen configuration
MethodThe same sideways-drag attack was applied at three rates through one frozen detector configuration (no per-rate tuning), to establish where the position-consistency check detects and where its boundary lies.
0.5 m/sNot flagged — below the frozen detector's boundary. At the slowest rates the position innovation stays under the threshold. This is a stated limitation.
1.0 m/sNot flagged — below the frozen detector's boundary, by the same mechanism.
2.0 m/sFlagged at ~8.3 s; the drone was ~9 m off its true position at that point, and the modelled navigation path transitioned to its rejected-input state. What follows is governed by the host autopilot's own loss-of-GPS response, not by Nodus Fortis: in this run the vehicle continued under that host behaviour to about 25 m total cross-track, against 51.8 m left entirely unprotected. Nodus Fortis identifies and rejects the compromised input; it does not itself return the vehicle to course. Automatic return-to-track is a roadmap capability.
Held constantSame idealised sensor-noise model, vehicle settings and detector configuration across all three rates; configuration frozen before the sweep. One tested geometry per rate. Full parameters are available under NDA.
TraceabilityLogic/RTL version and scenario identifier on file; ArduPilot SITL build recorded; single seed; t = 0 at spoof onset; configuration frozen before the sweep with no per-rate tuning. Full parameters (including thresholds) available under NDA.
Closing the slow-rate boundaryThe frozen configuration produced a modelled rejection for the tested 2 m/s drag, with no false intervention during the single clean-flight control. The slower ≤1 m/s cross-track drag is a known, stated boundary. Internal simulation indicates a companion-witness approach may detect the tested slower cases; this remains roadmap evidence requiring broader testing, available for review under NDA. [ROADMAP]
Supporting tests Clean-flight control and supporting data-integrity test

Clean-flight control — no attack

No false intervention ✓

A normal flight from take-off to cruise, with no spoofing at all — the essential control, and the one that matters most for trust: a detector that intervenes when nothing is wrong is worthless.

Without boxflies normally.
Black BoxNo false intervention occurred during the single clean-flight control, including take-off and the simulated manoeuvre transitions.
Test scope
ScopeOne clean-flight control · full simulated flight window (take-off through cruise) · single seed · idealised sensor-noise model.
Honest limitOne clean run is a successful control, not a general false-positive rate. Broader false-positive testing across additional flights, manoeuvres and sensor/noise conditions forms part of the next verification stage.

Simulated trusted-path data alteration

Detected

This test introduced an unauthorised alteration into the modelled trusted data path — testing the logic's response to a defined data-integrity condition. It is not a physical tamper-resistance test: it does not test enclosure opening, board probing, voltage or clock manipulation, memory extraction or physical key protection.

Without boxthe altered data flows on, unnoticed.
Black Boxthe model transitioned from the integrity-violation decision to its rejected state within one simulation timestep (~0.2 ms in the configured model) — a software-in-the-loop result, not a prediction or measurement of physical isolation latency.
What "fail safe" means hereIn this test, fail safe means the compromised navigation input is rejected and prevented from continuing to influence the controller. It does not mean the Black Box has independently restored the original mission path. After rejection, the host controller enters its configured navigation / loss-of-GPS response, which depends on the host's onboard sensors and flight-control settings.
What the evidence demonstrates — stated honestlyUnder the tested software-in-the-loop conditions, the decision logic autonomously identified the defined sideways position-deception at ~2 m/s, remained silent during the single clean-flight control, and transitioned the simulated navigation path to its rejected-input state — identifying the attack early, while the drift was still small. These results support the operation of the decision logic under the stated model and configuration — autonomous detection and modelled rejection of the compromised input within the software-in-the-loop environment. Physical navigation-path isolation latency, performance with real sensors, a general false-intervention rate, physical tamper resistance, and automatic restoration of the original mission path ("return-to-track") are not yet demonstrated — they are explicit objectives of prototype fabrication, bench characterisation and subsequent platform testing. [ROADMAP]
08 / TEXBAT Results

Tested against TEXBAT — a recognised public spoofing benchmark

TEXBAT — the Texas Spoofing Test Battery, developed by the University of Texas at Austin — is a public collection of recorded live GNSS/GPS-spoofing tests. It is the standard against which the field evaluates whether a detection method recognises different forms of counterfeit GPS signal. Using it means being tested on attacks Nodus Fortis did not design.

We ran the Black Box's position-checking logic against the TEXBAT scenarios relevant to the deception it is built to detect. Official TEXBAT dataset — University of Texas at Austin ↗

Read the evidence boundary firstThese are internally generated results obtained by processing recorded TEXBAT signals through Nodus Fortis software (maturity: TRL 4 self-assessment). They are not physical-board results, independent certification or TEXBAT certification.

Some scenarios were processed through an in-house software receiver that was separately checked against a surveyed reference position. The dynamic ds6 result uses a synthesised motion reference without fully independent moving-platform ground truth, and is the fastest observed trigger but the least independently grounded. Read these as evidence that the detection mechanism behaves as intended under the tested conditions — not as final hardware validation. [SIM] · [RECORDED DATA] · TRL 4 (self-assessment)
In-scope vs boundary — both answers are correctIn-scope attacks move the receiver's solved position — the inconsistency the Black Box is built to catch. Boundary attacks move the receiver's clock/timing, not its position — so the processed output did not contain the position-layer inconsistency this detector is designed to act upon, and the Black Box correctly stays below its detection threshold (timing deception can still affect other platform functions). On a boundary row, "silent" is the right answer, not a miss. A TEXBAT scenario named as a time push is described here by its observed position-layer effect in our processing — the benchmark's own terminology is unchanged. Detection time is measured from spoof onset, not from the start of the recording.
ScenarioTEXBAT attack (official) & plain descriptionPlatformScopeObserved position-layer effectResultDetected in
ds1Static switchGenuine GPS signal suddenly replaced by a counterfeit while the receiver is stationary — as though the real GPS were unplugged and a fake one connected.Static—Not evaluatedNot evaluated †—
ds2Overpowered time pushA much stronger counterfeit gradually corrupts the receiver's sense of GPS time.StaticMixedMostly a clock/timing shift, with a small position residualDetected~17 s
ds3Matched-power time pushA power-matched counterfeit gradually deceives the receiver.StaticIn-scopeGradual position driftDetected~58 s
ds4Matched-power position pushA power-matched counterfeit eases the stationary receiver's position off its true point.StaticIn-scopePosition pushed off the fixed pointDetected~95 s
ds5Dynamic overpowered time pushThe receiver is moving while an overpowering counterfeit gradually corrupts its sense of GPS time.Dynamic—Not evaluatedNot evaluated †—
ds6Dynamic matched-power position pushA power-matched counterfeit eases a moving receiver's position off its true path.DynamicIn-scopePosition pushed off the moving pathDetected ‡~1 s ‡
ds7Matched-power time push (carrier-aligned)A power-matched, carrier-aligned counterfeit shifts timing while leaving position steady.StaticBoundaryTiming shifted; position steadyNo position-layer trigger—
ds8SCER time pushA security-code estimation-and-replay variant of the timing attack.StaticBoundaryTiming shifted; position steadyNo position-layer trigger—

† ds1 & ds5 not evaluated. ds1 and ds5 have not yet been processed through the complete Nodus Fortis software-receiver pipeline. They are therefore reported as unevaluated, with no result and no prediction claimed either way, and remain part of the planned expanded benchmark programme.

"In-scope", "mixed" and "boundary" are Nodus Fortis classifications based on the position-layer effect observed in our receiver processing — they are not official TEXBAT classifications. TEXBAT officially describes ds3, for example, as a matched-power time-push scenario; in our receiver processing it produced a gradual position-layer drift, and that observed output is why it is treated as in-scope here.

‡ ds6 — the fastest observed trigger, and the least independently grounded. Read the two together. There is no independent moving-platform ground truth (the reference is a self-consistent clean twin), the motion reference is synthesised, not a physical sensor, and its clean baseline rests on a thin sample. ds6 is evidence that the mechanism responds on a moving platform under the tested conditions — not an independently validated result, and not comparable in strength to the static cases.

The result that matters most. ds3 and ds7 were processed through the same receiver, in the same regime, at the same frozen threshold. ds3 (a gradual position drift) was detected; ds7 (a carrier-aligned timing shift that left position steady) produced no trigger. That the same unchanged detector separates a genuine position drift from a timing-only attack — with no re-tuning between them — is the core evidence that the position-layer distinction is real, not an artefact of configuration.

Evaluated in-scope position cases detected
3 of 3 · ds3, ds4, ds6
Boundary / timing cases
no position-layer trigger
Sources of navigation solution
1 external (UT Austin) + 1 in-house
Evidence class
[SIM] · [RECORDED DATA]

Six of the eight TEXBAT scenarios were included in this evaluation; the remaining two (ds1, ds5) are shown with their status and reason. The position solutions came from two sources of navigation solutions: the University of Texas laboratory's own published solution for the pre-solved scenarios (including the cleanStatic reference), and an in-house software-defined receiver — gate-checked against a surveyed ground-truth position — for the three that exist only as raw recordings. This is not independent third-party verification.

How the receiver evidence was produced
Pre-solved (4)cleanStatic (the clean reference stream, not an attack scenario), ds2, ds3, ds7 — solved using the University of Texas Radionavigation Laboratory's own published navigation solution. This is an external receiver output; we did not build it. So the evaluation covered six attack scenarios plus one clean reference.
Raw-only (3)ds4, ds6, ds8 — TEXBAT provides these only as raw recorded radio, never solved by the laboratory. We built an in-house GPS L1 C/A software-defined receiver — a standard signal chain (signal acquisition → tracking → navigation-message decode → position solution) — to turn the raw recording into a position stream. This is the test instrument that produces the position; it is separate from, and reveals nothing about, the detection method.
Gate-checked before useBefore it was trusted on any attack scenario, the in-house receiver had to reproduce a surveyed ground-truth position (a location known to the millimetre) to within a few metres, with no drift. It agreed with the surveyed point and with the laboratory's own solution to ~2–3 m on the clean recording — the cross-check that justifies using it on the raw-only attacks.
Honest limitThe in-house receiver is our own implementation — gate-checked against ground truth, but not independently verified by a third party — and the moving-platform (ds6) solve carries the additional caveats noted above. Full receiver build and validation detail is available in the technical data room under NDA.
On the thresholds — three, each clean-calibratedThe detection logic was frozen before the TEXBAT evaluation. The distrust threshold was calibrated on clean, no-attack data for each processing regime, then applied unchanged across every attack scenario in that regime. In practice this meant three clean-calibrated thresholds — one for the external static receiver (ds2, ds3, ds7), one for the in-house static receiver (ds4, ds8), and one for the in-house dynamic receiver (ds6). No threshold was tuned on attack data, and no individual scenario was tuned. The specific values are held under NDA; what matters for reading these results is that each configuration was fixed on clean data before any attack was seen.

What the evidence shows. Within this evaluation, the Black Box detected every tested scenario that produced an in-scope position inconsistency, and stayed below its threshold on the timing-only cases that did not. Detection times ranged from about one second (ds6, with its caveats) to about 95 seconds, each measured from spoof onset. Most tellingly, the same unchanged detector separated a real position drift (ds3) from a carrier-aligned timing attack (ds7) in the same regime and at the same threshold.

These are internally generated results at TRL 4 self-assessment, not third-party certification, and the ds6 result rests on a weaker reference than the others. Taken together, they are credible evidence that the position-checking principle behaves as intended against recorded attacks it did not design for. Physical implementation, broader testing and independent reproduction are the next proof points.

[SIM]Demonstrated in software or closed-loop simulation
[RECORDED DATA]Tested using previously recorded external signal data
[DESIGN]Designed but not yet implemented physically
[HW PENDING]Requires physical hardware confirmation
[INDEPENDENT REVIEW]Reviewed externally; not necessarily independently reproduced
[ROADMAP]Future capability, not demonstrated today
09 / The Landscape

Existing systems protect navigation. Nodus Fortis acts at a different trust boundary.

Serious anti-spoofing and resilient-navigation systems already exist. Some authenticate satellite signals, some reject interference at the antenna, and others combine inertial, visual and alternative sensors to continue navigating when GNSS becomes unreliable. These systems are technically credible; several are operationally mature and fielded with major defence primes. They work.

Nodus Fortis is designed around a different integration point: after the existing GNSS receiver and before the controller. Its intended role is not simply to produce another spoofing warning, but to enforce the trust decision independently of both systems. The difference is not whether the lie is caught — it is where the trust decision is made and how it is enforced.

In plain termsExisting systems protect navigation in different ways — a better GPS receiver, a better navigation computer, a stronger antenna, or added sensors such as a camera. Nodus Fortis is designed around a different point: it sits after the receiver and before the controller, and enforces the trust decision independently of both — designed to avoid replacing either (installation, wiring and interface compatibility are still required).
The comparison Where each system sits — fair, accurate, one row each
SystemProtectsIntegration requirementIts referenceWhere it acts
Advanced NavigationCertus / Boreas — inertial navigation units that fuse GNSS with inertial sensors and reject spoofed GNSS, continuing on inertial nav.positionintegrate a high-grade INS + its aiding sourcesinertial — accumulates error over timeon-platform INS hardware
UAV Navigation — Grupo OesíaGNSS-denied nav kit — inertial + visual stack; a camera re-anchors accumulated inertial error to keep flying.positionadd an inertial + visual navigation kitinertial + visual (camera added to fight drift)on-platform navigation computer
Septentrio AIM+Receiver-resident anti-jam / anti-spoof; layered signal-anomaly checks with OSNMA authentication where available.signalreplace your GNSS receivercryptography + signal metricsinside the receiver
Microchip BlueSky FirewallInline firewall between antenna and receiver; flags jamming/spoofing from raw RF observables. Protects timing for fixed infrastructure.timinginsert before your receiverraw signal observablesupstream of the receiver (RF/signal)
GPSPATRON GP-ProbeInline probe between antenna and receiver; multi-channel RF analysis detects and classifies spoofing. Physical RF isolation requires the separate GP-Blocker.signal / timinginsert a probe before your receivermulti-antenna RF / signal observablesupstream of the receiver (RF/signal)
Huld Block-boxESA NAVISP-funded FPGA "RF2RF" device around a COTS receiver; AI threat detection plus DSP signal recovery and retransmission.signalinsert in the RF path around your receiverRF signal / AI classificationupstream of the receiver (RF domain)
Military assured PNT — MAPS GEN IIAssured-PNT architecture: a nav hub (NavHub-100) distributing trusted PNT + a CRPA / M-code multi-sensor antenna (MSAS-100).position + timingfit CRPA antenna + M-code, hold crypto keys, carry the SWaPencrypted signal + antenna geometry + sensor fusionvehicle-wide assured-PNT architecture
Nodus FortisInline hardware trust layer after the receiver and before the controller; checks position consistency and isolates untrusted position.position (the trust decision)add inline — designed to avoid replacing receiver or controllera reference designed not to accumulate position error through inertial integrationin hardware, after the receiver / before the controller — by design, outside both software trust domains
On the two closest architecturesThe GPSPATRON GP-Probe and Huld Block-box are the nearest neighbours: both are inline, and both can act on the signal itself (isolate or clean it). But both act upstream of the receiver, in the RF / signal domain — they judge the signal before the receiver solves a position. Nodus Fortis acts after the receiver, on the solved position, at the boundary before the controller. Same instinct — put a dedicated device in the path — but a different layer, a different quantity, and a different trust boundary.

① The decision is made outside the software the attacker is influencing. Most competing protection lives inside the navigation chain — within the receiver, the antenna system, the inertial-navigation computer, or the host navigation software. Its response therefore depends on that same software continuing to execute correctly, prioritising the warning, and acting on it. A software warning is, in effect, a request the host may act on, defer, weigh against other sensors, or treat as advisory. Nodus Fortis is designed as a separate hardware trust boundary, after the receiver and before the controller:

  • The GNSS receiver does not decide whether its own output should be trusted.
  • The flight controller does not decide whether to obey the warning.
  • Host software is designed to be unable to force rejected receiver data back through the isolated path.
  • Once distrust crosses the defined threshold, dedicated hardware controls the navigation-data path.
  • The protection is designed to be added without replacing the receiver or controller.
In plain languageOther systems improve one of the components already inside the navigation chain. Nodus Fortis is designed to stand between those components and independently determine whether navigation data is permitted to pass. Installation, wiring and protocol compatibility remain required and will be confirmed during hardware testing.
② A detection reference designed not to accumulate position errorLook closely at the reference column. INS-based navigation-continuity systems build their reference by integrating inertial measurements over time — and integration accumulates error. Two vendors in the table above manage it at real cost: one adds a camera to keep re-anchoring the estimate; another uses fibre-optic gyroscopes to slow the accumulation. Both are buying down a problem inherent to how the sensor works — in cost, size, weight and power.

The Nodus Fortis detection reference is designed not to construct position through continuous inertial integration, avoiding that specific source of accumulating error. It does not remove noise, bias or uncertainty, and it does not escape the shared theoretical limits of consistency-based detection (see below). That is part of why the device is designed to be small, low-cost and inline rather than a premium replacement unit. (How that reference works is the core of the invention and is not disclosed publicly.)
The honest boundaryWe say plainly what we are not. We do not catch every attack: a counterfeit engineered to be perfectly self-consistent — a fixed false offset moved at exactly the true speed — leaves no inconsistency for any consistency-based system to find. That is a shared theoretical limit of this entire family, ours included. And attacks that push a platform's clock rather than its position are outside the present position-layer decision scope — correctly so for steering, though timing faults can affect other platform functions.

We are also honest about maturity: the detection logic is demonstrated in closed-loop simulation and tested against the recognised public TEXBAT benchmark; the physical board is designed, internally reviewed, and pending PCB layout, fabrication and bench validation. (See Section 03.)

Existing systems prove the threat is real and that customers will pay for resilient navigation. Nodus Fortis does not claim that spoofing detection is new — its intended distinction is where the trust decision is made and how it is enforced: independently, after the receiver, before the controller, in dedicated hardware, by design outside both software trust domains, while preserving the receiver and controller already fitted. In that sense it is a different product category, not a better version of the same one — the systems above improve a component, replace one, or add an inline device in the RF path, whereas Nodus Fortis is designed to stand between components and enforce the trust decision itself.

Based on publicly available product information reviewed as of July 2026 — a review of public information, not a claim about classified or unpublished systems — we found no documented equivalent that makes the trust decision at this integration point, after the receiver and before the controller, on independent position-consistency, and enforces it in dedicated hardware while preserving the installed receiver and controller. Physical-board validation is the next step in proving that distinction.

10 / The Hardware Validation Phase

From demonstrated logic to independently tested hardware

The detection logic has been demonstrated in closed-loop simulation and internally evaluated against six of TEXBAT's eight attack recordings (Sections 07 and 08). The target-device digital logic has passed synthesis and timing closure.

The schematic and netlist are complete and have undergone internal technical review against primary manufacturer documentation. PCB layout, design-rule verification and the final fabrication package remain outstanding before manufacture. No physical prototype has yet been built or tested. Completing and independently characterising that prototype is the phase for which funding is being sought.

Three kinds of evidence, kept separateAll detection-performance evidence reported so far comes from closed-loop simulation and recorded-data evaluation. Separate implementation evidence includes target-device synthesis and timing closure. No detection, isolation, latency, power or interface performance has yet been measured on a fabricated board. We keep these three classes distinct rather than letting one stand in for another.
What the bench phase establishes The questions simulation cannot answer

Simulation cannot answer the electrical, timing and failure-behaviour questions that determine whether the enforcement node works as a physical product. The prototype phase is designed to measure:

  • operation across real receiver-to-controller electrical interfaces, protocol rates and message conditions;
  • execution of the frozen detection logic on the fabricated hardware, using controlled, representative navigation and motion inputs;
  • post-decision isolation latency — the time from distrust declaration to enforcement on the physical data path, measured rather than estimated;
  • the deterministic output presented to the host after rejection;
  • preliminary false-intervention behaviour across a defined clean and manoeuvring hardware-in-the-loop suite;
  • startup, shutdown, reset, brownout, watchdog and invalid-input behaviour;
  • power consumption, thermal behaviour, signal integrity and preliminary EMI/EMC characteristics;
  • repeatability across prototype units and repeated runs;
  • generation of a time-aligned intervention record from which an evaluator can reconstruct the input, the decision, and the enforced response.
Bench vs relevant-environment — kept separateThe device is assessed with physical sensors and live electrical interfaces under controlled bench and hardware-in-the-loop conditions, followed in the next stage by representative platform motion and environmental testing. Bench evidence and relevant-environment evidence are kept separate.
The spoofing testsDetection is exercised as a system-level response to controlled spoofing scenarios delivered through a GNSS simulator or recorded-RF test chain in an appropriately contained test environment, with the physical receiver, the Nodus Fortis prototype and the host interface operating together. Nodus Fortis is not itself an RF receiver: the test equipment deceives the installed receiver, and the prototype then assesses the resulting position output — the same division of roles as in the fielded device.
How the results will be judgedEach measurement above is being defined as a pass-or-fail criterion before testing begins — a defined bar the prototype must clear, rather than an outcome described after the fact. Before completion testing begins, the hardware revision, programmable-logic version, test scenarios, measurement definitions and acceptance criteria are frozen under version control. Any change made after a failed test creates a new test configuration and requires the affected completion tests to be repeated. The detailed test-and-validation plan — the specific equipment, scenarios and acceptance criteria — is available to funding and evaluation partners under NDA.
Independent validation, at three levelsThe proposed model is precise about what "independent" means: independent review of the test plan before execution; independent witnessing of the decisive completion tests; and provision of the resulting configurations, logs and measurements for external assessment. Full independent replication is a later proof point unless included within the funded work package.

What this means for where we are. The decision mechanism has been demonstrated under defined simulation and recorded-data conditions. The pre-layout electrical design is complete; PCB layout, fabrication and physical validation remain. The next step is bounded, fundable and measurable: build the enforcement node and prove, against predeclared criteria, how it behaves on physical hardware. Successful completion would convert a demonstrated mechanism into an independently assessable prototype and provide the evidence required to progress to relevant-environment trials. It would not, by itself, constitute a fielded or qualified capability.

The funded deliverable is not merely a fabricated board. It is an independently assessable body of physical evidence, judged against a bar defined in advance.

00 / 10