Initiative: Key Rotation — Customer-Visible Trigger and Status

[isanmaz]

Problem Statement

Key rotation happens automatically inside Krypton but customers have no visibility into it and cannot trigger it manually in an emergency (e.g. suspected key compromise). Rotation events are also not surfaced in a way customers can use for compliance reporting.

Business Context

Zero-downtime key rotation is a core OpenKCM differentiator. But a customer who suspects a key is compromised needs to trigger immediate rotation — not wait for the next scheduled interval. Security standards (PCI-DSS, NIST) require evidence that keys are being rotated. Without a customer-visible trigger and audit trail for rotation, OpenKCM cannot support compliance reporting for key rotation requirements.

Scope

In scope:

• Manual rotation trigger via API (immediate, outside scheduled interval)
• Rotation status queryable via API: in progress, completed, current version, previous version
• Rotation events in audit trail: triggered by, timestamp, old version, new version, cascade completion status

Out of scope:

• Rotation interval configuration UI (owned by CMK)
• Customer notification on rotation completion (owned by CMK)

Acceptance Criteria

• Manual rotation API triggers immediate new key version creation and cascading re-wrap of all child keys
• Manual rotation requires Key Admin authentication
• Rotation completes with zero downtime — existing decrypt operations continue during rotation using the previous version
• Rotation events are recorded in audit trail: who triggered it, when, which key, old version, new version
• Rotation status is queryable via API at any point during or after rotation

Success Metrics

• Manual rotation completes end-to-end (including child key re-wrap) within 30 seconds for a typical namespace
• Zero decrypt failures during rotation window