Initiative: OpenKCM on Platform Mesh — Customer-Managed Encryption

[isanmaz]

Problem Statement

Customers deploying services on Platform Mesh have no way to govern the encryption of their own data. They cannot register their own encryption keys, cannot revoke data access in an emergency, and have no visibility into which services are encrypting their data and which are not. The platform provider holds all encryption control — the customer has none.

Business Context

Data sovereignty is becoming a procurement requirement across regulated industries — banking, healthcare, public sector, and government. Customers are increasingly required to demonstrate that they — not the platform operator — control access to their own data. Without customer-managed encryption, Platform Mesh cannot serve these customers.

OpenKCM addresses this by giving customers a single control point: they register their own root key (from any keystore they already use — AWS KMS, Azure Key Vault, an HSM, or OpenBao), assign it to their workloads, and get a cryptographic kill switch. Disabling their key makes all their data instantly inaccessible — with no action required from the platform operator.

This initiative covers the integration of OpenKCM into Platform Mesh as a marketplace service — enabling customers to activate customer-managed encryption from their account, register their key, and govern it from a dedicated UI.

Scope

In scope:

• Customer activates OpenKCM from the Platform Mesh marketplace — account-level enablement
• Customer registers their root key (L1) from their external keystore via the OpenKCM UI
• Customer can see which services and workloads are protected under their key
• Customer can trigger the kill switch — instantly revoke access to all data under their key
• OpenKCM advertises supported regions via Platform Mesh so customers can select where their keys are served
• Tenant lifecycle — safe handling of key material when a customer deletes their account or disables OpenKCM

Out of scope:

• Internal key hierarchy management (L2, L3, L4) — these are operational keys managed by the platform and service providers, not the customer
• Service provider integration with Krypton — covered by separate initiative
• Multi-party approval for kill switch — covered by four-eyes initiative
• Multi-region deployment — covered by separate initiative

Acceptance Criteria

• A customer can enable OpenKCM from the Platform Mesh marketplace without any manual infrastructure setup
• A customer can register their root key from at least one supported external keystore (OpenBao for September demo; AWS KMS, Azure Key Vault as follow-on)
• A customer can see a list of workloads/services assigned to their key in the OpenKCM UI
• A customer can trigger a kill switch — disabling their root key makes all assigned workloads inaccessible within 5 seconds
• If a customer deletes their account, key material is not immediately destroyed — a grace period applies before garbage collection
• OpenKCM regions are discoverable via Platform Mesh — a customer ordering a service in a supported region is automatically routed to the correct Krypton deployment

Success Metrics

• Customer can complete the full journey (enable → register key → assign workload → verify encryption) without engineering support
• Kill switch executes and cascades within 5 seconds of L1 revocation
• Zero key material lost due to accidental account deletion during grace period
• September 2026 demo: end-to-end MongoDB encryption with customer-controlled kill switch demonstrated on Platform Mesh showroom