Guides
Proxy-Q: A Quantum-Safe Perimeter for Systems You Can’t Upgrade
Most conversations about post-quantum cryptography (PQC) assume that every system in the estate can eventually be patched, replaced or reconfigured to support new cryptographic standards. For organisations running IBM Power, AIX, i/Series or z/OS environments, that assumption rarely holds. A significant proportion of enterprise IBM infrastructure was built to run stably for decades, often supporting COBOL, RPG, MQ, DB2 or CICS workloads that cannot be modified without material operational risk. These systems are not going anywhere soon, yet many of them still rely on legacy TLS stacks, such as GSKit, System SSL, or older Java runtimes, that were never designed with quantum-era threats in mind.
This creates a specific and growing exposure: Harvest-Now, Decrypt-Later risk. Encrypted traffic captured today using classical RSA or ECC key exchange could, in principle, be decrypted retrospectively once sufficiently powerful quantum computing becomes available. For data with a long confidentiality shelf life, financial records, health data, contractual terms, intellectual property, that is a live governance question today, not a hypothetical one for the 2030s.
This guide, produced by Quantropi, introduces Proxy-Q, a proxy-based approach to closing that gap without touching the IBM systems themselves. Rather than attempting to upgrade cryptography inside AIX keystores, RACF, GSKit configurations or Java trust stores, Proxy-Q sits in front of IBM traffic and re-encrypts it using quantum-safe cryptography before it leaves the customer network. Legacy TLS is accepted on the inbound leg exactly as it is today; PQC-hardened TLS is enforced on the outbound leg. The IBM workload, its configuration files and its application code remain entirely unchanged.
For IT managers weighing up PQC strategy, the appeal of this model is largely architectural. It creates a single, central enforcement point for cryptographic policy across a heterogeneous estate, rather than requiring dozens of inconsistent cipher configurations to be reviewed and maintained across LPARs, partitions and middleware. It also reduces audit scope, since assessors have one control point to examine rather than the full spread of underlying IBM systems, and it supports a phased migration path: PQC protection can be deployed immediately, while the longer-term question of if and when to modernise the underlying endpoints is addressed separately, on its own timeline.
The guide also covers how Proxy-Q sources the entropy behind its cryptographic keys, an area that is easy to overlook but directly affects key strength, via Quantropi’s QiSpace platform and its use of Quantum Random Number Generators (QRNGs). Weak entropy has been shown to materially increase the risk of key compromise, and the guide sets out the reasoning and reference research behind Quantropi’s approach, alongside a summary of the security, compliance, cost and network implications of deploying Proxy-Q, together with indicative bill-of-materials and subscription pricing.
We’re sharing this guide because it speaks directly to a question we’re increasingly asked by customers running IBM Power and other legacy IBM estates: how do you plan for post-quantum compliance when the systems in question genuinely cannot be upgraded? Proxy-Q is one credible answer to that question, and this guide sets out the mechanics, the trade-offs and the practical deployment model in enough detail to support an informed evaluation.
As with any third-party technology, the right fit will depend on your specific environment, risk appetite and existing infrastructure investment. If you’d like to discuss how this applies to your own IBM Power, AIX or z/OS environment, or want a second opinion alongside your existing PQC roadmap, Covenco’s team is happy to talk it through.