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

> Why can a template deadlock when Key Vault certificate installation waits for a newly created VM identity's access policy?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-387-break-the-identity-and-certificate-dependency-cycle-before-deploying-windows/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:25:29+00:00
- Modified: 2026-09-10T02:01:56+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 2 minutes

## What you need to know

Why can a template deadlock when Key Vault certificate installation waits for a newly created VM identity's access policy?

## Potentially affected

Windows Server 2022 or 2025 deployments using Key Vault VM extension 4.x and certificate-dependent extension ordering.

## DSE recommendation

Authorize the intended user-assigned identity before deployment and review the complete certificate-dependent extension sequence for circular waits.

## Article

## 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](https://learn.microsoft.com/en-us/azure/virtual-machines/extensions/key-vault-windows).

## 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](https://learn.microsoft.com/en-us/azure/virtual-machines/extensions/key-vault-windows). Source reviewed September 9, 2026.

## Primary reference

- Name: Azure Key Vault VM extension for Windows - Azure Virtual Machines | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/virtual-machines/extensions/key-vault-windows
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Break the identity-and-certificate dependency cycle before deploying Windows extensions,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-387-break-the-identity-and-certificate-dependency-cycle-before-deploying-windows/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.