You read "advisory" and you relax. That's the whole point of the word.

So when Singapore's Cyber Security Agency released two quantum documents on 16 July 2026, both stamped "not mandatory, prescriptive nor exhaustive," most companies did exactly what that label invites them to do: filed it under someday.

That's a mistake. One of those two documents contains a fixed date by which critical infrastructure owners must submit a migration plan to the government. Another date after which new systems must be quantum-safe or quantum-safe ready. A third by which vulnerable cryptography must be gone entirely. None of that reads like optional guidance once you know it's there.

This post breaks down what Singapore actually published, who the dates apply to, and what every company, not just the ones directly named, should be doing in response.

Two Documents, One Day, Very Different Jobs

Singapore didn't release one quantum policy. It released two, and they do different things.

The Quantum-Safe Migration Handbook lays out what's at risk and what organisations should do about it. The Quantum Readiness Index is a self-assessment tool. You answer questions, it scores you across five domains (risk, governance, technology, training, and external engagement), and it hands you back a readiness level from L0 to L3.

Here's the distinction that trips people up. The Index measures whether your organisation has the processes and expertise to plan a migration. It does not measure whether you've actually migrated anything. A company could hit the top readiness tier without having replaced a single vulnerable algorithm. That's not a flaw in the tool. It's just not what the tool is for.

The Handbook is the one with weight.

The Dates Nobody Should Ignore

If your organisation owns Critical Information Infrastructure (CII), meaning you operate in energy, water, transport, finance, healthcare, or government, the Handbook gives you three fixed checkpoints:

  • 31 March 2027 — your quantum-safe migration plan is due to the Cyber Security Agency
  • 1 January 2028 — new CII systems with a digital component should support quantum-safe algorithms, or be ready to
  • 31 December 2031 — migration across CII systems should be complete, with vulnerable cryptography retired

These are the only dated commitments in either document. The agency itself notes that detailed guidance to support this timeline is still being developed. And nowhere does the Handbook claim these dates carry legal force.

But read the rest of the language and a pattern shows up. Organisations "must start now with planning." Cryptography vulnerable to attack "should be prioritized for replacement." Procurement policy should "explicitly require" vendors to prove they have a post-quantum roadmap. RSA, Diffie-Hellman, and elliptic-curve cryptography, the algorithms underneath most of the internet's encryption today, are formally listed as deprecated.

That's not soft language dressed up as policy. It's policy dressed up as soft language.

If You're Not a CII Owner, You're Not Off the Hook

Here's where founders and non-regulated companies tend to check out, and where they shouldn't.

The fixed dates in the Handbook apply narrowly to CII owners. No other category of organisation is assigned them. But the direction of travel applies to everyone, and it's going to reach you through a door you don't control: your vendors and your customers.

Think about it from the other side. A bank or a utility with a 2027 deadline to report a migration plan isn't going to wait until 2030 to ask its suppliers hard questions. It's going to start asking now, because its own plan depends on knowing what its vendors can deliver. If you sell software, infrastructure, or any digital service into a regulated sector, procurement is where this policy reaches you first, well before any regulator does.

Startups building anything with a long sales cycle into finance, healthcare, or government should treat "do you have a post-quantum roadmap" as a question that's coming, not a question that might come.

What the Documents Don't Solve

To be fair to Singapore's approach, it's candid about its own limits. The agency admits automated cryptographic discovery tools are still maturing and won't catch everything. It records real scepticism about the actual scale of the harvest-now-decrypt-later threat, where encrypted data is stolen today to be decrypted once quantum computers are capable. It also flags open debate about how mature quantum key distribution testing standards even are.

But several real gaps remain, and they're worth planning around rather than waiting on:

  • No CBOM specification. Companies are told to request a Cryptographic Bill of Materials from vendors, but no format or minimum content is defined. You'll be inventing your own standard.
  • No definition of "quantum-safe ready." That exact phrase carries the entire 2028 procurement expectation, and it isn't defined anywhere in either document.
  • No funding model, no risk methodology, no reference architecture. You're on your own for how to pay for this and how to sequence it.
  • No link between the Index score and the CII migration plan. A high readiness score and an approved migration plan are two separate things. Don't confuse one for the other.

What to Actually Do Now

Strip away the disclaimers and four moves hold up regardless of whether you're a CII owner, a startup, or a mid-size company watching from the sidelines:

Name an owner. Someone in your organisation needs to be accountable for cryptographic risk specifically, not folded into a general security mandate nobody tracks.

Scope your crown jewels first. Don't try to inventory every system you run. Identify the handful of systems where a breach or a future decryption would actually hurt, and start cryptographic discovery there.

Discover before you decide. You can't replace what you haven't found. Pull from what you already have: HSM logs, certificate systems, server configs, network diagrams. Automated tools help, but they won't catch everything on their own.

Start asking vendors for their roadmap. Even if nobody has asked you yet, you can get ahead of your customers' procurement teams by asking your own suppliers the same question first.

The Bottom Line

Singapore has set the clock. It has not set the method.

The CII dates are the only fixed points in either document, and they're worth planning backward from even if you're not directly named. Everything else, the evidence standard, the vendor specification, the funding model, is left open. That's not an invitation to wait. It's an invitation to decide, ahead of everyone else, what proof you'd put in front of a regulator or a board if asked tomorrow.

Standards and acceptable algorithms will keep evolving. Whatever you build now, build it to be changed again.