Most security threats are discussed in the present tense: something is vulnerable now, and it gets exploited now. The quantum threat is unusual because it is a future capability that attacks the past.
The mechanism
An adversary captures encrypted traffic today - VPN sessions, TLS connections, encrypted email, backup archives in transit - and stores it. They cannot read any of it. They do not need to. They need to be confident that at some point a cryptographically relevant quantum computer will exist, at which point the public-key cryptography protecting that traffic can be broken.
The capture is cheap, the storage is cheap, and the decision to capture does not depend on when the decryption becomes possible.
Why this changes the planning question
The usual question - when will quantum computers be able to break RSA? - turns out to be the wrong one to plan against, because it is unanswerable and because it is not the binding constraint.
The question that decides your exposure is: how long does your data need to stay confidential?
If your data stops mattering within a few years, the timeline probably outruns the threat and this is not a current priority. If you hold data that must remain confidential into the 2030s and beyond - mortgage agreements, medical records, legal files, long-term contracts, trade secrets, anything with a statutory retention period measured in decades - then the exposure is live today, because the capture is happening today.
What is actually affected
Public-key cryptography is the concern. RSA, Diffie-Hellman and elliptic curve algorithms underpin TLS key exchange, digital signatures, VPN establishment and code signing. These are the ones a sufficiently capable quantum computer breaks.
Symmetric cryptography such as AES is affected far less severely and is generally addressed by increasing key length. Bulk encryption is not the problem; key exchange and signatures are.
That distinction matters practically, because it narrows the migration substantially. You are not re-encrypting everything. You are replacing key exchange and signature algorithms.
The first task is an inventory, not a migration
The instinct is to reach for the new algorithms. That is premature, and not because the standards are immature - it is because almost no organisation can currently answer where public-key cryptography is used across its estate, which algorithms and key lengths are in play, which are embedded in appliances and third-party products it cannot change, and which protect data with a long confidentiality requirement.
Without those answers, a migration plan is guesswork about systems you have not located.
A cryptographic inventory is also useful regardless of quantum. It answers certificate expiry, weak cipher usage, and compliance questions that come up several times a year. It is the rare piece of quantum preparation that pays for itself even if the timelines slip badly.
Crypto-agility matters more than the algorithm you pick
The durable investment is not choosing a post-quantum algorithm. It is being able to change algorithms without rebuilding the system - algorithms configured rather than hardcoded, key sizes parameterised, protocol negotiation supported, certificate lifecycles automated.
Organisations that build that capability will migrate on a schedule of their choosing. Organisations that do not will rebuild systems under time pressure, and will do it again for the transition after this one.
A proportionate position
Do not panic and do not defer indefinitely. Build the inventory, map data lifetimes, identify the intersection of long-lived data and vulnerable algorithms - which in most estates is a short list - and start crypto-agility work on the systems you are already rebuilding for other reasons.
That is a defensible position that costs comparatively little, and it is considerably better than either extreme.