RADIUS Deployment failing miserably

The answer here lies in the security utility, which lets you manipulate the user's keychain and certificates contained therein. However, this is difficult, as the keychain needs to be unlocked or you need the user's password. That's not always feasible.

Practically, there's probably an easier solution here. Are you handing out the SCEP or AD Cert instructions in a configuration profile? If so, are you also handing out the WiFi settings in the same profile, or a separate one? If you send both in the same profile, you can explicitly tell the WiFi settings to use the certificate received from the SCEP request for authentication.

@kilodelta We are handing out the AD cert instructions in a configuration profile. So you're saying that putting out two configuration profiles, one for Wifi settings, and one for the cert instructions, could potentially resolve the issue that I'm experiencing?

Yes, but the opposite of what you said - put them in the same profile. When you have both a certificate and a WiFi payload, and you choose a WPA2 Enterprise EAP type that supports certificates, you'll see an "Identity Certificate" drop down with the option of "AD Certificate". Selecting that will tell the Mac to use the certificate it requests to authenticate to the WiFi network.

In a similar vein, be sure you configure upload the entire certificate trust chain for your RADIUS server under the trust tab. Failure to do so can cause clients to be prompted to trust the RADIUS server, even if the certificates it's using are otherwise explicitly trusted on the system.

Yeah, they basically need to be in the same profile for the OS to automatically create an "identity" that links the certificate to the wireless configuration. You can use the security command as mentioned above to create an identity, but it's not a great option and can be finicky.