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

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.

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.

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. Source reviewed September 9, 2026.