Cyber defense that runs inside the satellite.

A security core on a processor your spacecraft already flies with. It detects and quarantines attacks as they occur without ground contact, in just 114 KB of software, at the same constant cost per packet. With no new chip, no additional mass, no modification to power budget.

drag to rotate  ·  click a satellite to inspect its module
114 KB
Total flight footprint
303.6 µs
Fixed cost per packet
O(1)
Cost per decision
0.9911
Held-out ROC-AUC
Overview

Every satellite in orbit today trusts whatever reaches it.

Spacecraft security is nearly exclusively a ground segment affair. If the link gets jammed, if the spacecraft loses contact, or if the ground station itself is compromised, the spacecraft has nothing on board to help it distinguish a real command, or a real command altered in transit, from an imposter. Quaranet puts that judgment call down onto the spacecraft as a deterministic core that is programmed with high-dimensional arithmetic, not a neural network, so the cost of each packet is precisely the same and a stray bit-flipping error in space cannot change the answer without being noticed.

The threat surface

The 2022 Viasat attack disabled tens of thousands of terminals across Europe and it never left the ground segment. As the ground hardens, the attack climbs the chain: the spacecraft is the next link.

Framing note. Viasat/KA-SAT was a ground-segment compromise. Quaranet would not have stopped it, and we are not going to imply otherwise. We cite it because it is the clearest public demonstration that space systems are now a target worth the effort, and because the segment that is left once the ground is hardened is the one we defend. Reflecting CISA and ENISA advisories, 2022.
Why ground defense stops at the horizon

You cannot carry the firewalls of Earth up into space. Dynamic memory cannot perform without fragmentation and potential lockup under a hard real time deadline. Standard models go softly corrupt under cosmic rays: the answer changes, nothing notices. Data-dependent execution paths invalidate flight software certification. Small quantized nets will run on flight hardware, but come without constant time performance and fault-tolerant model memory. Orbit demands deterministic, highly efficient arithmetic.

Why now

Onboard defense is turning into a design requirement.

For twenty years spacecraft security meant securing the ground station. Three things changed that at roughly the same time, and none of them is a sales argument we invented.

01
The standard now names the spacecraft itself.

In March 2026 the IEEE Standards Association accepted P3536, a new international standard meant to make cybersecurity a part of a space system's design, not something added later in life to systems once they are already in space. The standard includes definitions of controls for multiple modules, from the ground system, the link layer and an integration layer, down to the vehicle itself. Space systems that are only protecting their ground segments have no capability to offer controls for that vehicle column.

IEEE SA Standards Board approval, 26 March 2026 · IEEE P3536, Standard for Space System Cybersecurity Design.
02
Policy asked for it before the standards did.

In 2020, US Space Policy Directive-5 established guidelines on space system cybersecurity that specifically included protecting commands, control and telemetry from interference and outside control. For most of a space vehicle's life the ground station is not even in sight of the vehicle. Ground based control is no control at all in these cases.

Space Policy Directive-5, Cybersecurity Principles for Space Systems, 4 September 2020.
03
The economics stopped favouring hardware.

A constellation is all but identically cloned spacecraft operating a single software image. Any system that must ship on a per vehicle basis must be qualified, and the cooling and power paid for on every ship. A system that ships as a software bundle only has to be written once and costs nothing to replicate. It seems clear this disparity will determine which defenses are actually flying on these constellations.

Architecture

It ships as software. That is the whole point.

Quaranet is a library linked into the existing flight software you are writing. It is not a box that bolts to the bus. All measurements hereafter are at the current software core. If there is a target rather than a product, it is noted as such.

SPEC 01 / 03
Zero new hardware
114 KB

Quaranet compiles into your flight image and runs bare-metal on your Cortex-R or Cortex-M family ARM processor that is already in the box. No new part number. No supplier qualification. No new bus interface or addition to power or thermal budgets. Integration is linking against an existing no_std static library through a C interop interface.

The model fits in 116,808 bytes and fits into the 256 KB tightly coupled RAM of an R5F within a Zynq UltraScale+ chip. It runs at 44.6% utilization, so it sits outside cache and in deterministic memory.

There is an FPGA accelerator, verified at RTL simulation in single-clock latency. This could be an option in new hardware, but is not needed.

Software-first · FPGA optional
SPEC 02 / 03
Predictable to the cycle
303.6 µs

Each packet will take the same amount of time. There is no split, no recursion, and no branching dependent on the data, and so the worst case and the normal case is the same number, and traffic cannot move it. This is the property that flight software is certified on, and the reason why a flood cannot make response time grow.

303.6 µs end-to-end per packet on a Cortex-R5 at 600 MHz, of which 19.9 µs belongs to the classification itself. Not measured using a stopwatch but counted instruction by instruction, based on the compiled armv7r code, and hence a static bound.

Assumes the model in tightly coupled memory. Running from SRAM or flash adds wait states this figure does not include. These numbers replaced earlier, more flattering ones of our own. See Evidence.
Static WCET · armv7r
SPEC 03 / 03
Built to be corrupted
93.7 %

Radiation causes errors by flipping bits in memory. Quaranet distributes decisions over a large number of weights, spread across 10,000 bits, so single bit errors just shift the final answer and do not completely change the output. The internal data structure uses Hamming-SECDED encoding, which corrects single bit flips at runtime within the model while refreshing the double-bit error by pulling new bits from ROM.

For a model that has 2.5% of its memory deliberately corrupted, performance drops from 94.19% accuracy to 93.70% accuracy, while an int8 network experiences an accuracy drop of 96.32% to 53.60%.

This is an accelerated margin test. 2.5% corruption is orders of magnitude beyond the roughly one upset per day modelled on orbit, where each single upset is corrected by SECDED as it happens.
SEU tolerant · self-healing
Empirical validation

Assessed, rather than expected.

Three things a buyer is actually interested in: does it stop attacks, what can go wrong, is the product you are testing the product that is flying. All are answered below.

01 / 03 · DETECTION

What it catches, and what it costs in false alarms.

On 7,200 packets of data that it had not seen during its training period, the model successfully identified 3,347 of 3,619 attacks, and successfully classified 3,435 of 3,581 clean packets as clean, to achieve an overall accuracy of 94.19%.

It also gave 146 false alarms, yielding a false-positive rate of 4.08%. We make this number appear in print as prominently as the overall accuracy, since any false positive alarm spends the attention of an onboard operator, and 4.08 percent is too much. Driving the false positive rate down to less than 1 percent is currently open engineering work.

Fused corpus of CICDDoS2019 + ToN-IoT, 1,327,989 packets, evaluated on a held-out, class-balanced split of 7,200.
CONFUSION MATRIXHELD-OUT · n = 7,200
Pred. threat
Pred. benign
Threat
0
TRUE POS.
0
FALSE NEG.
Benign
0
FALSE POS.
0
TRUE NEG.
ACCURACY 94.19% FALSE-POSITIVE RATE 4.08%
02 / 03 · BALANCE

Precise and sensitive at the same time.

Precision 95.82%. When it says an attack, 96 out of 100 times it will be correct. Recall 92.48%. It will find 92 out of 100 attacks on average. Those usually work against each other, and how tightly a detector can hold them both gives a good approximation as to whether it has really learned something.

It separates out attacks from non-attacks with an ROC-AUC of 0.9911 irrespective of the alarm threshold. That is why we front-load it instead of accuracy.

Binary nearest-prototype classifier over 10,000-bit vectors. Same held-out split as above.
CLASSIFICATION METRICSTEST SET
Accuracy0%
Precision0%
Recall0%
F1-score0%
Threshold-free separability · ROC-AUC0.9911
03 / 03 · PARITY

The thing we tested is the thing that flies.

The model used for training was in Python. What is actually flying is Rust, cross-compiled for the spacecraft processor. And the two are far from just equivalent. They are exactly the same, bit for bit. Every time you build it, it tests the Rust core against stored golden reference vectors and compares all ten thousand bits in question, and the resulting decision.

This is, by and large, the step that all the published benchmarks omit, and the step that can actually distinguish if a benchmark matters once you take the code off the laptop. Currently the flight code passes 27 out of 27 tests and all builds are clean for the armv7r-none-eabihf flight target.

Golden-vector parity, checked on every build. The 105,534 vectors per second figure opposite is the Python reference on a desktop CPU during validation, not a flight number. The flight number is the 303.6 µs fixed budget in SPEC 02.
PYTHON → RUST PARITYEVERY BUILD
CheckedComparedResult
Golden vectors8 stored cases8 / 8 match
Hypervectorevery bit10,000 / 10,000
Verdictthreat decisionidentical
Flight coreunit + parity suite27 / 27 pass
0
PYTHON REFERENCE · VECTORS / SEC
Why it works

Five properties, and where each one comes from.

Quaranet's advantage on constrained orbital hardware is not really a software gimmick. Each of the following is from something you can actually verify, such as a published paper, a standard, or a measurement we publish. A source is provided for each.

01 · GEOMETRY

Random noise never looks like an attack.

5,000 ± 50
Distance between any two unrelated 10,000-bit patterns

Pick two random 10,000-bit patterns and see how many of the bits differ between them. They are 5,000 places apart almost always, usually only varying by about 50. Three standard deviations is 150 bits, which on 10,000 bits is pretty near negligible, to the point of rounding error. Everything is reliably and boringly separate in this space at this size and scale.

The entire point of using 10,000 dimensions is size. At this scale, randomness does not even have a tiny chance of accidentally finding a learned threat signature. The distinction is purely a property of the geometry and something it does not even need to learn, and we have a 10,000 bit region for every single one of your new threats, as long as you train that system with enough bad traffic.

P. Kanerva, Hyperdimensional Computing, Cognitive Computation, 2009. Measured on our own vectors.
02 · COMPUTATION

Every packet costs the same.

11,959 cyc
Classification stage · 19.9 µs at 600 MHz

A neural network does matrix multiplications, and the complexity depends on what goes into them. Quaranet's work is to exclusive-or pairs of bit patterns and count the ones. A 64-bit processor takes 64 bits per clock cycle, meaning a comparison of 10,000 bits has a machine work equivalent of 157 machine words against every stored pattern.

Two stored patterns took 11,959 cycles, 19.9 µs on a Cortex-R5 at 600 MHz, and the complete pipeline was at 303.6 µs. Since this whole path does not depend on the data, the load does not affect the cost. On the optional FPGA the comparison simplifies to one clock cycle.

An admission. Our first published figure was 6,343 cycles. The analysis tool had counted one loop while the compiler had issued two, and a similar mistake had made the encoder look about 190 times quicker than it is. We found it, checked against the generated assembly, re-published and bumped it up. The numbers on this page are our corrected ones.

Loop-nest analysis of the emitted armv7r assembly. In-order, non-speculative core, and every access is assumed to hit tightly coupled memory.
03 · RADIATION

A flipped bit cannot quietly change the answer.

93.7%
Accuracy with 2.5% of model memory corrupted, from 94.19%

Charged particles corrupt bits in memory. In the context of a neural network this is a corrupted weight, and changing any bit changes the output with no indication it occurred. The spread throughout all 10,000 bits that Quaranet gives for any decision ensures corrupted bits only shift the output by a tiny amount, rather than change the whole output.

For 2.5% corrupt, 250 bits, a deviation distance of only 250 against a 5,000 bit separation, accuracy of Quaranet comes down from 94.19% → 93.70%. Compare this to a typical int8 network, where accuracy drops from 96.32% → 53.60%, essentially flipping a coin but confidently continuing. Even at the deepest levels, Hamming-SECDED coding alone would restore any bit upset, correcting all single bit upsets and reading the remainder out of ROM for any double bit upset.

This is an accelerated margin test. 2.5% corruption is orders of magnitude beyond the roughly one upset per day modelled for this orbit, where SECDED corrects each single upset as it happens. Not yet confirmed under a real particle beam. That campaign is Step 04.
04 · QUEUEING

A flood cannot fill the buffer.

30.4%
Processor load under a 1,000 packet/s flood

Conceptually treat the uplink as a queue. One Cortex-R5 core processes 3,294 packets per second end-to-end with the model in fast memory. Dump a 1,000 packet per second flood at it, very much more than a real rate for telecommands, and the processor is running at 30.4%, with only a tenth of a packet queued up on average. Since the queue size is mathematically bounded, it cannot continue increasing indefinitely and the buffer does not overflow.

ρ = λ / µ = 1,000 / 3,294 = 0.304

At the rates the spacecraft actually experiences, the processor load is a rounding error: about 3.0% for 100 packets per second, and 1.0% at 33 packets per second. We can say that because of the aforementioned property. Since every packet has the exact same cost, its service rate is a fixed quantity and not just an average rate.

M/M/1 queue with the service rate taken from the static WCET above, not from a benchmark. Figures assume the model resident in tightly-coupled memory. The optional FPGA path raises the service rate substantially; every number here is without it.
05 · SWaP

Nothing new to power, cool, or launch.

+0 kg
114 KB of software · 44.6% of one R5F's local memory

Since vacuum has no air to take heat away, any spacecraft can only radiate heat away from itself. Each watt is one that must be disposed of at an already budgeted and paid for area, and each kilogram added to the mission must also be paid for again in propellant. For that reason, "just add a co-processor" is a far bigger ask than it at first sounds: new hardware must be qualified, powered, cooled, radiator-budgeted and hauled about for its whole life.

Quaranet does none of these. It is just 116,808 bytes of program that already runs upon a processor the platform powers, already cools and has already accounted for in its thermal budget. The only additional cost is one in duty cycle, roughly 3 percent of the use of one CPU core at a hundred packets a second, rather than hardware or mass. No additional component is ever added.

Footprint computed from model structure: 116,808 bytes = 114.07 KiB, which is 44.6% of the 256 KB tightly-coupled memory on a Zynq UltraScale+ R5F. Duty cycle follows from the timing figures in 02 and 04.
Engineering evidence · TRL-4.5

Eight lines of primary evidence.

Eight lines of primary evidence: the cryptography, the radiation-hardened memory, the synthesizable silicon, the instruction-level timing proof, actual NASA spacecraft telemetry, and the red team attack that we ran against our own detector, published with the results that went against us.

Explore the evidence
Interactive

Build a satellite. Launch an attack. Watch it hold.

Pick a processor, choose an attack, and dial up the intensity. The Quaranet lane is driven by the same measured cycle budget as the rest of this page. It is not a demo animation with numbers written on it.

1 · Onboard processor
2 · Attack vector
3 · Injection rate
100 packets / sec
A real telecommand uplink sits between 1 and roughly 200.
4 · Protected asset
LIVE PACKET STREAM → QUARANET SHIELD
Quaranet CoreREADY
CPU load0%
Queue occupancy0%
Model integrity100%
Service rate
Conventional NNREADY
CPU load0%
Queue occupancy0%
Model integrity100%
Service rate
Configure your satellite and press Run simulation.

That was a model. The real thing runs on NASA telemetry.
Fifteen minutes, live, with the actual flight core, including the parts that fail.

Book a live demo
How to read this honestly. The Quaranet lane uses the measured Cortex-R5 cycle budget (170,207 to encode + 11,959 to classify) scaled by each processor's clock; only the R5 figure is measured on that architecture, so the others are indicative. The FPGA entry moves the classify stage into fabric and leaves the encoder in software, which is why it is faster but not thousands of times faster. The comparison lane models a small float32 network on a core with no hardware floating-point unit. Its cycle cost is a labelled estimate, but its behaviour under radiation is measured (94.19→93.70% versus 96.32→53.60% at 2.5% corruption). Asset values are illustrative and play no part in the arithmetic.
Where we are

Four steps. Two done, one underway.

We say plainly which is which. Nothing below is marked complete unless it has been built and checked.

STEP 01Completed
The detection core works.
We built the core and tested it against real attack traffic, over 1.3 million packets of it. Then we rebuilt it in the language it will actually fly in, and confirmed the two versions give exactly the same answer, every time.
STEP 02Completed
It survives the conditions in orbit.
We added command authentication, so a forged instruction is rejected before anything else happens. We made the memory repair its own radiation damage. And we proved the timing, not that it is usually fast, but that its slowest possible response is a fixed, known number. Real spacecraft telemetry from NASA went into the testing at this stage.
STEP 03In progress
It runs on real flight-grade hardware.
Moving off the simulated processor and onto a physical development board, then measuring on silicon what we have so far proven on paper. The gap between those two is the most useful number we can produce right now. This is the step the current round funds.
STEP 04Planned
It gets demonstrated the way a customer would want to see it.
A demonstration on flight-representative hardware alongside a satellite manufacturer, and a radiation campaign at a beam facility to confirm under real particles what we have so far only measured in software.
Request a demo

Let's talk about defending what's in orbit.

Whether you're a space agency, satellite manufacturer, defense fund or deep-tech investor, we'd be glad to walk you through the architecture and the measurements behind it, including the ones that went against us.

A live 15-minute demoThe flight core running on real NASA telemetry, attacks included.
Technical deep-diveArchitecture, timing budget, integration path, and the raw artifacts.
Partnership & researchFlight-heritage collaboration and FPGA co-design.
Tell us what you need
We reply to every message ourselves, usually within two working days.
Please enter your full name.
Please enter a valid email address.
Please include a short message.

We use what you send only to reply. No newsletter, no tracking, no sharing with anyone. See our privacy notice.