Singapore's Quantum-Safe Migration Handbook: What It Actually Means for PQC Migration
- Brian Couzens
- Aug 8
- 8 min read
Singapore has set the clock. It has not set the method.
Singapore published two quantum-related documents on 16 July 2026:
The Quantum-Safe Migration Handbook v1
The Quantum Readiness Index v1.0
The team at SITG-Consulting has reviewed both documents in detail.
There is useful material here. The documents move the discussion beyond general awareness of quantum computing and towards organisational preparation, cryptographic discovery, governance, supplier engagement and migration planning.
But they also need to be read carefully.
Both documents explicitly state that they are "not mandatory, prescriptive nor exhaustive". At the same time, the Quantum-Safe Migration Handbook sets out dated milestones for Singapore's Critical Information Infrastructure, or CII, owners.
That creates an important distinction.
These documents are not simply another statement that organisations should start thinking about post-quantum cryptography.
Nor are they, taken as a whole, a complete regulatory or enterprise migration framework.
The question is therefore not whether Singapore is taking quantum risk seriously.
It clearly is.
The more useful question is:
What has Singapore actually established, who does it apply to, what does the Quantum Readiness Index actually measure, and what does an organisation still have to work out for itself?
The full SITG-Consulting forensic analysis is attached to this article.
What has Singapore actually published?
The two documents perform different functions.
The Quantum-Safe Migration Handbook provides practical guidance around the quantum threat and the organisational and technical considerations involved in preparing for migration.
The Quantum Readiness Index is a self-assessment mechanism designed to help an organisation understand its organisational readiness.
The distinction is important.
The Index assesses organisational readiness, not whether an organisation has actually completed cryptographic migration. CSA defines readiness as the "organisational processes and expertise required to plan and execute the migration".
The Index uses five domains:
Risk Assessment
Governance
Technology
Training and Capability
External Engagements
Each domain contains two objectives, with four maturity levels ranging from Not Started through Initial and Defined to Operational.
This makes the QRI useful as a readiness baseline.
But it is important not to confuse a readiness assessment with evidence of migration.
They are different things.
The CII deadlines are the significant signal
The most consequential part of the Handbook is the dated milestones for CII owners.
The Handbook identifies three dates.
31 March 2027
CII owners are expected to submit their quantum-safe migration plan to CSA.
1 January 2028
New CII systems with a digital component should support quantum-safe algorithms or be quantum-safe ready.
31 December 2031
Migration across CII systems should be complete, with vulnerable cryptography no longer used.
The Handbook also states that detailed guidance to support CII owners is still being developed.
These dates matter.
But precision matters just as much.
The Handbook does not state that these dates are legally enforceable.
Therefore, the correct description is not that Singapore has suddenly created a universal PQC deadline for every organisation.
The dates identified in the Handbook are addressed specifically to CII owners.
That distinction should be maintained throughout any discussion of Singapore's quantum-safe migration policy.
Read the language carefully
One of the easiest ways to misinterpret cybersecurity policy is to treat every statement as carrying the same level of obligation.
The Handbook does not do that.
For example, it states that organisations "must start now with planning".
It says public-key cryptography vulnerable to Shor's algorithm "should be prioritized for replacement".
It says procurement policies should be updated to "explicitly require" crypto-agility and vendor post-quantum roadmaps.
It also identifies RSA, DH and ECC as deprecated in its algorithm table.
Those statements should not be collapsed into one generic category called "requirements".
There is a difference between a stated expectation, a recommendation, a deprecation position and a legally enforceable obligation.
The distinction becomes particularly important when organisations translate government guidance into internal programme requirements.
The cryptographic inventory question
One of the more useful aspects of the Handbook is its approach to cryptographic discovery.
It does not simply tell organisations to build an enormous inventory and attempt to discover everything simultaneously.
Instead, it recommends starting with the most critical systems and conducting cryptographic discovery on those systems first. It identifies existing sources of information such as HSM and key management logs, certificate systems, server configurations and network diagrams.
There is another important point.
CSA explicitly states that automated discovery tools are "still maturing" and will "not catch everything".
That is significant.
Because identifying an algorithm is not the same as understanding the cryptographic dependency.
A discovery process may tell an organisation that ECC exists.
It may not tell the organisation:
What business process depends on it.
What data it protects.
Who owns the dependency.
Which applications rely upon it.
Which suppliers are involved.
What downstream systems could be affected by changing it.
What operational consequences could arise from migration.
That distinction is central to effective cryptographic transformation.
The Handbook also moves beyond the idea of a static inventory.
It states that cryptographic policy should maintain a live cryptography inventory and says vendors should supply a Cryptographic Bill of Materials, or CBOM.
That is an important direction.
It also raises an obvious implementation question.
What exactly should that CBOM contain?
The documents do not define a CBOM format or minimum content standard.
Cryptographic agility is not optional thinking
The Handbook also places emphasis on crypto-agility.
That matters because post-quantum migration should not be treated as a single algorithm replacement exercise.
The organisation needs to be capable of changing cryptographic mechanisms as standards, algorithms and implementation requirements evolve.
The procurement discussion is particularly important here.
The Handbook says procurement policies should explicitly require crypto-agility and vendor post-quantum roadmaps.
That pushes the issue beyond the security function.
If a critical application cannot be upgraded because a supplier has embedded a cryptographic dependency into its product, the problem is no longer simply a cryptography problem.
It becomes a supplier, architecture, procurement and operational resilience problem.
The Quantum Readiness Index is not proof of migration
The QRI deserves careful treatment.
It is a self-assessment.
An organisation completes the assessment, receives readiness levels for its objectives and receives a PDF report. The Index does not require external verification or submission to CSA. It also does not prescribe specific solutions or minimum levels of readiness.
That makes the Index accessible.
It also defines its boundaries.
The Index measures organisational process and expertise.
It does not independently establish the cryptography actually operating in production.
The distinction can be expressed simply:
Readiness is not migration.
A readiness score can tell an organisation something useful about its organisational preparation.
It cannot, by itself, demonstrate that vulnerable cryptography has been identified, remediated and retired.
That is why a readiness score should not become a substitute for evidence.
The CII distinction matters
The Handbook's dated milestones are specifically directed towards CII owners.
The documents do not assign those same dates to every organisation.
That is an important point because quantum-readiness discussions frequently flatten different regulatory populations into one generic "organisational deadline".
Singapore's documents do not support that interpretation.
For non-CII organisations, the documents provide strategic direction and practical guidance, but they do not assign them the CII migration dates.
SITG-Consulting's interpretation is that procurement and supplier requirements are likely to become an important transmission mechanism for non-CII organisations.
That interpretation is supported by the Handbook's emphasis on supplier roadmaps and crypto-agility, but it should remain clearly identified as interpretation rather than presented as a CSA requirement.
What makes the Singapore material different?
The Handbook goes beyond basic quantum awareness in several ways.
It provides dated CII milestones.
It provides an algorithm table identifying RSA, DH and ECC as deprecated.
It includes a four-stage RACI involving the steering committee, CISO, CIO and business owner.
It provides worked threat examples involving a hospital VPN and family office, using STRIDE-LM and MITRE ATT&CK.
It also records CSA's own discussion of uncertainty around the scale of Harvest-Now-Decrypt-Later and the maturity of QKD testing standards.
That makes the Handbook substantially more useful than a generic awareness paper.
But useful does not mean complete.
What the Handbook and QRI do not solve
This is where organisations need to avoid over-reading the documents.
The Handbook and QRI provide direction.
They do not provide a complete enterprise migration execution framework.
The documents do not define:
A CBOM specification.
A CBOM format or minimum content requirement.
A definition of "quantum-safe ready".
A funding model.
A quantitative risk methodology.
A reference migration architecture.
A comprehensive assurance model.
A defined evidence standard.
A specific audit expectation.
An enforcement mechanism.
The QRI also prescribes no minimum readiness level, requires no external verification and does not require submission of the result to CSA.
There is also no stated linkage between a QRI result and the CII migration plan due on 31 March 2027.
None of this makes the documents worthless.
Quite the opposite.
It tells organisations where the documents stop.
And that boundary matters.
Guidance is not execution machinery.
What should organisations do now?
For CII owners, the dates provide a clear planning constraint.
The appropriate response is to work backwards from those dates rather than waiting for every implementation question to be resolved.
For other organisations, the absence of those CII dates should not be interpreted as a reason to do nothing.
The practical starting point is the same.
Establish accountability
Someone needs to own the migration problem.
Not simply cybersecurity.
Not simply architecture.
The issue crosses business, technology, risk, procurement and supplier management.
Identify the crown jewels
Do not begin by pretending that every cryptographic dependency can be discovered simultaneously.
Start with the systems and information where confidentiality, authenticity or integrity have long-term consequences.
Discover the cryptography
Use the evidence already available.
Certificate systems.
HSM and key management information.
Server configurations.
Network information.
Automated discovery tools where appropriate.
But recognise the limitations of automated discovery.
Understand the dependencies
Knowing that RSA, ECC or another vulnerable mechanism exists is not enough.
The important question is what depends upon it.
That is the difference between an inventory and an understanding of the cryptographic estate.
Engage suppliers
Ask suppliers for:
Their post-quantum roadmap.
The cryptographic mechanisms embedded in their products.
Their crypto-agility capability.
Their approach to algorithm transition.
Their CBOM capability.
And, importantly, what they actually mean when they claim that a product is "quantum-safe ready".
Design for algorithm change
Do not build a migration programme around the assumption that today's acceptable algorithms will remain the answer forever.
Standards evolve.
Algorithms evolve.
Implementation guidance evolves.
The architecture therefore needs to support cryptographic change.
That is the practical significance of crypto-agility.
The SITG-Consulting view
The team at SITG-Consulting considers the Singapore publications useful and significant.
They provide practical guidance.
They establish dated CII milestones.
They introduce a readiness assessment.
They recognise the importance of cryptographic discovery.
They acknowledge limitations in automated discovery.
They address live cryptographic inventories, CBOMs, supplier engagement and crypto-agility.
They also make an important distinction between organisational readiness and actual migration.
But organisations should not confuse the publication of guidance with the completion of a migration framework.
Singapore has set the clock.
It has not set the method.
For CII owners, the dates should be treated as fixed planning constraints.
For other organisations, these documents provide direction rather than the same dated obligations.
And for everyone involved in PQC migration, the harder question remains:
What evidence can you produce to demonstrate where your cryptographic estate is, what depends upon it, who owns the risk, what needs to change and whether you can actually execute that change?
That is the question that ultimately matters.
Download the forensic analysis
The full 12-page SITG-Consulting forensic analysis, "Singapore Published Two Quantum Documents on the Same Day", is attached to this article.
It sets out the evidence from the Quantum-Safe Migration Handbook v1 and Quantum Readiness Index v1.0, the CII milestones, the QRI limitations, the cryptographic discovery position, the implementation gaps and the SITG-Consulting interpretation.
The document is deliberately evidence-led.
It separates what CSA says from what the team at SITG-Consulting concludes from that evidence.
Sources: CSA Quantum-Safe Migration Handbook v1 and Quantum Readiness Index v1.0, both published 16 July 2026.
Comments