August 10, 2026

IBM is making significant changes to how it handles encryption keys with IBM i 7.6. The big news is that IBM i shops now have bring-your-own-key (BYOK) support via IBM Key Protect for IBM Cloud offering, which scratches a certain regulatory itch. But IBM has also bolstered how it handles master keys and save/restore keys stored on the IBM i server, which boosts security, but also makes IPLs following DR events more complicated.

Let’s start with the new bring-your-own-key (BYOK) support for IBM i in IBM Key Protect for IBM Cloud offering. IBM Key Protect is a cloud-based key management service (KMS) that allows customers to import their existing symmetric keys, and store and manage them from the safety of a central location. It supports servers and applications running in the IBM Cloud, as well as custom applications running on-prem (however, a connection to the IBM Cloud is required for it to work).

Key Protect uses hardware security modules (HSMs) to ensure the integrity of encryption keys, which helps it to meet tough regulatory standards for key management. IBM sells two version of it: A standard tier for storing keys for systems in multi-tenant systems, such as its cloud, and a dedicated tier for customers to store keys that are protecting single-tenant environments (i.e., IBM i servers running on-prem). You can read more about it here.

Tim Mullenbach, the IBM i security business architect, described how the new BYOK feature for Key Protect works during a recent IBM i Guided Tour.

“We’re tying it directly in with the IBM Cryptographic Services API,” Mullenbach said. “So if you have any applications that are doing their own encryption, that would be the native IBM i interface that you’d use to leverage our crypto engine. We’ll be providing the ability to export or move your existing AES keys out of a key store that it’s in today, into the Key Protect space.”

Customers will be able to “wrap” their existing IBM i encryption keys by creating a new key in Key Protect. That wrapped key can be stored locally on the IBM i, as before, but since it’s wrapped by Key Protect, it can only be accessed if Key Protect unlocks it, Mullenbach said.

“So you will be able to use this type of key with the existing encrypt and decrypt cryptographic services APIs,” the IBM i security architect continued. “You will also have the ability to, when you are generating master key parts today, to be using passphrases. You will also be able to use IBM Key Protect for different pieces of that.”

Customers can manage the lifecycle of their encryption keys using the Key Protect offering from IBM. On the IBM i side, they will use Navigator for i or commands to configure the IBM i operating system to use Key Protect. “That would be password protected,” Mullenbach added. “So you’d need to provide that password at the time you are trying to activate that key context.”

We mentioned during our first story on the summer Technology Refreshes (TRs) that this feature is specific to IBM i 7.6. Customers running on 7.5 or lower will have to upgrade to take advantage of this new feature. The second part of the encryption update, which you’re about to read about, is also exclusive to 7.6.

Master Key Protection Enhancements

IBM also made several changes to how it handles master keys for IBM i. As Mullenbach mentioned, they’re somewhat related to the BYOK support via Key Protect discussed above. But they will also impact customers who are not outsourcing key management to IBM Key Protect. It will also impact how disaster recovery (DR) works.

There are four specific enhancements made by IBM. For starters, customers can no longer use the default setting for the master key; it must be changed whenever it’s being set or modified.

“Any master keys that are already set [with the default] are still going to work. We’re not doing anything there,” Mullenbach said. “It will just require, if you’re going to touch your existing master keys, that you’ll need to save or create a non-default save/restore master key.”

The second change: System master keys are always going to be stored encrypted when stored to disk, and the encryption is going to be done by the save/restore key. The third and related enhancement: Customers now have the option of caching the save/restore keys in the Platform Key Store (PKS), which was introduced over a year ago with IBM i 7.6.

“The save/restore key [today] only protects it when it’s on the save media, but now we will also be protecting it when it is just on the regular load source,” Mullenbach said. “We are providing the ability for those who have access to a Platform Key Store the ability to cache that save/restore master key there instead of also having that save/restore key on disk as it is today.”

As Mullenbach warned, things are getting more complicated with the new encryption capabilities discussed above. They get even more complex with the fourth new master key feature discussed below.

The fourth change is this: Customers can now implement their own BYOK regime at the IBM i operating system level. “It’s not for the faint of heart, only those who have a very strong regulatory requirements,” Mullenbach said. “It’s a very complicated thing.”

Implementing BYOK at the OS level is enforced by requiring customers to furnish a save/restore key to be able to IPL a system. They can call that save/restore key by using a preconfigured remote key agent (RKA), which is basically just another IBM i server in the private cloud environment.

“At a high level, you have two systems,” Mullenbach explained. “You have what I call my BYOK system, where in order for that to IPL up successfully, a key will have to be provided. You think about this in a managed service provider or cloud space, where you don’t control the storage where your load source is at. So this is a way where that thing can’t IPL up unless you have a key.

“So as it’s IPLing up, we reach out to our friend for help. ‘I don’t have my save/restore key. Can you give it to me?” he said. “You have another pre-configured IBM i that knows about your key, knows how to communicate with you, [and has] the ability to notify an administrator when this situation is going on. That administrator can provide the key that flows back at a DST [dedicated service tool] level. We’re not really the DST, but right below it, we get that key, and thank you, we have it. And now we can IPL up. So again, not for the faint of heart, but it truly would provide operating system level bring-your-own-key.”

The OS-level BYOK also leverages the PKS, which leverages extended PowerVM technology that IBM originally introduced with the Power10 chips and platforms. With PKS, keys are stored deep in the partition firmware, below the SLIC. Kris Whitney, the new IBM i chief architect, called it “software-based HSM.”

The original support for PKS in 7.6 could only provide encryption at the ASP or iASP level. It couldn’t encrypt at the operating system level. The PKS, together with the new RKA system, enables IBM to offer OS-level BYOK support.

“When you do that, recovering from that, booting from that, is a little more complicated because we have to go retrieve that key and such,” Whitney said in a recent Fortra webinar. “But that is there to meet those compliance requirements.”

RELATED STORIES

How IBM Bolstered IBM i Resilience In The Summer Tech Refreshes

Big Blue Finally Unveils First IBM i Tech Refreshes Of 2026

What IBM’s Got Cooking In Db2 For i In The Summer TRs

IBM i 7.6 Brings More Security Improvements Than Just MFA