# Do not mistake a Log Analytics cluster link for historical re-encryption

> Does linking a workspace to a customer-key cluster change the encryption of previously ingested logs?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-207-do-not-mistake-a-log-analytics-cluster-link-for-historical-re-encryption/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:28:29+00:00
- Modified: 2026-09-10T01:20:45+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Explainer
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 2 minutes

## What you need to know

Does linking a workspace to a customer-key cluster change the encryption of previously ingested logs?

## Potentially affected

Log Analytics workspaces linked to an Azure Monitor dedicated cluster configured with a customer-managed key.

## DSE recommendation

Document the ingestion cutover as an encryption boundary rather than certifying the workspace's entire retained history under the new key.

## Article

## Source facts

After a workspace links to a dedicated Azure Monitor cluster, new records go to that cluster while earlier records remain in the prior Log Analytics cluster. Queries automatically combine both locations. If the dedicated cluster uses a customer-managed key, only the newly ingested data uses it; older data remains Microsoft-key encrypted. Queries span both encryption arrangements transparently. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/logs-dedicated-clusters).

## Applicability

Use this interpretation when an existing workspace is being linked to a customer-key cluster. The source also requires the workspace and cluster to share a region and the cluster to finish provisioning before linking. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/logs-dedicated-clusters).

## DSE recommendation

Document the ingestion cutover as an encryption boundary rather than certifying the workspace’s entire retained history under the new key. Ask the data and key owners to distinguish pre-link history from subsequent arrivals in their assurance statement. Keep that statement separate from a successful cross-period query: a unified result should not be used to infer a unified encryption history.

## Verification

Inspect the completed link and cluster key configuration, preserving the cutover evidence and the relevant ingestion periods. Query representative records across the boundary to verify operational continuity without describing that query as proof of re-encryption. Review any policy or audit statement that says all retained records use the customer key and correct its scope where needed. Do not delete or reingest historical data merely to simplify the statement; any such data-lifecycle change needs its own approved plan.

## Official references

[Microsoft Learn: Dedicated Log Analytics clusters](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/logs-dedicated-clusters). Source reviewed September 9, 2026.

## Primary reference

- Name: Azure Monitor Logs Dedicated Clusters - Azure Monitor | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/azure-monitor/logs/logs-dedicated-clusters
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Do not mistake a Log Analytics cluster link for historical re-encryption,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-207-do-not-mistake-a-log-analytics-cluster-link-for-historical-re-encryption/
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.