I've been trying to come up with scenarios where someone relying on that security would suffer worse from this revelation than merely enabling hardware clone ma

I've been trying to come up with scenarios where someone relying on that security would suffer worse from this revelation than merely enabling hardware clone manufacturing. (Note that most of those cases are very far from where you would typically find an NRF52) Decryption keys for "broadcast" style DRM schemes? Kind of bad, but usually those also have implementations on far more open hardware, it wouldn't be the weakest link. A Yubikey-like second factor configured only for presence? When you can take a soldering iron to the device you might just as well keep the one you already have. It would only make a difference for elaborate attacks involving more than one copy of the destroyed original (e.g. sneaking a clone back to the original owner). I'd argue that it retains 98% of the security upside compared to not using a second factor and would still come ahead of many weaker second factors. A Yubikey-like second factor configured to require on-device decryption of its keys? (e.g. built in PIN pad) Bad because the readout would enable unthrottled attemps, but still only terrible if the resulting key isn't throttled otherwise (e.g. bad for decrypting some offline storage). An anti-tampering signature for content production, e.g. camera hardware confirming that a pictue is based on actual photons hitting a CCD? Bad, definitely. An encapsulated root CA in its CEO's pocket? Someone will get fired, but it won't be the right person. I'm sure that this list could be longer, but so far I don't see any overlap with the usual application domain of NRF52.