How to Prepare Legacy Delphi and C++ Software for a Post-Quantum World

There’s been a growing buzz around quantum computing. Along with actual research and standards comes the inevitable wave of marketing: “quantum-ready” products, “quantum-safe” assessments, and offers to urgently protect corporate systems from computers that don’t yet exist in a form capable of breaking the cryptography used today. But if we greatly simplify the practical challenge, roughly 99% of the work involved in preparing conventional business software for the post-quantum world has nothing to do with buttons, reports, SQL queries, or business logic, but to cryptography—specifically, how the system protects access to data, establishes secure connections, and verifies the authenticity of another party or a file. This isn’t research-based statistics, but a practical illustration of the scale of the challenge. And even here, a significant portion of readiness does not depend on the Delphi or C++ application itself. The operating system, cloud platform, database driver, TLS library, identity provider, certificate infrastructure, and other vendor products must also support the new standards. Therefore, in many projects, the challenge lies not only in modernizing one’s own code but also in assessing how ready the vendors across the entire technology stack are for the migration.

For regulated industries, this topic is no longer just a discussion about the distant future. In U.S. federal systems, the use of NIST standards is mandatory, and government agencies are required to maintain a cryptographic inventory and plan the transition to post-quantum cryptography. In the European Union, the Coordinated Implementation Roadmap requires member states to begin the transition by the end of 2026 and to prioritize high-risk use cases. In its June 2026 Risk Assessment Report, the European Banking Authority (EBA) specifically noted that banks must already begin to account for the risks associated with the anticipated future use of quantum technologies. This does not mean that regulated companies need to replace all their cryptography overnight. A practical, phased plan begins with an inventory of the software estate and cryptographic dependencies, followed by the development of a migration roadmap, and only then are specific technical measures implemented. (https://www.nist.gov/pqc) (https://pages.nist.gov/nccoe-migration-post-quantum-cryptography/) (https://digital-strategy.ec.europa.eu/en/policies/post-quantum-cryptography) (https://www.eba.europa.eu/publications-and-media/publications/risk-assessment-report-june-2026)

This is exactly how we should view legacy software modernization. The National Institute of Standards and Technology (NIST)—the U.S. National Institute of Standards and Technology—is one of the key organizations developing widely used cryptographic standards. (https://www.nist.gov/) NIST has already released the first standards for **Post-Quantum Cryptography (PQC)*—cryptographic algorithms designed to be resistant to both conventional and future quantum computers. (https://www.nist.gov/pqc)

But that doesn’t mean you need to rush to rewrite your old Delphi or C++ application.

The Quantum Problem Is Narrower Than It Sounds

A quantum computer does not automatically make databases, Delphi forms, reports, business rules, or thousands of lines of C++ code vulnerable.

The main risk concerns public-key cryptography.

The two best-known classes of algorithms here are RSA (Rivest–Shamir–Adleman), named after its creators, and ECC (Elliptic Curve Cryptography), cryptography based on elliptic curves. They are used for tasks such as securely establishing a secret key over an open channel, certificates, and digital signatures. A sufficiently powerful quantum computer could potentially undermine the mathematical assumptions on which their security is based. NIST cites RSA and ECC as examples of existing public-key cryptography that is threatened by the advancement of quantum computing. (https://pages.nist.gov/nccoe-migration-post-quantum-cryptography/)

To replace these mechanisms, NIST has standardized several new algorithms. Their names may sound complicated, but their purpose is quite simple.

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) is a mechanism that allows two parties to securely agree on a shared secret key over an open channel. This key can then be used to encrypt regular network traffic. This is the NIST FIPS 203 standard. (https://csrc.nist.gov/pubs/fips/203/final)

ML-DSA (Module-Lattice-Based Digital Signature Algorithm) — a post-quantum algorithm for digital signatures: one party signs the data, and the other verifies who signed it and whether it has been altered. This is the NIST FIPS 204 standard. (https://csrc.nist.gov/pubs/fips/204/final)

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) — another NIST-standardized digital signature algorithm, based on a different mathematical approach and designed for the same fundamental task of verifying authenticity. This is the NIST FIPS 205 standard. (https://csrc.nist.gov/pubs/fips/205/final)

As the owner of a legacy application, it is generally not necessary to understand the inner workings of these algorithms. It is more important to understand exactly where the existing system uses public-key cryptography and how easily this mechanism can be replaced.

Start With Problems That Do Not Need a Quantum Computer

In a legacy application, it’s often much easier to steal a secret today than to wait for a quantum computer to become available.

We saw this clearly in one of the CRM systems developed many years ago using a classic desktop stack.

The same encryption key was hard-coded directly into the desktop application. It was used to protect both user data and the database connection string. A separate utility program could decrypt them using the same key.

This means that a person who has received the application and has the opportunity to analyze it does not need a quantum computer at all. The secret is distributed along with the program it is meant to protect.

Passwords were also stored using reversible encryption. Upon login, the program encrypted the entered password and compared it to the stored value. From an architectural standpoint, this is not a secure method of password verification: the system is capable of recovering the original password.

The connection string to SQL Server was protected by the same mechanism and the same key. Therefore, a compromise in one location simultaneously exposed several classes of secrets.

The Integrity Update Package was verified using CRC32 (32-bit Cyclic Redundancy Check). This checksum helps detect accidental file corruption, but does not confirm its origin: whoever replaced the file could have recalculated the checksum as well.

The database update was performed from a desktop computer and required privileged SQL credentials on the client side.

The web component of the system used an outdated ASP.NET stack, a long-lived authentication session, and MD5 (Message-Digest Algorithm 5) for password storage in one of its components.

Finally, the old database driver did not meet the architectural requirement that the connection to the database must always be encrypted.

None of these problems arose because of quantum computing.

And those are the ones that need to be corrected before we start discussing ML-KEM.

First Build a Cryptographic Inventory

For an older Delphi or C++ application, the most important initial technical task is not to choose a new algorithm, but to figure out where the cryptography is located in the first place.

NIST recommends that organizations begin the transition by conducting an inventory of systems that use cryptography and engage separately with technology vendors regarding the upcoming changes. (https://www.nist.gov/cybersecurity-and-privacy/what-post-quantum-cryptography) NIST’s more detailed migration guidance also places the cryptographic inventory at the beginning of the practical transition. (https://pages.nist.gov/nccoe-migration-post-quantum-cryptography/)

A legacy system inventory should answer at least a few questions:

– where the application stores passwords, encryption keys, and certificates;

– which components establish encrypted network connections;

– where RSA, ECC, or other public-key algorithms are used;

– how the authenticity of update packages and executable files is verified;

– which cryptographic libraries are used and who maintains them;

– which database drivers, operating systems, cloud services, and external APIs are involved in secure communication;

– what data must remain confidential for five, ten, or twenty years.

The last point is particularly important because of the “harvest now, decrypt later” scenario: encrypted traffic can be stored today and decrypted later if a sufficiently powerful quantum computer becomes available. NIST considers long-lived sensitive data to be one of the factors that must be taken into account when conducting an inventory and prioritizing migration. (https://pages.nist.gov/nccoe-migration-post-quantum-cryptography/)

After taking inventory, it usually becomes clear that the quantum scope is much smaller than the total volume of the application.

A Practical Migration Path

For most Delphi and C++ systems, we would carry out the migration in roughly the following sequence.

1. Inventory the software estate and cryptography. Identify the applications, services, libraries, certificates, network protocols, keys, and vendors on which security depends.

2. Remove secrets embedded in applications. Database passwords, encryption keys, and other long-term secrets should not be stored inside an executable or configuration file in a form that allows the application to recover them on its own.

3. Replace reversible password storage. Passwords should be stored in a format designed for verification, not for decryption. Existing records can be migrated gradually after a successful login.

4. Move privileged operations away from desktop clients. Database schema migration and other administrative operations should be performed on the server side or through a controlled deployment process. Desktop applications should not be granted administrator credentials.

5. Require encrypted connections and authenticated updates. Communication with the database, API, and backend must use a modern encrypted transport. Update packages must be verified using a digital signature, not just a checksum.

6. Centralize cryptography. Business modules should not directly select algorithms. Delphi desktop, C++ service, updater, and utilities should call upon a restricted cryptography layer or supported platform APIs.

7. Replace vulnerable public-key mechanisms when the surrounding platform is ready. After completing the previous steps, it becomes clear where PQC will actually be needed: secure connections, certificates, update signatures, or other public-key operations.

In this way, the abstract “quantum readiness project” is transformed into a series of specific engineering tasks.

Two Areas Usually Matter Most

For many business applications, the post-quantum scope ultimately revolves around two things.

The first is a secure connection.

When an application connects to a backend, cloud service, update server, or database, a secure protocol must establish secret session keys. Today, some of these mechanisms may rely on RSA or ECC. This is precisely where quantum-resistant key establishment is expected to emerge over time.

This does not mean that Delphi business code must implement ML-KEM on its own. Typically, the correct approach is the opposite: the application should use a modern, supported security provider, operating system, or networking library, and the cryptography is handled within that layer.

The second area is digital signatures.

Let’s imagine that the CRM is downloading an update package. The checksum shows that the file corresponds to a certain set of bytes, but it does not prove who created the file.

A digital signature solves exactly this problem. The vendor signs the update with its private key, and the application verifies the signature using the public key.

Today, this may be an existing classical algorithm. In the future, the signing infrastructure and verification component should allow for a transition to a post-quantum signature algorithm.

The business logic updater should not change in this case.

This is a good example of what true crypto agility is: the ability to replace a cryptographic mechanism without rewriting the application itself.

What Does Not Need to Become “Post-Quantum”

This boundary is particularly important when estimating the cost of a project.

Delphi forms are not post-quantum. Reports are not post-quantum. SQL queries are not post-quantum. Business rules are not post-quantum.

Password hashing needs to be updated if MD5 or reversible encryption is used, but this problem exists regardless of quantum computing.

The hardcoded key must be removed for the same reason.

CRC32 is not sufficient to verify the authenticity of an update package, regardless of the quantum threat.

The administrator password must not be stored on the client machine, regardless of when a sufficiently powerful quantum computer becomes available.

This is the difference between security modernization and post-quantum migration itself.

A legacy application may have ten cryptographic issues. Most of them will need to be fixed because they are already insecure today. Only a few will remain directly related to the future replacement of public-key algorithms.

For the customer, this is a key point: a significant portion of the budget provides an immediate security benefit, rather than merely protecting against a hypothetical future threat.

Your Vendors Are Part of the Migration

In a legacy environment, it is not possible to make an application quantum-ready in isolation.

Let’s say a Delphi application uses OpenSSL for HTTPS or email. The application itself may not implement public-key cryptography at all—it calls an external library.

The current version of OpenSSL already supports the standardized NIST post-quantum algorithms: support for ML-KEM, ML-DSA, and SLH-DSA was added in OpenSSL 3.5. (https://openssl-library.org/post/2025-04-08-openssl-35-final-release/) However, an older Delphi component may be tied to a long-obsolete version of OpenSSL and may not work with the modern provider. In this case, modernization is needed not for the CRM’s business logic, but for the integration layer between the application and the cryptographic library.

The same applies to C++.

Cryptography may be found in a statically linked library, an operating system API, a database driver, a VPN client, a cloud service, a certificate service, or a third-party SDK.

Therefore, if we use a qualitative rather than a statistical assessment, a significant portion of that “90% quantum readiness” is often found among vendors.

The system owner needs to determine when the operating system will receive the necessary support; when the database vendor will update the driver; which TLS stack is being used; whether the cloud provider supports new standards; whether the certificate mechanism can be replaced; whether the library in use receives security updates; and whether any legacy components are blocking the transition to a new version.

That is precisely why NIST recommends not only conducting your own inventory but also discussing the transition with vendors in advance. (https://www.nist.gov/cybersecurity-and-privacy/what-post-quantum-cryptography)

For very old systems, the analysis may sometimes lead not to “adding a new algorithm,” but to replacing a networking component, updating the runtime, or moving secure communication to a separate, modern service.

Crypto Agility Matters More Than One Algorithm

One of the main problems with legacy software is not that a particular algorithm was chosen twenty years ago.

The problem arises when this algorithm cannot be replaced.

If encryption is called directly from multiple forms, certificate validation is implemented in several libraries, a single key is shared across utilities, and the updater uses yet another separate crypto implementation, any migration becomes a major software modernization project.

Therefore, the architectural goal should be simple: the business code knows what it needs to do—establish a secure connection, verify the signature, retrieve the protected secret—but does not determine which cryptographic algorithm is used to perform these tasks.

The specific algorithm is implemented behind a cryptographic layer, an operating system service, or another replaceable provider.

That’s what crypto agility is all about.

It is useful regardless of which specific post-quantum standard will be in use ten years from now.

Prioritize by Risk and Data Lifetime

Not all applications carry the same level of quantum risk.

If the data loses its value after a week, the risk is at one level. If the system stores medical records, financial information, industrial intellectual property, government information, or other data that must remain confidential for decades, the situation is entirely different.

Therefore, the right question doesn’t go like this:

“When will a quantum computer be available?”

No one knows the exact date.

A more useful question:

“How long should our current data remain confidential, and how long will it take us to replace the cryptography we’re using?”

NIST emphasizes that migrating to new cryptographic standards takes time and recommends beginning the transition now, before a cryptographically relevant quantum computer becomes available. (https://www.nist.gov/pqc) (https://www.nist.gov/cybersecurity-and-privacy/what-post-quantum-cryptography)

For regulated organizations, there is a second issue to consider:

“When will a regulator or customer require us to prove that we understand our cryptographic dependencies and have a migration plan?”

For many organizations, this moment will come well before the actual quantum computer.

What a Real Quantum-Readiness Project Should Deliver

After a standard project, the client shouldn’t just receive a presentation on quantum risk.

He must achieve a specific result.

For the CRM described, this would mean the following: the encryption key is no longer contained within the desktop executable; passwords cannot be decrypted; privileged database credentials are not passed to the desktop application; network connections are always secured; the update package has a valid digital signature; and the cryptographic logic is not scattered across the desktop, portal, and utilities.

In addition, an inventory is generated that identifies where cryptographic algorithms are used, which libraries and vendors are responsible for them, which components need to be updated, and which data flows have long-term confidentiality requirements.

After that, a migration roadmap is created.

And only then do changes begin in those areas where post-quantum cryptography is truly needed.

If a networking provider gains support for a new key-establishment mechanism, the transport layer is updated.

If the signing infrastructure transitions to post-quantum signatures, the signing and verification layer is updated.

The business application continues to perform the same function.

This is the practical approach to legacy application migration in a post-quantum world: rather than rewriting the entire application around a trendy new algorithm, ensure that the cryptography it uses is no longer architecturally irreplaceable.

Post-Quantum Readiness Is an Architecture Property

Companies don’t need to choose between two extremes: ignoring quantum computing or rushing to turn every legacy application into a separate quantum project.

The practical approach is much less stressful.

First, conduct an inventory of the software estate and cryptographic dependencies.

Next, fix the security issues that are already posing a threat today.

Next, identify which data requires long-term confidentiality and determine which public-key mechanisms are vulnerable.

At the same time, review the roadmaps for the operating system, cloud, database, libraries, and other vendors on which the application depends.

Next, centralize cryptography and establish crypto agility.

And only then should post-quantum mechanisms be implemented where they are truly needed and where the surrounding platform is ready to support them.

For an older Delphi or C++ application, this is often a much smaller project than one might expect from the term *post-quantum migration*.

But that is precisely why it’s worth starting now—not by buying yet another quantum-ready product, but by understanding your own architecture.