I am frequently being asked to design in products such as the ATECC508 to provide extra security. While I understand the idea, I can see very limited value in these.
The problem is an obvious one. In order to establish a TLS/SSL connection it is necessary that each party to the connection provides their certificate and then use their key to sign a challenge code from the other party to verify that they have not only the lock (the certificate) but also the key that belongs to that lock. Traditionally these would be stored in either internal or external ROM. Someone gaining access to the memory of the processor could therefore easily access the key and then use this to launch an attack on what ever server the product is supposed to be connected to (normally a cloud service now-a-days). For external flash, this means desoldering the chip, locating it in the flash and you're done. For internal flash, most products have a read protection feature which makes it a bit more complicated but even assuming that you can't break this directly, generally a small app can be written which can then be programmed (after a partial erase) and read out the certificate and key directly from the flash. It might take a couple of products to figure out how to do it on any unit but there is not much of a challenge.
The solution from Microchip to this is to take the key and put it in a chip that can not be read from and helps to do the signing directly, thus on paper removing a lot of complexity from the code and preventing anyone being able to access the key. Keys can even be generated by the part itself meaning they are never even seen by a human being and thus there isn't even a risk that a member of staff will leak the keys and so on. On paper very safe.
The problem is that the default mode for the devices involve passing the challenge from the server to the device over an I2C bus and it will be signed. There is no validation of the device or any other way to restrict access to the device. It is painfully easy for anyone with a scope to locate at the key number being accessed and then they don't even need to try to figure out which of the 16 keys belongs to the certificate being presented. The same attack can be launched with a simply USB-I2C dongle and can even by used with something like an Arduino to virtualise it and then simply allow multiple computers to access it over IP and get their challenge strings validated and you are back where you were in terms of security, if not worse - you probably don't even need to buy a second unit.
Their is a slightly better mode, but it buys you only a little bit of extra security. This involves authorisation before using the device. The authorisation state is then preserved until the power is removed or the device enters sleep state. Again, it looks good, but the ease of intercepting the I2C communication and effecting a man-in-the-middle type attack means that it can allow the device to authorise the key and thereafter use it as often as it likes. It is a bit more complicated, but probably easily done by anyone with basic firmware skills. Alternatively, the private key used for authorisation could just as easily be located in the firmware and then this used to do the authorisation directly. This requires a significant reverse engineering of the firmware to extract it however and at the end of the day you only have the same situation as if you had stored the key/certificate pair in the internal flash.
In short for IoT applications, save your money and the lead time, skip it.
What do I recommend? If the controller has an integrated Hardware Security Module, then use that. If it has the ability to encode all of its (external) data, then use that. If not, a simply obfuscation algorithm so the plain text is not visible, customised to each device, gives you more protection than these devices in an IoT context and then rely on the read protection facility of the internal flash. No protection can be absolute, but at least breaching these takes hours as opposed to minutes in the case of the external Hardware Security Modules.
Don't even get my started on storing the certificate in there as well...