Understanding the authentication with ATSHA204A
The workflow is probably wrong, but the main idea should be something close to it.

Nope, this is basically useless. This would be fine if you'd use your crypto IC for example to validate the authenticity of an addon device (say, a printer verifying the  cartridge was made by the same company).
It doesn't help you, because &quot;refuses to work&quot; won't fly if someone has your firmware's machine code: finding the check in the disassembled machine code is usually not that hard. Then, it's as much as replacing a &quot;jump to 'stop and do nothing'&quot; with a &quot;jump to 'start of useful functionality'&quot;; typically, that involves changing a byte.
You need to encrypt the interesting part of your firmware in the permanent storage (typically, the MCU's built-in flash). Only a bootloader that uses the crypto chip to decrypt the main firmware would stay unencrypted. At boot, the bootloader decrypts the firmware into RAM.
Small problem there: You'd need to be pretty clever, hardware-wise, so that one couldn't just attach a logic analyzer between your MCU and the crypto IC and sniff the decrypted bytes.
There's workarounds that obfuscate things by wildly jumping around in memory while decrypting stuff etc. Problem is that there's nothing secret about that, it's just a bit more work to understand how the jumping around is done from machine code. (And if you manage to insert a single piece of machine code on that bus that makes the MCU stream out its entire RAM via some pin, then it's game over, too; it doesn't really matter to you whether you know where that piece of code ends up in RAM, you'll find it later in the dump, it's only important that it gets executed at some point.)
In other words, if you really think your firmware is that commercially interesting (people wildly overestimate that! For things that aren't mainly firmware, such as for about any consumer device and any industrial control it's usually hard to source all the parts and build the same/similar device cheaper than the original, and completely rewriting the firmware is often easy compared to that), then your only chance is to integrate secret keeping, encrypted storage and secure execution (so that RAM dumping is impossible).
There's microcontrollers that do that. They're usually a bit more expensive. But, as you can guess, if you're, for example, in a defense environment where you need to certify the firmware can't be tampered with, well, that's your way to go.
Nintendo makes devices where the financial incentive to not let anyone read their firmware or even modify it is strong:
The inability of users to run software that wasn't licensed by Nintendo on their consoles is critical to their business model. Therefore, being unable to circumvent checking of game's signatures is paramount, and that's why a Nintendo Switch goes all-out with multiple layers of protection. As you can guess, that's no guarantee – there were simply hobbyists (not even people with a criminal/commercial interest!) that found a way around that.
But you'll notice one thing: Just because it's hard to make perfect doesn't mean it's not worth it making it harder to clone your device. In my humble experience, cloners typically capitulate as soon as you'll need understanding of how a device works to copy it – otherwise, they'd be in the position of having engineers that could do your work, more or less, and those engineers typically work in your sector, not in some counterfeit lab. A good deterrent hence is putting the firmware encrypted into flash. It's not perfect, but the moment they'd have to get out the logic analyzer and spend weeks on reverse-engineering your into-RAM decryption protocol, just to get something that they might be able to copy, could be enough that they consider the financial risk too high and go for something else.