The ML-KEM and ML-DSA standards both let you store the private key in two ways. There is a small seed, 64 bytes for ML-KEM and 32 bytes for ML-DSA, and there is a larger expanded form that gets derived from that seed through a hash function(s). The two are mathematically equivalent and you can go from the seed to the expanded form any time you want, but you cannot go back. If you are picking between what to store as the private key, store the seed. It is the actual secret that everything else gets derived from. You can expand it into the full key whenever you need to, and it takes about 40 microseconds, so there is no real reason to store the expanded version on disk. If you need it in memory for repeated operations, just expand once at load time. The seed is just random bytes so any value is a valid key. The expanded form has a structure to it; coefficients that need to be in range, an embedded public key, a hash that has to match, and the standard requires you to check all of that on import. That is much more surface for things to go wrong that you just do not have with a seed. There is also an ongoing serialization problem at IETF where the current compromise format allows both the seed and the expanded key to sit in the same data structure. That means two conforming implementations can read different fields from the same key and end up with different key material, which is not a thing you want from a key format. TL;DR: store the seed and expand it on use as needed. Full write up below.