When legacy FileVault was first introduced as part of Mac OS X 10.3 Panther in 2005, it supported a recovery key method which used a special keychain named FileVaultMaster.keychain which by default had a private key and public key inside. This recovery key was used to provide certificate-based authentication to unlock the encrypted disk images which were used by legacy FileVault.

When FileVault 2 was announced as part of Mac OS X Lion in 2011, Apple announced that there would be two kinds of recovery keys available:

1. Personal recovery keys (PRK) – These are recovery keys that are automatically generated at the time of encryption. These keys are generated as an alphanumeric string and are unique to the machine being encrypted. In the event that an encrypted Mac is decrypted and then re-encrypted, the existing personal recovery key would be invalidated and a new personal recovery key would be created as part of the encryption process.
2. Institutional recovery keys (IRK) – These are pre-made recovery keys that can be installed on a system prior to encryption and most often used by a company, school or institution to have one common recovery key that can unlock their managed encrypted systems.

IRKs were the sole part of Apple’s FileVault 1 (also known as legacy FileVault) that was carried over into FileVault 2. IRKs were legacy FileVault’s recovery keys and they were used in almost exactly the same way. The main difference was that they were now used to unlock an encrypted disk as opposed to legacy FileVault’s disk images.

In FileVault 1 deployments, you were asked to set a Master Password when turning on FileVault 1’s encryption. When you set the Master Password, the FileVault 1 encryption process set the password that was entered as the password on the /Library/Keychains/FileVaultMaster.keychain file. In turn, the FileVaultMaster.keychain file contained two keys used for PKI certificate-based authentication (one public key and one private key). When the public and private keys are both stored in one keychain, the keychain can be used to unlock your FileVault 1-encrypted home folder in the event that the password to open it was lost or forgotten. The Master Password only unlocked the keychain and allowed the system to access those two PKI keys. This is the reason why you needed to set the Master Password before encrypting and why it was also important to use the same FileVaultMaster.keychain file across the machines where you wanted to make sure that the same recovery key was being used.

If you were deploying the same recovery key for your FileVault-encrypted Macs, Apple consistently recommended that you go into the FileVaultMaster.keychain file, remove the PKI private key, put the private key somewhere secure and deploy the FileVaultMaster.keychain file with only the public key inside. The reason was that, in the event that the password to the FileVaultMaster.keychain file was compromised, all the compromiser got was one half of the keypair (the public key half.) The private key would not be on the machine and thus not available to compromise the FileVault 1-encrypted homes on the machine. However, FileVault 1 would work with both the public and private keys stored in /Library/Keychains/FileVaultMaster.keychain.

In FileVault 2, Apple changed removing the private key from being a suggested best practice to being a technical requirement. If you want to use an institutional recovery key, your FileVaultMaster.keychain file needs to have just the public key in it. If both public and private keys are stored in the /Library/Keychains/FileVaultMaster.keychain file on a Mac, FileVault 2 will ignore the keychain and not use it as an institutional recovery key. In this case, enabling FileVault 2 encryption will automatically generate a personal recovery key.

That was then, this is now

Over the years, the PRK gained functionality while the IRK largely did not. With the advent of PRK escrow systems (found in most present-day MDM solutions), the IRK’s main advantage of being a recovery key which could be mass-deployed came to seen instead as a weakness. After all, better to have recovery keys where each encrypted drive has its own unique key in place of the danger of a compromised recovery key being able to unlock all the machines in your Mac environment.

You can also only use an IRK to unlock or decrypt if you were booted to macOS Recovery. Recovery’s limited functionality meant that users of an IRK would have to do some preparation work, including making sure that the IRK’s keychain file was available somewhere which could be reached from Recovery.

Meanwhile, Apple has made changes to the environments where you could use an IRK. Beginning with macOS Catalina, macOS Recovery now prompted you to log in with either a password associated with an admin user or with a PRK.

You could not use an IRK at this login screen. So now Mac admins found themselves in the situation where they had an IRK, but couldn’t use it to authenticate in Recovery and get to the point where they could use the IRK.

With the introduction of Apple Silicon Macs, Apple has also discontinued Target Disk Mode functionality. This also affected the use of IRKs because it removes the ability to unlock using an IRK while the locked drive is connected to another Mac via Target Disk Mode.

The combination of all of these factors has led to Apple making a written recommendation to not use IRKs for institutional deployments of FileVault on Macs.

It’s been a long run for IRKs and they still do work as recovery keys (for now), but in my opinion it’s time to follow Apple’s stated recommendation and stop the deployment and use of IRKs as FileVault recovery keys.