Encrypted traffic is being collected today by people who cannot read it yet and expect to later. If your data still matters in ten years, that is a problem you already have rather than one you will get.
Most security risks are about what could happen to you. This one is about what may already have happened.
The premise is uncomfortable and simple. Encrypted traffic can be recorded now and stored indefinitely by somebody who cannot read it today. If a cryptographically relevant quantum computer arrives later, everything collected in the meantime becomes readable at that point, retroactively.
The industry calls this harvest now, decrypt later. It means the clock on a piece of data started when it crossed the wire, not when the decryption becomes possible.
Nobody knows when, or whether, such a machine arrives. Serious estimates vary by more than a decade and anyone giving you a confident date is selling something.
Fortunately you do not need the date. You need one number, which is how long your data stays sensitive.
If the answer is days, this is not your problem. Session tokens, market data, most operational traffic, none of it matters once it is stale.
If the answer is decades, it is already your problem and the uncertainty about timing works against you rather than for you. Patient health records. Financial identities. Legal privilege. Intellectual property in long development cycles. Government and diplomatic material. Anything covered by a retention obligation measured in years.
Take your longest retention requirement, add the years until a capable machine might plausibly exist, and if those two numbers overlap, data you are transmitting this week is inside the window.
You are not protecting this data from an attacker who exists today. You are protecting it from one who will exist while it still matters.
Not everything, and the distinction saves a lot of unnecessary work.
Public key cryptography is the exposed part. The algorithms that establish keys and carry digital signatures, which is RSA and the elliptic curve family, are the ones a sufficiently capable quantum computer undermines. That covers the key exchange protecting your traffic, your certificates, your code signing and much of your authentication.
Symmetric encryption is in better shape. Moving to longer keys is a reasonable and cheap hedge, and the well regarded modern ciphers do not need replacing.
So the migration is narrower than the headlines imply. It is a public key problem, which is still a very large problem, because public key cryptography is embedded in nearly everything and mostly in places no inventory records.
The replacements exist. The post quantum standards published by NIST are finalised, and the practical question has moved from which algorithm to how you find every place the old ones are used.
Ask an engineering team where RSA is used in their estate and watch what happens.
They will name the obvious things. The web certificates, the VPN. Then the conversation slows, because the honest answer includes a payment library chosen in 2016, an embedded certificate inside a device that has no update mechanism, a partner integration whose configuration nobody has opened in four years, and a signing key held by someone who left.
This is why every serious guide says the first step is a cryptographic inventory, and why every organisation underestimates it. You are not making a list of algorithms. You are finding every place a cryptographic decision was made, usually by somebody who is no longer there, frequently inside a dependency rather than your own code.
That inventory is worth building even if quantum computing never arrives. Organisations that have one can answer a question they currently cannot, which is what breaks if an algorithm is deprecated tomorrow. That has already happened twice in living memory with hash functions, and it will happen again.
The phrase gets used loosely. What it means practically is that changing an algorithm is a configuration change rather than a rebuild.
Very little software is built this way. Algorithms get hardcoded, key sizes get assumed, certificate handling gets written once and copied. The result is that a migration which should be a settings change becomes a development project across dozens of systems.
If you are specifying new systems now, this is the moment it is cheap. Ask suppliers how an algorithm gets replaced, and treat a vague answer as the answer. Ask about their own post quantum roadmap and their inventory. A supplier who has not thought about it is one you will be waiting on later.
Work out your data lifetimes first, because that tells you whether any of this is urgent for you specifically rather than in general.
Build the cryptographic inventory, starting with anything that carries long lived sensitive data across a network you do not control.
Fix the easy wins while you are there. Long lived data moving over weak or outdated transport security is a present tense problem, not a future one, and you will find some.
Put crypto agility into procurement, because everything you buy this year will still be running when this matters.
Then plan the migration for the systems where the exposure is real, hybrid key exchange first, since it costs little and hedges properly.
What you should not do is buy a post quantum product before you have the inventory. You would be purchasing a solution to an exposure you have not measured, and the vendors know it.
Our GRC practice treats cryptographic inventory as part of asset management rather than a separate exercise, because it is the same question asked about a different property, and the frameworks are converging on asking it. Our VAPT team finds the transport security and certificate handling problems that are already exploitable today, which is usually the more immediate finding.
Because this is a multi year programme, the record of it matters. CyberNexus holds that, so the decision that a given system was accepted as out of scope, and the person who accepted it, is still retrievable when somebody asks in three years. ControlGraph matters here for a different reason. When a cryptographic control is weak, the useful question is what else that reaches, and that is a question about structure rather than about cryptography.
Answer one question and write the number down. What is the longest period for which data you transmit today must remain confidential.
If that number plus your view of the timeline overlaps, you have a real exposure and the next step is an inventory. If it does not, you have a procurement requirement for new systems and no emergency, which is a perfectly respectable place to be and a much cheaper one.
Collecting encrypted data today with the intention of decrypting it later, once the capability exists. It matters because the risk attaches at the moment data is transmitted rather than at the moment decryption becomes possible.
Public key cryptography, specifically RSA and elliptic curve algorithms used for key exchange and digital signatures. Symmetric encryption is far less affected, and moving to longer keys is a reasonable hedge there.
There is no credible fixed date. The practical test is whether your data retention period overlaps with the period in which a capable machine might exist. Organisations holding data sensitive for decades should be planning now. Organisations whose data is stale in weeks should not be treating this as urgent.
A record of every place cryptography is used across your estate, covering algorithms, key sizes, certificates, where keys are held and who owns them. It is the prerequisite for any migration and it is usually the longest part of the work.
The ability to change cryptographic algorithms through configuration rather than redevelopment. Most existing software lacks it, which is why algorithm deprecation tends to become a multi system engineering project instead of a settings change.
PISF turns security in Pakistan from something organisations were encouraged to do into something they are expected to evidence. What the framework covers, who it applies to, and where to start if you are beginning from very little.
Read the article
Pakistani organisations have been told to stand up security operations centres on a short timeline. Most of what gets built under that pressure watches everything and catches nothing. What a working SOC needs first.
Read the article
Moving data inside the country satisfies the letter of a residency rule and often changes very little about who can actually reach it. What the harder questions are, and what to ask a cloud provider before signing.
Read the articleIf this raises a question about your own compliance position or your security operations, the quickest route is a direct conversation.
