The Global PQC Migration Clock: Where 24 Jurisdictions Stand and Where Their Requirements Conflict

A CISO at a European bank with US defense contracts, Australian operations and a Singapore subsidiary sits down in late 2026 to update her PQC migration plan. She opens four browser tabs.

• Tab one: CNSA 2.0 says new acquisitions for US National Security Systems must support CNSA 2.0 from 1 January 2027, less than three months away. EO 14412 adds 2030 for key establishment and 2031 for signatures on federal high-value systems, and her federal contracts may carry a FAR clause once that rule is final, depending on how it defines a covered contractor.
• Tab two: Germany’s BSI stops recommending classical key agreement on its own after 2031 (2030 for the most sensitive applications), recommends hybrid, and has just advised against Classic McEliece for new developments.
• Tab three: Australia’s ASD wants the transition complete and traditional asymmetric cryptography retired by the end of 2030, and does not recommend hybrid.
• Tab four: MAS has told Singapore’s financial institutions that supervisory expectations aimed at quantum resilience before the end of the decade will arrive before the end of 2026.

Four jurisdictions, four different answers to the same question. They differ on dates, on whether hybrid mode is recommended or merely tolerated, on algorithm portfolios, on scope and on enforcement. And she needs one migration plan that satisfies all of them at once. The plan has to finish by 2035, but its first deliverables fall due between 2026 and 2031, in whichever jurisdiction asks earliest.

This is the state of global PQC migration in late 2026. Twenty-four jurisdictions have weighed in, along with the G7, NATO and the main financial and industry bodies. They all agree quantum computers will eventually break current public-key cryptography. They all agree organizations should migrate to post-quantum algorithms. They disagree on almost every implementation detail.

I track these deadlines across jurisdictions in the Global PQC Migration Timeline, which now maps more than 150 milestones, and I write individual analyses of each country’s approach. This capstone pulls together what the individual pieces cannot: the patterns that emerge when you lay every jurisdiction’s timeline on the same axis, the conflicts that create real compliance problems for multinationals, and the strategic conclusions that should drive your planning. My September article One Quantum Threat, Many Migrations looks at why the national programs diverge; this one stays with the dates and the requirements.

The 2035 Mirage

Most major jurisdictions still converge on the same outer boundary. In the United States, 2035 is NSM-10’s goal year, the end of OMB M-26-15‘s fifth phase and the proposed disallowance date in the still-draft NIST IR 8547. The UK’s NCSC says 2035. The EU’s coordinated roadmap expects medium-risk use cases by 2035. Canada, Japan, South Korea, the Netherlands and Sweden all point to 2035, BSI plans to end classical-only signatures by then, and Brunei disallows classical algorithms that year.

The convergence has a simple cause. Most national cybersecurity agencies calibrate their outer timelines against the same inputs: the NIST standardization schedule, the estimated CRQC arrival window, and the time a large migration takes. Robert Campbell’s enterprise migration study, published in December 2025, puts that at 5 to 7 years for small organizations, 8 to 12 for medium ones and 12 to 15+ for large ones. If you start in 2025 and need ten years, 2035 is where you land.

The 2035 consensus creates a dangerous illusion of alignment. Board presentations cite “2035” as the deadline, and the comfortable distance makes it easy to defer action. I’ve sat through executive briefings where “aligned with global timelines” meant “we have nine years, so this can wait.”

2035 is the date by which you must be finished. The dates by which you must have started, and in many cases finished your critical systems, fall between 2026 and 2031, and 2026 is when they hardened. The US now has binding 2030 and 2031 dates for its most important federal systems. Singapore wants its critical infrastructure migrated by the end of 2031, India by the end of 2029, Australia everything by the end of 2030, and the HKMA aims for full readiness across Hong Kong’s banking sector, measured by its Quantum Preparedness Index, by 2030. Those intermediate milestones are where the jurisdictions diverge, where the compliance pressure arrives first, and where most organizations are already behind.

The 2026–2030 Squeeze

Between October 2026 and the end of 2030, I count 54 dated PQC milestones across 22 jurisdictions and bodies. In May the count for the whole 2026–2030 window was 14. A partial list of the ones that will shape most programs:

• Already passed in 2026: the Bank of Israel’s preparedness plans (January), the plans and procurement clauses required by Canada’s Treasury Board SPIN (April), and the FIPS 140-2 sunset (21 September), which turned out to be a CMVP recommendation rather than a ban.
• The rest of 2026: US agency migration plans under M-26-15 (about 22 October), the EO 14412 FAR proposed rule and CMVP revision (19 December), SAMA‘s deadline for cryptographic asset procedures (31 December), and the end-2026 planning milestones in the EU, Australia and the Netherlands.
• 2027: the CNSA 2.0 acquisition gate (1 January), ANSSI’s PQC requirement for qualification, CISA’s cryptographic bill of materials guidance (19 March), SAMA’s risk assessments and Singapore’s CII migration plans (31 March), FINMA’s roadmaps (mid-2027) and the Cyber Resilience Act‘s main obligations (11 December).
• 2028–2029: Singapore’s quantum-safe procurement rule for CII (1 January 2028), Australia’s start of critical-system migration and the NCSC’s discovery phase (both 2028), and full PQC adoption across India’s critical infrastructure (December 2029).
• 2030: 20 milestones, including TLS 1.3 across US federal systems (2 January), CNSA 2.0 exclusive use for signing and networking, EO 14412 key establishment, DoW support and federal contractor compliance (all 31 December), the EU’s high-risk use cases, BSI’s end date for classical-only key agreement in the most sensitive applications, ASD’s full transition and the HKMA’s readiness target.

That is a lot of pressure in 51 months, and several of these dates carry real consequences, a topic I examine in Who Actually Enforces PQC Deadlines?

Three Axes of Divergence

The 2035 convergence hides three axes along which national approaches conflict.

Axis 1: Hybrid vs. Pure PQC

The most consequential divergence for implementation architects is whether to deploy PQC algorithms alongside classical ones (hybrid mode) or replace classical algorithms entirely (pure PQC). I cover this in depth in The Hybrid Question. The summary positions:

Hybrid recommended, and strongly favored in EUCC evaluations: Germany’s BSI recommends hybrid and, from the end of 2031, no longer recommends classical key agreement on its own; its TR-02102-1 is formally a recommendation, though it binds products that handle classified information. France’s ANSSI “strongly recommends” hybrid for both key establishment and signatures. The ECCG’s Agreed Cryptographic Mechanisms v2, the cryptographic reference for EUCC evaluations, say lattice-based schemes should not be used in a standalone way. The November 2024 joint statement of 18 EU Member States endorsed hybrid, and the Czech NÚKIB and Europol recommend it. FINMA refers Swiss institutions to the joint statement’s recommendation. In my May version I wrote that BSI and ANSSI mandate hybrid; both recommend it. The EUCC guidance comes closest to a requirement, and the applicable protection profile decides what a given product must implement.

Hybrid tolerated as an interim step, pure PQC as the end state: The NSA will not require hybrid for National Security Systems, accepts it where interoperability forces it, and says hybrid solutions will not be part of the eventual deployable solutions. OMB M-26-15 calls hybrid “an intricate and resource-intensive stopgap” and leaves the choice to agency risk assessments. The NCSC says hybrid, if chosen, should be an interim measure on the way to PQC-only. ASD does not recommend hybrid, does not prohibit it, and expects organizations to move to purely post-quantum algorithms.

Hybrid as a transitional option: Japan’s National Cyber Command Office recommends hybrid PQ/T schemes as a transitional strategy, Malaysia and Brunei encourage hybrid where appropriate, Singapore’s CSA treats it as a useful interim strategy, and India’s roadmap includes hybrid pilots.

No stated position: Canada, South Korea, the UAE, SAMA, the HKMA, the Bank of Israel and the Dutch national quantum strategy. NATO’s public roadmap states no hybrid policy.

For a company operating VPN infrastructure across Germany, Australia and the US, these positions point in different directions. Germany recommends hybrid. Australia does not recommend it and wants traditional asymmetric cryptography gone after 2030. The US tolerates it for now and plans it out of NSS. Until the end of 2030, a hybrid built on ML-KEM-1024 and P-384 fits the German, Australian and US civilian positions at once; NSS is the exception. From 2030, CNSA 2.0’s exclusive-use dates take effect for NSS, and ASD wants the classical half gone once that year ends. The European guidance still says lattice-based schemes should not stand alone. You need crypto-agility, the architectural capability to run different algorithm configurations per deployment, or you pick hybrid and accept that Australian and NSS deployments will need reconfiguration to pure PQC.

My recommendation: deploy hybrid key exchange now for commercial and European-facing environments. X25519MLKEM768 is enabled by default in Chrome and Firefox, is the default in OpenSSL 3.5 and is now standardized in RFC 10024. For compatible general-purpose TLS it fits the European recommendations, the NCSC’s interim allowance and M-26-15’s agency discretion, and it reduces risk from PQC implementation bugs, of which 2026 produced several. Regulated deployments still need their own check of the required assurance level and algorithm profile. For NSS, build to CNSA 2.0: ML-KEM-1024 for key establishment, ML-DSA-87 for general signatures, and LMS or XMSS for software and firmware signing. Plan to remove the classical component by 2030 for networking and firmware signing and by 2033 for the rest. Architect everything else so that you can drop the classical component when Australia, CNSA 2.0 or your own risk assessment requires it.

Axis 2: Algorithm Portfolios

NIST’s standards are the dominant international baseline: ML-KEM, ML-DSA and SLH-DSA, with HQC selected as a backup KEM and FN-DSA’s draft FIPS 206 reported in April 2026 to be in NIST’s approval chain. Neither the FN-DSA nor the HQC draft had been published by October 2026. Every jurisdiction in my dataset outside China accepts the NIST algorithms as a standard or a baseline, although approved algorithms, parameter sets and uses vary by security regime; ASD’s parameter restrictions are one example. The divergence is mostly about what else goes on the approved list.

Germany’s BSI lists FrodoKEM, which is based on unstructured LWE and avoids the additional algebraic structure ML-KEM uses, as an acceptable alternative and has listed Classic McEliece for years. On 1 October 2026, BSI advised against using Classic McEliece in new developments after researchers estimated key recovery below the scheme’s claimed security levels, and it plans to revise the guideline in early 2027. BSI notes that no practical attack on the recommended parameter sets has been shown. ANSSI has signaled it may not guarantee its accepted algorithms exactly match NIST’s. Both agencies favor a conservative cryptographic philosophy, and the McEliece advisory shows that conservative choices also need revisiting when the evidence changes.

South Korea has gone further. The KpqC competition selected four algorithms in January 2025: HAETAE, AIMer, SMAUG-T and NTRU+. In my May version I wrote that none of them appeared in the NIST pipeline; HAETAE and AIMer were in fact submitted to NIST’s additional signature process, and neither advanced to the second round. Korea will adopt NIST’s algorithms as well, but the KpqC selections hold official national positions. If Korean procurement requires KpqC algorithms for domestic government use, international vendors face an implementation burden that no other market creates.

China is on a separate track entirely. The Institute of Commercial Cryptography Standards launched its Next-generation Commercial Cryptographic Algorithms Program in February 2025 and published 119 first-round candidates on 20 September 2026. The program excludes algorithms already standardized by international bodies or other countries, so ML-KEM and ML-DSA cannot enter it. Within three days, reviewers had logged 104 findings against 65 candidates and broken five designs outright. I would treat 2029 as the earliest plausible date for national standards. For organizations operating in China, the PQC migration is a parallel project with its own algorithm set, standards body and timeline.

The practical impact is predictable: the more algorithms you need to support, the more complex your cryptographic infrastructure becomes. That is why I keep returning to crypto-agility as the foundational architectural requirement. An organization that hardcodes ML-KEM-768 into its stack satisfies most jurisdictions today, but has no flexibility when a German government contract asks for FrodoKEM, a Korean partner requires SMAUG-T, or an algorithm on today’s list is withdrawn.

Axis 3: Scope and Enforcement

The third divergence is about who these deadlines apply to and what happens if you miss them. I examine this in Who Actually Enforces PQC Deadlines?, but the spectrum runs from binding rules with market-access consequences to guidance that nobody audits.

At the binding end: CNSA 2.0’s 2027 acquisition gate is a procurement requirement, and ANSSI’s 2027 PQC requirement for qualification works the same way for buyers of qualified products in France. The EU Cyber Resilience Act is market-access law for in-scope products with digital elements. EO 14412, the DoW strategy and M-26-15 bind US federal systems, and the FAR rule will extend EO 14412 to contractors. The Bank of Israel’s Directive 202501 and SAMA’s circular are supervisory requirements with named deliverables. The UAE’s National Encryption Policy binds government entities, and Canada’s Treasury Board SPIN binds the federal organizations covered by the Policy on Government Security and their new contracts.

In the middle: Singapore’s CSA calls its CII dates requirements, but the handbook that carries them says it is not mandatory. FINMA’s guidance is formally non-binding but comes from the institutions’ supervisor. BSI’s TR-02102-1 is a recommendation with fixed end dates that German auditors read as binding. The EU’s coordinated roadmap has strong political backing, and the Commission’s proposal to amend NIS2 would write the PQC transition into every national cybersecurity strategy.

At the softer end: the UK NCSC’s three-phase timeline is guidance without statutory force. Japan’s target has no intermediate checkpoints. Malaysia’s roadmap is a framework, and the G7 Cyber Expert Group roadmap says it sets no regulatory expectations. The HKMA’s 2030 readiness aim, set out in its July 2026 whitepaper, and MAS’s end-of-decade aim are supervisory goals, and MAS’s expectations are still to come.

As of 10 October 2026, I have found no publicly reported fine, examination finding, procurement rejection or public censure tied to a PQC requirement, although supervisory reviews and procurement files are not public. The one audit on record shows the mechanism producing findings: GAO’s October 2026 public report, based on an audit completed in September 2025, found that one of 24 US agencies had completed the cryptographic inventory M-23-02 asked for by May 2023.

The mistake organizations make is treating “non-binding” as “non-urgent.” The UK NCSC has no statutory power to enforce its 2028 discovery deadline, but UK regulators (FCA, PRA, Ofcom, ICO) use NCSC guidance as the benchmark for reasonable cybersecurity practice. An organization that ignores it and later suffers a quantum-related breach can expect hard questions about why it deviated from the national authority’s published timeline. Guidance can become quasi-binding through the liability chain even when it is not statutory.

The Earliest Deadline Wins

I’ve been making this argument for over a year, and the global timeline picture makes it concrete: the earliest deadline in any jurisdiction you operate in is your effective deadline.

A European bank with US defense exposure does not get to plan against the UK’s 2028 discovery phase. It has to meet CNSA 2.0’s January 2027 acquisition gate for any products it supplies to NSS. A German manufacturer selling security products into France does not plan against BSI’s 2031 date; if it wants ANSSI qualification, it plans against ANSSI’s 2027 PQC requirement for qualification and the CRA’s December 2027 obligations. An Australian subsidiary of a Japanese conglomerate does not get Japan’s 2035 endpoint; it gets ASD’s 2030.

The principle sounds obvious, but I see it violated constantly. Organizations build migration plans against their home jurisdiction’s timeline and then discover, mid-program, that a client contract, a market-access requirement or a procurement gate in another jurisdiction pulls the deadline forward by three to five years.

The planning principle should be: identify every jurisdiction where you operate, sell or are contractually bound. Map the earliest applicable deadline for each legal entity, system and deliverable, because a plan submission, a procurement gate and a migration-completion date ask for different things. The earliest of them is your program’s first milestone; work backward from there.

For most multinationals in late 2026, the milestones that should be driving immediate action are:

If you sell into US government or defense markets: the CNSA 2.0 acquisition gate on 1 January 2027, less than three months away. If you are a federal contractor, read the FAR proposed rule when it appears around 19 December 2026; the compliance date it implements is 31 December 2030.

If you sell security products that need ANSSI qualification: ANSSI’s PQC requirement for qualification from 2027.

If you hold a Saudi banking or payments licence: SAMA’s cryptographic asset procedures by 31 December 2026 and your enterprise quantum risk assessment by 31 March 2027.

If you own or operate Critical Information Infrastructure in Singapore: a migration plan to CSA by 31 March 2027 and quantum-safe procurement from 1 January 2028.

If you are supervised by FINMA: a PQC migration roadmap by mid-2027, based on a quantum strategy approved by the board.

If you sell products with digital elements in the EU: the Cyber Resilience Act’s main obligations from 11 December 2027. Your in-scope products must be securely designed and receive security updates across their support period. The CRA sets no PQC deadline, but for cryptography crypto-agility is the practical way to meet the update obligation.

If you operate in Germany or Australia: BSI’s end-2030 and end-2031 dates for classical-only key agreement, and ASD’s end-2030 completion date, the most aggressive full-stop date among Five Eyes governments.

If you serve financial clients in the EU, Hong Kong or Singapore: the EU roadmap’s end-2030 date for high-risk use cases, which supervisors will read alongside DORA; the HKMA’s 2030 readiness target; and MAS’s end-of-decade aim. The enterprise migration study says a large organization needs 12 to 15+ years. Do the arithmetic.

If you serve no government, defense or regulated-sector clients and operate in a single jurisdiction with soft guidance: you have more time, but not as much as you think, because client expectations flow upstream. When a bank starts requiring PQC attestations from its vendors under SAMA, FINMA, DORA or G7 pressure, the vendor’s deadline becomes the bank’s deadline. The G7’s September 2026 call to action warned that organizations that delay “may be excluded from contracting opportunities, including public procurement.”

What Convergence Tells Us

Despite the divergences, the global picture contains a strong consensus signal.

Every major jurisdiction treats Harvest Now, Decrypt Later as a present-tense threat. The UAE policy cites it explicitly, the Bank of Israel frames its directive around it, and the Dutch strategy asks every central-government organization to assess it. The US put the consequence into its dates: EO 14412 and M-26-15 require key establishment by the end of 2030 and signatures a year later. Data confidentiality is the highest-priority migration target everywhere. Migrate key exchange for long-lived confidential data first, and start in parallel on the signing roots and update infrastructure that are hardest to replace, such as firmware roots of trust.

Crypto-agility appears in nearly every framework on this list, as a requirement or a design expectation. M-26-15 requires every federal civilian system to be cryptographically agile by 2030, and the UAE requires it for government systems. The CRA does not name it, but its update obligations are hard to meet for cryptography without it. ANSSI treats it as a design prerequisite, and NIST’s CSWP 39 sets out how to build it. In my judgment, an architecture that cannot swap algorithms will struggle under every framework on this list.

The newest convergence is on inventories. SAMA wants procedures for identifying and classifying every cryptographic asset by the end of 2026. EO 14412 orders CISA to publish the minimum elements of a cryptographic bill of materials by March 2027. India’s roadmap makes vendor CBOMs mandatory from fiscal year 2027–28, Singapore’s CII owners need inventories to write their March 2027 plans, and the GAO audit shows how long inventories take even under a mandate. If there is one deliverable every regulator will ask for first, it is a credible cryptographic inventory, and it is the deliverable most organizations underestimate.

Every jurisdiction in my dataset outside China accepts the NIST algorithm suite as either the standard or the baseline, with its own choices of parameters and uses. None has rejected ML-KEM, ML-DSA or SLH-DSA; the divergences are about parameters and about what to add to the list. China’s NGCC program excludes internationally standardized algorithms from its competition by design, which is not the same as a general ban on using them in China. For an organization starting its migration, the NIST suite is the safe starting point, with crypto-agility providing the flexibility to add the algorithms specific jurisdictions require.

What Divergence Tells Us

I do not expect international coordination to iron out the divergences in hybrid requirements, algorithm portfolios and enforcement mechanisms. They reflect real differences in national security philosophy, cryptographic culture and risk appetite. I’ve written about this in the context of PQC standards fragmentation and sovereignty in the PQC era.

The European preference for hybrid reflects a legitimate concern that PQC algorithms and their implementations are younger and less tested than their classical predecessors, and the 2026 implementation bugs in ML-DSA and ML-KEM libraries gave that concern evidence. The US, UK and Australian preference for a single move to pure PQC reflects a different calculation: that the operational complexity of running two algorithm stacks outweighs the marginal security benefit, and that a clean break is simpler to implement and audit.

Both positions are defensible. Their end states are incompatible, and since May they have hardened: OMB wrote its “stopgap” language into a memo that binds every civilian agency, while BSI wrote its preference into dated end points and the EUCC guidance says lattice-based schemes should not stand alone. My planning assumption is that the divergence on the hybrid question will last.

South Korea’s parallel algorithm standardization reflects an industrial policy calculation: domestic PQC development builds cryptographic capability, creates export products and reduces dependence on NIST. China’s NGCC program is the same move at larger scale, and Russia’s GOST work follows the same logic. The long-term trajectory is toward a world with several PQC algorithm standards rather than a single global baseline.

Where This Is Heading

In May I expected three developments over the following 12 to 18 months: sharper enforcement, a tighter EU regulatory chain, and financial-sector deadlines. Four months later, the third has arrived, the second has started, and the first is still waiting for 1 January 2027.

The financial sector set its own deadlines. SAMA’s circular, the HKMA’s 2030 target, MAS’s end-of-decade aim and FINMA’s mid-2027 roadmaps all appeared between July and September 2026, and the ECB has promised a quantum letter to the banks it supervises. Taiwan’s Financial Supervisory Commission issued reference guidelines with a 2035 completion date, and India’s central bank formed an expert committee to recommend a roadmap. The G7’s call to action added the procurement warning. Banks will pass these requirements to their suppliers through contract clauses and vendor questionnaires, which is how guidance becomes mandatory without legislation.

The EU regulatory chain started to tighten. The Commission’s January 2026 proposal to amend NIS2 would put the PQC transition into every national cybersecurity strategy; it was still at first reading in October. The CRA’s main obligations apply from December 2027, the EUCC guidance already favors hybrid for lattice-based schemes, and ANSSI’s qualification requirement makes PQC a condition for products entering qualification in France from 2027. If the NIS2 amendment is adopted and national strategies take up the roadmap’s 2030 date, the EU framework will bind more tightly, but the enforceable duties will depend on the final text and on national implementation.

Enforcement is still untested. The US June package put hard dates on federal systems: EO 14412, EO 14413 on the quantum industrial side, the DoW strategy and M-26-15, which I mapped in US Federal PQC Mandate After June 2026. I have found no public record of anyone being penalized under a PQC requirement. The CNSA 2.0 gate in January 2027 will be the most visible test in the West so far. How many exceptions the US government grants will set the tone for other jurisdictions.

The timelines compressed, as I expected in May. Microsoft moved its date from 2033 to 2029. The US set 2030 and 2031 for its most important systems, Singapore 2031 for CII, India 2029 for CII and the HKMA 2030 for banks’ readiness. Korean trade press reported in September 2026 that South Korea’s National Intelligence Service is considering bringing forward its 2035 date for core national systems.

What I am watching over the next twelve months: the M-26-15 agency plans (October 2026), the FAR proposed rule (December 2026), SAMA’s first deadline and the EU’s national strategies (end of 2026), the CNSA 2.0 gate (January 2027), CISA’s CBOM guidance and Singapore’s CII plans (March 2027), Japan’s government roadmap (by the end of fiscal 2026), BSI’s revised guideline (early 2027), MAS’s supervisory expectations, and the FIPS 206 and HQC drafts.

What to Do With This

This analysis is the strategic layer. The practical question, what to do first, in what order and with what resources, is addressed by the PQC Migration Framework and the practical steps guide. The global timeline picture drives three strategic conclusions for how you scope and sequence your program:

Scope your program to your most demanding jurisdiction, not your home jurisdiction. Identify every market, contract and regulatory relationship that creates a PQC obligation. Map the corresponding deadlines. Your program’s first milestone is set by the earliest one. The Global PQC Migration Timeline is designed to make this mapping visible.

Architect on the assumption that divergence lasts. Do not assume that the hybrid question will resolve, that algorithm portfolios will converge or that enforcement will harmonize. Build your cryptographic infrastructure to support algorithm substitution, switching between hybrid and pure modes, and jurisdiction-specific configurations. That costs more than a single global rollout, but the alternative is re-architecture every time a jurisdiction changes its requirements, and in 2026 several did.

Start with the inventory and key exchange, prioritize HNDL-exposed data, and treat the first half of 2027 as your planning anchor. The CNSA 2.0 gate, ANSSI’s qualification requirement, SAMA’s and Singapore’s March deadlines and CISA’s CBOM guidance all arrive in that window. Production-ready hybrid key exchange exists today in OpenSSL 3.5 and RFC 10024, so key exchange migration can start now for most organizations. Signature work runs in parallel where it protects long-lived roots of trust, such as firmware signing and PKI roots, and follows elsewhere. The tooling is less mature, but EO 14412 already puts US federal signatures at the end of 2031.

The global PQC migration clock is not one clock. It is two dozen of them, ticking at different speeds, set to different alarms, and occasionally running backward when administrations change or standards get revised. The organizations that handle this well will be the ones that see the full board, plan for the most demanding case, and start moving while their competitors are still debating which deadline to believe.

From the author