ECDSA と RSA は常にハッシュ値に署名するため、データをストリームで、あるいは別のマシンでハッシュでき、HSM が受け取るのは常に 32〜64 バイトだけです。一方、PureEdDSA と ML-DSA は、メッセージ全体を鍵に依存する値と一緒に処理します（EdDSA の nonce とチャレンジはどちらもメッセージをハッシュし、ML-DSA は公開鍵のハッシュ値をメッセージ代表値 μ に組み込みます）。そのため、メッセージ全体が署名者に届かなければなりません。
このような場合のために、事前ハッシュのバリアントがあります。Ed25519ph と Ed448ph（RFC 8032。FIPS 186-5 §7.8 では HashEdDSA）、HashML-DSA（FIPS 204 §5.4）、HashSLH-DSA（FIPS 205 §10.2.2）で、後の 2 つはハッシュ関数の OID を署名対象に組み込みます。これらは署名も異なる別個のアルゴリズムなので、純粋な（pure）バリアント用の検証者はこれらを拒否します。また FIPS 204 では、署名用の乱数の生成を除く ML-DSA のすべてのステップを署名モジュールの外で実行することが認められており、HSM のインターフェースはこれを利用して、事前に計算された μ を受け付けます。
事前ハッシュを行うと、安全性がハッシュ関数の衝突耐性に依存するようになりますが、純粋な EdDSA はハッシュの衝突があっても安全性を保ちます。ストリーミングやリモートの署名者のためにやむを得ない場合を除き、純粋なバリアントを使ってください。また、ドメイン分離なしに 1 つの鍵で両方のバリアントを混在させてはいけません（RFC 8032 §8.6。FIPS 204 は鍵ごとに 1 つのバリアントを推奨しています）。