Replace cryptographic algorithms on remote, inaccessible systems.

Extend a deployed system's operational life and keep it in service when its cryptography breaks, and replace its algorithms on schedule across the whole mission, built on information-theoretically secure cryptography.

Contact us →
// The Threat

Every deployed computational cryptographic algorithm has a limited lifetime.

Crypto-agility means replacing the cryptographic algorithms on a deployed device at any point in its life. The hard part is not changing an algorithm; it is delivering that change over a channel an adversary cannot forge, because the update channel itself depends on cryptography. Once the deployed cryptography is broken, that channel can no longer be trusted.

When the cryptography of a satellite or device is broken:

  • Commands and telemetry can be forged. An adversary who can forge the channel can issue commands the system accepts as genuine, and falsify what it reports.
  • Malware can be injected through the update path. The channel meant to repair the device becomes the way to subvert it.
  • The asset cannot be re-secured, and is lost. With no trusted channel to deliver a fix and no way to recall the hardware, a compromised device stays lost for the rest of the mission.
  • A shared algorithm exposes the whole fleet. When many units run the same cryptography, one break puts every identical device at risk at once.
// QURSUS

An update system that does not depend on the cryptography it replaces.

QuBalt delivers crypto-agility through QURSUS, its Quantum- and Cryptanalysis-Secure Remote Software Update System, built on QuBalt's authentication core.

QURSUS authenticates each algorithm-replacement package with information-theoretic security, manages the replacement, and controls its installation on the device, so deployed algorithms can be replaced remotely, with no dependence on the cryptography being replaced. This is a higher level of security than the cryptography standardised today, in place throughout the mission and not only after a break.

Every algorithm-replacement package and the command that drives 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 software updates 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
  • Re-secure a broken device. Replace cryptographic algorithms after they have been broken, over a channel that does not depend on them.
  • Migrate on your schedule. Replace deployed algorithms as a planned step, for PQC migration or a sovereignty requirement, without waiting for a break.
  • FPGA or software. Replace algorithms running in an FPGA core or in host software.
  • At any point in the mission. Replace algorithms throughout the operational life, not only at manufacture.
// 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.
  • 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 replacement algorithm or 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.

Crypto-agility keeps a deployed system's cryptography current, so it stays cyber-resilient long after the algorithms it was fielded with are broken, and lets you refresh those algorithms on schedule in normal operation before any break. 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

A cryptographic break no longer ends the mission.

For the deployed system, that means protection kept current and an asset kept in service:

  • Cyber resilience. A device whose cryptography is broken keeps operating and recovers, re-secured over a channel that does not depend on the broken crypto.
  • No premature loss. Broken cryptography is replaced remotely, so the device stays trusted and in service, with no replacement hardware.
  • Crypto-agility for the whole mission. Algorithms replaced remotely at any point in the device's life, including PQC migration.
  • Extended lifetime. The device outlives any single cryptographic generation: QURSUS replaces the algorithm, not the device.
  • Rapid threat response. A broken algorithm is replaced in days or weeks, not over a hardware cycle.
  • Cryptographic sovereignty. Algorithms adapted to national regulations where policy requires.
// The Key Difference

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

For crypto-agility, the security basis is decisive: an update channel built on the same kind of cryptography it replaces cannot be trusted to deliver the fix once that cryptography is broken.

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 protecting deployments 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 is also PQC-migration ready: when you choose to run post-quantum algorithms, QURSUS authenticates and installs them on the device.
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.
Which cryptographic algorithms can QURSUS replace?
The cryptographic algorithms running on the deployed device and its host, in an FPGA core or in host software, at any point in the mission. QURSUS delivers the replacement and does not depend on the algorithms being replaced.
Can the algorithms be adapted to national or sovereign requirements?
Yes. Because QURSUS can replace the deployed algorithms at any point in the mission, they can be changed to meet national regulations or a sovereignty requirement whenever policy calls for it, not only at manufacture.
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.
Is confidentiality included?
Authentication is always on. Confidentiality is optional: add AES where the replacement algorithm or 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 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.
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.
// Get in Touch

Discuss your crypto-agility requirements

Whether you are fielding a satellite, a constellation, or a long-life critical-infrastructure asset, our team will work with you to plan crypto-agility that fits your platform and your threat model. Contact us to discuss your mission.

Contact us →