NOTE: In this series of posts, we revisit recent presentations delivered at MU.SCL and provide additional context around the slide decks shared here. While a written post cannot fully reproduce the depth, examples and discussion of a live session, it should help readers better understand the topic, the key messages, and the practical points behind the slides.

Earlier this month, at our latest Mauritius Cyber Security Club event, I gave a presentation on Post-Quantum Cryptography with a deliberately practical objective: not to explain every detail of quantum physics, but to answer a much more useful question for organisations:

What do we need to do now to make sure that information which must still be secret tomorrow remains protected?

The presentation therefore focused on four things:
why the deadline may be closer than it appears, where vulnerable cryptography actually hides inside an organisation, what a realistic migration programme looks like, and what "good" quantum readiness should mean in practice.

The timing of the presentation was particularly relevant, as today, 17th of September, DigiCert is marking the third annual World Quantum Readiness Day.
It is an industry-led initiative rather than a regulatory deadline, but its 2026 theme, "From Blueprint to Build", describes quite well where cybersecurity has now reached with Post-Quantum Cryptography (PQC).
The discussion is shifting from "is this something we should worry about?" to "how do we actually do it?”, an important change in mindset, and one we will come back to later in this post.

As a side note, every year there is a World Quantum Day and a World Quantum Readiness Day and they are not quite the same thing:

The World Quantum Day, celebrated every year on 14 April is a global, science-led initiative intended to promote understanding of quantum science and technology. By the way, the date "4.14" is a reference to the first digits of Planck's constant, a fondamental component of quantum mechanics.

World Quantum Readiness Day has a narrower and rather more operational purpose: what are organisations doing about the cybersecurity consequences of quantum computing?

Quantum computing has enormous potential in science, engineering, medicine and many other fields but from a cybersecurity perspective, however, one specific capability creates a problem: a sufficiently capable quantum computer could undermine the mathematical problems on which much of today's public-key cryptography depends.
The day this will happen is called Q-DAY.

Before anyone panics, there is no publicly demonstrated Cryptographically Relevant Quantum Computer (CRQC) capable of doing this today.
But that does not mean the cybersecurity deadline starts on Q-Day, in fact, waiting for Q-Day would be one of the worst possible migration strategies.

Future attacks that can start today

One of the most important concepts in the presentation was "Harvest Now, Decrypt Later" and this attack is relatively simple:
An adversary collects encrypted information today, they do not need to decrypt it, they just keep it.
Years later, if the cryptography protecting that information becomes breakable, they apply the new capability to whichever collected information still has value.
That data could come from intercepted network traffic, stolen backups, exfiltrated mailboxes, cloud snapshots, archives or other sources. Crucially, upgrading a system after that information has already been collected does nothing to protect the copy sitting on somebody else's storage.

This creates a very different risk calculation from most technology migrations as the date that matters is not simply the estimated arrival date of a capable quantum computer:
Data secrecy lifetime + migration time > time to a capable quantum computer

If information needs to remain confidential for another 15 years, and replacing the cryptography protecting it will realistically take five years, an organisation cannot safely decide to start the migration ten years from now.
In other words, the clock has already started!
This is why arguing about whether Q-Day will occur in 2029, 2032, 2035 or later misses part of the point: Nobody knows the exact date.

You do, however, have much more control over how long your sensitive information remains valuable and how long your own migration will take.

No, quantum computers will not "break all encryption"

This is another area where the headlines are often more dramatic than the technical reality as quantum computing is not a universal skeleton key. To use quantum computing against cryptography you need to set them up specifically for that task, and to do that, there are 2 main known algorithms:

Shor's algorithm threatens the mathematical foundations of the public-key algorithms we rely upon for key establishment and digital signatures, including RSA, finite-field Diffie-Hellman and elliptic-curve cryptography.

Grover's algorithm has a different effect on symmetric cryptography and hashing. It reduces their security margin, but it does not affect them in the same catastrophic way.

It means that AES does not suddenly become useless overnight!
The more accurate statement is that much of our current public-key cryptography eventually needs to be replaced, while appropriately sized symmetric encryption and hashes remain usable.

That distinction is extremely important when organisations start looking at their own environments:
A backup encrypted using AES-256 may be perfectly acceptable.
But how was the AES key protected? Was it wrapped using RSA? Was it exchanged using traditional Diffie-Hellman? What certificates authenticate the systems involved?

Cryptography is a dependency chain, and looking only at the algorithm protecting the data can give a false sense of security.

We are no longer waiting for the standards

A few years ago, one reasonable argument for delaying PQC deployment was that the standards were still being developed, well, that argument is disappearing!

In August 2024, NIST finalised its first three major Post-Quantum Cryptography standards: ML-KEM for key establishment, and ML-DSA and SLH-DSA for digital signatures. NIST explicitly says that organisations should begin migrating and that the standards are ready for implementation.

And now governments are adding timelines:

The UK NCSC recommends completing discovery and an initial migration plan by 2028, carrying out the highest-priority migrations by 2031 and completing migration by 2035. National Cyber Security Centre

The European Union's coordinated roadmap says Member States should start transitioning by the end of 2026, with high-risk use cases and critical infrastructure transitioned as soon as possible and no later than the end of 2030. Interestingly, the EU published additional feedback on the roadmap this month, highlighting risk-based prioritisation, hybrid approaches and crypto-agility among the most useful elements identified by respondents.

And in June this year, the United States issued Executive Order 14412, establishing an accelerated federal transition to PQC. Among other things, it puts 2030 and 2031 dates around key establishment and digital signatures for high-value federal systems and brings federal procurement into the migration effort.

These are different jurisdictions with different legal effects and they should not be misrepresented as one universal global compliance deadline, but the direction is difficult to miss:
Inventory. Prioritise. Get supplier plans. Start migrating.

And Mauritius?

There is currently no Mauritian regulation saying that every company must replace RSA with ML-KEM tomorrow but that does not mean organisations here can ignore the issue.
The Bank of Mauritius Guideline on Cyber and Technology Risk Management already requires financial institutions to use encryption and cryptographic controls in accordance with recognised standards and processes, including appropriate algorithms and key lengths.
The Data Protection Act also requires security measures to take account of factors including the state of technological development, implementation cost, processing risks and the nature of the information being protected.

Neither statement should be stretched into claiming that Mauritius has already mandated PQC but the practical pressure may arrive from somewhere else first:
A Mauritian company providing services to a European customer may find PQC appearing in a third-party security assessment.
A bank may receive new requirements through international payment or correspondent-banking relationships.
A multinational parent company may impose its own migration programme.
Cloud, security and networking vendors will progressively change supported protocols and cryptographic defaults.

In other words, for many organisations in Mauritius and the wider Indian Ocean region, the first quantum deadline may not arrive in a law, it may arrive in a supplier questionnaire.

Being quantum-ready does not mean being quantum-safe by Friday

The objective is not to launch a huge project and attempt to replace every cryptographic implementation immediately as it would be expensive, disruptive and, in some cases, technically impossible today.
Readiness means knowing enough about your environment to make rational decisions as standards, products and risks evolve.

In the presentation I reduced this to five fairly simple questions:

What cryptography do you actually run: algorithms, certificates, keys, protocols, libraries, HSMs and suppliers?

What information needs to remain confidential for the longest period, and until when?

Who actually owns the migration risk?

What have our important suppliers committed to, in writing, with a product version and a date?

And finally, if an algorithm needed to change again, could we do it without launching another multi-year project?

That last question leads to something that may ultimately matter more than the particular algorithms selected today: Crypto-agility.

Cryptographic migration is continuous

A useful reminder arrived only a few weeks before the MU.SCL presentation:
In July, HAWK, one of the additional post-quantum digital-signature candidates being evaluated by NIST, was withdrawn after an AI-assisted mathematical attack identified a weakness in the scheme.

That did not break NIST's finalised ML-KEM or ML-DSA standards, NIST was explicit about this, and HAWK was still a candidate: the review process did what a review process is supposed to do as a weakness was discovered before the algorithm became a standard and was widely deployed.
The interesting lesson for organisations is something else: Cryptography changes.

Algorithms are weakened, standards evolve, parameters change, certificates get shorter lifetimes, protocols are deprecated and new attacks appear.
If changing an algorithm requires three years of meetings, business cases, application rewrites and hardware replacement, you do not only have a quantum problem: You have a cryptographic agility problem.
This is why a mature PQC programme should not simply ask "which quantum-safe product should we buy?". It should build the ability to discover cryptography, abstract it away from business logic where possible, automate key and certificate lifecycle management, observe which algorithms are actually being negotiated, test migration and rollback, and repeat that process when the next change inevitably arrives.

The presentation summarised the target state as four capabilities: OWN, KNOW, CHANGE and PROVE.
Have a named risk owner; maintain a prioritised cryptographic inventory; have tested migration and rollback capability; and retain evidence of supplier commitments and progress. Three of those four are primarily governance capabilities, not cryptographic ones.

That is perhaps the most useful way to think about "quantum readiness".

From Blueprint to Build

Which brings us back to World Quantum Readiness Day.
The 2026 theme, "From Blueprint to Build", is appropriate because we now have quite a lot of the blueprint:

We have standardised algorithms.

We have government roadmaps.

We have migration deadlines beginning to appear.

We have major technology vendors implementing hybrid post-quantum mechanisms.

We understand the Harvest Now, Decrypt Later problem.

What many organisations still do not have is the less glamorous part: an inventory, an owner, priorities, supplier commitments and a realistic migration plan.

This is where the work should start, and not by ripping out every RSA certificate tomorrow or by buying something labelled "quantum-safe" and assuming the problem has disappeared and certainly not by waiting until somebody announces Q-Day.

Our own practical recommendation from the presentation was deliberately achievable: name an owner, start the cryptographic inventory, identify the information that needs the longest protection, enable the easy wins already available, and start demanding product versions and migration dates from suppliers.

Nobody can finish the post-quantum migration in 2026, but everybody can start it in 2026.