> For the complete documentation index, see [llms.txt](https://docs.envector.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.envector.io/1.5.x/key-management/managed-kms/key-rotation.md). # Key Rotation & Incident Response Procedures for rotating the KEK, periodic key-health checks, and responding to suspected key compromise. For the key hierarchy see [KMS Architecture](/1.5.x/key-management/managed-kms.md); for basic KMS operations see [Key Management Service (KMS)](/1.5.x/key-management/managed-kms/kms.md). ## KEK rotation model KEK rotation refreshes only the **wrapping layer**: the KEK version is rotated via Vault Transit and every sealed FHE SecKey / Metadata Key envelope is **rewrapped** with the new KEK version. The underlying secret keys are unchanged, so **no data re-encryption is required**. Because a container restart puts the KMS back into the sealed state, always re-run the [Unseal](/1.5.x/key-management/managed-kms/kms.md#2-unseal-required-on-every-restart) procedure after any operation that restarts the KMS. ## Pre-deployment checklist | Priority | Area | Item | | ----------- | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | | Highest | SSS storage | Isolate the SSS in air-gapped offline storage or an HSM. Confirm the SSS is not stored on or exposed to any operational server/container | | Highest | SSS access control | Document the SSS access procedure (including break-glass). Confirm an access-history logging scheme is in place | | Required | TLS/CA | No plain HTTP in production. Apply TLS/mTLS across the KMS API and Vault segments | | Required | Certificates | Issue and mount the Vault server cert/key, KMS-TEE client cert/key, and KMS API cert/key separately | | Required | CA private key | Do **not** mount the CA private key into the KMS/TEE/Vault runtime containers | | Required | Network | Do **not** publish a KMS-TEE host port. Use an internal network reachable only by KMS, TEE, and Vault | | Recommended | RBAC | Verify the OIDC `tenant_id`, role, audience, and KMS capability policy | | Recommended | Logs | Confirm secret values, tokens, sealed key bodies, and plaintext decrypt results are not logged | ## Periodic inspection | Interval | Item | | ---------------- | ------------------------------------------------------------------------------------------------ | | Every deployment | Confirm the SSS storage location and access controls are unchanged | | Every deployment | Confirm the KMS API TLS certificate, Vault CA bundle, and KMS-TEE client-certificate mount scope | | Every deployment | Confirm the KMS-TEE host port is not published | | Quarterly | Rehearse the SSS break-glass access procedure | | Quarterly | Rehearse the KEK rotation procedure and validate the rollback runbook | | Quarterly | Validate the CA replacement / certificate re-issuance procedure | | On incident | Block KEK access, stop KMS/TEE, review audit, and rotate tokens/credentials | ## Incident response ### Suspected SSS leak (highest severity) A leaked SSS puts the **entire key hierarchy** at risk. Perform the following immediately: 1. **Rewrap** all sealed FHE SecKey and Metadata Key envelopes with a new KEK. 2. **Revoke** every credential and token issued using the previous SSS. 3. Trace the breach path and exposure scope through the audit log, and assess whether the FHE SecKey plaintext could have been exposed. ### Suspected individual-key compromise 1. Check the audit log for abnormal access, permission-denied, rotation, and decrypt events. 2. If the KEK may be exposed, regenerate it and run the FHE-key re-encryption procedure. 3. If an FHE key may be exposed, move it to a **suspended** state and determine the exposure scope. 4. Rotate the affected OIDC credentials, Vault AppRole secret IDs, and TLS certificates. 5. Record the post-incident root-cause analysis and recurrence-prevention policy in the operational documentation. ## Related token & password rotation KEK/SSS rotation is separate from routine credential rotation. For operational token, refresh-token, Keycloak admin/user password, and license-token rotation cadences, see [Authentication → Token rotation](/1.5.x/operations-and-management/authentication.md#3-token-rotation). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.envector.io/1.5.x/key-management/managed-kms/key-rotation.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.