Azure Hybrid Management & Security: What’s New and Insights from the Field – August 2026

Once again this month, I’m back with my recurring series focused on the evolution of Azure management and security services, with a special focus on hybrid and multicloud scenarios enabled by Azure Arc and enhanced by the use of Artificial Intelligence.

This monthly series aims to:

• Provide an overview of the most relevant updates released by Microsoft;

• Share operational tips and field-proven best practices to help architects and IT leaders manage complex and distributed environments more effectively;

• Follow the evolution towards a centralized, proactive, and AI-driven management model, in line with Microsoft’s vision of AI-powered Management.

The main areas addressed in this series, together with the corresponding tools and services, are described in this article.

Hybrid and multicloud environment management

Azure Arc

Extended Security Updates for Windows Server 2016 through Azure Arc

Microsoft has made Extended Security Updates for Windows Server 2016 available through Azure Arc, giving organizations a simplified path to keep protecting systems that cannot be upgraded or migrated before the operating system reaches the end of extended support, scheduled for January 12, 2027.

By connecting Windows Server 2016 machines to Azure Arc-enabled Servers, you can enroll in the ESU program directly from the Azure portal and continue to receive the security updates that Microsoft rates as Critical and Important. Coverage can be maintained for up to three years after the end of support, from January 12, 2027 through January 2030. ESUs introduce no new features and no non-security fixes, but they act as a temporary bridge for business-critical workloads and applications that need more time to be modernized or migrated.

Consuming ESUs through Azure Arc also brings a more flexible operating model than traditional licensing mechanisms. Billing follows a monthly pay-as-you-go model and can be stopped as soon as a server is migrated, upgraded, or decommissioned, avoiding costs for coverage periods that are no longer needed. The spend is billed through Azure, can count toward any existing Microsoft Azure Consumption Commitment (MACC), and can be tracked through Microsoft Cost Management and Billing.

Azure Arc also simplifies the management of ESU coverage at scale. From the Azure portal you can centrally review the server inventory and the enrollment status, and quickly spot any systems that are not yet protected. Update delivery is keyless as well: there is no need to purchase, distribute, and manually activate ESU keys on individual servers.

The availability of Extended Security Updates through Azure Arc therefore reinforces the role of the service as a management layer for hybrid and multicloud infrastructures. Beyond extending governance and security to servers running outside Azure, Arc also makes it possible to centrally manage a delicate phase of the operating system lifecycle, keeping legacy workloads protected while the upgrade or migration path is being planned.

Security posture across hybrid and multicloud infrastructures

Microsoft Defender for Cloud

New way to access CVE details through Azure Resource Graph

Microsoft Defender for Cloud has updated the model used to expose and query, through Azure Resource Graph, the details of the CVE vulnerabilities detected by vulnerability assessment processes. The information is still available, but the detail properties are now exposed through the microsoft-security/cvedetails resource type.

The change was introduced to improve query performance, service scalability, and the handling of larger data volumes. The new model separates CVE details more clearly from the main vulnerability assessment records, making access to the information more efficient in environments with a high number of resources and vulnerabilities.

Organizations that use APIs, Azure Resource Graph queries, workbooks, scripts, or automations to retrieve CVE details should review their existing implementations and update them to use the new resource. Queries that keep reading those properties directly from the previous vulnerability assessment records may no longer return all the expected information.

The change therefore deserves particular attention in environments where Defender for Cloud data is integrated with external reporting, remediation, or vulnerability management processes. It is advisable to take inventory of existing queries and automations and align them with the new model before any dependency starts producing incomplete results.

Retirement of the classic Defender for SQL APIs

Microsoft has announced the retirement of the classic Defender for SQL APIs used to configure the Vulnerability Assessment and Advanced Threat Protection capabilities. The affected APIs will be decommissioned on August 16, 2027.

Organizations still using these interfaces need to move to the currently supported configuration model and, by that date, update any scripts, Infrastructure as Code pipelines, provisioning tools, or automations that depend on the legacy APIs.

The transition period leaves plenty of room to plan the work in advance, but the change deserves particular attention in large-scale managed Azure environments, where Defender for SQL configuration is often automated through templates, scripts, or centralized governance tooling.

It is therefore worth including a review of dependencies on the classic APIs in lifecycle management and technical debt activities, so as to avoid disruption to deployment processes or to security posture management as the retirement date approaches.

Targeted on-demand malware scanning in Microsoft Defender for Storage

Microsoft Defender for Storage is extending its on-demand malware scanning capabilities with the ability to scan specific items, without necessarily having to scan the entire storage account.

You can now limit the scan to a single blob or file, to a specific container or file share, or to all objects matching a given path prefix. The items to be scanned are selected through filters defined in the body of the REST API request. With no filters in place, the behavior is unchanged and the scan covers the whole storage account.

This finer granularity makes the feature especially useful in incident response scenarios, in checks that follow the upload of suspicious files, or in the selective validation of large datasets and repositories. The analysis can be focused only on the resources of interest, narrowing the operational scope of the scan and making verification activities more efficient.

The new capability also makes it easier to integrate malware scans into automated workflows, where an event or an application process can trigger the analysis of only the objects involved, reinforcing the use of Defender for Storage as a security component embedded in operational processes.

Change to overprovisioned identity assessments in AWS and Google Cloud

Microsoft Defender for Cloud is changing how the assessments for overprovisioned identities work in AWS and Google Cloud environments. To improve performance and scalability when generating recommendations, information about unused actions will no longer be factored into the overprovisioning assessments.

As a result, the Unused actions list will no longer appear in recommendations for AWS and Google Cloud identities. Any process, workflow, or automation that relied on this information within the Cloud Infrastructure Entitlement Management capabilities of Defender for Cloud will therefore need to be revised.

The change does not remove the ability to verify how permissions are actually used, but it moves that task to the native tooling of each cloud provider. For AWS, you can use the activity and last-accessed information available in AWS Identity and Access Management, while for Google Cloud the checks can be performed through the IAM tools and Cloud Asset Inventory.

Microsoft has therefore chosen to stop collecting and surfacing these signals directly in multicloud recommendations, leaving them to the services that are their authoritative source. For organizations that use Defender for Cloud as a centralized CIEM platform, the change means reviewing permission analysis processes and, where necessary, supplementing them with information coming directly from AWS and Google Cloud.

Backup & Resilience

Azure Site Recovery

Bring Your Own NIC in Azure Site Recovery

Azure Site Recovery now supports the Bring Your Own NIC (BYON) model in Azure-to-Azure scenarios, making it possible to use and attach an existing, pre-provisioned Network Interface Card in the target region during test failover and failover operations.

The feature provides greater control over the network configuration of the Disaster Recovery environment, allowing the required NICs to be prepared in advance and their existing settings to be preserved. This approach is particularly useful in environments where the network configuration of the secondary region has to meet precise addressing, security, or integration requirements.

Key benefits include the ability to reserve IP addresses in the target region ahead of time and to retain network configurations that have already been validated, reducing the need to recreate or change those settings during a failover event. This makes the recovery process more predictable and limits the risk of divergence between the configuration designed for Disaster Recovery and the one actually used when it is invoked.

BYON support therefore helps improve readiness for business continuity scenarios, especially in more complex Azure architectures, where networking is often one of the most critical elements of the Disaster Recovery plan. Being able to prepare and control the target network interfaces in advance allows failover tests that are closer to real conditions and raises the level of determinism of the recovery procedures.

Monitoring

Azure Monitor

AKS control plane metrics with Azure Monitor Managed Service for Prometheus

Microsoft has made the collection of Azure Kubernetes Service control plane metrics available through Azure Monitor Managed Service for Prometheus. The capability provides native visibility into the main managed components of the AKS control plane, improving observability and operational analysis for Kubernetes clusters.

The metrics collected cover key components such as the API server, etcd, kube-scheduler, kube-controller-manager, cluster autoscaler, and node auto-provisioning. These signals help platform teams better understand control plane behavior and analyze over time how workloads, controllers, automation mechanisms, and scaling processes interact with the services managed by AKS.

Having this information available makes it easier to identify anomalies, bottlenecks, or operating conditions that can affect cluster behavior. It also becomes possible to correlate application activity with scheduling, autoscaling, and node provisioning events, gaining a more complete view of the internal dynamics of the Kubernetes environment.

Finally, the integration with Azure Monitor Managed Service for Prometheus makes it possible to use a monitoring model consistent with the Prometheus metrics already adopted for workloads and application components. This strengthens the centralized approach to AKS observability, giving operations teams a more complete set of data for troubleshooting, capacity planning, and performance analysis.

Conclusions

August’s announcements confirm an evolution increasingly geared toward the operational maturity of hybrid and multicloud environments, where lifecycle management, security, resilience, and observability have to be addressed as elements of a single operating model.

From this perspective, Azure Arc continues to take on a central role: being able to manage Extended Security Updates for Windows Server 2016 directly through Azure is a concrete example of how the service is becoming the control layer for legacy workloads and distributed infrastructures as well. At the same time, the Defender for Cloud updates highlight how important it is to keep under control not only the security posture, but also the operational dependencies on APIs, queries, and automations, including them in the normal processes of lifecycle management and technical debt management.

The developments on the operational front are interesting too: the selective malware scanning in Defender for Storage brings greater granularity to security automation processes, while Bring Your Own NIC support in Azure Site Recovery makes Disaster Recovery scenarios more deterministic. On the monitoring side, finally, exposing AKS control plane metrics through Managed Prometheus further reduces blind spots in Kubernetes environments and enables a more complete analysis of cluster dynamics.

The message that emerges is therefore clear: centralizing management does not just mean having a common console, but building consistent, automated, and measurable processes across the entire infrastructure lifecycle. This is the ground on which services such as Azure Arc, Defender for Cloud, Azure Monitor, and Azure Site Recovery keep progressively converging, laying the foundations for a management model that is increasingly proactive and, over time, increasingly supported by AI.