If the firmware of your device can be made less complex than the bootloader required for a secured remote update, then do not implement remote update.
I know the consensus is to have a secured and robust bootloader, with strong public crypto authentication, safe rollover mechanisms, maybe a basic network stack, and then put on top of that a RTOS, with a full IP+TLS network stack, then add on top of that your application. This is pure insanity for a low-cost low-power device. IMHO, this leads to products that are updated every week or so, which tend to bother users because sometimes updates start at the wrong moment, fail or break something. Updates drain a lot of power too, so user have to charge more often. And security is still far from guaranteed as the attack surface is large.
Your device is doing basic sensing/actuating, maybe some local triggering/displaying but not much? Skip all that.
Write bare metal code, use a very basic stack, audit it thoroughly, do some formal verification if possible. And then you can be relatively confident that your device will not have security issues for the next decade.
If all you have is a hammer, everything looks like a nail. And that's why most coder try to write code to secure their unsecured existing code. Writing less code doesn't always come naturally.