Quantum-safe migration, in plain language

1. What a quantum computer breaks

Almost everything that secures the internet today rests on two families of mathematics. Public key cryptography, which is RSA, ECDSA, Ed25519, Diffie-Hellman and their relatives, protects key exchange, digital signatures and identity. Symmetric cryptography, which is AES and ChaCha20, protects the bulk of the data.

A sufficiently powerful quantum computer running Shor's algorithm breaks the first family outright. Not weakens. Breaks. There is no larger RSA key size that fixes it, which is why the answer is replacement rather than reinforcement.

The second family is different. Grover's algorithm halves the effective key length rather than breaking the algorithm. That is the reason AES-256 is preferred over AES-128 for data that must stay confidential for a long time. The MAS advisory to financial institutions frames it exactly this way: symmetric cryptography may require larger key sizes to remain secure.

2. Why the risk starts now, not later

The common objection is that quantum computers are years away, so this can wait. That reasoning misses the point of the attack.

Traffic encrypted today can be recorded today and decrypted later, once a machine exists. The CSA Handbook calls this out directly: systems holding long-lived or highly sensitive data, financial and medical records in particular, are described as the primary targets of harvest-now-decrypt-later.

One practical way to think about it is to compare three numbers for any given system. How many years must this data stay confidential, how many years will migrating it take, and how many years until a machine exists. If the first two added together exceed the third, the exposure is already live, whatever the calendar says. The workbench does that arithmetic for you on the crown jewels register.

3. What replaced RSA and the rest

The replacement algorithms are no longer theoretical. The US National Institute of Standards and Technology finalised three standards, and the rest of the world is building on them.

• ML-KEM (FIPS 203, from CRYSTALS-Kyber) for key establishment.
• ML-DSA (FIPS 204, from CRYSTALS-Dilithium) for digital signatures.
• SLH-DSA (FIPS 205, from SPHINCS+) as a hash-based signature alternative, with different trade-offs.

In practice most deployments start with a hybrid: classical and post-quantum key exchange together, so that the connection is no weaker than today if the new algorithm turns out to have a flaw. That is why a scan reports on a group name like X25519MLKEM768 rather than a single algorithm. TLS 1.3 is the protocol version that makes hybrid key exchange possible, so a host still refusing TLS 1.3 cannot offer it at all.

A useful rule of thumb: if a scan says a host does not negotiate TLS 1.3, post-quantum hybrid key exchange is not merely missing, it is unavailable until TLS 1.3 is enabled.

4. What Singapore actually requires

Two documents matter, and they come from different regulators.

The CSA Quantum-Safe Handbook sets out requirements for Critical Information Infrastructure owners. Three dates are quoted verbatim from it: by 31 March 2027 a CII owner submits its quantum-safe migration plan to CSA; from 1 January 2028 new CII computer systems with a digital component should either support quantum-safe algorithms and technologies, or be quantum-safe ready; and by 31 December 2031 migration should be complete, meaning vulnerable cryptography is no longer in use.

The MAS advisory, circular MAS/TCRS/2024/01 dated 20 February 2024, was addressed to the chief executives of all financial institutions. It asks for crypto-agility, an inventory of cryptographic assets recording the algorithm and key length, who owns each asset and where it is used, and a strategy for the transition.

If you are neither a CII owner nor a financial institution, none of this is addressed to you directly. It reaches you through your customers. A bank or a government agency cannot meet its own obligations while depending on suppliers who cannot answer questions about cryptography, so the questions arrive in procurement documents and security questionnaires.

5. How to run a cryptographic inventory

The Handbook's first no-regret move is to identify your most critical systems and run cryptographic asset discovery on those first, rather than attempting to inventory everything at once.

1. Pick the systems that matter. Not all of them. The ones where compromise would hurt most, or where data must stay secret longest.
2. Look in more than one place. Applications and their dependencies, configuration files, TLS endpoints, certificates, keystores, and the contracts with whatever you rent.
3. Record more than the algorithm. The MAS advisory is specific: algorithm and key length, the owner, and the system where it is used. An inventory without owners does not survive its first review.
4. Separate production from everything else. Test fixtures and example code inflate a finding count and hide the real work.
5. State what you did not cover. An inventory that implies complete coverage when it only covered the public edge is worse than one that says plainly what it missed.

6. What crypto-agility means in practice

Crypto-agility is the ability to change an algorithm without re-engineering a system. It is the difference between a migration measured in weeks and one measured in years, and it is why both the Handbook and the MAS advisory treat it as central rather than optional.

The test is simple. If a new algorithm is mandated tomorrow, how many places in your estate must change, and how long would that take? If the answer involves a code release across several applications, agility is not yet in place.

The workbench has a twelve point agility checklist you can work through in a few minutes, and the gaps feed straight into the migration plan it generates.

Questions people ask before they start

What is quantum readiness?

Quantum readiness is knowing where your organisation depends on cryptography that a quantum computer would break, and having a plan to replace it. In practice it means a cryptographic inventory, an assessment of which systems matter most, and a sequenced migration plan.

What does the CSA Quantum-Safe Migration Handbook require?

The Handbook, published 16 July 2026 by CSA with GovTech and IMDA, sets out five workstreams and a set of no-regrets moves. For Critical Information Infrastructure owners it sets the dates: a quantum-safe migration plan submitted to CSA by 31 March 2027, new systems quantum-safe or quantum-safe ready from 1 January 2028, and migration complete by 31 December 2031.

What is the Quantum Readiness Index?

It is a self-assessment questionnaire published alongside the Handbook. It asks questions across five domains and returns a readiness level per domain, so a system owner can see where to start and can track progress over time.

Will RSA be broken, and when?

RSA and elliptic curve cryptography are broken by Shor's algorithm on a sufficiently large quantum computer. No RSA key size survives it. The date is not known, which is exactly why the work starts now: migration takes years, and data recorded today can be decrypted later.

What is harvest now, decrypt later?

An attacker copies encrypted traffic or stored data today, keeps it, and decrypts it once a quantum computer is available. If data must stay confidential for longer than the time to quantum, it is exposed already, even though nothing appears broken yet.

What is a cryptographic bill of materials?

A CBOM is an inventory of the cryptographic assets an application depends on: algorithms, key sizes, certificates, libraries and protocols, with where each one appears. It is the artefact a migration plan is built from.

What does MAS expect from financial institutions?

The MAS advisory of 20 February 2024 asks financial institutions to build crypto-agility and to maintain a cryptographic inventory covering algorithms, key lengths, ownership and the systems they protect.

Do we have to send you our source code?

No. Public repositories and endpoints can be scanned from here, and everything else runs through the offline scanner inside your own network, where source never leaves and only findings are produced.