IBM i 7.6 BYOK encryption can block your own IPL now

IBM i 7.6 TR2 shipped bring-your-own-key encryption in July, and most of the coverage treated it the way IBM’s own release notes do: one more line item in a Technology Refresh with a dozen other things in it. That undersells what’s actually in the box. Turn on the strictest version of this feature and you can configure your system to refuse to IPL until someone hands it the right key. That’s not a side effect. IBM documents it as the intended behavior. It’s also the part nobody outside IBM’s own support pages has written about.

What the bring-your-own-key feature actually does

BYOK support landed in IBM i Cryptographic Services via native integration with IBM Key Protect for IBM Cloud, IBM’s centralized cloud key management service. It’s 7.6 TR2 only, not available if you’re still on 7.5, and it shipped alongside the rest of the summer Technology Refresh, which also brought the new Power S1112 entry server.

In practice it gives you three things. You can export any AES key sitting in a cryptographic services keystore file up to Key Protect using the CRTEKMKEY command or through Navigator. You can wrap a key that stays local with a root key held in Key Protect, using WRPEKMKEY. And you can use a key that’s wrapped by or stored in Key Protect through an External Key Manager Description (EKMD), which plugs straight into the encrypt and decrypt APIs Cryptographic Services already exposes. IBM also added storage and wrapping of Master Key parts directly in Key Protect, and a new QSYS2.EKM_INFO() table function that reports on your EKM configuration, 7.6 TR2 only as well.

Tim Mullenbach, IBM’s i security architect, described the target audience plainly during a webinar covering the release: “This is really targeted for those who are trying to run their IBM i in the cloud and have a compliance requirement where they have to have external key management. It’s also an option for you to run on-prem.” If you’re on PowerVS or another cloud IBM i deployment and an auditor has asked why your encryption keys live on the same box as your encrypted data, this closes that gap. It’s also available if you just want the option without a cloud mandate forcing your hand, and it’s a genuine step forward from the obscurity-based security posture many IBM i shops have leaned on for years.

The part that matters more than the announcement

Here’s where it gets specific, and where the actual operational decision lives. IBM i has always had a Save/Restore master key, a special-purpose key that wraps your other master keys whenever you run a SAVSYS operation, so the master keys aren’t sitting in plaintext on save media. That’s not new.

What’s new in 7.6 TR2 is how far you can push that protection. You can enable BYOK at the OS level by removing the Save/Restore key from the partition load source entirely. Once you do that, the Save/Restore key has to be supplied during or after IPL by an administrator before the Master keys it wraps become usable again.

Go a step further and combine that with ASP encryption of the system ASP, ASP1, and IBM’s own documentation is explicit: this will prevent IPL until the Save/Restore key is provided. Not “until it’s convenient.” Not “with a warning.” The IPL does not complete.

There are two supported ways to get the key there when it’s needed:

Platform Keystore (PKS). An encrypted keystore living in non-volatile memory on that specific partition’s service processor. The boot loader pulls the key from PKS automatically, no human involved. This is the convenient path, and for a normal IPL on the hardware you configured it on, it’s invisible. You won’t notice it’s there.

Remote Key Agent (RKA). A separate IBM i LPAR, not the production partition, preconfigured to hold the Save/Restore key information. An administrator connects to that LPAR and supplies the key manually during IPL. This is the path built for when PKS isn’t available or isn’t appropriate.

Read those two options again with a disaster recovery scenario in mind, because that’s exactly where they stop being interchangeable.

Where PKS quietly stops working

PKS is tied to the service processor of the specific hardware partition it was configured on. That’s the whole point, it’s a hardware-rooted keystore. It’s also the exact thing that doesn’t survive a disaster recovery event where the recovery target is different hardware: a hot site box, a replacement system after a total loss, a PowerVS instance you’re standing up because the data center is gone.

If your only configured path is PKS and you restore to different hardware, there’s no cached key waiting for the boot loader to find. You did the SAVSYS. You did the restore. Every byte landed correctly. And the system still won’t IPL, because the key that unlocks the Master keys lived in a service processor that’s sitting in a building you can’t get into anymore.

This is exactly why IBM shipped RKA as a second, independent path, and exactly why it’s worth treating as a required step rather than an optional one if you’re enabling Save/Restore BYOK in production. A Remote Key Agent, reachable from wherever your actual recovery environment is, is the thing that makes this feature survive a real DR event instead of just a planned reboot. And if you were counting on the migration tooling in the same Technology Refresh to cover you here, check that assumption: Migrate While Active keeps a synchronized target running but is explicitly not a disaster recovery product.

This also isn’t a hypothetical you can shrug off because you’ve never needed to prove it. The standard master key rule still applies, and it bites harder now: any time you change a master key, you back it up, and master keys saved through SAVSYS are themselves encrypted with the Save/Restore master key. If the Save/Restore master key on your recovery target doesn’t match the one that was active on the source system at save time, the restored master keys don’t just fail to decrypt cleanly. They land in a pending state, waiting on a resolution you now have to work out in the middle of an actual recovery, not ahead of one.

What changed in Navigator to support this

Navigator for i picked up matching updates in the Q2 2026 PTFs. Two are worth knowing about specifically. First, there’s a new requirement: on IBM i 7.6 with the PTF installed, the Save/Restore Master Key has to be set to a user-chosen value. You no longer get to leave it at an IBM-assigned default, which closes off a lazy configuration path that used to exist. Second, Navigator added a Remote Key Agent Configuration Wizard, under Cryptographic Services > Manage Master Keys, specifically to walk you through setting up the RKA path instead of leaving it as a manual CL exercise.

Both of those exist because IBM expects shops to actually configure the RKA path, not just PKS by default and call it done.

A checklist before you flip this on in production

If you’re evaluating Save/Restore BYOK for a production IBM i partition, verify these before enabling it, not after:

Confirm your DR target hardware. If you’re restoring to a hot site, a replacement partition, or a cloud target that isn’t the exact box the Save/Restore key was configured on, PKS alone will not get you through the IPL.
Configure a Remote Key Agent reachable from your actual recovery environment, not just from your primary data center. An RKA that only exists on-site is no better than PKS if the site is the thing you lost.
Test the IPL path you’ll actually use in a real DR event, on hardware that resembles the recovery target, not just on the production box where PKS makes everything look effortless.
Set the Save/Restore Master Key to a deliberate, documented value through Navigator’s new requirement, and store that value somewhere your DR plan references, not somewhere only one person remembers.
Confirm the Save/Restore master key matches between source and target before you rely on a SAVSYS-based recovery. A mismatch doesn’t fail loudly, it puts your master keys into a pending state you’ll be untangling live.
Write all of this into the DR runbook itself. A feature that changes IPL behavior belongs in the document your team follows during an actual incident, not just in the change log for the TR that introduced it.

None of this is a reason to skip BYOK. It’s a reason to treat it as a DR planning change, not a switch you flip and move on from. The PTF and security update cadence most shops already track monthly is the natural place to fold in a review of whether your key management configuration still matches your actual recovery plan, especially after any hardware change on either side.

Bottom line

BYOK via Key Protect and the tightened Save/Restore key protections in IBM i 7.6 TR2 are a legitimate security upgrade, exactly the kind of external key management compliance teams have been asking IBM i shops to produce for cloud deployments. The mistake would be treating it as a checkbox you enable and forget. IBM built two supported paths, PKS for convenience and RKA for exactly the scenario where convenience runs out, specifically so this doesn’t strand anyone. Use both. Test the one you hope to never need. If your IBM i security posture is part of a broader modernization push, the IBM i AI Field Guide covers where this kind of operational documentation fits into that work.

Frequently Asked Questions

What is bring-your-own-key (BYOK) encryption on IBM i 7.6?

It’s a native integration between IBM i Cryptographic Services and IBM Key Protect for IBM Cloud, added in IBM i 7.6 TR2. It lets you export, wrap, and manage AES keys and Master Key parts through Key Protect instead of keeping key material solely on the local system. It is not available on 7.5 or earlier.

Can enabling BYOK on IBM i actually prevent a system from IPLing?

Yes, if you configure it that way on purpose. Combining Save/Restore key protection with ASP encryption of the system ASP is documented by IBM to prevent IPL until the Save/Restore key is supplied, either automatically from the Platform Keystore or manually through a Remote Key Agent. It’s a deliberate security control, not a bug, but it changes what a clean IPL requires.

What’s the difference between Platform Keystore and Remote Key Agent for supplying the Save/Restore key?

Platform Keystore (PKS) caches the key in encrypted non-volatile memory on that specific partition’s service processor, and the boot loader retrieves it automatically. Remote Key Agent (RKA) is a separate IBM i LPAR configured to hold the key, which an administrator supplies manually during IPL. PKS is tied to that exact hardware, so it does not travel to a different box in a disaster recovery scenario unless RKA is also configured.

Does IBM Key Protect for IBM Cloud cost extra?

IBM has offered both free and paid usage tiers for Key Protect historically, along with a separate Key Protect Dedicated tier for single-tenant HSM workloads. Confirm current pricing on IBM Cloud’s own pricing page before budgeting, since tier structures change and a stale number is worse than none.