# Keep MSP key-reset counters increasing across recovery automation

> What must repeated MSP key-reset requests preserve when more than one recovery attempt updates the VM?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-073-keep-msp-key-reset-counters-increasing-across-recovery-automation/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:30:43+00:00
- Modified: 2026-09-10T00:35:07+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

What must repeated MSP key-reset requests preserve when more than one recovery attempt updates the VM?

## Potentially affected

Operators recovering a lost or rejected Metadata Security Protocol long-lived key on a supported Azure VM.

## DSE recommendation

Coordinate key-reset writers and record the existing counter before submitting the next value.

## Article

## Source facts

When an MSP VM loses its long-lived key, it cannot communicate with Instance Metadata Service or WireServer, and Azure cannot safely issue a replacement automatically. Microsoft documents resetting the key through KeyIncarnationId in the VM model. Repeated or automated requests must use strictly increasing values; otherwise the change might not apply. After the reset, the Guest Proxy Agent periodically retries recovery and acquires the replacement key. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machines/metadata-security-protocol/troubleshoot-guide).

## Applicability

Use this procedure only after diagnosing a key-acquisition problem through the documented agent status and logs. Keep it distinct from an eBPF, cgroup, or unsupported-image problem, which has a different recovery path in the source.

## DSE recommendation

Coordinate key-reset writers and record the existing counter before submitting the next value. Have one recovery owner control the sequence so a retry or parallel automation job does not send a stale value. Preserve the reason for the reset and the approved VM identity without recording the long-lived secret itself. Do not recycle a hard-coded counter in a reusable recovery template.

## Verification

Inspect the resulting VM-model value and then observe the agent’s status as it attempts recovery. Confirm the intended metadata-dependent operation works again, using a controlled request that does not expose credentials. Keep the accepted counter and sanitized status evidence with the incident. If the model update succeeds but the agent remains unhealthy, investigate the reported component state before issuing another reset.

## Official references

[Microsoft Learn: Troubleshoot MSP](https://learn.microsoft.com/en-us/azure/virtual-machines/metadata-security-protocol/troubleshoot-guide). Source reviewed September 9, 2026.

## Primary reference

- Name: Troubleshoot MSP - Azure Virtual Machines | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/virtual-machines/metadata-security-protocol/troubleshoot-guide
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Keep MSP key-reset counters increasing across recovery automation,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-073-keep-msp-key-reset-counters-increasing-across-recovery-automation/
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.