As part of testing macOS Golden Gate, it was discovered by myself and others that MDM enrollment does not appear to completely work. In my testing, here’s what I did:

1. Create a macOS VM running macOS 27.0.0
2. Enroll it in an MDM (in my case, Jamf Pro) using profile-based device enrollment.
3. MDM enrollment profile is successfully installed.

Expected behavior following step #3:

• Additional configuration profiles and Jamf software components are installed on the macOS VM.

Actual behavior following step #3:

• No additional profiles or Jamf software components are installed. Only the MDM enrollment profile is visible in System Settings, in General: Device Management.

What’s happening after step #3? For more details, please see below the jump.

To check on this issue, I ran the following command using the log command line tool to see what was being logged within the last hour by apsd, the background system process on macOS responsible for maintaining macOS’s persistent connection to Apple’s Push Notification service (APNS):

When I checked the logging, I saw the following logging repeatedly appear:

Based on the information discussed in this post in the Apple Developer Forums, this logging appears to indicate the following:

1. The macOS VM is trying to get a key from Secure Enclave. macOS VMs do not have Secure Enclave, so this effort fails.
2. Without the key, a separate process called MobileActivation cannot create a reference key.
3. Without the reference key from the MobileActivation process, a BAA device identity certificate cannot be retrieved.

In the logging on my end, this process repeats multiple times.

When I attempted to enroll a macOS VM running macOS 26.6.2 using the test procedure described above, I saw the following logging:

This appears to show the following:

1. The macOS VM does not attempt to get a key from Secure Enclave
2. The macOS VM successfully retrieves a BAA device identity certificate
3. The macOS VM specifically identifies itself as a virtual machine

From this evidence, my assumptions are as follows:

When a virtual machine running macOS Golden Gate 27.0.0 tries to register itself with APNS, macOS 27.0.0 erroneously assumes itself to be running on a Mac equipped with a Secure Enclave. That assumption is incorrect. That incorrect assumption by macOS then triggers a series of downstream failures which results in the macOS VM being unable to register itself with APNS.

If this is correct, the failure to register with APNS explains why the macOS VM never gets the additional configuration profiles and Jamf software components from my Jamf Pro MDM server. The macOS VM’s registration failure means the VM is unable to communicate with APNS and that’s essential to be able to communicate back to the MDM server. Failure to communicate with the MDM server means that the VM never receives anything from the MDM server.

That said, that’s my conclusions based on what I observed in the logs. I do not know for certain if my assumptions and resulting conclusions are correct. If someone has more information, please share it in the comments.