New Project

Błażej Pawlak

03 Sep 2017 • 7 min read

Editor's note (2026-05-11): this began life as a short September-2017 note about a project we were just starting. The body below is roughly as it stood at the time. The "Update" sections near the bottom are later additions — 2022, when IBM rebranded the product and we moved our work over with it, and 2023, when the IBM Cloud edition won a Red Dot Design Award.

We've been hard at work on a new project; bringing key management and insights to pervasive encryption.

What pervasive encryption actually changes

The premise of pervasive encryption is straightforward and somewhat overdue: instead of asking application developers to remember to encrypt particular fields, particular tables, particular files, the platform encrypts everything at rest by default. The IBM z14 announcement earlier this year is the most visible recent move in that direction — hardware-level encryption with the goal of "encrypt everything, all the time" — and on IBM Z, pervasive encryption is the official name for that capability.

When encryption stops being an application concern and becomes a default behaviour of the platform, the bottleneck moves. The question stops being "did we encrypt this?" and becomes:

which keys protect what?
who can use them, and under which controls?
when were they last rotated, and against what policy?
what would happen if any of them went missing?
how would we even notice?

Key management has always mattered. It now matters in a different way. The crypto primitives are no longer the hard part. The lifecycle, the visibility, and the audit trail are.

One of the more interesting practical consequences of pervasive encryption is that it changes who has access to what. Storage administrators need access to the encrypted data sets to do their jobs, but they explicitly should not have access to the keys that would let them decrypt that data. The platform makes that separation enforceable; the key management layer has to make it operable.

What we're building: EKMF Web

That's the gap we're working on.

The product the work is anchored in is IBM Enterprise Key Management Foundation — Web Edition, or EKMF Web for short. It's the piece that sits next to z/OS and orchestrates the keys that pervasive encryption depends on: a central repository, a UI, and an agent per z/OS system so that one team can manage data set encryption keys across the whole estate from one place rather than logging into each LPAR.

What EKMF Web brings to the table, and what we've been digging into:

A central key repository. Every key, with its metadata — activation dates, last-used timestamps, rotation policy, what it protects. Not just a list of opaque labels.
Policy-driven generation via key templates. Keys are generated by parameterised templates rather than by hand. New keys come out matching policy by construction, not by reviewer vigilance.
Centralised management across multiple z/OS systems. An EKMF Web instance with an agent on each managed system, so the team running encryption sees one console instead of one per LPAR.
Role-based access control. Who can request a key, who can rotate one, who can sign off on a destroy operation — separated cleanly, so the storage-admin / key-custodian split that pervasive encryption needs is actually enforceable.

The "insights" part of the work — the bit we're spending most of our time on — is about turning that key store from a black box into something the people accountable for the data can actually reason about. Where the keys live, what they protect, how they relate to applications and to each other, what's drifted from policy, and what risks are sitting in the corners that nobody's looked at recently.

There's a lot still to figure out — the data model, the integration points, the harder problems around access policy — and we'll write more about specific pieces as we go.

Update: EKMF Web became Unified Key Orchestrator

Five years after the original note, the product name changed.

IBM Enterprise Key Management Foundation - Web Edition, usually referred to as EKMF Web, is now Unified Key Orchestrator for IBM z/OS. IBM's current product page says it plainly: "Unified Key Orchestrator for IBM z/OS, formerly IBM Enterprise Key Management Foundation-Web Edition."

That rename is the small part of the story.

The more interesting part is that the product scope grew.

EKMF Web was mainly about making key management for IBM Z and z/OS data set encryption usable from a web interface. Unified Key Orchestrator keeps that lineage, but reframes the problem as enterprise key orchestration across on-premises and multicloud environments.

That is a bigger shift than the name suggests.

From key management to key orchestration

In the EKMF Web era, the problem was mostly local and operational:

How do we make the key store understandable and manageable for the people responsible for z/OS encryption?

With UKO, the problem becomes broader:

How do we govern key lifecycle consistently across IBM Z, on-premises systems, and multiple cloud key managers?

The UKO line now covers several related offerings.

Unified Key Orchestrator for IBM z/OS is the direct successor to EKMF Web. It centralizes and secures the lifecycle of encryption keys across enterprise environments, including IBM Cloud, AWS KMS, Azure Key Vault, and Google Cloud.

IBM also introduced Unified Key Orchestrator inside IBM Cloud Hyper Protect Crypto Services, announced in March 2022 as a managed multicloud key management capability.

Later, IBM introduced Unified Key Orchestrator for Containers, aimed at centralized key lifecycle management across hybrid and multicloud environments from a containerized deployment model.

Those are not just packaging differences. They reflect a real change in the operating model.

The old question was:

Where are the keys?

The newer question is:

Who controls the keys, under which policy, across which environments, and with what audit trail?

What UKO adds to the original EKMF Web model

The original EKMF Web job was already important: make z/OS encryption key management more visible, more controlled, and less dependent on specialist-only workflows.

UKO extends that model in several directions.

First, it supports centralized orchestration across multiple key stores. The security team does not need to treat every cloud KMS as a completely separate universe with its own vocabulary, workflow, and audit story.

Second, it formalizes operational controls that auditors care about:

role-based access;
separation of duties;
dual-control style workflows;
vault-level isolation;
policy-driven key templates;
lifecycle operations such as generation, distribution, rotation, revocation, and destruction.

Third, in the IBM Z and LinuxONE deployment model, the trust anchor remains hardware crypto. Key generation and protection can be tied to Crypto Express HSMs and policy-defined templates, rather than becoming a loose collection of software-managed secrets.

Fourth, there is an API-driven operating model.

That matters.

Key management cannot remain a console-only activity once encryption becomes part of platform engineering, CI/CD, and compliance evidence. At some point, the lifecycle has to be automated. Keys need to be created, rotated, distributed, revoked, and reported on from controlled workflows.

A REST API is not a nice extra here. It is what makes the system usable from pipelines and higher-level governance tooling.

What changed for us

For us, the practical effect was that the work we had been doing on top of EKMF Web transitioned to UKO.

The codebase moved. The integration points moved. Some of the product language changed.

But the underlying problem stayed the same:

Make the key store legible to the humans who are accountable for it.

That was the problem in 2017, and it is still the problem now.

The product around it has grown up. The orchestration layer is now first-class. It covers more environments, more workflows, and more of the key lifecycle.

The layer we still care about sits above that:

policy drift across environments;
cross-cloud risk reporting;
human-readable audit narratives;
evidence that explains not only what happened, but whether it should have happened;
visibility for teams that are accountable for encryption but do not live inside the key manager every day.

That is where the next useful work is.

UKO gives the organization a stronger control plane for cryptographic key lifecycle management.

The next step is making that control plane understandable, reviewable, and operationally safe for the people who have to sign their names under the audit.

Update (2023): UKO's interface won a Red Dot

A nice bit of news from a year later: Unified Key Orchestrator within IBM Cloud Hyper Protect Crypto Services won a Red Dot Award: Brands & Communication Design 2023 in the Interface Design category.

In plain English, this is the IBM Cloud edition of UKO: Unified Key Orchestrator sitting inside IBM Cloud Hyper Protect Crypto Services.

IBM Design wrote up the award and described the work as a team sport, with contributors across design, engineering, product, and architecture. The core design problem was exactly the one that makes UKO interesting in the first place: turning multi-cloud key management into a single, navigable mental model.

That is not a small thing.

Every cloud provider has its own key-management vocabulary, lifecycle, defaults, constraints, and sharp edges. Pulling that into one interface is not just a UI exercise. It is product architecture made visible.

The IBM Design write-up also included a customer quote that is hard not to enjoy:

"Unified Key Orchestrator is the sexiest solution on the market."

Not a sentence I expected to read about a key management product in this lifetime.

A note on credit: the Red Dot award is specifically for the interface design. That recognition belongs to IBM's design team and the broader product team that shaped the experience.

That is not our work.

What is our work is part of the engineering underneath the UKO story: the platform surfaces, integration points, and lifecycle operations that an interface like this eventually drives and makes legible.

It is a good feeling to see that kind of underlying work end up inside something the design world can recognize. Infrastructure work does not often get the spotlight, even indirectly. Most of the time, if it works, nobody notices. Glamorous career choice. Excellent for posture.

The original 2017 bet was that the orchestration layer above pervasive encryption would matter more once encryption became everywhere.

Five years later, IBM had turned that orchestration layer into a named product line.

Six years later, Red Dot recognized the interface work around it.

I will take that as a decent signal that the original instinct was not completely mad.