Your biggest problem will be to prevent spoofing. What I might suggest is to allow a user 30 days to visit the web site to get a permanent key using a challenge/response method.
So here is the idea in general:
Your software has some numbers associated with it. These numbers have to somehow change with each copy, sort of like a product serial number.
Your customer's computer has some things you can look at. For instance, the serial number of the hard drive, the serial number of the CPU, or the serial number of Windows, all of which should be unique in some way or another. So you write some VBA code that, when you trigger it, provides the user with a bunch of numbers - the software product serial number and one or more of the other numbers above. Perhaps disguised in some way like scrambling digits or hashing before they are even published.
Your web site has a challenge/response page. You enter all of the numbers supplied by the little application on the user's computer. (You might have to do a web search for "hashing algorithms" and pick one.) Hash the user's responses using a formula known only to you. Reply to the user with the resultant hash value. The little app takes this number and does something to the user's registry. See help topics for SaveSetting and GetSetting for how to do this.
OK, here is the part that is tricky. You cannot distribute the source code for this registration app because that would let folks know what you are using. Binaries only for that app. But put the same computation in the app that your web page uses.
If your user registers, your web site remembers the combination of numbers for product serial number and whatever else you used. When your product starts on the user's computer, you try to retrieve the key you choose with GetSetting. You will have three possible cases:
1. No such key - you are in the 30-day trial period of an unregistered copy. It is up to you do to the date tests and decide what to do about that. Possibly test for a second registry entry that contains a date of first use. Always write a third entry that contains a date of LAST use plus a hash.
1.a No date of first use: Encode the date in clear text PLUS include a hashed variant of that date as a part of the same key. Save the key. Write the date of LAST use entry.
1.b Date of first use exists, hash is OK, "today" is within proper time limits, last use is earlier than today's date, hash is OK: Allow the use
1.c Date of first use exists, hash is OK, last use exists, hash is OK, date is outside of limits: Product trial period has expired. Here, be gentler than the next case, but refuse to run.
1.d Any of the following cases: (First use exists & hash is wrong; Last use exists & hash is wrong; Last use exists with good hash but today's date is earlier than last date; one of the two dates does not exist) - product registry data has been tampered. Barf all over the user.
2. Key exists and its value matches the computed hash - you have a registered product. Keep on truckin'
3. Key exists and its value does not match the computed hash - your user's configuration has changed. You cannot tell whether the problem is a hardware change or an attempt to pirate your software, but you know it ain't what it used to be.
Complain to the user that the product key (which, due to hashing, contained computer identification data) appears to be incorrect for the current environment, delete your old key settings, and advise the user they have 30 days to register correctly. Write the registry entries for date of first use and date of last use as though this was an initial install.
If you take this approach, it is incumbent on you to notify the user during initial installation that the product has a strictly enforced expiration policy if you don't register it AND that the policy is bound to some unspecific characteristics of the computer running the app. Further explain that changing out a hard drive, CPU chip, or certain other things will possibly require product re-registration.
Now, on the web site, when a registration combination is entered, you can test for duplication of product identification key with different machine identifiers. If a person tries to register a key that has been used already and the system identification information doesn't match, advise the user of a phone number to call in order to get the previous registration deleted. Of course, you will write down a lot of information about the owner when such a call comes in, because that person is now suspected of being a pirate.
And here is the final secret: The reason a person is involved is because you cannot trust the computer to forever get it right. At some point you want a human hand in the process when you suspect a breach of trust. Because, you see, trust is always and ultimately based on human judgement.
ALL TRUST MODELS start with the concept of "Does the system administrator trust client XYZ" as a basic question for security setup for all new systems. That is not (or should not be) an automatic decision the first time.