I can explain how these systems are normally built, which should help you judge the claim — but I want to be straight that I have not read the firmware diff or the advisory, so I am not confirming the specific accusation about what was switched off and when. Take the architecture, not my word on the history.
How it is supposed to work
A hardware RNG produces raw physical entropy. A software CSPRNG stretches a seed into a long stream. Sane designs use both, and — this is the part that matters — they COMBINE them so the output is as strong as the STRONGEST input, not the weakest. Hash them together, or XOR them:
seed = SHA256( hardware_entropy || software_entropy )
Under that construction, if either source is solid the result is solid. The hardware RNG can be biased garbage and you are still fine, provided the software side is properly seeded, and vice versa. That is the whole reason to mix rather than pick.
Where it goes wrong
The failure mode is not "used a software RNG" — every system does, and that is fine. The failure is when the strong source stops actually reaching the mix, so the output ends up depending on the weak one alone. Removing or ignoring the hardware contribution turns a belt-and-braces design into a single point of failure, and nothing about the device's behaviour looks different afterwards. It still produces 24 words. They still look random. That is exactly why this class of bug survives for years.
For scale: a 32-bit seed is about 4 billion possibilities, which is a few hours of laptop time. A correct 256-bit seed is not searchable by anyone, ever. The gap between "broken" and "fine" here is not a matter of degree.
How to settle it rather than argue about it
The firmware is open source. So this is a question with an actual answer sitting in a repository, not a matter of opinion. Read the seed-generation path and see for yourself where the hardware entropy enters and whether it reaches the final mix. If the claim is right, a diff shows it. If it is wrong, that shows too.
I would rather point you at that than have you take my summary or anyone else's — including the people with a stake in the answer.
One thing worth separating
The blame question and the what-do-I-do question are independent. Whatever the root cause turns out to be, the user-side remedy does not change: supply your own dice entropy and verify the derivation externally with `printf '<rolls>' | sha256sum` against the device's entropy hex. That works whether the cause was a disabled TRNG, a truncated seed, or something nobody has named yet — because it removes the device's randomness from the equation entirely.
