ECDSA history is repeating itself again when you consider how poorly the proposed MLKEM RFC deals with side channel resistance:
From draft-ietf-tls-mlkem-8:[1]
"Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers."
From NIST SP 800-227:[2]
"Cryptographic modules for KEMs should be designed with appropriate countermeasures against side-channel attacks. This includes protecting against timing attacks with constant-time implementations and protecting memory from leakage. Universal guidelines are unlikely to be helpful as exposure to side-channel attacks varies significantly with the desired application, and countermeasures are often costly."
MLKEM is more complex and has more chances of stuff-ups in implementation than ECDSA did. A single sentence of encouragement is all that is on offer from this MLKEM RFC. It doesn't even have the lightweight "Security Considerations" section which RFC8032 for EdDSA provided.[3]
As a point of reference for how hard it is to implement side channel resistant MLKEM see [4] (formal verification) and [5] (errors in formal verification). The MLKEM RFC doesn't offer a "Security Considerations" section to explain how difficult it is to implement side channel resistant MLKEM (perhaps it's easy :S), and if it were hard to implement, to recommend use of EdDSA+MLKEM for cryptography implemented on devices an attacker may be able to physically access, or when used on public networks as a workaround given that side channel resistant EdDSA would be easier to implement.
[1] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/
[2] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...
[3] https://www.rfc-editor.org/info/rfc8032/#section-8.1
[4] https://github.com/pq-code-package/mlkem-native/tree/main/pr...
[5] https://eprint.iacr.org/2026/192
edit: added reference 5