Break the identity-and-certificate dependency cycle before deploying Windows extensions

Source facts

The Windows Key Vault extension reports successful startup only after installing every configured certificate, allowing dependent extensions to wait for that point. Microsoft warns of a deadlock when the same template creates a system-assigned identity and updates Key Vault access policy using it: that policy update cannot complete until extensions start. The documented alternative is a preauthorized user-assigned identity. Version 4.x supports Windows Server 2022 and 2025, not 2019 or earlier. Microsoft Learn.

Applicability

Review templates where another extension must wait for certificates before starting. Identify the actual managed identity, the operation granting vault access, and the dependency that prevents that operation from completing. Do not generalize this documented access-policy cycle into a claim that every system-assigned identity deployment fails.

DSE recommendation

Authorize the intended user-assigned identity before deployment and review the complete certificate-dependent extension sequence for circular waits. Have the identity and deployment owners agree which prerequisite must already exist. Keep certificate-dependent applications blocked until their prerequisite is genuinely satisfied rather than removing the dependency just to obtain a successful deployment status.

Verification

In an approved test deployment, verify that the intended identity has access before the extension sequence begins. Observe certificate installation and then the dependent extension’s start. If startup remains transitioning or ends in error, inspect the certificate download evidence and authorization path before rerunning the template. Retain the dependency design and actual start order, without copying private keys or token material into the review record.

Official references

Microsoft Learn: Key Vault VM extension for Windows. Source reviewed September 9, 2026.