As far as secure firmware updates are concerned, I'd like to refer to François Baldassari to get in-depth information - https://interrupt.memfault.com/blog/secure-firmware-updates-with-code-signing

Basically you have 2 options when deploying firmware updates:
You either use
a) symmetric crytpography alone or
b) also make use of asymmetric crytpography.

As for a)
You can use an AEAD cipher again for encrypting/signing your image. The problem is: If you use the same symmetric key for all devices, then once 1 device gets hacked and the internal key extracted, an attacker can sign firmware updates for ALL devices! That's the problem with symmetric encryption: The key that's used for verifying whether an image is authentic, is also used for signing the image.

So you'd need to install a unique key on every single device. That again would mean that when deploying a firmware update, your update server would need to know all the keys of all the devices where you want to send updates to.
This would probably mean that your update server needs to store all device keys, which is a security risk per se.

As for b)
In scenario b) symmetric encryption is used to keep the firmware secret, and asymmetric cryptography is used to verify the authenticity of the firmware.
Encryption could still be some symmetric AES or Chacha20 cipher with a key common to all devices. The worst thing that could happen is, that once an attacker gets hold of the device internal key, he can decrypt all future images. But if the attacker has managed to extract the key already, he'll probably also manage to read the rest of the firmware anyway.

When it comes to authentication you'd go with ECDSA - a digital signature algorithm based on elliptic curves which is computationally very intensive (unlike symmetric ciphers).
You create a key pair - a public and a private key. The private key is used to sign the firmware update and should not be on a machine that is online. The public key -on the other hand- is stored on every IOT device. It's public.
Even if it is extracted from the device, it cannot be used to sign an image as is the case with a). The public key can only be used to verify an image.

An ECDSA library can be found under https://github.com/ncme/c25519
Some are using a library called micro-ecc but it has many unresolved issues - I wouldn't recommend it therefore.
While writing this, I stumbled upon an ECDSA implementation for Cortex M4 written in assembler: https://github.com/Emill/P256-Cortex-M4