Post-quantum migration checklist for SMBs: what the White House deadline means for you

The signal: why this deadline is different

Cryptographic migration deadlines have existed for years. The shift from SHA-1 to SHA-256 played out across a decade. The deprecation of TLS 1.0 and 1.1 was announced, ignored, and then forced by browsers. Each of those migrations was painful enough that organisations who waited until the last signal — a browser warning, a failed handshake, a compliance audit — paid a premium in emergency remediation.

The White House executive order compressing the quantum-crypto deadline is a different category of signal. It is not a browser vendor making a unilateral decision about a specific protocol version. It is a federal government accelerating the migration timeline for the entire public-key infrastructure that underpins secure communication across every US federal system — and, by extension, every vendor and contractor that interfaces with those systems.

A compressed federal deadline does not stay federal. It flows downstream to every contractor, vendor, and technology provider in the supply chain. Australian SMBs with US government exposure are inside that boundary today.

For Australian operators, the relevant secondary signal is the Australian Signals Directorate (ASD) and the Australian Cyber Security Centre (ACSC), which align their guidance closely with NIST standards. What the White House mandates for federal systems tends to set the benchmark that Australian government procurement follows within a planning cycle. An SMB that waits for the ACSC mandate before starting is likely to begin migration after their government clients have already started asking procurement questions about it.

The harvest-now-decrypt-later threat model

Understanding why the deadline matters now — before quantum computers are commercially available — requires understanding the attack pattern it is designed to close.

The harvest-now-decrypt-later (HNDL) threat works as follows: an adversary intercepts and stores encrypted traffic or data today, using existing network access or a prior compromise. The data is unreadable with current computing resources. The adversary archives it and waits. When a sufficiently powerful quantum computer becomes available — projections for cryptographically relevant quantum hardware vary, but serious state-level actors are treating it as a decade-scale problem, not a century-scale one — the archived data can be decrypted retroactively.

The HNDL threat model is the reason the migration is urgent now even though quantum computers capable of breaking RSA are not yet commercially available. The encrypted data being targeted is already in transit and in storage. The window for reducing that exposure is open today and closes incrementally as more sensitive data accumulates under quantum-vulnerable encryption.

The post-quantum migration checklist for SMBs

The checklist below is structured in three phases: audit work that should happen immediately, vendor-dependency assessment that follows, and migration sequencing for the medium term. Work through the phases in order — you cannot prioritise migration without first knowing what you are migrating.

The NIST PQC standards: what SMBs need to know

NIST finalised three post-quantum cryptographic standards in August 2024 after an eight-year selection process. These are the algorithms the federal migration targets, and the ones SMBs should be asking their vendors about.

For most SMBs, the relevant practical question is not which algorithm to implement directly — that will be handled by libraries and platform providers — but whether the vendors and libraries they depend on have updated to support these standards and on what timeline.

The key distinction for procurement conversations: asking a vendor “are you quantum-safe?” is not sufficient. The specific question is: “Do you support hybrid post-quantum TLS using ML-KEM (FIPS 203) for key exchange and ML-DSA (FIPS 204) for certificate signing, and what is your timeline for full PQC-native support without the classical hybrid?”

Priority matrix: how to triage your exposure

Not every cryptographic dependency carries equal risk. The migration priority framework below maps data sensitivity and confidentiality horizon against migration complexity to help SMBs sequence their effort.

The common failure mode is treating PQC migration as an all-or-nothing infrastructure project and therefore not starting it. The priority matrix exists to make the opposite case: starting with the highest-HNDL-exposure data and the easiest migration surfaces (TLS renewal) creates measurable risk reduction immediately, while the longer tail of the migration runs in parallel over a 12–24 month horizon.

The vendor conversation you need to have now

Most SMBs are not implementing post-quantum cryptography directly. They are inheriting it from their cloud providers, CDN, certificate authorities, IAM vendors, and software libraries. The migration readiness of those vendors is therefore the practical constraint on the SMB’s migration timeline.

The following questions, asked of each cryptographic dependency vendor, turn the abstract deadline into a concrete vendor-risk assessment:

A vendor who cannot answer items 1 and 2 without escalating to their engineering team is a vendor who has not started. That is a legitimate finding to include in your internal migration risk register and, where relevant, your government contract security documentation.

What the deadline compression means for procurement

The White House compressed deadline changes the procurement conversation in two directions: it creates a buying trigger for SMBs that need PQC-capable tools, and it creates a vendor-evaluation filter for any technology procurement made from this point forward.

Any technology purchase made today under a three-to-five year contract that does not include PQC readiness commitments is a procurement that will require renegotiation or replacement before the contract term ends. That includes cloud contracts, CDN agreements, IAM platforms, backup and encryption services, and security tooling with embedded cryptographic operations.

A technology contract signed today without a PQC migration clause is a contract that will expire before the migration is optional. Price the re-procurement cost into the evaluation now, or pay it as an emergency mid-contract upgrade later.

The practical procurement addition is a PQC readiness clause that mirrors what buyers now demand in AI vendor contracts for accuracy SLOs and model version change notifications: a stated timeline for PQC support, a notification obligation when the migration path is available, and an exit right if the vendor fails to deliver PQC-compatible service before the compliance window closes.