Post-Quantum Security Just Went to Space. Here Is What That Means for Your Enterprise.

In April 2026, Voyager Technologies and IBM established the world’s first post-quantum cryptography (PQC) secured communication link between the International Space Station (ISS) and the ground. The platform behind it was not exotic hardware or a purpose-built quantum system. It was a software layer deployed on a micro datacenter sitting 250 miles above the planet, wrapping legacy applications in NIST-standardized cryptographic protection without touching a single line of application code.

Most coverage of the story stopped at the headline. This post is about what the deployment actually proves for security leaders who have been told, or have themselves said, that their legacy infrastructure cannot be migrated to post-quantum security

The ISS is the most operationally constrained environment that exists for a cryptographic migration: limited compute, communication latency, physical inaccessibility, and applications designed for stability rather than agility. If a crypto-agility architecture works there, the objection that “our legacy systems cannot be migrated” no longer has a technical leg to stand on.

Why Satellite Data Is Already a Target

The post-quantum threat conversation in enterprise security tends to center on financial systems, healthcare records, and government communications. Satellite infrastructure rarely makes that list, even though it underpins all of those sectors. Weather forecasting, GPS navigation, financial transaction routing, and military communications all depend on satellite networks, and unlike a server in your data center, a satellite in orbit is hardware you cannot reach, patch, or rotate keys on.

What makes this especially pressing is that the adversarial threat to satellite data is not hypothetical. Attackers do not need to wait for a quantum computer to begin collecting valuable data.

• Research presented at Black Hat 2020 by James Pavur of Oxford University demonstrated that satellite communications data from 18 geostationary satellites, covering approximately 100 million square kilometers of ground area, could be intercepted using under $400 worth of off-the-shelf consumer television equipment. The affected communications included data from nine Fortune Global 500 companies, six of the ten largest airlines, and government agencies.
• The harvest-now-decrypt-later attack model means that adversaries with the resources and the incentive do not need to break encryption in real time. They collect encrypted satellite data today and store it until a cryptographically relevant quantum computer (one capable of breaking RSA or elliptic curve cryptography (ECC) at scale) becomes available. At that point, years of archived data becomes readable.
• With approximately 14,000 active satellites currently in orbit serving applications from national defense to commercial telecommunications, the aggregate volume of encrypted data in flight at any given moment represents a significant and growing collection target for well-resourced actors.

This threat is not bounded by domain. All data encrypted with classical asymmetric algorithms is, by definition, already in the harvest-now-decrypt-later window. It does not matter whether the interception happens on the ground or in orbit.

The Real Obstacle: Crypto-Agility in Systems You Cannot Touch

Ask most security teams why their PQC migration is not further along, and you will hear some version of the same answer. The systems that need migrating are the hardest to touch. Operational technology, network appliances, embedded cryptographic modules, and long-lifecycle hardware all share the same trait: their cryptographic implementations are built into firmware or hardware, and updating the algorithm means replacing the device.

In space, this constraint is absolute. There is no field technician available to swap out a module at the ISS.

This is precisely the problem IBM Quantum Safe Remediator was designed to solve, and the ISS deployment validated it under real operational conditions.

• IBM Quantum Safe Remediator functions as an intelligent proxy around legacy applications. Externally, it communicates using NIST-standardized PQC algorithms. Internally, it translates to the classical encryption that the underlying application already speaks, requiring no changes to application code. IBM Fellow Ray Harishankar described the architecture directly: “To the outside world, that facade speaks post-quantum cryptography. Internally, it speaks classical encryption.”
• The deployment model lets organizations apply post-quantum protection to existing systems during the transition period, without waiting for a hardware refresh cycle that may be years away and without undertaking a full application rewrite.
• The principle demonstrated here is crypto-agility, the architectural property of being able to replace cryptographic algorithms without systemic redesign. This is not a new concept in cryptographic engineering, but it is one that most organizations have not built into their infrastructure because there was never a compelling reason to do so until now.
• IBM Fellow and CTO for Security Research JR Rao framed the forward requirement explicitly: “As we move forward with lunar and deep space missions, we need infrastructure with crypto-agility, the ability to replace cryptographic algorithms in an agile fashion”. The same logic applies, unchanged, to every enterprise running applications it cannot easily modify.

The ISS deployment is not proof that PQC migration is easy. It is proof that the most common architectural blocker, legacy systems with embedded classical cryptography, can be addressed with a software layer today, not after a hardware refresh in 2029.

What Voyager and IBM Actually Deployed

To draw the right lessons from the ISS demonstration, it helps to understand the components involved and what each one contributes to the broader migration picture.

Voyager’s Space Edge Micro Datacenter is a cloud infrastructure platform launched to the ISS in September 2025. It functions as an edge computing layer in orbit, enabling containerized applications to be deployed and operated on-station. IBM Quantum Safe Remediator was deployed as a running instance on Space Edge and used to establish the PQC-secured link with ground-based users.

Three specific details from the deployment carry direct implications for enterprise migration planning.

• The PQC algorithms used are the same NIST standards published in August 2024: ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, standardized as FIPS 203), ML-DSA (Module-Lattice-Based Digital Signature Algorithm, standardized as FIPS 204), and SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, standardized as FIPS 205). These are not experimental algorithms. They are finalized federal standards, and IBM contributed to the development of two of the three.
• The communication link was bidirectional, between Space Edge on the ISS and users on Earth, confirming that NIST PQC algorithms perform operationally in a high-latency, bandwidth-constrained environment. The performance concern that some enterprise teams cite as a reason to delay adoption was addressed in a test environment considerably more demanding than a typical corporate network.
• IBM Fellow and CTO for Security Research JR Rao explicitly framed the result as a starting point, not an endpoint: the demonstration proved that the infrastructure exists to begin protecting orbital data with PQC today, with the expectation that the same architecture must scale to lunar and deep space missions.

What was proved on the ISS was not that post-quantum cryptography works in theory. That has been established for years. What was proved is that a crypto-agility architecture, running on constrained commercial hardware, in an operationally demanding environment, can deliver NIST-standard PQC protection to legacy systems without downtime and without code changes.

The Enterprise Parallel Is Closer Than It Looks

The structural challenge of PQC migration in space and on the ground is the same. Both environments are populated with systems that have long operational lifetimes, embedded classical cryptography, and update cycles that do not align with the pace of cryptographic standards evolution.

A programmable logic controller managing an industrial process, a hardware security module (HSM) provisioned three years ago, an IoT device deployed across a building management network, or a certificate authority (CA) root established before the NIST standards were finalized all present the same migration constraint as an on-orbit satellite. You can change the software around it more easily than you can replace the hardware itself.

The lesson from the ISS deployment is that the answer to this problem is architectural, not purely algorithmic.

• Crypto-agility should be treated as a first-order design requirement for any new system or service being deployed today, rather than a property to be retrofitted after the migration deadline approaches. Systems built now that cannot swap algorithms without full redeployment are accumulating migration debt before they are even in production.
• For systems already deployed, the proxy and middleware model demonstrated by IBM Quantum Safe Remediator is directly applicable. Applications that cannot be rewritten can be wrapped in a PQC-compliant communication layer, with classical cryptography encapsulated internally and NIST-standard algorithms presented at the network boundary.
• Hybrid cryptography, running a PQC algorithm and a classical algorithm in parallel during the transition period, reduces implementation risk for organizations that require confidence in the maturity of newer standards while still advancing toward NIST compliance.
• Every month spent on legacy cryptography without a migration plan is a month closer to 2030 with less time to act. The prerequisite for any of these approaches is knowing exactly which cryptographic assets you are working with, because you cannot sequence a migration against dependencies you have not mapped.

None of these steps requires waiting for a large-scale quantum computer to materialize. They require planning, and they require starting now.

The Compliance Timeline Is Not a Distant Horizon

The 2035 date is the most frequently cited figure in PQC policy discussions, and it is often treated as a comfortable buffer. It is not. NIST Interagency Report 8547 (NIST IR 8547), published as an initial public draft in November 2024, lays out the federal transition timeline with a specificity that removes any ambiguity about when the compliance window actually closes.

Understanding what the timeline actually requires is the difference between beginning migration work with options and beginning it under pressure.

• Under NIST IR 8547, algorithms providing 112 bits of security or less, including RSA-2048 and ECC P-224, are scheduled for deprecation by 2030. After that date, these algorithms should not be used in new federal systems. Higher-strength algorithms providing 128 bits or more, including RSA-3072 and P-256, skip the deprecation step and are disallowed outright after 2035. For organizations in the federal supply chain, the 2030 date will surface in procurement, audit, and contractual requirements before it becomes a hard regulatory cutoff.
• By 2035, all classical asymmetric algorithms across all security strength levels are disallowed in NIST standards. This aligns with the requirements of National Security Memorandum 10 (NSM-10), which establishes 2035 as the federal government’s target date for system-wide PQC adoption.
• The compliance exposure window does not open in 2035. It opens in 2030. Organizations continuing to operate RSA-2048 on production systems between 2030 and 2035 will be within the technically permitted window, but operating deprecated algorithms. Auditors, insurers, and federal procurement teams will begin treating that exposure as a risk signal well before the hard cutoff.
• Migration programs for organizations with complex public key infrastructure (PKI) hierarchies, operational technology networks, HSMs, and custom cryptographic integrations typically require three to five years of lead time at minimum. An organization that begins planning in 2032 is not starting early. It is arriving after the gate has closed.

The ISS demonstration showed that the infrastructure to begin migration exists today. The compliance timeline makes clear there is no strategic case for waiting.

How Encryption Consulting Can Help

The ISS deployment settled the “can it be done” question. Legacy systems can receive NIST-standard PQC protection without hardware replacement. The question your security team now needs to answer is more specific: which of your systems are actually exposed, and in what order do they need to move?

That is a harder question than it sounds. Most organizations discover mid-engagement that they do not have an accurate picture of the cryptographic algorithms running across their environment. Keys, certificates, protocols, and cipher suites sit scattered across endpoints, applications, APIs, and infrastructure, frequently undocumented and inconsistent with policy. Before any migration can be sequenced, that picture needs to be complete.

CBOM Secure

Encryption Consulting’s CBOM Secure platform is built for exactly that problem. It sweeps your full environment and produces a Cryptographic Bill of Materials: a structured, machine-readable inventory of every certificate, key, algorithm, and protocol in scope across every system connected to your network.

The inventory tells you what you have. CBOM Secure goes further by telling you what has to change. It validates algorithms against current NIST standards, flags quantum-vulnerable dependencies, and distinguishes which systems need attention before 2030 and which before 2035. When a compliance deadline or a board-level question is bearing down, that specificity replaces guesswork with a prioritized list of actions you can actually execute. Upcoming releases will add automated remediation, cloud-native integrations, and continuous policy enforcement to keep configurations aligned as NIST standards continue to evolve.

PQC Advisory Services

Inventory is the prerequisite. Migration is the work. Our PQC Advisory Services take the CBOM Secure output and build on it: a quantified assessment of your quantum exposure, a severity-ranked view of every RSA- and ECC-dependent system in scope, and a migration roadmap calibrated to your regulatory obligations and operational constraints.

The roadmap is built to last. Crypto-agility is designed into the migration architecture from the start, so the plan does not need to be rebuilt each time a standard is updated or a compliance deadline shifts. You migrate to a system that can evolve, not to one that creates the next generation of debt.

The earlier this work begins, the more options your team retains when 2030 arrives. If your organization is ready to map its cryptographic exposure or begin shaping a migration plan, we are ready to help.

Reach us at [email protected] for any further information.

Conclusion

The Voyager and IBM ISS deployment will be remembered as a landmark in applied cryptography. Not because it happened in space, but because of what it demonstrated: that a software-based crypto-agility architecture can deliver NIST-standard PQC protection to legacy systems in an environment where hardware replacement is simply not an option.

The threat that motivated it, the harvest-now-decrypt-later collection of encrypted data against the eventual arrival of a cryptographically relevant quantum computer, applies with equal force to every satellite downlink, every PKI-protected enterprise application, and every encrypted communication flowing across your network today. The compliance timeline that surrounds it is specific, published, and counting down in increments of years, not decades.

The organizations that treat the ISS milestone as confirmation that PQC migration is achievable today, and begin their cryptographic inventory and architecture work now, will have real options when the 2030 deprecation date arrives. The ones that treat 2035 as the start line will not.

The technology is proven. The standards are final. The timeline is published. What comes next is a planning decision.