Quantum computing has been attracting considerable attention over the past few years. Some believe it will revolutionise computing. Others question how long it will take before the technology delivers meaningful commercial benefits. And, as with almost every major technological development, there are already predictions about which existing technologies it will replace. Including the mainframe.
But will quantum computers actually replace systems such as IBM Z? And perhaps more importantly, what does quantum computing mean for organisations that rely on mainframes to process and protect some of their most important information?
I believe there are two very different aspects worth considering.
The first concerns cryptography and the long-term security of information.
The second concerns how quantum computers may eventually work alongside conventional systems to solve particular types of problems.
Both are interesting. But only one requires organisations to start preparing their existing mainframe environments today.
Quantum Computing Isn’t Simply Faster Computing
Before looking at the implications for the mainframe, we need to understand what makes quantum computing different.
Traditional computers process information using bits, representing either a zero or a one. Quantum computers use quantum bits, or qubits.
Through quantum properties such as superposition, entanglement and interference, quantum algorithms can perform certain calculations differently from classical algorithms. This doesn’t mean a quantum computer can simply evaluate every possible answer simultaneously and immediately return the correct one. That is a common misconception. Quantum algorithms must be carefully designed to exploit those properties. And the potential advantage depends on the problem being solved.
For some mathematical and scientific problems, quantum computing could eventually offer substantial benefits. For many other workloads, conventional computers remain far more appropriate.
There is no established reason to believe that a quantum computer will be better suited to processing millions of CICS transactions, executing COBOL applications or managing large Db2 databases. Those workloads require characteristics such as predictable performance, transactional integrity, availability and efficient processing of conventional data. Quantum computing doesn’t automatically improve any of those things.
The technologies are fundamentally different. And that is why I believe the idea that quantum computers will simply replace mainframes is misleading.
The Real Concern Is Cryptography
The more immediate issue for mainframe organisations is security. More specifically, the public-key cryptography used throughout enterprise computing.
Many existing cryptographic mechanisms depend on mathematical problems that are extremely difficult for conventional computers to solve. RSA, for example, relies on the difficulty of factoring large integers. Elliptic Curve Cryptography (ECC) relies on the difficulty of solving the elliptic-curve discrete logarithm problem.
These algorithms support important security functions, including digital signatures and key establishment. However, a sufficiently powerful, fault-tolerant quantum computer running Shor’s algorithm could undermine the mathematical assumptions on which RSA and ECC depend.
That is the concern. Not that quantum computing will suddenly bypass RACF. But that some of the cryptographic mechanisms used to protect communications, establish trust and verify digital signatures may eventually become insecure. And this affects mainframes just as it affects distributed systems.
Does This Mean All Encryption Will Become Useless?
No. And this is an important distinction.
Public-key cryptography and symmetric encryption are not affected in the same way. AES, for example, is a symmetric encryption algorithm. It doesn’t depend on integer factorisation or elliptic-curve discrete logarithms.
Grover’s algorithm provides a theoretical quadratic improvement for unstructured search, but that doesn’t mean a quantum computer can simply break AES in the same way that Shor’s algorithm threatens RSA.
AES-256 remains an appropriate symmetric encryption option in a post-quantum security strategy, assuming it is implemented and used correctly.
The same general distinction applies to other symmetric cryptographic mechanisms, although the appropriate security strength must be assessed for each use case.
So when someone says quantum computers will break all encryption, the statement is technically incorrect. The real concern is primarily the long-term security of quantum-vulnerable public-key algorithms.
What Does This Mean for z/OS?
Consider a typical enterprise mainframe environment:
- It may use TLS to protect communications between applications.
- Digital certificates to authenticate systems.
- Public-key cryptography to establish shared secrets.
- Digital signatures to verify software or information.
- ICSF to provide cryptographic services.
- Crypto Express features to support cryptographic operations.
- And numerous applications and middleware products that depend on these mechanisms.
These components form part of a much larger security architecture.
For example, an organisation may have a distributed application communicating with CICS over TLS. The connection may use a certificate containing an RSA or elliptic-curve public key. The TLS handshake may use an ephemeral elliptic-curve Diffie-Hellman key exchange. These are different cryptographic functions. The certificate is used for authentication. The key exchange establishes shared keying material. And symmetric encryption protects the application data.
That distinction matters when evaluating quantum-related risks. Replacing a certificate doesn’t automatically make the key exchange quantum-resistant. Likewise, implementing a quantum-resistant key-establishment mechanism doesn’t automatically solve every digital-signature dependency.
The complete protocol and application architecture must be considered.
Harvest Now, Decrypt Later
There is another reason organisations should already be paying attention. It is commonly referred to as Harvest Now, Decrypt Later.
Imagine an attacker recording encrypted communications today. The attacker cannot currently decrypt them, but the information is retained in the hope that future quantum computers will make decryption possible.
This is particularly relevant when the information needs to remain confidential for many years:
- Financial records.
- Government information.
- Intellectual property.
- Sensitive personal information.
- And other long-lived business information.
Mainframes frequently process this type of data.
Consider a TLS 1.3 connection using an ephemeral elliptic-curve key exchange. Although the protocol provides forward secrecy against the later compromise of the server’s long-term private key, that does not automatically protect the recorded handshake against a future quantum computer capable of solving the relevant elliptic-curve discrete logarithm problem.
If the attacker recorded the necessary handshake information, future advances could potentially allow recovery of the session secrets. That is different from compromising a database encrypted using AES-256.
The risks are not identical. And this is precisely why organisations need to understand which cryptographic mechanisms protect which information. The fact that a connection uses TLS 1.3 doesn’t, by itself, make it quantum-safe.
Post-Quantum Cryptography Is Already Available
The good news is that the industry isn’t waiting for a cryptographically relevant quantum computer before addressing these risks.
In August 2024, the US National Institute of Standards and Technology (NIST) finalised its first three post-quantum cryptography standards. These are:
- FIPS 203 — ML-KEM, a module-lattice-based key-encapsulation mechanism.
- FIPS 204 — ML-DSA, a module-lattice-based digital signature algorithm.
- FIPS 205 — SLH-DSA, a stateless hash-based digital signature algorithm.
ML-KEM addresses key establishment. ML-DSA and SLH-DSA address digital signatures. They are not interchangeable. These algorithms are designed to resist currently known attacks from both conventional and quantum computers.
Importantly, post-quantum cryptography doesn’t require a quantum computer. It runs on conventional systems, including IBM Z, where supported implementations are available.
NIST recommends beginning the transition now rather than waiting until a sufficiently capable quantum computer exists. And that is where things become particularly relevant to mainframe professionals.
IBM Z Already Has Post-Quantum Capabilities
IBM has been developing quantum-safe cryptographic capabilities for the mainframe (IBM Z) for several years, and these capabilities are not limited to theoretical research.
IBM documents support for NIST-standardised ML-KEM and ML-DSA through relevant z/OS cryptographic interfaces and software components. For example, IBM’s z/OS Cryptographic Services documentation describes the cryptographic services available through ICSF.
IBM also documents ML-KEM support through both PKCS #11 and CCA interfaces, with different hardware and software requirements.
Support is not necessarily restricted to IBM z17. Depending on the function, interface and installed maintenance, certain capabilities are available on IBM z16 systems with the appropriate Crypto Express features.
IBM Semeru for z/OS also provides post-quantum cryptographic capabilities for supported Java applications.
However, there is an important distinction: having a post-quantum algorithm available through ICSF doesn’t automatically mean that every application using ICSF is quantum-safe.
An application must actually use the appropriate algorithm. The required interfaces must be supported. The necessary hardware and software prerequisites must be satisfied, and the systems communicating with the application must support compatible cryptographic mechanisms.
The same applies to TLS. An implementation of ML-KEM within ICSF doesn’t automatically mean that every TLS connection established by z/OS System SSL, Java or a third-party product uses post-quantum key establishment. That depends on the capabilities and configuration of the specific TLS implementation and its communicating peer.
This is why organisations need to assess the actual end-to-end configuration rather than relying on a general statement that IBM Z supports quantum-safe cryptography.
There Is Another Important Compatibility Issue
Some organisations may already have experimented with early post-quantum cryptographic implementations.
For example, CRYSTALS-Kyber and CRYSTALS-Dilithium. These algorithms formed the basis of the NIST-standardised ML-KEM and ML-DSA algorithms. However, the final standards are not automatically interoperable with the earlier versions. IBM’s documentation explicitly identifies this distinction. That means organisations using earlier implementations may need to update their applications, replace algorithm-specific keys or perform additional migration activities.
This is another example of why cryptographic agility matters. Implementing an algorithm is one thing. Being able to replace it without significant disruption is another.
The Biggest Challenge May Be Knowing What We Already Use
I believe one of the most difficult parts of the transition will be cryptographic discovery. Think about a large mainframe environment:
- How many applications use TLS?
- How many certificates exist?
- Which algorithms are used for key establishment?
- Which applications use RSA or ECC for digital signatures?
- Which products call ICSF directly?
- Which use Java cryptographic providers?
- Which use z/OS System SSL?
- Which rely on cryptographic functionality provided by third-party software?
- And how many of those dependencies are properly documented?
Simply listing certificates in RACF isn’t enough. Some applications may use other certificate stores. Some cryptographic operations may be performed outside the mainframe. And some dependencies may exist in external systems communicating with z/OS applications.
Organisations need to understand the complete cryptographic architecture. They also need to know how long the information being protected must remain confidential. Not every system will have the same migration priority. A connection protecting information that remains sensitive for decades presents a different risk from one protecting short-lived information.
This is why I believe the first practical step should be to establish a proper cryptographic inventory. Without that information, it is difficult to know what needs to change.
Cryptographic Agility Will Become Increasingly Important
There is another concept that deserves attention: Cryptographic agility.
In simple terms, it means designing systems so that cryptographic algorithms can be replaced without requiring extensive application changes. This becomes particularly important with post-quantum cryptography.
Although NIST has finalised its first standards, cryptographic research continues. Additional algorithms are being evaluated. Implementations will evolve and protocols will continue to change.
Applications should therefore avoid unnecessary dependencies on particular algorithms, key formats or fixed cryptographic data lengths. Where appropriate, they should use supported cryptographic interfaces rather than implementing cryptographic algorithms themselves.
For mainframe environments, this is especially important. Some applications have been operating for decades and many will continue operating for decades to come.
A cryptographic dependency introduced today could become a significant migration problem tomorrow.
Will Quantum Computing Replace the Mainframe?
Now let’s consider the other side of the discussion.
Could quantum computers eventually replace IBM Z? I don’t believe so. At least not for the types of workloads mainframes are designed to process.
Quantum computers are specialised computational systems. Their potential advantage depends on the availability of suitable quantum algorithms and the characteristics of the problem being solved.
Mainframes are designed for large-scale business transaction processing, data integrity, high availability and efficient execution of conventional enterprise workloads.
These are different requirements.
A quantum computer isn’t going to become a better CICS transaction processor simply because it uses qubits, nor does quantum computing automatically make COBOL applications or Db2 databases obsolete.
The more interesting possibility is that quantum computers will complement conventional systems.
Quantum and Classical Computing Working Together
IBM has been developing an approach known as quantum-centric supercomputing.
In March 2026, IBM published a reference architecture describing how quantum processors can be integrated with conventional computing resources such as CPUs and GPUs. The idea is to use different processing technologies for the parts of a problem they are best suited to solving.
This is an important direction for quantum computing, but it doesn’t mean that IBM has announced a quantum processor directly integrated into IBM Z, nor does it mean that existing mainframe applications can automatically offload work to quantum hardware. Those are very different claims.
Nevertheless, consider a possible future scenario. A financial institution uses IBM Z for transaction processing and maintaining its core business records. It also has specialised analytical workloads involving optimisation or simulation. If suitable quantum algorithms eventually demonstrate a practical advantage for some of those calculations, the organisation might choose to use an external quantum-enabled service. The mainframe would continue processing transactions and maintaining the relevant information. The specialised service would perform a particular calculation, and the results would be returned to the conventional application environment.
This is a possible future architecture. Not an established production capability or a demonstrated quantum advantage for those specific financial workloads, but it illustrates how the technologies could complement one another.
What About IBM’s Quantum Roadmap?
IBM continues to invest heavily in quantum computing. Its current roadmap includes the objective of delivering IBM Quantum Starling, a fault-tolerant quantum computer, in 2029. The planned system is intended to support 200 logical qubits and approximately 100 million quantum gates.
These are ambitious engineering objectives. However, the roadmap represents IBM’s plans, not a guarantee that every milestone will be achieved on schedule, and it certainly doesn’t mean that RSA or ECC will automatically become practically breakable in 2029.
A cryptographically relevant quantum attack would require sufficient logical qubits, fault-tolerant operations, error correction and other computational resources. The exact requirements depend on the algorithm, key size and attack method. The timeline remains uncertain.
But there is an important point here: we don’t need to know the exact date when quantum computers will threaten existing public-key cryptography to know that migration planning should already be underway.
The systems we operate today may still be running when that threat becomes practical, and some of the information we protect today may still be sensitive at that time.
What Should Mainframe Organisations Be Doing Now?
I believe organisations should approach this in two separate ways.
The first concerns security.
They should identify where quantum-vulnerable cryptography is used, assess the sensitivity and lifetime of the information being protected, evaluate the post-quantum capabilities available in their environments and develop a controlled migration strategy. That includes understanding the requirements of z/OS, ICSF, System SSL, Java, middleware, third-party applications and communicating systems.
The second concerns the potential business applications of quantum computing.
Organisations should follow developments in quantum algorithms and quantum-classical integration, particularly where there is evidence of a practical advantage for a relevant workload, but they should avoid assuming that quantum computing will automatically improve every computational problem.
There is no reason to replace functioning mainframe applications simply because quantum technology is advancing. There is, however, every reason to ensure that the cryptography protecting those applications remains appropriate.
The Mainframe Isn’t Going Anywhere
Every few years, a new technology appears that is supposed to make the mainframe obsolete:
- Distributed computing.
- Cloud computing.
- Artificial Intelligence.
- And now quantum computing.
Yet the mainframe continues to evolve because organisations still need the capabilities it provides.
Quantum computing doesn’t change that. What it does change is the long-term security outlook for some of the cryptographic mechanisms used throughout enterprise computing.
And that is something mainframe professionals need to understand. Not because quantum computers are about to replace IBM Z, but because some of the security assumptions we rely on today will eventually need to change.
The mainframe will continue processing transactions, managing critical information and supporting essential business services.
The question is whether the cryptographic architecture surrounding those services will be ready for the future.
Quantum computing doesn’t need to replace the mainframe to have a significant impact on it. It only needs to make some of the cryptography we rely on today no longer secure enough for tomorrow.
The principal sources used for this article were:
- NIST — Post-Quantum Cryptography: standards, migration recommendations and developments through 2026.
- IBM — ML-KEM support in z/OS ICSF: supported interfaces and cryptographic hardware requirements.
- IBM — Post-quantum support for Java on z/OS: supported algorithms, prerequisites and compatibility considerations.
- IBM — Quantum Computing Roadmap: IBM’s fault-tolerant quantum computing objectives.
Be the first to comment