# Match Prometheus remote-write authentication to the installed client version

> Do all supported Azure remote-write identity methods have the same minimum Prometheus version?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-208-match-prometheus-remote-write-authentication-to-the-installed-client-version/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:28:28+00:00
- Modified: 2026-09-10T01:20:45+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

Do all supported Azure remote-write identity methods have the same minimum Prometheus version?

## Potentially affected

Self-managed Prometheus clients configured to remote-write directly to an Azure Monitor workspace.

## DSE recommendation

Record the running Prometheus version and hosting environment before selecting its Azure authentication method.

## Article

## Source facts

Azure Monitor’s direct Prometheus remote-write guide sets different minimum client versions: 2.45 for user-assigned managed identity, 2.48 for Microsoft Entra application authentication, 3.5.0 for system-assigned managed identity and 3.7.0 for workload identity. Supported hosting environments also differ by method; the documented workload-identity path lists AKS and Arc-enabled Kubernetes. Microsoft recommends direct configuration when replacing its remote-write sidecar. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/metrics/prometheus-remote-write).

## Applicability

Apply this compatibility check before changing authentication on a self-managed sender. A supported identity mechanism in Azure does not establish that an older Prometheus binary or every hosting environment supports that same path.

## DSE recommendation

Record the running Prometheus version and hosting environment before selecting its Azure authentication method. Compare both with the documented requirements, then plan any needed client upgrade separately from the identity change. Preserve the current working configuration and agree how the team will identify a failed cutover. Do not substitute a credential-bearing method merely to avoid investigating a client-version mismatch.

## Verification

Confirm the version of the actual running sender, not only a proposed image tag or a workstation’s command output. Check that its selected authentication configuration matches the approved environment and method. During a bounded cutover, inspect sender errors and verify expected new samples at the intended workspace. Treat successful identity creation and successful metric ingestion as separate results, and retain unresolved compatibility failures before expanding the change.

## Official references

[Microsoft Learn: Self-managed Prometheus remote write](https://learn.microsoft.com/en-us/azure/azure-monitor/metrics/prometheus-remote-write). Source reviewed September 9, 2026.

## Primary reference

- Name: Connect self-managed Prometheus to Azure Monitor managed service for Prometheus - Azure Monitor | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/azure-monitor/metrics/prometheus-remote-write
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Match Prometheus remote-write authentication to the installed client version,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-208-match-prometheus-remote-write-authentication-to-the-installed-client-version/
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.