Short answer: It's possible.
Long answer: It's complicated. That's why so many many very bad implementations are out there.
At the very least you have two steps in any remote / over-the-air update process.
- Transmitting firmware
- Installing firmware.
Of course, this is the absolute bare minimum. If you're working in iterations it's also a very valid first step. If you have more than one device you'll have to be able to associate the correct firmware to the correct device. If you want to to reduce the chance of bricking your device you'll want a way to verify your device's state before and after the update, you'll also want to secure the transport and make the transport as reliable as possible and—naturally—have a fallback strategy in case of update error.
That's five more steps that bring you towards a reliable product. There are best practices out there for these things but they depend on your project surroundings. Maybe it's something cheap and 5% failure rate on updates is okay, maybe it's a pacemaker and even one error in total is unacceptable because it leads to a fatal scenario. You'll have to find solutions to those basics that fit your product.
Furthermore, there are dozens of different things to consider. Will you have customers? Do you have to inform them? Do they have a say in update timing/installation? Are your devices in different countries? Do legal restrictions apply? Do normative standards apply? How many devices are you updating? 1? A dozen? Hundreds? Millions?
If you update five devices the process can be very chatty. If you're updating millions that could turn very expensive. And yes, that impacts what I listed above as step one, transmitting the firmware. Maybe you do create a pacemaker and a process cost of hundreds of messages per update is okay considering the alternative.
Those are only the questions I wrote down in two minutes, so this list is certainly not exhaustive. My point is without information regarding the scenario we can't really help you properly.
