For IT teams, the useful question is not whether the announcement contains enough Microsoft product names. It certainly does. The question is which recovery gaps the changes address—and what administrators still need to validate before trusting them during an incident.
Azure protection expands beyond virtual machines
Cohesity says its expanded Azure coverage includes Blob Storage, Azure Data Lake Storage and Azure Kubernetes Service. For Kubernetes, it specifies application-consistent backups and granular restoration of Kubernetes resources. Azure Government additions cover Azure SQL Database, SQL Managed Instance, PostgreSQL, MySQL, Table Storage and Cosmos DB.
Those are concrete workload additions, but the announcement does not supply a compatibility matrix, configuration requirements or recovery-time measurements. Nor does the Azure Government coverage establish authorization for a particular regulated deployment. Administrators should request workload-specific support details rather than treating the service list as a universal compatibility guarantee.
A sensible evaluation would test the application’s recovery outcome, not merely whether a backup job turns green. For a Kubernetes workload, for example, ask the vendor to demonstrate exactly which application components and dependencies its application-consistency claim covers.
GitHub and Azure DevOps protection enters preview
The developer-focused preview covers GitHub repositories and Azure DevOps organizations. Cohesity specifically names pull requests, boards, wikis and pipelines, alongside flexible recovery and an isolated, immutable copy. It does not provide a final release date or preview enrollment instructions in the announcement.
That distinction deserves a prominent place in any procurement discussion. Evaluate the preview against a representative development environment, and make the acceptance criteria explicit:
- Which assets are restored, and which require reconstruction?
- Are permissions, relationships and pipeline dependencies preserved?
- Can recovery target an isolated environment?
- What operational limits apply during preview?
These are evaluation questions, not capabilities established by the announcement. A successful repository restore should not automatically count as a successful development-platform recovery.
Microsoft 365: retained content matters too
Cohesity’s Microsoft 365 changes include threat scanning for Exchange, SharePoint and OneDrive, protection for the Preservation Hold Library, metadata-preserving recovery across OneDrive, SharePoint, Teams and Groups, expanded Microsoft Graph API use and multi-geo support. The company calls this “compliance-grade” recovery, but names no particular certification or legal guarantee.
Preservation Hold Library coverage is more consequential than its unassuming name suggests. Microsoft’s documentation explains that SharePoint and OneDrive use this hidden system location to preserve content under applicable retention settings. It is not intended for ordinary interactive use, and Microsoft does not support manually editing, deleting or moving its automatically retained files. Compliance tools such as eDiscovery provide access instead.
Microsoft also states that the library counts against the site’s storage quota. That creates a practical connection between Cohesity’s recovery and data-optimization announcements: removing content from a user-facing location does not necessarily eliminate retained copies or immediately reduce storage consumption. Administrators should assess retention behavior alongside archiving plans, not as an afterthought.
A useful recovery demonstration should therefore include retained content and the exact metadata fields the organization needs—not just a collection of restored documents.
Entra ID and Intune join the recovery picture
Cohesity says its identity enhancements recover permanently deleted objects synchronized to on-premises Active Directory. Administrators can also assign a new password when restoring an Entra ID user, and the protection scope now includes Intune configuration objects within Entra ID backups.
The release does not enumerate supported Intune object types or explain hybrid restoration prerequisites. Before relying on those functions, request an object-level support matrix and a documented recovery sequence. “Intune configuration objects” should not be read as a promise to restore every component of endpoint management.
AI access and archiving need governance tests
On the data-management side, Cohesity says its data security posture management capabilities identify redundant, obsolete and trivial data. Cohesity Cloud Services can then apply policy-based archiving and stubbing, with the stated aim of keeping active Microsoft 365 content relevant for tools such as Copilot.
Separately, Gaia Catalog can curate and expose enterprise datasets to Azure Databricks as an external source while the underlying data remains in Cohesity Data Cloud. Cohesity says this avoids new extract, transform and load pipelines for moving or duplicating that data. Its existing Gaia integration with Microsoft 365 Copilot supports natural-language queries, with role-based and file-level access controls governing responses. These are vendor descriptions, not independently measured results.
For an evaluation, test permission changes, archived-content access and data freshness explicitly. In particular, ask what “no duplication” covers throughout the analytics workflow, rather than assuming it answers every question about processing or storage.
What to take into an Ignite discussion
Cohesity lists booth 5215 at Moscone Center and a session titled “Build resilience and recover Microsoft operations after compromise” for November 19, 2026, from 10:45–11:10 a.m. Pacific Time. Its planned scope includes Microsoft 365, Azure, Active Directory and Entra ID recovery.
The announcement gives administrators a substantive list of capabilities to investigate, but no pricing, detailed deployment requirements or independent recovery benchmarks. The strongest next step is a scoped demonstration: restore the data, identities, configuration and development assets your organization actually needs, then verify the result. A broader coverage list is welcome; a proven recovery runbook is what earns its place in the incident-response plan.