Why would a vendor use Legacy DFU instead of Secure DFU?

[tjhasan]

I've been analyzing various nRF52 devices and noticed that there is an inconsistency with vendors using Legacy DFU and Secure DFU. Or in other words, there doesn't seem to be any rhyme or reason as to why a specific vendor uses Legacy as opposed to Secure DFU.

Given that Secure DFU uses various methods of image checking to prevent malicious updates, why wouldn't all vendors simply use Secure DFU instead of Legacy?

My only guess would be computational limitations on the device, but I was curious if anyone on the Nordic Team might know why.

Any insight would be appreciated!

[Vidar Berg]

Hello,

My guess would be that the devices that had the legacy bootloader were developed before the secure bootloader became available (DFU with signing was introduced in SDK 12.0.0 - year 2016). Subsequent SDK releases did not include the legacy bootloader.

My only guess would be computational limitations on the device, but I was curious if anyone on the Nordic Team might know why.

 I think the biggest drawback is typically that you need more flash to fit the crypto algohritms (the secure bootloader is approx. 2x larger than the legacy bootloader).