Article arguing banks should start PQC migration now, before Shor turns compliance into a horror show.
4 comments
the part people keep glossing over with pqc in banks is that it is not just a swap of algorithms, it's a migration of assumptions. a lot of the current mess is around long-lived certificates, hardware security modules, embedded appliances, and protocols that were designed when rsa and ec were the only real game in town, so even testing the new stack without breaking settlement systems is awkward.
a lot of shops have been treating this like tls-only work, but the real exposure is anywhere data needs to stay confidential for 10 or 20 years, which is a very normal horizon for financial records and identity docs. if you wait until the quantum threat is obvious, you also get hit with compliance deadlines, vendor lag, and the ugly question of which parts of the system can support hybrid modes versus a clean cutover. the crypto part is one piece, the operational cleanup around it is where most of the pain lives
> a lot of shops have been treating this like tls-only work
Isn't that a bit overstated, since for a bank the hard part is usually inventorying every place a public key shows up (cert chains, firmware, vendor boxes, archived docs, internal APIs) rather than TLS itself?
> a lot of shops have been treating this like tls-only work
Not really, TLS is just the easiest thing to point at, and plenty of bank teams stop there because it’s visible and testable. The ugly part is exactly the inventory you mention, but that doesn’t make the TLS-only framing wrong, it’s the common failure mode when the project gets handed to the network or web crypto people and nobody owns the rest.
TLS is the poster child because you can flip it in a lab and feel progress, which is catnip for committees (until the HSM firmware says no).
The thing that keeps biting is the long tail of cert lifetimes and vendor boxes, where the crypto choice is the easy bit and the procurement queue becomes the real attack surface...