There is neat trick to make hardware wallets robust to random bit-flips in RAM.

By having the signer only return signatures, corrupt memory during transaction processing would at worst result in an invalid signature.

The host wallet has a redundant copy of he transaction and only incorporates the signatures from the hardware wallet.

A borked transaction would then be rejected by the host wallet or network, avoiding a catastrophe.

The BitBox02 does this to avoid catastrophic failure.

If a bit-flip were to happen in the generated output, the bitcoins would be sent to nowhere and lost forever*.

(*or at least until ECC-DLP is solved 🙃)

To make things worse, the host wallet cannot perform a sanity check, as it would need the private keys of the signer or the scan key of the recipient to verify the output.

A possible mitigation is to split output generation and signing into two separate steps, making UX a lot worse.

Another mitigation is to not only accumulate private keys in the inputs (as per BIP-352 sender side), but also the public keys (as per the BIP, receiver side), and perform a sign/verify sanity check. Some other computations could be computed twice & compared.