Microsemi, now Microchip, has FPGAs that the programming tools can be setup to need authorization keys to program a specific number of devices.
The system is designed for this sort of environment, where you don't have complete trust of your assembly house.
They don't need the FPGA source code unless they need to change or retarget the FPGA, and if you give them that, you will need to price the transaction understanding that you are lossing control over your IP.
If they are just building a defined product, they just need the compiled bit-stream, which for some devices, like the Microsemi ones I mentioned, may have some control over its duplication if properly encrypted.
You can do some kind of DRM with crypto keys and such, but do you have a way to securely identify one board from another? If you can safely query the FPGA serial number you can bind a decryption key (eg of the bitfile or some critical firmware) to that serial number, and only issue keys for specific FPGAs.
But if they can spoof the FPGA serial number then they can make every FPGA look the same.
For example, working with Stratix 10s lately, we haven't found a way to get the chip serial number via JTAG without programming a bitfile that reads it out. Although I suppose you could first program a 'good' (encrypted) bitfile that reads out the serial number. That would require somebody to MITM that bitfile to replace it with a chosen-serial number: not impossible, but hard to do at scale. (Bonus points if every device has a slightly different way to send the serial number, like every bitfile send it with a encrypted with a different key)
Or, if the thing is online in some way, you can make it check in to a licence server, where you would notice if lots of the same serial number turned up and could block them.
The Microsemi FPGA's each have a factory assigned crypto-serial number (and individual key) built into the FPGA itself, and a programming file can be generated that can only program that EXACT FPGA (that factory assigned key). You can also generate a programming file encrypted to a generic key that any of that model FPGA can take (when you trust the programming facility)
Their secure programmer takes a programming file encrypted to the programmers key, and with a secure file that the designer has to sign, gets the public key for the FPGA and decrypts and reencrypt the programming file for THAT FPGA, while ticking off the usage count kept in its own secure storage.
Firstly, if they're trying to ensure robustness against future supply shortages, i.e they might need to change to a different FPGA, they're going to need the source code anyway.
Secondly, if you add a smaller chip to add authentication, it needs to perform some critical function that cannot easily be replicated. That is, it needs to be the part that implements your core innovations. Removing it (and changing the FPGA code) must not result in a workable device.
If you can do that without incurring the exact same continuity problem that you could have with the main chip, go for it. But I think this kind of secure lockout is much harder than you think, and probably harder that it's worth.
Another path that might work with some networked equipment is to design it to either "phone home" periodically, or to expire an internal license key that must be renewed to restore operation. But that's more appropriate for a high-value device where you don't charge your customers, and may only be legal in a rental/subscription model, not outright ownership. It typically engenders so much ill will among buyers that you'll sell enough more without any protection to make up the difference.
Business is built on relationships of trust. If you don't trust these folk, and can't get them to agree to some regime that will keep your confidence, quit them and find someone else to do business with.
It does, but it doesn't seem to address the OP's threat model. Which is that they want to give the third party the source code and the ability to generate their own FPGA bitfiles while still maintaining control (to prevent overproduction). In that instance the third party can modify the FPGA to work around the protection, and you need to do attestation against some external authority (microcontroller for example) to 'activate' the system, and a way that can't be spoofed by changing the FPGA bitfile.
So if you can run the secure programmer on a microcontroller and extract the serial number without trusting any bitfile, you might be able to use that as a key for some component that you do not release to the third party (eg firmware that runs on a soft-core inside the FPGA).
Or you could require your third party to submit their FPGA bitfile for signing by an approved key server you control, along with a list of serial numbers of FPGAs you want to allow to run it.
It sounds like they have a useful toolkit, but it would need further understanding of the pieces and put them together to meet the requirements.
IF you actually need to give source code, then this system doesn't provide protection, but my reading of the situation doesn't define that they absolutely need to get source code, but the OP thinks they may want it.
Fundamentally, if you give source code, you have not true secretes in what you give them. If you can put something ESSENTIAL, that is also not possible to reverse engineer or duplicate into something you can control, you can maintain control, at least until they figure out how to get around that toll-gate.
In my opioion, if you are going to sell the code for the major part of the system, you need to price that part of the transaction to get what you need out of it, and make the effectively unenforceable unit fees (if any) small enough that they aren't incentivized to break the agreement.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.