Azure PostgreSQL Flexible Server Cross-Tenant CMK Is GA: Setup, Limits and Key Access Risks

This is not the introduction of encryption at rest to Flexible Server. Microsoft says the service already encrypts data at rest by default with service-managed keys. CMK changes who manages the key lifecycle; cross-tenant CMK changes where that key can be held relative to the database. It does not replace controls for database access or connections in transit.

What changes for a SaaS operator and its customer​

Consider a software provider running a PostgreSQL-backed application in its own Azure tenant. Previously, the customer’s desire to keep the encryption key under its own tenant’s administration complicated that hosting model. Cross-tenant CMK gives the provider a way to run the Flexible Server while the customer controls the Key Vault or Managed HSM holding the key. That separation may help organizations assign key administration and database administration to different parties. It also means both parties must coordinate access and key changes: custody is useful only if the server can still reach the key.

Microsoft documents a multitenant Entra application and a user-assigned managed identity as the bridge across the tenant boundary. The provider creates the application and configures the managed identity as its federated credential. An administrator in the customer tenant installs the application, grants it the necessary permissions on the customer’s key store, and supplies the key identifier. The provider then uses that identity, application and identifier when provisioning the server. Granting the server identity ordinary same-tenant vault access is not, by itself, the documented cross-tenant setup.

For a new server, Microsoft’s portal procedure starts on the Security tab: select Customer-managed key, assign the user-assigned managed identity, select the multitenant application and enter the customer-tenant key identifier. Microsoft also documents Azure CLI and REST configuration paths. These are provisioning decisions, not a switch an administrator can casually flip on an existing service-managed-key server.

Check the constraints before provisioning​

• Choose the encryption mode when creating the server. Microsoft says an existing Flexible Server cannot be changed in place from service-managed keys to CMK, or changed back in place afterward. Its documented route for changing modes is a point-in-time restore to a new server configured for the desired mode.
• Keep the key store in the server’s Azure region. “Cross-tenant” removes the same-tenant requirement for this configuration; it does not remove Microsoft’s same-region CMK requirement.
• Review backup and tooling needs. Microsoft’s cross-tenant limitations say long-term retention backups are not supported and Azure PowerShell does not support this configuration. Teams that depend on either should resolve that design conflict before creating a production server.
• Treat key access as an availability dependency. Microsoft warns that a CMK server can become Inaccessible and deny connections if it loses access to its key. Permissions, key expiry, vault availability and network rules therefore belong in the operational runbook—not merely the deployment checklist.

There is one documentation wrinkle worth noting. Microsoft’s broader PostgreSQL security overview still calls cross-tenant CMK a preview scenario, while the Azure Updates entry marks it launched. That appears to be guidance lagging the release announcement, rather than a reason to describe the capability itself as still in preview. Administrators should nevertheless confirm any feature-specific constraints that matter to their deployment instead of assuming general availability removes them.

Bottom line: this release gives SaaS providers and their customers a clearer division of key custody without moving the PostgreSQL server into the customer’s tenant. The trade-off is an additional cross-tenant identity setup and a key-access dependency that both sides must be prepared to operate.