The cloud connection for over-the-air updates and everything else is negotiated using public key crypto with keys that are placed into the device at the factory (or replaced later by you if you like). The result of the negotiation is a session key for AES that is used for all cloud communications, including code updates, for the current session. This has round-about the same security as a SSL/TLS connection widely used on the net today.
Every device has a copy of the cloud’s public key and every device has it’s own private key stored. One of the steps in the setup of a new device is essentially sending or identifying the public key of device to the cloud so the negotiation can happen correctly.
There are system events that your code on the device can listen for and one event is (or will be soon) the update event. You are (or will soon be) free to decline the update. I am not sure where development stands of that feature right now, but it is planned.
With physical access to the device, there is very little that cannot be done, so if your threat model includes that type of access, you will need to think about hardened packaging or detection methods, but these devices are not really designed against that type of threat.