Azure Database for PostgreSQL – Flexible Server entered Inaccessible state as it has lost its access to the customer-managed key in Azure Key Vault.

Restore the PostgreSQL Flexible Server’s configured managed identity access to the exact customer-managed key, then allow up to 60 minutes for key revalidation and the automatic transition from Inaccessible to Ready.^1^

1. Identify what interrupted key access

In the Azure portal:

1. Open the affected Azure Database for PostgreSQL flexible server.
2. Select Security → Data encryption.
3. Record:
   • The user-assigned managed identity.
   • The primary encryption key and Key Vault.
   • The backup identity and key, if geo-redundant backup is enabled.
4. Check the server’s Activity log and Resource health around the time it became inaccessible.

A CMK-protected server needs continuous access to its encryption key. It becomes inaccessible when the key is disabled, deleted, expired, unreachable, or its vault permissions, identity, or network access have changed.^1^

2. Restore the identity’s Key Vault permissions

First check Key Vault → Settings → Access configuration to determine which permission model the vault uses.

If the vault uses Azure RBAC

1. Open Key Vault → Access control (IAM).
2. Select Add → Add role assignment.
3. Assign Key Vault Crypto Service Encryption User to the exact user-assigned managed identity recorded above.
4. Scope the assignment to the vault, unless your access design intentionally uses a narrower scope.

That role allows reading key metadata and performing wrap/unwrap operations. Key Vault Contributor is insufficient, because it grants control-plane management but not access to keys in the data plane.^2^

If the vault uses legacy access policies

Open Key Vault → Access policies, select or add the server’s managed identity, and grant these key permissions:

• Get
• List
• Wrap Key
• Unwrap Key

An exact PostgreSQL Flexible Server case recovered after these permissions were restored and the service reconciled its configuration.^3^

3. Validate the key and Key Vault

Correct whichever condition applies:

• Key disabled: Enable it.
• Key expired: Extend its expiry. Wait until the server returns to Ready before rotating it or changing the server to another key.
• Key deleted: In the vault, select Keys → Manage deleted keys, recover the key, and ensure it is enabled.
• Vault deleted: Open the Key vaults service, select Manage deleted vaults, choose the subscription and vault, and select Recover. Recovery requires the relevant permissions and is possible only while the resource remains recoverable under soft delete.^4^
• Key rotated: If PostgreSQL references a version-specific key URI, update the server to the new version. For future rotations, a versionless URI enables automatic key-version updates.
• Firewall changed: Configure the Key Vault network settings to permit the server’s access. When using restrictive firewall rules, enable Allow trusted Microsoft services to bypass this firewall.^1^

Do not purge a deleted vault or key; purging is permanent.

4. If the managed identity was deleted or must be replaced

Restoring an identity is preferable because it preserves the original identity object. Creating another identity with the same name does not recreate the deleted identity.

If recovery is not possible:

1. Create a new user-assigned managed identity.
2. Grant it the Key Vault role or legacy key permissions described above.
3. Open the PostgreSQL server’s Security → Data encryption page.
4. Select the new identity and the existing encryption key, then save.

The server configuration must explicitly reference the replacement identity.^1^ The portal supports changing both the identity and encryption-key reference on an existing CMK-configured server.^5^

The equivalent CLI pattern is:

az postgres flexible-server update \
  --resource-group <resource-group> \
  --name <server-name> \
  --identity <managed-identity-resource-id> \
  --key <key-resource-id>

Both --identity and --key must be supplied together, even if only one reference is changing.^5^

5. Confirm recovery

After correcting access:

1. Wait up to 60 minutes for periodic key revalidation.
2. Confirm the server state changes to Ready.
3. Test a database connection.
4. If it remains Inaccessible after the key, identity, permissions, and networking are valid, open an Azure support request and include the server resource ID, timestamp of the failure, Activity Log events, Key Vault name, key URI/version, and managed identity resource ID.

For prevention, enable Key Vault soft delete and purge protection, retain old key versions for at least two hours during rotation, use automatic key-version updates, and configure Resource Health/Activity Log alerts for loss of CMK access.^1^

References

1. Data encryption at rest in Azure Database for PostgreSQL flexible server
2. Provide access to Key Vault keys, certificates, and secrets with Azure role-based access control
3. The postgreSQL Flexi 17.9 Azure database is in inaccessible state. How to we change its state to ready? - Microsoft Q&A
4. Azure Key Vault recovery management with soft delete and purge protection
5. Configure data encryption in Azure Database for PostgreSQL flexible server