There is no safe way as long as you don't have your hands on the hardware before. Even if you add some sort of code encryption based on UUID, you will have to include an algo to decrypt this in your firmware and it can be reverse engineered. I.e. only you can do is to make it harder this way. But it still always leaves a possibility to reverse engineer it. It's so called "Security through obscurity".
At least as long as your end device doesn't have some sort of Internet functions, where you can rely some authentication/authorization things on your servers.
Anther real way is to implement and install a bootloader at the read protected area first. But this bootloader shouldn't be disclosed to make it safe. I.e. you have to program it on your own first and send MCU to your client. You just can't send HEX to end user.
Anyways, as long as you have MCU first - you can simply enable readout protection and that should be enough for most projects if you aren't planning in updating it. But that way you have to pre-program and sell it with hardware.
There is also some sort of security/authentication IC exists on the market (ATSHA204A for example) which sometimes have a properties of safe challenge-response identification. You can include this in your device design (i.e. add another security IC to the PCB). That way your customer can build complete hardware with that IC. Next either you derive encryption key based on some sort of it's identification or you provide a first stage firmware (HEX) to authenticate that device. It depends on how exact IC works and we aren't talking about exact part here, out of scope of this question. Next, once you've have the encryption key, you can assemble your actual end firmware encrypted with that key. Which will only be able to decrypt and ran paired with that particular security IC based on some sort of crypto methods. But that really involves pretty good knowledge of cryptography and how such things works. Also add some additional work for your customer.
