X25519 is elliptic-curve Diffie-Hellman over Curve25519. It is fast, has a clean implementation story, resists most side-channel mistakes by construction, and is the default key exchange for the large majority of TLS 1.3 connections today.
It is also quantum-vulnerable, and that is the entire problem.
Why an excellent algorithm is now a liability
Nothing is wrong with X25519 classically. There is no practical attack, and none is expected. Its security rests on the elliptic-curve discrete logarithm problem.
Shor's algorithm solves that problem efficiently on a sufficiently large quantum computer. The concern is not that X25519 is weak today; it is that a session protected by X25519 can be recorded today and opened later.
Present-tense exposure
This is the distinction that matters for planning. A quantum-vulnerable signature is a future problem: an attacker needs the quantum computer while the certificate is still valid, and certificates rotate every few months.
A quantum-vulnerable key exchange is a present problem, because the capture happens now and the decryption happens whenever the attacker likes. See harvest-now-decrypt-later.
For data with a long confidentiality lifetime — health records, legal files, financial positions, government material — traffic protected by X25519 today may still need to be secret when quantum hardware arrives.
What to do
Do not remove X25519. Pair it. The hybrid group X25519MLKEM768 keeps X25519 exactly as it is and adds ML-KEM-768 alongside, so the session is secure if either holds.
NIST's draft transition roadmap places quantum-vulnerable public-key algorithms, X25519 among them, as deprecated after 2030 and disallowed after 2035. Hybrid modes are explicitly not caught by that disallowance.