Key Rotation

Encryption keys age. A mature install rotates them on a schedule, after an incident, or when an employee with access to the key provider leaves. Novantra supports rotation at three distinct layers:

1. Install keyring — the root of trust for install-level data (license, install settings, the metadata about your organizations).
2. Organization keyring — one per organization, holds the keys that encrypt that organization’s data.
3. Customer-managed wrapping keys (BYOK) — when an organization uses Self Managed Secret Keys, the key in your KMS that wraps the organization keyring.

Each layer is rotated differently. Each has its own evidence and its own failure modes.

Key management lives under System → Key management in the system console; per-organization key management lives under Settings → Security → Key management inside each workspace.

The two-part model behind rotation

Before getting into procedures, the mental model matters. Novantra uses envelope encryption:

• Data is encrypted with a data encryption key (DEK) that lives close to the data.
• That DEK is itself encrypted (“wrapped”) by a wrapping key that lives in your key provider.

This means there are two distinct rotation operations:

• Rotate the wrapping key in your provider. Fast. Doesn’t re-encrypt any data; just changes which key wraps the DEK.
• Rotate the DEK itself. Slow. Re-encrypts the data that was protected by the old DEK.

Most “rotation” you’ll do day to day is wrapping-key rotation. DEK rotation is reserved for incident response.

Install keyring rotation

The install keyring protects install-level state (license metadata, install settings). It’s wrapped by the install-level key provider you configured during installation (Vault Transit, PKCS#11 HSM, AWS KMS, Azure Key Vault).

Rotate the install wrapping key

In your provider:

1. Rotate the install’s wrapping key version using your provider’s own mechanism (e.g., vault write -force transit/keys/<name>/rotate, or AWS KMS automatic annual rotation).
2. The new key version becomes active in the provider.
3. From System → Key management → Install keyring, click Refresh. The system fetches the new active key version and uses it for all subsequent wrap operations. Older key versions remain available for unwrap (so existing wrapped DEKs continue to work).

Old key versions are not retired automatically. You decide when to retire (and that’s a separate, deliberate action on your provider).

Rotate the install DEK (rewrap install data)

Rarely needed in normal operation; appropriate after a security event suggests the DEK itself may have been exposed (extremely uncommon — DEKs live in memory only during operations).

This is a break-glass operation:

1. From System → Key management → Install keyring, click Plan rewrap.
2. The system shows a dry-run estimate (size of affected data, time estimate).
3. Approve. Provide a reason. Live rewrap runs as a background job; the install remains available throughout.
4. When complete, an operation-ledger entry records the rotation with full evidence.

Organization keyring rotation

Each organization has its own keyring. By default, organization keys are wrapped by the install keyring; if the organization has Self Managed Secret Keys enabled, they are wrapped by the customer KMS instead.

Rotate the organization wrapping key

If the organization uses the install keyring (default), rotating it follows install keyring rotation above.

If the organization uses BYOK (its own KMS), rotation is done in the customer’s KMS:

You do not need to touch Novantra after rotating the wrapping key on your side. The next operation that needs to wrap data uses the current active key version.

Rotate the organization DEK (rewrap org data)

A serious operation. Rewrapping an organization’s data:

1. From the workspace, Settings → Security → Key management → Plan rewrap.
2. The system shows the scope (databases, artifact metadata, audit chain, etc.) and a dry-run estimate.
3. Approve with a reason. Live rewrap runs in the background.
4. During the run, members can continue to use the workspace. Performance may be measurably affected for large organizations.
5. Operation-ledger evidence records the rotation.

BYOK provider rotation

Two separate questions about a BYOK organization:

• “How do I rotate the wrapping key version inside my KMS?” That’s a normal operation in your provider; Novantra observes the new version automatically.
• “How do I change which KMS key Novantra uses entirely?” That’s a re-keying migration: pointing Novantra at a different external key.

For the second case:

1. The organization’s Self Managed Secret Keys flow already requires dry-run activation before a live change.
2. Re-keying to a new external key follows the same dry-run → live activation pattern.
3. After a successful re-key, the old wrapping key in your KMS is no longer used and can be retired according to your KMS’s own retirement procedure.

You can never re-key an organization that has data wrapped by a currently-unreachable provider. You must restore access to the old key first, perform the re-key with both old and new reachable, and only then disable the old.

Break-glass procedures

Two break-glass operations are exposed for incident response:

• break-glass/open — temporarily disables the fail-closed behavior on a specific key provider check. Used when a confirmed false positive blocks an active incident response. Time-bounded.
• break-glass/close — re-enables normal behavior.

Every open and close is recorded in the operation ledger with the actor, the reason, and the duration. Use these only under documented incident procedures; they intentionally produce loud evidence.

What customer-managed providers can and cannot do

A clarification because it comes up often:

• AWS KMS keys are non-exportable. You cannot extract the key material to use elsewhere. Rotation is in-AWS only.
• Azure Key Vault keys are likewise non-exportable in their normal mode.
• Vault Transit keys are non-exportable by default; can be made exportable, but should not be for Novantra’s use case.
• PKCS#11 HSM keys are non-exportable, by definition of the standard.

This means you cannot move a Sovereign install from one provider to another by “copying the key.” Provider migration is a re-keying migration: a new key in the destination provider, dry-run, live re-key, retire the old key.

Fail-closed during rotation

A note on what happens if your provider becomes unreachable during rotation:

• Wrapping-key rotation: the next wrap call uses the new key version. If the provider is unreachable, the call fails and is retried. No data is corrupted.
• DEK rewrap (data re-encryption): if the provider becomes unreachable mid-run, the rewrap pauses. Already-rewrapped data is fine; remaining data is still wrapped with the old DEK. The run resumes when provider access is restored.

At no point will Novantra “fall back” to platform-managed keys to keep the rewrap moving. That would break the custody promise.

Rotation schedules

There is no built-in rotation timer that forces wrapping-key rotation on a calendar. The expectation is:

• Customer KMS automatic rotation (AWS KMS, Azure Key Vault) is the recommended approach for BYOK organizations. Set it once.
• The install-level wrapping key follows your organization’s own cryptographic policy.
• DEK rewrap is incident-driven, not calendar-driven.

If your security team requires evidence of regular rotation, the operation ledger has it — every rotation event is recorded with a verifiable timestamp.

Related

• Self Managed Secret Keys — BYOK activation, prerequisites, and fail-closed behavior.
• Backup & Restore — why key custody is part of the backup story.
• Health & Monitoring — key-provider drift surfaces here.