That's actually a really interesting question. Mostly because I think there is no really good solution.
However, considering that we are putting more and more computing power into all devices and more and more of their value is derived from the software it seems to be very relevant for the future.
If you want something that can even remotely be called cryptography you should define your security model. Given that you are using a commodity board what is stopping your software from running on a different one of these boards? Clearly nothing, because that's how you are going to produce your devices. So the only option you really have is to keep your software secure in the first place.
I actually think solving this problem is the reason why many devices are IoT devices in the first place. It allows you to put the important parts of the software on the server and authenticate your users when they want to use it.
Let's say this is
Option 1: Keep parts of software on your own hardware and restrict access.
Now, there are a lot of other techniques that are somehow trying to achieve your goal...
Option 2: Trusted execution environment (careful, that article is basically advertisement) A way to protect your software from being extracted from the device. Something like Intel's SGX or ARM Trustzone.
Option 3: Make a mess
A combination of the following might give you sufficient security:
Whitebox crypto: Hide cryptographic keys that your software might be using. Afaik all schemes are broken. However there is no shortage of companies trying to sell it to you. (Sad, it doesn't even have its own Wikipedia article.)
PUF: To achieve hardware binding (that's the common term for making something run only on your boards) you use some hard to fake property of the hardware like the initial state of the RAM when turning the device on.
Code obfuscation: Add unnecessary abstraction and redirection and such to your code so that somebody cannot reverse engineer it with reasonable effort and remove all the safeguards you have put in.
Option 2 seems much more solid but a combination of these might help mitigate sufficiently many attacks for you to confidently deploy in a scenario where you don't have a TEE or the option to do things online.