MacOS Big Sur will only recognise UR28M in class compliant mode

After using Parallels and Windows 10, my MacOS Big Sur (Intel) installation no longer recognises my UR28M unless it’s in class compliant mode. I don’t know for certain that Parallels may have caused it, but it was around the same time. I also installed the IK Multimedia firmware updater that required a startup. (It also doesn’t work under Big Sur - that’s why I ended up using Parallels)

Even though it doesn’t show up in AudioMIDI setup, and isn’t recognised in the sound preference pane, it shows up as connected in the System Report, and dspMIXFx recognises that it’s connected.

I uninstalled and then reinstalled the 3.05 USB driver with no change in behaviour.

After speaking with a high level tech at Apple, I’ve been informed that the behaviour I’m experiencing is simply MacOS Big Sur working the way it should.

He shared this document with me: Kernel extensions in macOS - Apple Support

Essentially, kext’s cannot be loaded on demand and are no longer recommend for use.

Basically, Steinberg audio hardware users are going to start to get this problem a lot.

Kernel extensions in macOS

Starting with macOS 11, if third-party kernel extensions (kexts) are enabled, they can’t be loaded into the kernel on demand. Instead, they’re merged into an Auxiliary Kernel Collection (AuxKC), which is loaded during the boot process. For a Mac with Apple silicon, the measurement of the AuxKC is signed in to the LocalPolicy (for previous hardware, the AuxKC resided on the data volume). Rebuilding the AuxKC requires the user’s approval and restarting of the macOS to load the changes into the kernel, and it requires that the secure boot be configured to Reduced Security.

Important: Kexts are no longer recommended for macOS. Kexts risk the integrity and reliability of the operating system and Apple recommends users select solutions that don’t require extending the kernel.

jmax, thank you for forwarding Apple’s reply on the kext topic. We are fully aware of Apple’s recommendation but so far, there has been no statement as to when the support will finally be cut off.
The upcoming macOS Monterey still supports the use of kernel extensions, regardless of an Intel-based system or an Apple Silicon based solution - unfortunately including the “Security & Privacy” settings and changing the security policy. At the moment, we simply still need to use kext and so do some of our competitors.
However, we work on a permanent and future-proof solution to what will inevitably need to happen.

The issue with the UR28M, is not directly related to the above-mentioned situation. It should still work, though we have seen cases where the device is recognized as a class compliant device only removing the option to use the device-specific features.
Just to be sure: the issue is not when using Windows 10 in Parallels but in macOS Big Sur only, right?

Please make sure that the “Security & Privacy” settings are configured properly.

It is very difficult for us to reproduce the issue but we had a case where Parallels itself caused the issue and uninstalling Parallels fixed it (Parallels also uses a kext).

Thanks for getting back to me on this. I can confirm that the problem only exists in MacOS Big Sur.

The only reason I associate it with Parallels is that it was working fine until I ran Parallels on Big Sur for the first time. That may have been a coincidence, but I will try uninstalling it and see what happens.

The Security & Privacy settings are correct. The only way to get it to work is to manipulate files in the Extensions folder. Here’s a link to a video showing the process.

I showed this to the tech at Apple, and they said that that was simply Big Sur working the way it was designed to.

Screen recording

And it’s now started working fine again. With no changes on my part (that I know of)

I am sorry. I totally missed your last reply. It is good to read that it is working again.