I fear with the onset of notarization, this scenario is going to become increasingly common: you’ve just tried to install software which you understand includes at least one kernel extension, and has worked fine before macOS 10.14.5 (which you’re running). The install fails for no apparent reason. What do you do next?

The probable cause is that one or more of the kernel extensions haven’t been notarized, and the security system in macOS has taken exception to that, refusing to install them. Of course there are a thousand and one other possible reasons, but here I’ll assume it’s the result of this change in security. Check first to ensure that you’re not overlooking the normal security dialog, which invites you to open the Security & Privacy pane and agree to the extensions being installed there.

The only piece of information that you require is the developer ID of those kernel extensions. The simplest way to obtain this now is to open the Installer package using Suspicious Package.

There, locate one of the kernel extensions, open the contextual menu, and export that whole kext (the folder with the extension .kext) to your Downloads folder.

To get the developer ID and check whether that extension has been notarized in one fell swoop, use the spctl command in the form
spctl -a -vv -t install mykext.kext
One easy way to do this is to type most of the command
spctl -a -vv -t install
then drag and drop the extension from your Downloads folder to the end of that line, where its path and name should appear, e.g.
/Users/hoakley/Downloads/VBoxDrv.kext

Then press Return, and you should see three lines of response:
mykext.kext: accepted
source=Developer ID
origin=Developer ID Application: DeveloperName (NJ2ABCUVC1)

If the extension is notarized already, they will instead look like
mykext.kext: accepted
source=Notarized Developer ID
origin=Developer ID Application: DeveloperName (NJ2ABCUVC1)

Make a note on paper or your iOS device of the developer ID provided in parentheses, as you’ll need those in a few moments.

Close your apps down and restart your Mac in Recovery mode. There, open Terminal and type in the command
/usr/sbin/spctl kext-consent add NJ2ABCUVC1
where the code at the end is exactly the same as the developer ID which you just obtained from spctl. Press Return, wait for the command prompt to appear again, then quit Terminal and restart in normal mode.

Now when you try running the Installer package, you should find that its extensions install correctly, as you’ve bypassed the new kext security controls.

Please let the developer know of your problems and this workaround: they need to get their kernel extensions notarized to spare other users of this same rigmarole.

New spctl features and wrinkles

The man page for spctl hasn’t been updated for over six years, but in 2017 it gained a set of actions to handle kernel extensions and your consent for them to be installed – what Apple terms User Approved or Secure Kernel Extension loading. You should be able to see these if you call spctl with the -h option. These kext-consent commands only work when you’re booted in Recovery mode: they should return errors if you’re running in regular mode.

This appears to unblock kernel extensions which macOS won’t install because they don’t comply with the new rules on notarization, presumably by adding the kernel extension to the new whitelist which was installed as part of the macOS 10.14.5 update. Kernel extensions which are correctly notarized should result in the display of the consent dialog taking the user to Security & Privacy; those which aren’t and don’t appear in the whitelist are simply blocked and not installed now.

To show whether the normal system for obtaining user consent to install extensions is enabled:
spctl kext-consent status

To enable the normal system for obtaining user consent:
spctl kext-consent enable
and disable to disable, of course.

To list the developer IDs which are allowed to load extensions without user consent
spctl kext-consent list

To add a developer ID to the list of those allowed to load kernel extensions without user consent
spctl kext-consent add [devID]
as used above, and remove to remove that.

It is strange that this control using kext-consent works at a developer ID level, thus applies to all kernel extensions from that developer, whereas notarization is specific to an individual release of a certain code bundle from that developer.