{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-207-do-not-mistake-a-log-analytics-cluster-link-for-historical-re-encryption/", "item": { "id": "https://update.dsesecurity.com/updates/dse-20260909-207-do-not-mistake-a-log-analytics-cluster-link-for-historical-re-encryption/", "slug": "dse-20260909-207-do-not-mistake-a-log-analytics-cluster-link-for-historical-re-encryption", "url": "https://update.dsesecurity.com/updates/dse-20260909-207-do-not-mistake-a-log-analytics-cluster-link-for-historical-re-encryption/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-207-do-not-mistake-a-log-analytics-cluster-link-for-historical-re-encryption.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-207-do-not-mistake-a-log-analytics-cluster-link-for-historical-re-encryption/" }, "title": "Do not mistake a Log Analytics cluster link for historical re-encryption", "summary": "Does linking a workspace to a customer-key cluster change the encryption of previously ingested logs?", "format": { "slug": "explainer", "name": "Explainer" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:28:29+00:00", "modified_at": "2026-09-10T01:20:45+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 248, "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.", "primary_source": { "name": "Azure Monitor Logs Dedicated Clusters - Azure Monitor | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/azure-monitor/logs/logs-dedicated-clusters", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Source facts

\n

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.

\n

Applicability

\n

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.

\n

DSE recommendation

\n

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.

\n

Verification

\n

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.

\n

Official references

\n

Microsoft Learn: Dedicated Log Analytics clusters. Source reviewed September 9, 2026.

", "content_text": "Source facts\nAfter 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.\nApplicability\nUse 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.\nDSE recommendation\nDocument 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.\nVerification\nInspect 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.\nOfficial references\nMicrosoft Learn: Dedicated Log Analytics clusters. Source reviewed September 9, 2026.", "content_markdown": "## Source facts\n\nAfter 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).\n\n## Applicability\n\nUse 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).\n\n## DSE recommendation\n\nDocument 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.\n\n## Verification\n\nInspect 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.\n\n## Official references\n\n[Microsoft Learn: Dedicated Log Analytics clusters](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/logs-dedicated-clusters). Source reviewed September 9, 2026." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/dse-20260909-207-do-not-mistake-a-log-analytics-cluster-link-for-historical-re-encryption/", "url": "https://update.dsesecurity.com/updates/dse-20260909-207-do-not-mistake-a-log-analytics-cluster-link-for-historical-re-encryption/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-09-09" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/dse-20260909-207-do-not-mistake-a-log-analytics-cluster-link-for-historical-re-encryption/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Do not mistake a Log Analytics cluster link for historical re-encryption", "item": "https://update.dsesecurity.com/updates/dse-20260909-207-do-not-mistake-a-log-analytics-cluster-link-for-historical-re-encryption/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/dse-20260909-207-do-not-mistake-a-log-analytics-cluster-link-for-historical-re-encryption/#article", "identifier": "https://update.dsesecurity.com/updates/dse-20260909-207-do-not-mistake-a-log-analytics-cluster-link-for-historical-re-encryption/", "url": "https://update.dsesecurity.com/updates/dse-20260909-207-do-not-mistake-a-log-analytics-cluster-link-for-historical-re-encryption/", "headline": "Do not mistake a Log Analytics cluster link for historical re-encryption", "description": "Does linking a workspace to a customer-key cluster change the encryption of previously ingested logs?", "abstract": "Does linking a workspace to a customer-key cluster change the encryption of previously ingested logs?", "articleBody": "Source facts\nAfter 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.\nApplicability\nUse 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.\nDSE recommendation\nDocument 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.\nVerification\nInspect 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.\nOfficial references\nMicrosoft Learn: Dedicated Log Analytics clusters. Source reviewed September 9, 2026.", "datePublished": "2026-09-10T00:28:29+00:00", "dateModified": "2026-09-10T01:20:45+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/dse-20260909-207-do-not-mistake-a-log-analytics-cluster-link-for-historical-re-encryption/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/dse-20260909-207-do-not-mistake-a-log-analytics-cluster-link-for-historical-re-encryption/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Do not mistake a Log Analytics cluster link for historical re-encryption" }, "articleSection": [ "Cybersecurity", "IT" ], "keywords": [ "Cybersecurity", "IT", "Explainer", "Information priority" ], "genre": "Explainer", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 248, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Azure Monitor Logs Dedicated Clusters - Azure Monitor | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/azure-monitor/logs/logs-dedicated-clusters" } } ] } }