This blog explains how Microsoft's shift from the legacy Azure Diagnostics Agent to the Azure Monitor Agent fundamentally changes how VM logging is controlled and highlights how this redesign can introduce detection blind spots if security teams don't update their monitoring approach.
Following this change, a single, low-visibility API action can silently disrupt logging across multiple systems, increasing the risk of missed or misattributed security events.
We explain what changed and how to adapt.
We reported this behavior to Microsoft, who acknowledged it and are implementing changes to improve visibility, including additional VM-level logging for DCR association removal. These changes are expected to roll out by April 21. We will update this post as more details become available.
Shift from VM Extensions to DCR-based Logging
On March 31st 2026, Microsoft retired the legacy Azure Diagnostics Agent (WAD/LAD) and replaced it with the Azure Monitor Agent (AMA), shifting VM logging from VM-level extensions to centralized Data Collection Rules (DCRs) and DCR associations.
This change moves control of logging into the control plane, fundamentally altering how logging changes and disruptions appear in Azure Activity Logs.
Impact on IT and SecOps
Previously, logging changes were tied to VM extension activity. A common signal for logging-related changes was:
Microsoft.Compute/virtualMachines/extensions/write
With AMA, logging is controlled through DCRs, meaning it can be modified or removed via control-plane operations such as:
Microsoft.Insights/dataCollectionRuleAssociations/writeMicrosoft.Insights/dataCollectionRuleAssociations/deleteMicrosoft.Insights/dataCollectionRules/writeMicrosoft.Insights/dataCollectionRules/delete
In testing, removing a DCR or its association stops logging immediately. However, the expected VM extension signal is delayed by 2-2.5 hours and attributed to a Microsoft-managed identity as opposed to an actionable actor.
This introduces two risks: delayed detection and loss of attribution, breaking assumptions in existing detections.
What Happens in Practice
We tested this behavior using Azure VMs with AMA installed and creating a DCR associated with multiple VMs. Key differences were observed between Portal and API behavior:
- The Azure Portal prevents deleting a DCR with active associations.
- The API allows deleting a DCR and all associations in a single call (
deleteAssociations=true).
From a logging perspective:
- Logging stops immediately across all affected VMs.
- Only a single
Microsoft.Insights/dataCollectionRules/deleteevent was observed. - No individual association delete events are logged.
This means a single API call can disable logging across multiple VMs while generating minimal telemetry.
Detection Gaps Introduced
These behaviors create detection gaps:
- Portal and API actions generate different telemetry.
- A single API call can remove logging with minimal visibility.
- VM extension signals are delayed and cannot be attributed making them less reliable indicators.
As a result, detections relying on extension activity only may completely miss or misinterpret logging disruption.
What to Monitor Going Forward
At a minimum, defenders should expand coverage for:
Microsoft.Insights/dataCollectionRuleAssociations/delete(resource-level logging disruption)Microsoft.Insights/dataCollectionRules/delete(multi-resource impact via single action)Microsoft.Insights/dataCollectionRules/write(configuration tampering)
The Need for Resilient Coverage
This shift underscores the need for detections that remain effective despite changes in the threat landscape and the attack surface.
At Vectra AI, we updated detection coverage to prioritize DCR and DCR association events over VM extension activity before this change took effect ensuring visibility into logging disruption and actionable attribution of related defense evasion activities.
By continuously monitoring both attacker behaviors and platform changes attackers we proactively adapt our coverage ensuring customers receive up-to-date, robust and reliable coverage even as underlying telemetry and control mechanisms change.
Microsoft Communication and Follow-up
Microsoft communicated this change through a Service Health advisory tied to the retirement of the Azure Diagnostics Agent and the migration to AMA before March 31, 2026.
Microsoft announced this change through a Service Health advisory as part of the AMA migration ahead of the March 31, 2026 retirement deadline. We opened a ticket with Microsoft regarding the observed behavior and the security implications observed in testing. This was accepted by Microsoft and is being investigated with updates expected April 21st. We will update this post as guidance evolves.
Bottom Line
This is not just an agent migration. It changes where logging is controlled and how disruption occurs. Teams relying on Azure Activity Logs for detect tampering should update coverage promptly to ensure defense evasion behaviors are not missed.