Owners and users: Primary and secondary systems on M1 Macs

Knowing now that on M1 Macs there are not only admin users but also Owners, this article looks in more detail at how Ownership works, particularly in setting the Mac up initially and when installing second operating systems, such as a copy of macOS on an external disk. Apple provides details in its Platform Security Guide, so here I’ll try to explain them, and their problems.

Initial key and certificate creation

There are two situations in which an M1 Mac needs to be set in its default state: when it’s brand new, and when it has been fully erased and restored in DFU mode using Apple Configurator 2. As Apple explains: “When macOS is first installed in the factory, or when a tethered erase-install is performed, the Mac runs code from temporary restore RAM disk to initialize the default state. During this process, the restore environment creates a new pair of public and private keys which are held in the Secure Enclave. The private key is referred to as the Owner Identity Key (OIK). If any OIK already exists, it’s destroyed as part of this process.”

So during this creation of the default state, the OIK, the private half of a public-private key pair, is generated and stored in the Secure Enclave. Also created is a new User Identity Key (UIK) for Activation Lock. This is sent to Apple for certification, where it’s checked to see if it’s associated with a lost Mac using the Find My Mac service. If it is, then certification is refused and that attempt to set that Mac up fails. If the UIK is certificated successfully, then that User Identity Certificate (ucrt) is used to sign in RemotePolicies, which provide constraints for LocalPolicies.

The ucrt and OIK are then used to obtain an Owner Identity Certificate from Apple: “When an Activation Lock/ucrt is successfully retrieved, it’s stored in a database on the server side and also returned to the device. After the device has a ucrt, a certification request for the public key which corresponds to the OIK is sent to the Basic Attestation Authority (BAA) server. BAA verifies the OIK certification request using the public key from the ucrt stored in the BAA accessible database. If the BAA can verify the certification, it certifies the public key, returning the Owner Identity Certificate (OIC) which is signed by the BAA and contains the constraints stored in ucrt. The OIC is sent back to the Secure Enclave. From then on, whenever the Secure Enclave signs a new LocalPolicy, it attaches the OIC to the Image4.”

At the end of these processes, the Mac has an OIC, kept in the Secure Enclave, which is used to attach to all LocalPolicies for that Mac, a private OIK, also kept in the Secure Enclave, RemotePolicies which are signed into the ucrt, and a UIK for Activation Lock.

These processes are summarised here:


which is also available as a downloadable PDF: SettingM1Mac1


Creating and maintaining LocalPolicies requires a user to have access to the private OIK in the Secure Enclave, making that user an Owner. Apple states: “Access to the Owner Identity Key (OIK) is referred to as “Ownership.” Ownership is required to allow users to resign the LocalPolicy after making policy or software changes.”

Who is an Owner?

Any user with access to the OIK is therefore an Owner. Although there’s only one OIK for any given M1 Mac, and by default only the primary admin user has access to it: “The OIK is protected with the same key hierarchy as described in Sealed Key Protection (SKP), with the OIK being protected by the same Key encryption key (KEK) as the Volume encryption key (VEK). This means it’s normally protected by both user passwords and measurements of the operating system and policy.”

So any user with access to the Volume Encryption Key for the internal storage also has access to the OIK, and has Ownership. By default, that includes all users added after FileVault encryption is enabled on a Data volume, for example.

Installing a second operating system

M1 Macs always start their boot process from their internal storage, even when they’re then going to boot from a second operating system stored elsewhere. To be able to boot from that second OS, it requires a LocalPolicy with an OIC attached, and Ownership has to be handed off to an Install User created when that OS is installed. Creating and changing that LocalPolicy thus requires Ownership, for which the same password is required as for access to encrypted internal storage.

Handing off Ownership to the Install User is more of a problem, as users are only created once the installation is complete. To accommodate that, macOS offers to copy a user from the current boot system as the Install User, and the primary admin user, on the second OS. Apple states: “When running an Install Assistant and targeting installation for a secondary blank volume, a prompt asks the user if they’d like to copy a user from the current volume to be the first user of the second volume. If the user says yes, the “Install User” which is created is, in reality, a KEK which is derived from the selected user’s password and hardware keys, which is then used to encrypt the OIK as it’s being handed to the second operating system. Then from within the second operating system Install Assistant, it prompts for that user’s password, to allow it to access the OIK in the Secure Enclave for the new operating system.”

Apple strongly recommends that this offer is accepted, as it ensures that the Install User can access the OIK, and that security is fully preserved. However, if the user decides not to copy the current user, macOS will create an Install User with a blank password.

These processes are summarised here:


and in the downloadable PDF version: Install2ndOSM1

Addressing problems

These are complex processes which don’t always work as expected, particularly when using beta releases. You can make them more reliable by:

  • Retaining the primary admin accounts created on the first OS on internal storage, and any second OS on internal/external storage. Although creating a second account may work perfectly well, the original Owner and Install User accounts are likely to prove the most reliable.
  • Installing second OS from the primary admin account on the primary OS.
  • Installing macOS updates from the primary admin account of that OS.
  • Copying the Install User from the first OS to a second, as invited during installation.

Problems normally manifest in failure to install a second OS, or failure to update it. Sometimes an attempt may be blocked, with an alert reporting that the disk has no Owner, or an update may apparently proceed normally, but fail to change the version of macOS installed. Although macOS should always prompt the user for the Owner’s password on such occasions, and make clear which user that is, if that doesn’t happen access to the OIK may fail.

There currently appears to be no way to identify Owners or Install Users. Even the command tool bputil doesn’t appear to provide that information. File system ‘volume ownership’ appears to be completely unrelated to this type of Ownership.