Should organisations treat key management as part of the tenant configuration model?

Tenant configuration and key management are not separate control problems

Tenant design already defines who can govern, recover, rotate, and prove control over encryption material. If key handling sits outside that model, teams usually end up with incomplete ownership, inconsistent evidence, and a false assumption that server-side encryption removes customer responsibilities. In practice, the boundary has to cover the control plane and the recovery path together.

That matters because tenant settings often determine whether keys are customer-managed, provider-managed, or customer-accessible only through a wrapped workflow. A tenant model that omits those choices cannot accurately describe blast radius, recovery obligations, or who can actually restore access after rotation, compromise, or deletion.

When organisations treat encryption material as part of tenant configuration, they can reason more clearly about operational scope. The same tenant record that governs environment, region, and access should also tell you whether the tenant depends on a recovery key, a certificate chain, a signing key, or a specific encryption workflow that must be preserved during migration or incident response.

What changes when keys are part of the tenant model

The main change is ownership. Tenant configuration stops being a static provisioning record and becomes a living control boundary that includes lifecycle decisions for keys, certificates, and other secret material. That makes the tenant the right place to record whether a control is optional, mandatory, or inherited from the platform.

It also changes evidence. If key management is treated as outside the tenant, auditors and operators often have to reconstruct the control story from multiple systems, which weakens assurance. If it is embedded, the tenant view can show rotation expectations, recovery dependencies, and whether any customer-controlled encryption path exists alongside the base service encryption.

This is especially important for certificate and signing workflows, where the security consequence is not only confidentiality but also trust. A tenant that uses customer-controlled signing or encryption material needs configuration that reflects expiry, revocation, and retirement, not just access to the application itself. That is why lifecycle-oriented guidance such as NIST SP 800-57 Key Management is directly relevant to tenant governance.

How to draw the boundary in practice

The practical boundary is simple: if the tenant can influence possession, protection, rotation, recovery, or retirement of encryption material, key management belongs in the tenant model. If the tenant cannot influence any of those things, the platform may own the keys, but the tenant still needs to document that dependency and the resulting limitations.

For cloud and SaaS teams, that means the tenant record should capture at least the key ownership model, the recovery method, the rotation trigger, and the consequences of tenant deletion or offboarding. A tenant that can export, import, or wrap its own material has different operational obligations from a tenant that only consumes provider-managed encryption.

For certificates and signing keys, the same logic applies to expiry and revocation. A tenant that relies on long-lived cryptographic material needs a lifecycle process, not just an application setting. NHIMG’s Machine Identity, PKI and Certificate Lifecycle Guide and Cryptographic Key Management Guide are useful references for the lifecycle and operational controls that tenant design must surface.

When the workflow is API-driven, the same principle applies to key issuance and revocation. A tenant should expose whether API keys, token signing keys, or client-side secrets are part of its operating model, because those assets determine how quickly a tenant can be recovered or isolated after compromise. The same is true for SSH and other infrastructure credentials, where orphaned or unreconciled material creates hidden risk. See also API Key Management Guide and SSH Key and SSH Certificate Management Guide.

Risk and Threat Considerations

When key management is excluded from tenant configuration, organisations often lose the ability to prove who controls recovery material, who can rotate it, and what happens if a key or certificate is exposed. That creates a real control gap even when the underlying service remains encrypted.

Failure mechanism: The tenant model describes service access and data location, but not the cryptographic dependencies that determine recovery, rotation, or revocation. Attackers or operators can then exploit stale keys, unreconciled certificates, or forgotten signing material to retain access or break trust.

Impact: The result is weaker blast-radius control, incomplete incident response, and higher chance of lockout, impersonation, or unrecoverable data. The problem is especially severe when tenant offboarding or credential rotation is expected but not built into the control boundary.

Practitioner Guidance

What to prioritise: Put key ownership, rotation responsibility, recovery method, and offboarding handling into the tenant inventory before you rely on any encryption control claim. If the tenant cannot answer those questions, the control boundary is not complete.

What to verify: Confirm whether the tenant uses provider-managed encryption, customer-managed keys, customer-held recovery keys, or certificate-based trust, and make sure each mode has an owner and an evidence trail. If the service can encrypt data but cannot show recoverability or revocation, treat that as an operational gap.

Practitioner takeaway: The safest interpretation is that encryption is not fully governed until the tenant model explains who can create, protect, rotate, recover, and retire the material that makes the encryption usable.

Related resources from NHI Mgmt Group

• When should organisations treat an NHI as a high-priority risk?
• Should organisations treat IT asset management as part of zero trust?
• Should organisations treat AI coding tools as part of secret management?
• Should organisations treat multimodal AI as part of their identity and access model?