Deliver software updates to remote mission-critical systems.

Keep every update provably genuine and the system current for its whole operational life, through a cryptographic break and normal operation alike, built on information-theoretically secure cryptography.

Contact us →
// The Threat

A mission-critical system is only as trustworthy as the updates it accepts.

A mission-critical system must be kept current for its whole life, and every update it accepts has to be provably genuine, because a single forged update can take over or disable it. Today those updates are authenticated with standardised digital signatures such as RSA and ECDSA, based on computational hardness: a computational assumption, not a proof. A quantum computer breaks both of them, while AI and new cryptanalysis may break any computational scheme, the post-quantum signatures included, so the algorithm authenticating your updates has a limited lifetime.

When the authentication of a mission-critical update can be forged:

  • A forged update subverts the system from the inside. The path meant to maintain the device becomes the way to take it over.
  • Computational update authentication weakens over the mission. Digital signatures such as RSA and ECDSA fall to a quantum computer, and the post-quantum standards, like any computational scheme, may fall to AI and new cryptanalysis.
  • For a remote asset there is no recall. With no way to reach the system, a single accepted forgery can mean total loss of the asset.
  • One break exposes the whole fleet. When many units share the same update cryptography, one break puts every identical device at risk at once.
// QURSUS

A break in the deployed cryptography does not compromise the update path.

QuBalt delivers secure remote software updates through QURSUS, its Quantum- and Cryptanalysis-Secure Remote Software Update System, built on QuBalt's authentication core.

QURSUS authenticates every update package with information-theoretic security, manages the updates, and controls their installation on the device, so the device installs only updates it can prove are genuine, and that guarantee does not weaken over the mission. It is a higher level of security than the cryptography standardised today, on every update in normal operation and not only after a break.

Every update package, and the command to apply it, carries an information-theoretically secure tag, so the device installs only what it can prove is genuine. This authentication is a core part of QURSUS, and it protects its crypto-agility in the same way.

QURSUS is delivered as a building block that integrates into your existing systems, at both ends of the update path. Device-side, the QURSUS software stack and its pre-shared keys run on the deployed device. Operations-side, QURSUS runs as a software stack on the operations computer, fitting into the existing operations toolchain. QURSUS is validated to TRL 4 under the ESA GSTP programme and is adapted to each customer's specific requirements and hardware environment.

// Capabilities
  • Provable authenticity on every update. Each update carries an information-theoretically secure tag: the best forgery available to any adversary, at any computing power, is a blind guess with negligible, fixed odds.
  • Update a device after a break. Deliver and install software updates after the deployed cryptography has been broken, authenticated independently of it.
  • Mission-critical software, whole-system. Update firmware and mission-critical software on the main device, its subsystems, and its payloads.
  • Authenticity that does not age. Each update stays provably genuine for the whole operational life and beyond, because its authentication rests on no hard problem that a faster computer could later solve.
// In operation
  • FPGA core or software library. QURSUS is available as an FPGA core, or as a pure C library on the host processor where no secure FPGA is available.
  • Standalone or alongside. QURSUS runs on its own, or beside an existing update system, taking over the moment that system can no longer be trusted, or carrying only the mission-critical updates.
  • Keys sized to outlast the mission. Key material is provisioned to both endpoints before deployment, sized with margin, and tracked throughout. Keys are consumed on use and never reused.
  • Encryption is optional. Where the update content must also be kept confidential, encryption can be added.
// A Managed Key Lifecycle

Truly random keys are consumed on use, so the key budget is provisioned before deployment, sized with margin to outlast the mission, monitored in operation, and fails secure if ever spent: the system stops authenticating rather than accept unverified traffic. Unlike systems that stay secure only by rekeying reusable keys over the air, QURSUS needs no such channel: its keys are one-time, and its authentication guarantee rests on no channel a future computer could break. Any replenishment is by offline transfer or one-time-pad-encrypted delivery, so it never weakens that guarantee.

// Application Areas

Cyber resilience for the whole operational life.

Secure remote software updates keep a deployed system's software current, so it stays cyber-resilient long after it is out of reach. We bring this to the systems that must stay trustworthy for their entire operational lifetime:

In space

Satellites, constellations, CubeSats, probes and rovers, ground stations, and their payloads that operate for years and can never be recalled.

In the field

Ships, missiles, remote sensors, wind turbines, and critical infrastructure deployed far from maintenance.

In secure hardware

Cryptographic devices, communication modules, TPMs, HSMs, and QKD nodes that must stay mission-grade across a long fielded life.

// What You Get

Your asset stays patchable after a cryptographic break.

For the deployed system, QURSUS keeps mission-critical software current and provably authentic for the whole mission:

  • Provable authenticity on every update. Each update is authenticated with information-theoretic security, so the system acts only on software it can prove is genuine.
  • Mission-critical functions protected. The update path accepts only updates it can prove genuine, so the functions that software controls stay under your control.
  • Authenticity that does not age. A recorded update cannot be forged years later, so what you deploy stays provably genuine for the whole operational life and beyond.
  • Whole-system updates. Firmware and software are refreshed remotely across the whole system, from the main device to its subsystems and payloads.
  • Rapid threat response. A discovered vulnerability is fixed in days or weeks, not over a hardware-replacement cycle.
  • Cyber resilience. The asset stays patchable and recovers even after its own deployed cryptography is broken, because the update authentication does not depend on it.
// The Key Difference

Security proven by information theory, not assumed to be hard.

For mission-critical updates, the security basis decides how long every update stays provably genuine: authentication that weakens over the mission eventually lets a forged one through.

State-of-the-art update systems authenticate with digital signatures such as RSA and ECDSA, and the post-quantum standards, all standardised and all based on computational security: their security rests on a problem staying too hard to solve, an assumption that has never been proven. A quantum computer breaks RSA and ECDSA, while AI and new cryptanalysis may break the post-quantum standards too. QURSUS instead uses information-theoretic authentication: provably secure under its stated assumptions of truly random, single-use keys and a correct implementation, and independent of any attacker's computing power, now or in the future. That proof covers the authentication algorithm; full system security also rests on key management and implementation assurance.

QURSUS therefore rests on a different security basis, one that stays secure against quantum computers, AI, and future cryptanalysis, suited to keeping deployments patchable throughout their entire operational life.

// Frequently asked questions

Questions a technical evaluator asks.

What exactly is information-theoretically secure, and under what assumptions?
The guarantee belongs to the authentication algorithm: at any computing power, the best attack is a blind guess with negligible, fixed odds. It holds under four assumptions, all required: keys are truly random, used exactly once (reuse breaks it), the implementation is correct and free of side-channel or fault leakage, and keys are kept secret and securely provisioned. The authentication core is our validated implementation of that algorithm plus its key management, so the core is not itself called information-theoretically secure; full system security also rests on that key management and on implementation assurance.
How is this different from post-quantum cryptography?
PQC is still computational security: it rests on problems only assumed too hard to solve, and holds only while that assumption holds. QURSUS authentication does not rest on a hardness assumption, so it stays secure against quantum computers, AI, and future cryptanalysis. QURSUS can also deliver post-quantum update software to the device whenever you choose to run it.
Does a recorded update stay protected if it is attacked later?
QURSUS authentication does not rest on a hardness assumption that can fall later, so recording an update to forge it later gains nothing: at any computing power, and whenever the attempt is made, the best a forger can do is a blind guess with negligible, fixed odds. Its authenticity holds for the mission's whole life and beyond it. Where AES is added for confidentiality, that content rests on AES strength.
What can QURSUS update?
Firmware and mission-critical software on the main device, its subsystems, and its payloads, at any point in the mission.
Does the update path become an attack surface once the cryptography is broken?
No. The authentication does not depend on the deployed cryptography, so even after that cryptography is broken the update path stays trusted: the authentication gating it does not weaken, and the path keeps accepting only updates it can prove genuine.
Can QURSUS run alongside our existing update system?
Yes. QURSUS runs on its own, or beside an existing update system and takes over the moment that system can no longer be trusted, or carries only the mission-critical updates alongside it.
Is the update content encrypted?
Authentication is always on. Confidentiality is optional: add AES where the update content must also be kept confidential. AES is not itself information-theoretically secure, and authenticity stays information-theoretic either way.
How are keys provisioned, and what happens if the budget runs low?
Key material is provisioned to both endpoints before deployment, sized with margin to outlast the mission, and monitored in operation. Keys are consumed on use and never reused. If the budget were ever spent, QURSUS fails secure, stopping authentication rather than accepting unverified traffic. Any replenishment is by offline transfer or one-time-pad-encrypted delivery, so it never weakens the guarantee.
What primitive and standards does QURSUS use?
Authentication is an information-theoretic one-time MAC, with keys consumed on use and never reused. Optional encryption is AES-128/256 with PKCS#7 padding. Validated to TRL 4 under the ESA GSTP programme.
What if there is no secure FPGA on the device?
The authentication core is delivered as a pure C library on the host processor instead of an FPGA core.
What footprint, throughput, and overhead does QURSUS need?
Byte-exact footprint, RAM, CPU budget, per-message overhead, throughput, and key-budget sizing are supplied for your target platform. We do not quote figures we have not measured for your case.
Is the implementation hardened against side-channel and fault attacks?
The core is developed within the ESA GSTP programme. Side-channel and fault-injection resistance and radiation tolerance are being implemented in an ongoing project to advance the technology to TRL 5.
What is QURSUS's maturity and flight heritage?
The authentication core is validated to TRL 4 under the ESA GSTP programme and is selected for in-orbit demonstration aboard ESA's CyberCUBE, 2026.
// Get in Touch

Discuss your software-update requirements

Whether you are updating a satellite payload, a remote sensor fleet, or a critical-infrastructure controller, we can scope a provably authentic update path around your hardware, operations, and compliance constraints. Talk to our team about your programme.

Contact us →