Loading kernel extension now produces message "System Extension Blocked"?

My company's software relies on a codeless kext in order to prevent a macOS built-in driver from taking control of hardware. We automatically generate numerous kexts for many different hardware configurations. Earlier kernel extensions we've built and notarized still load fine in macOS 10.15.6, though of course the first time requires the user to allow the kext to load in the Security & Privacy pref pane.

Now the most recent driver I've built and notarized produces this message:

"System Extension Blocked

A program tried to load a new system extension(s) signed by "XYZ" that need to be updated by the developer."

Now there is no option to load the kext!

Why are some kexts able to load in 10.15.6 and not others? Is there some restriction on how recently a kext can be signed or notarized and still be allowed to load?

Replies

Nevermind -- this issue has suddenly gone away on its own!

Now if I try to load the same kernel extension in a fresh install of macOS 10.15.6, it pops up the dialog box that lets me load the kext. This is after reproducing the issue with the "need to be updated by the developer" message six or seven times.

Even more perplexingly, two of the systems I was testing in were virtual machines, and I tried rolling them back into the same clean state I had used for testing minutes earlier and installed the same driver that had been having the issue. Now it lets me load it in the Security & Privacy system preferences. Suffice it to say, this is very odd! I can only guess that macOS is contacting a server when validating the kext, and something changed on Apple's servers so that macOS now permits this kext to load. Am I correct in this? If so, why was the kext denied permission to load in the first place?

Some say the definition of insanity is doing the same thing over and over again and expecting a different result. So it seems that one has to be at least a little insane to deal with kernel extensions in macOS.