Self Managed Secret Keys

Self Managed Secret Keys (sometimes called “bring your own key” or BYOK in the industry) puts the encryption key that protects your workspace into your key management service rather than Novantra’s. Your AWS KMS key or your Azure Key Vault key becomes the root of trust for everything sensitive in your organization’s data.

If you disable that key in your account, your workspace becomes unreadable, even to Novantra. That is the point.

What it is

Novantra always encrypts your data. By default, the master key used for that encryption is held inside Novantra’s own key management. With Self Managed Secret Keys turned on, that master key role is delegated to a key you own in your cloud provider’s key service:

AWS KMS (Customer Managed Key)
Azure Key Vault (key)

Novantra never holds a usable copy of that key. Every time your data is encrypted or decrypted, Novantra has to ask your KMS to do it for us. You see every one of those requests in your own provider’s audit log, and you can cut them off at any time.

Why use it

Cryptographic control. Your security team holds the off-switch. Revoke our access to your key and our access to your encrypted data ends with it, immediately.
Compliance and audit. Many regulated environments (financial services, healthcare, government) require encryption keys for customer data to be held by the customer. Self Managed Secret Keys satisfies that requirement directly.
Separation of duties. Anyone who could view your data inside Novantra would also need cooperation from your provider account to decrypt it. The two privileges live in two different systems run by two different teams.
Provider-side audit trail. Every wrap/unwrap operation appears in your CloudTrail or Azure Activity Log. You have a clean, independent record of when your data was accessed for cryptographic operations.
Defense against subpoena and insider risk. A request made to Novantra cannot be fulfilled without your provider also fulfilling its part.

What you provide

You need three things on your side before activation:

A key. One Customer Managed Key in AWS KMS, or one key in an Azure Key Vault. The key stays in a region you choose, in your account.
An identity Novantra can use. Either:
- an AWS role we can assume (recommended), or an approved credential reference;
- an Azure app registration or managed identity (recommended), or an approved credential reference.
The minimum permissions on that identity to wrap and unwrap data using that key. Nothing more. We do not need permission to read your other keys, list your vault contents, or change policy.

You do not need to send Novantra raw key material. We do not want it, and our system is designed to reject it: even if you tried to share the actual key bytes with us, we have no place to store them.

AWS KMS prerequisites

Your runbook covering this customer should list:

The customer-owned KMS key or alias.
The Novantra principal or role allowed by the key policy.
The minimum cryptographic actions allowed (the ones Novantra needs to wrap and unwrap your master key envelope).
Key region and residency.
Any key policy conditions you require (for example external ID).
That CloudTrail (or equivalent) gives you visibility into every call we make.
Your own internal process for planned key disablement, deletion scheduling, and rotation.

Azure Key Vault prerequisites

Your runbook covering this customer should list:

The customer-owned vault and key.
The Novantra app, principal, or managed identity allowed.
The minimum cryptographic permissions on the key.
Vault region and residency.
Your expectations around soft-delete and purge-protection.
That Azure Activity Logs give you visibility into every call we make.
Your own internal process for planned key disablement, deletion, and rotation.

How activation works

Activation is deliberate and broken into stages so that you can stop before anything changes:

Commercial approval. Self Managed Secret Keys is an enterprise capability. Your account is granted the entitlement through the commercial process: nobody at your organization can flip it on from inside the product UI, and nobody at Novantra can flip it on through a back door. Every grant ties back to an order or written approval.
Provider setup. Once entitled, your workspace exposes a key-management settings page. Your admin enters the provider, region, key identifier, and the credential reference for Novantra’s access.
Verification. Novantra runs a verification probe against your provider using that credential. It confirms we can reach the key and perform the wrap/unwrap operations needed. Failures come back redacted. Raw provider errors, secrets, or tokens are never returned to anyone, including support.
Dry-run activation. You launch activation with dry-run explicitly checked. Nothing changes. You and Novantra’s support team review the operation ledger together: the right organization, the right key, the right provider, and zero actual mutation.
Live activation. Only after a clean dry-run does live activation happen, and it requires explicit customer approval. The system records the operation. The customer-side audit log shows the wrap calls. The workspace key is now wrapped by your provider.
Handoff. Final state, your escalation contacts, and your runbook references are recorded for support.

What happens day to day

Once activated, you typically do not interact with this feature at all. Your data continues to be encrypted, your workspace works as normal, and your provider sees a steady stream of wrap/unwrap calls in its audit log.

You can rotate the key on your side following your own policy. If you disable the key, schedule it for deletion, or change its access policy in a way that revokes Novantra’s access, the system will detect that on the next operation and behave as described below.

Fail closed behavior

If your KMS key, credentials, or network path to your provider becomes unavailable, Novantra will not fall back to platform-managed keys. Your workspace will fail closed.

This is the whole point of the feature. The promise of Self Managed Secret Keys is that you hold the key. If we silently switched to a Novantra-held key during an outage of yours, we would have broken that promise without you knowing.

When the provider is unreachable:

Reads and writes against encrypted data stop working for your organization.
The status page shows a degraded posture.
A security event is recorded with sanitized evidence.
Your support team is notified through the operational incident path if there is service impact.

As soon as your provider access is restored, operations resume automatically. Nothing needs to be re-encrypted.

When things go wrong: recovery paths

There are three legitimate ways out of a fail-closed situation. Support will help you walk through whichever applies.

Path A: restore your provider access

This is by far the most common path. Causes are usually:

The key was disabled or scheduled for deletion.
A key policy or access policy was changed.
A credential reference expired or rotated incorrectly.
A role, principal, app registration, or managed identity lost its permission.
A firewall, private endpoint, or DNS rule started blocking the call.
A regional outage in AWS or Azure.

You fix the cause on your side. Novantra re-runs verification. The system returns to normal.

Path B: approved offboarding back to platform-managed keys

If you decide to stop using Self Managed Secret Keys (a major change), it has to be done explicitly, with approvals on both sides, and only while your provider is still reachable so the active key material can be unwrapped one final time and rewrapped under a Novantra-managed key.

This is never an emergency shortcut. If your provider is completely unavailable and the key cannot be unwrapped, the data wrapped under it generally cannot be safely moved. You will need to restore provider access first.

Path C: wait out a cloud provider outage

If the cause is an AWS or Azure regional incident rather than something in your account, the right action is usually to wait. Support will keep the incident open, monitor provider status, and verify recovery once the provider comes back. We will not bypass your key control as a “workaround.”

What Novantra will and will not do

We will:

Encrypt everything we always encrypt, using your key as the root of trust.
Show you sanitized, useful errors when something is wrong.
Detect drift in your provider access automatically and surface it.
Keep a tamper-evident record of activation, verification, and incident evidence.

We will not:

Hold a usable copy of your key.
Fall back to platform-managed keys to keep service running.
Accept raw key material from you in tickets, email, or any other channel.
Log raw provider error details that might leak sensitive information.
Edit key-version records by hand to “unblock” an incident.

What’s not included in v1

Key providers other than AWS KMS and Azure Key Vault.
Connecting to your provider over private link, VPN, or VPC peering.
Automatic entitlement grants from inside the product.
Automatic offboarding back to platform keys without explicit approval.

Self Managed Storage — keep your files in a storage bucket you own. Works independently from this feature, but the two are often turned on together for a consistent custody story.