Most multi-tenant platforms sign things: audit entries, webhook payloads, issued tokens, exported evidence. The straightforward implementation uses one platform key for everything. It works, it is simple, and it concentrates risk in a way that becomes hard to defend as soon as a customer's security team asks the right question.
The question is: if your platform key is compromised, what can the attacker do to my records? With one key, the answer is forge anything for anyone, including records that are supposed to be evidence.
What Per-Tenant Keys Change
Blast radius. A compromised tenant key affects that tenant. The others are unaffected and can be demonstrated to be unaffected, which matters as much as the fact itself during an incident.
Meaningful verification. A tenant can verify their own records against a key associated specifically with them. With a shared key, verification only proves the platform signed it — which the tenant already assumed. With a tenant key, the verification is scoped to their own chain of custody. This is what makes an offline audit verifier useful rather than ceremonial. See tamper-evident audit logs and audit trails that hold up.
Isolation you can articulate. Cryptographic separation is a stronger statement than logical separation. For customers who ask how their data is isolated from other tenants', "different keys, and here is the verification path" is a materially better answer than a description of your query filters. It complements rather than replaces row-level isolation — see tenant isolation with row-level security.
A revocation lever. With customer-managed keys, the tenant can revoke platform access to their key. That is the difference between a policy commitment and a technical control, and it is the reason the feature exists in enterprise procurement checklists.
Substrate Options
The same key model can sit on different substrates, and the choice is about custody strength versus operational cost.
Local key material. Keys generated and stored by the platform, encrypted at rest under a master key. Simplest, fastest, and the weakest custody claim: the platform can read the private key, so every guarantee reduces to trusting the platform's own controls. Adequate for development and for low-sensitivity tenants.
Platform-managed KMS. Keys in a cloud KMS under the platform's account. Key material never leaves the KMS; signing is an API call. Meaningfully better — a database compromise does not yield keys — and it gives you audited key usage for free. Still platform-controlled: the platform can sign at will.
Customer-managed KMS (BYOK). Keys in the customer's KMS account, with the platform granted signing permission through a cross-account role. The customer can revoke that grant unilaterally, inspect key usage in their own audit log, and apply their own key policies. This is the version that changes the trust relationship rather than just the storage location.
HSM-backed. FIPS-validated hardware, either as a cloud HSM or on premises. Required by some regulated environments, and appropriate for root keys. Highest assurance, highest cost and operational rigidity.
Vault or equivalent. A transit-style secrets engine performing signing, often preferred by organizations that have standardized on it and want one control plane across clouds. Custody properties comparable to a platform-managed KMS, with the customer's own operational tooling.
A workable design supports several of these as pluggable substrates behind one interface, with the substrate chosen per tenant. Enterprise tenants get their own KMS; smaller tenants use the platform default; nothing about the application logic differs.
The Operational Cost, Honestly
Per-tenant keys with customer-controlled substrates are not free.
Latency. Every signature becomes a network call to an external KMS — single-digit to low tens of milliseconds. For audit entries written on every governed call, that is a real per-request cost. The mitigations are batching (sign a batch root rather than each entry, which fits hash-chained designs naturally) and asynchronous signing with the entry durable before it is signed.
Availability coupling. If the customer's KMS is unreachable, you cannot sign. Decide the failure mode in advance and state it: fail closed (reject operations, prioritizing integrity) or fail open with a queue (accept and sign when available, prioritizing availability). Both are defensible; an undocumented choice is not. For audit specifically, a durable queue with monitored depth is usually the right answer, because refusing to serve traffic because you cannot sign a log entry is a poor trade — provided the queue is bounded and alarmed.
Rotation multiplied. One rotation becomes N. Automate the whole sequence per tenant, and track key age per tenant as a metric so drift is visible. Manual per-tenant rotation across a large tenant base does not get completed. See key rotation for agent credentials.
Verification key distribution. Verifiers need the public half, including for retired keys, so historical records stay verifiable. Publish per-tenant public keys at a stable endpoint with clear validity ranges.
Onboarding friction. BYOK requires the customer to create a key, write a policy, and grant a cross-account role. Document it precisely, provide infrastructure-as-code templates, and validate the grant during onboarding rather than at first signature.
Revocation is real. If a customer revokes the grant, your platform stops being able to sign for them. That must degrade cleanly and visibly — an alert to both sides — rather than producing unexplained errors. Treat customer-initiated revocation as a supported operation with a defined behavior, because it is the whole point of the feature.
Scoping: Which Keys Should Be Per Tenant
Not everything benefits.
Per tenant: audit chain signing, evidence export signing, webhook payload signing, and any artifact the tenant may need to verify or present to an auditor. These are the ones where tenant-scoped custody produces a real claim.
Platform-wide: internal service-to-service tokens, TLS certificates, and platform integrity artifacts. Making these per tenant adds complexity without a corresponding claim, since the tenant is not the verifier.
Separate by purpose, not just by tenant. A tenant's audit signing key should not also sign webhooks. Purpose separation limits what a single key compromise enables and keeps rotation schedules independent.
Encryption keys for data at rest are a related but distinct feature: customer-managed encryption keys mean the customer can render their data unreadable by revoking. That is often bundled with BYOK in procurement conversations, and it has different mechanics (envelope encryption, re-encryption on rotation) than signing. Keeping the two separate in your design and in your documentation avoids over-promising.
Common questions
Does BYOK actually prevent the platform from accessing my data?
For signing keys, it prevents the platform from producing signatures once you revoke — that is a genuine control. For data confidentiality, customer-managed encryption keys prevent access to data at rest after revocation, but the platform necessarily processes plaintext while operating, so it is not a technical bar to access during normal operation. BYOK is best understood as a strong revocation and auditability lever rather than as end-to-end confidentiality. Vendors that market it as the latter are overstating it.
Is per-tenant signing worth it if we already have strong row-level isolation?
They address different questions. Row-level isolation prevents tenant A's queries from returning tenant B's data — a confidentiality control. Per-tenant signing bounds forgery and enables independent verification — an integrity control. Regulated customers increasingly ask for both, and the audit-verification story is difficult to tell convincingly without tenant-scoped keys.
What happens to old records when a tenant's key rotates?
They remain verifiable against the retired public key, which must stay published with its validity range, and the chain should record which key signed which range. This is the detail that determines whether your audit trail is durable evidence or merely current evidence — deleting retired public keys silently invalidates history.
Can I offer this without supporting every KMS?
Yes, and you should start narrow. Support one cloud KMS plus a local default, behind an interface that makes adding substrates a contained change. Most enterprise demand concentrates on the major cloud KMS offerings and Vault. Building a plugin abstraction before you have a second customer requirement usually produces the wrong abstraction.
How Praesidia approaches key custody
Praesidia signs per tenant rather than platform-wide, and supports customer-controlled keys for tenants that need the ability to revoke independently. Audit records are tamper-evident and carry an independent timestamp, so their integrity does not rest on the platform's own assertion.
Because verification uses the tenant's published public key, an audit export can be verified offline rather than by trusting a platform API — which is what makes the record useful as evidence. See compliance and audit machinery, multi-tenant organizations and membership, and the Praesidia documentation.