rss.livelink.threads-in-node

Authenticating AWS Workloads to Azure Functions using Workload Identity Federation

kasturi — Mon, 29 Jun 2026 04:38:32 GMT

What you will learn:

What Workload Identity Federation is and how it works
How to set up trust between AWS and Microsoft Entra ID
How to exchange AWS identity tokens for Azure access tokens
How to securely call an Azure Function from AWS without storing credentials

This approach improves security, removes secret management overhead, and aligns with Zero Trust principles.

Let’s start by understanding why this approach is needed in a multi-cloud environment.

Why this approach is needed

In today’s multi-cloud landscape, organizations frequently need to connect services across cloud providers like AWS and Azure.

Traditionally, this required storing long-lived Azure client secrets within AWS environments. While functional, this introduces:

Security risks (secrets can leak or be misused)

Operational overhead (secret rotation and storage)

Increased maintenance complexity

Microsoft Entra ID provides a modern alternative: Workload Identity Federation, which eliminates the need for static credentials entirely.

What is Workload Identity Federation?

Workload Identity Federation is a feature in Microsoft Entra ID that allows you to trust identities from external providers like AWS, GCP, or GitHub. Instead of a secret, Azure validates the identity of the AWS resource based on its own native OIDC (OpenID Connect) token.

This approach is particularly useful for:

Securing Cross-Cloud Pipelines: Enabling AWS Lambda or EC2 to call Azure APIs without managing keys.

Eliminating Secret Rotation: Removing the need to update expired secrets across different cloud providers.

Enhancing Security: Using short-lived, verifiable claims that automatically expire.

In this blog, we will cover the configuration for service-to-service authentication and user-led validation for troubleshooting. The following guide outlines the complete technical configuration required to implement this architecture.

An overview of what we will be doing:

Generate AWS Token: Your AWS resource (Lambda, EC2, etc) generates a short-lived OIDC token signed by AWS.
Exchange for Azure Token: The AWS token is sent to Microsoft Entra ID. Azure validates the AWS signature using your Federated Credential and issues a native Azure Access Token in return.
Attach Verified Permissions: We configure an App Role on the Function App and link it to our Caller App. This helps Azure identify the correct permissions to inject into the token, confirming the caller is officially permitted to access your API.
Authorize Azure Function: The AWS resource calls the Function URL with the Azure token. The Function's authentication layer verifies the token's claims and grants access.

Section 1: AWS side setup

Step 1–Enabling Outbound Identity Federation

Go toIdentity and Access Management (IAM)-> Access Management->Account Settings
Scroll down to the Outbound Identity Federation section and enable it. Note down the Token Issuer URL—we will use it later to set up the Issuer claim in the federated credentials on the Azure side.

Step 2– Create a role for your AWS resource (Lambda, EC2)

Go to Identity and Access Management (IAM) -> Access Management->Roles
Click on the Create role button on the top right and select the trusted entity type, I selected AWS service. For use case I selected EC2.
Under Permissions, click Add permissions > Create inline policy.
Switch to the JSON tab and paste this:
curl -X POST "https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/token" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "client_id=<CLIENT_ID> " \ -d "scope=api://<APP_URI> /.default" \ -d "grant_type=client_credentials" \ -d "client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer" \ -d "client_assertion=<WebIdentityToken> "
Review and Save (name it something like AllowSelfWebIdentityToken). This permission allows the role to generate its own OIDC token for external exchange (you can do this step after the creation of role as well by editing the role)
I named the role aws-federation-role. Review and create the role. After the creation is complete note down the ARN for the role.

Section 2: Azure side setup

Step 3 — Register the AWS Caller App in Entra ID

This registration represents the AWS resource that will request a token and call your API in the Azure side.

Go to Azure Portal → Microsoft Entra ID → App registrations → + New registration. Fill in the following details:
- Name: aws-caller-app
- Supported account types: Single tenant (your tenant)
Click Register. Now you’ll see Application (client) ID and Directory (tenant) ID. Copy both — you’ll need them later.

Step 4— Create Federated Credentials

This allows AWS to impersonate this application by establishing a trust with an external OpenID Connect (OIDC) identity provider and get tokens to access Microsoft Entra ID resources.

In the aws-caller-app that you just created, go to Manage->Certificates and Secrets. Go to the Federated credentials section on the page.
Fill the following details:
- Federated credential scenario: Other issuer
- Issuer: Add the Token Issuer URL that we copied in Step 1 from AWS.
- Type: Explicit subject identifier
- Value: Add the ARN of the AWS resource that we copied in Step 2
- Name: aws-federation
Add Description and leave the Audience claim as is. Click Add.

Step 5— Register your Function App in Entra ID

This registration represents the Function App resource that will receive a token and be called on the Azure side. My Function App is an API called aws-entra-federation-api.

Go to Azure Portal → Microsoft Entra ID → App registrations → + New registration. Fill in the following details:
- Name: function-api-app
- Supported account types: Single tenant (your tenant)
Click Register. Now you’ll see Application (client) ID and Directory (tenant) ID. Copy both — you’ll need them later.

Step 6– Create an App Role in function-api-app

App roles are custom role templates which define permissions that can be assigned to users or apps.

In the function-api-app that you just created, go to Manage → App Roles in the left menu.
Create a new Role and fill the following details:
- Display Name: access_as_app
- Allow Member Types: Applications
- Value: access_as_app
- Description: Allow application to application access
- Do you want to enable this app role?: True (Checked)
Click "Apply".

Step 7– Assign API Permissions to the aws-caller-app

In the previous step we created a role on the function-api-app, now we will assign this role to the aws-caller-app so that it is able to authorize and call the function-api-app.

In the function-api-app, go to Manage → API Permissions in the left menu.
Click "+ Add a permission". Click on the "APIs my organization uses" tab.
In the search bar, enter the name of the app/service principal created before function-api-app.
Select Application permissions and, under the Permissions section, choose the role created before (access_as_app).
Click the "Add permissions" button.
Back in the Manage → API Permissions screen, click "Grant admin consent for Default Directory".

Step 8— Configure Authentication on the Azure Function resource (aws-entra-federation-api)

Enable authentication on your function resource (aws-entra-federation-api) and link it to the app registration (function-api-app) you created earlier.

Go to your Function App resource in the Azure Portal
(aws-azure-federation-api)
On the left menu, select Authentication.
Click + Add identity provider. Add the following details:
- Identity provider: Microsoft
- App registration type: Provide details of an existing app registration
- Client ID: Paste the Application (client) ID of your function-api-app from step 5(APP_URI)
- Issuer URL: https://login.microsoftonline.com/<tenant-id>/v2.0 (Replace <tenant-id> with your Directory (tenant) ID)
- Client application requirement: Allow requests from any application
- Identity requirement: Allow requests from any identity
- Tenant requirement: Allow requests only from the issuer tenant
- Under Restrict access, select Require authentication
- Unauthenticated requests: HTTP 401
Any other field not listed should remain as default. Click "Add" and refresh the Settings → Authentication view.
The new configured provider will appear. Click "Edit". A list of fields will appear. Make the following changes:
Allowed token audiences: Lets consider Application ID for function-api-app from step 5 as the value for variable APP_URI. Add the following three different audiences.
- <APP_URI>
- api://<APP_URI>
- api://<APP_URI> /.default
Any other field not listed should remain as default. Save the changes. Now the Function App will only accept calls with valid Azure AD access tokens.

Congratulations, you have successfully completed the setup required for using Federated Identity authentication. Now let’s test if the setup is working correctly.

Section 3: Validating the setup

Step 9 – Requesting Azure token and authenticating to the function app.

In my case, I’ve logged in to my AWS account using my user account (not root user) and then opened AWS CloudShell. I will be validating the setup through user account as I have not deployed any AWS resource. You should be able to request for Azure token through Lambda or other AWS resource in a similar manner.

We will be using the following variable and values in the following steps:

ARN: The ARN of the role created in step 2 on AWS.

TENANT_ID: Your Azure tenant ID, you can find this by going to your Account->All directories and copy the Directory ID

CLIENT_ID: The application (object) ID of the app registration created for the AWS caller app generated in step 3(aws-caller-app, in this case).

APP_URI: The application (object) ID of the App registration created for the function app resource generated in step 5 (function-api-app, in this case).

DEFAULT_DOMAIN: You can find this in the overview section of your Azure Function app resource (aws-entra-federation-api, in this case).

We need to follow a few extra steps because this validation uses a user account. In production, the AWS SDK performs the ‘identity proofing’ step (step 4) for you. In your code, you simply take that identity, exchange it for an Azure token at the Microsoft Entra endpoint, and use the token to call your Azure Function. As a result, a production workload typically doesn’t need the first four steps.

Assume the Role that was created earlier for the AWS resource in Step 2, we are logged in to the AWS CloudShell with the user account but we need to use the role that we created earlier to generate AWS token and exchange it for Azure token. aws sts assume-role --role-arn <ARN>
As output, we get accesskeyid, secretaccesskey and sessiontoken. We will be using these as variables in the next step.
Set these values as variables:
export AWS_ACCESS_KEY_ID="<accesskeyid> " export AWS_SECRET_ACCESS_KEY="<secretaccesskey> " export AWS_SESSION_TOKEN="<sessiontoken>"
Generate the AWS OIDC Token that is specifically formatted for Azure.
aws sts get-web-identity-token \ --audience "api://AzureADTokenExchange" \ --signing-algorithm "RS256" \ --duration-seconds 3600
We get the WebIdentityToken in the output. Store it as we will be using it in the next step.
Now we will exchange the AWS token (WebIdentityToken) for an Entra ID token
curl -X POST "https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/token" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "client_id=<CLIENT_ID> " \ -d "scope=api://<APP_URI> /.default" \ -d "grant_type=client_credentials" \ -d "client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer" \ -d "client_assertion=<WebIdentityToken> "
We get the access_token as the output of the last step. Store it as we will be using it in the next step.
Use the Entra ID token from the last step to send a request to your app—in this case, the function-api-app.
curl -X GET "https://<DEFAULT_DOMAIN> " \ -H "Authorization: Bearer <access_token>" \ -H "Content-Type: application/json"
You should get a 200 OK response.

Conclusion

By implementing Workload Identity Federation, you have moved away from the "Secret Management" era of cloud security. Instead of worrying about rotating client secrets or securing them in a vault, you are now using a short-lived, verifiable trust relationship between AWS and Azure.

What's Next?

Now that your authentication is secure, you can explore:

Fine-Grained Authorization: Use the claims inside the Azure Access Token to restrict specific actions within your Azure Function code.
Conditional Access Policies: Layer on Azure Conditional Access to ensure requests only come from trusted locations, such as your specific AWS VPC or a designated IP range.
Automating with Terraform/Bicep: Now that you've done it manually, consider codifying this setup to ensure consistent security across all your environments.

Check This Out! (CTO!) Guide (May/June 2026)

TysonPaul — Thu, 18 Jun 2026 21:36:23 GMT

Member: TysonPaul | Microsoft Community Hub

Triggering Azure Functions from Blob Storage Using Event Grid

Team Blog: Core Infrastructure and Security

Author: AndrewCoughlin

Published: 05/11/2026

Summary: The article explains how to trigger Azure Functions from Blob Storage events using Azure Event Grid for real-time file processing. It outlines a step-by-step approach: create and deploy an Azure Function with an Event Grid trigger, set up an Event Grid subscription for BlobCreated events, and validate the process by uploading a blob. The method minimizes latency and avoids polling, making it suitable for enterprise scenarios. Key pitfalls include creating subscriptions before the function exists and misconfigurations. The article provides sample code and emphasizes the solution's simplicity, reliability, and operational transparency.

TLS Certificate Pinning and Best Practices in Azure Open-Source Relational Databases

Team Blog: Core Infrastructure and Security

Author: TameikaL

Published: 05/13/2026

Summary: The article explains TLS certificate pinning and its implications for Azure open-source relational databases (PostgreSQL, MySQL). Certificate pinning enhances client-side security but increases operational risk, especially during certificate rotations, by causing connection failures if certificates change. Unlike Azure SQL, where certificate validation is platform-managed, Azure OSS databases use client-managed trust. The article advises against certificate pinning and recommends trusting documented root CAs, using standard TLS validation modes, and maintaining up-to-date trust stores to ensure secure and resilient client connections during certificate updates.

Azure DDoS Protection & Azure WAF: A Layered Defense for Modern DDoS Attacks

Team Blog: Azure Network Security

Author: saikishor

Published: 05/28/2026

Summary: The article explains how Microsoft Azure provides a layered defense against modern DDoS attacks by combining platform-level infrastructure protection, Azure DDoS Protection for network-level threats (Layers 3/4), and Azure Web Application Firewall (WAF) for application-layer (Layer 7) attacks. This multi-tiered approach ensures comprehensive mitigation by addressing both high-volume network floods and sophisticated application-level threats, using adaptive techniques, rate limiting, bot protection, and real-time analytics. The article emphasizes that a defense-in-depth strategy—leveraging both Azure DDoS Protection and WAF—is essential for safeguarding internet-facing applications and maintaining service availability.

Scaling GitHub Advanced Security in Azure DevOps with a single reusable YAML template

Team Blog: Azure Infrastructure

Author: Paulams732

Published: 05/11/2026

Summary: The article describes how to streamline GitHub Advanced Security (GHAS) integration in Azure DevOps by using a single, reusable YAML pipeline template. This approach dynamically detects repository content, runs only relevant security scans for application code and infrastructure-as-code, and centralizes configuration and reporting. It eliminates the need for multiple pipelines, reduces maintenance, ensures consistent security coverage, and supports polyglot and mixed repositories, resulting in a scalable and efficient DevSecOps process. Key lessons include the importance of detection-driven execution, dynamic configuration, and unified workflows for effective security management across diverse codebases.

Building AI Guardian Extension: AI Detection and Enterprise AI Security

Team Blog: Azure Infrastructure

Author: ranjsharma

Published: 05/19/2026

Summary: The article discusses the security and governance challenges posed by rapid enterprise adoption of generative AI tools, focusing on the risks of "Shadow AI"—the unauthorized use of AI platforms that can lead to data leakage and compliance violations. It introduces the AI Guardian Extension, a platform that autonomously detects and protects against Shadow AI by monitoring AI interactions, preventing sensitive data exposure, blocking risky prompts, and generating compliance reports, thereby enabling safe, compliant, and visible enterprise AI usage.

Public Preview: Migrate your regional virtual machines to availability zones

Team Blog: Azure Compute

Author: micahmckittrick

Published: 05/07/2026

Summary: Microsoft has announced a public preview feature enabling Azure users to migrate regional (nonzonal) Virtual Machines (VMs) and VM Scale Sets (VMSS Flex) into specific availability zones without rebuilding resources. The migration preserves VM names, disks, IPs, and other properties. This improves fault isolation, compliance, and disaster recovery. The process involves deallocating the VM, assigning it to a zone, and restarting it. Migration is one-way and must be done per VM. Certain configurations, like Basic SKU IPs and unmanaged disks, are not supported. Users are advised to roll out migrations in batches for production workloads.

Use Azure Container Registry as an Upstream Source for Artifact Cache

Team Blog: Azure Compute

Author: toddysm

Published: 05/05/2026

Summary: Azure Container Registry (ACR) now supports using another ACR as an upstream source for artifact cache, enabling secure image promotion and distribution within organizations. This feature allows registries to cache images from other ACRs, with user-assigned managed identities (UAMI) supported for authentication, improving security by eliminating credential management. Common scenarios include promoting images between Dev and Prod registries and implementing hub-and-spoke registry topologies. The setup uses Azure CLI, requires proper RBAC permissions, and works best within the same tenant. Cross-tenant and some network configurations have limited support; portal integration is coming soon.

How to use Instance Mix with Azure Virtual Machine Scale Sets

Team Blog: ITOps Talk

Author: OrinThomas

Published: 05/24/2026

Summary: Instance Mix for Azure Virtual Machine Scale Sets allows you to specify up to five compatible VM sizes in a single scale set (Flexible orchestration mode), enhancing scalability, cost optimization, and provisioning success. Azure selects VM sizes during scale-out based on your chosen allocation strategy (LowestPrice, CapacityOptimized, or Prioritized). Best for stateless, horizontally scalable workloads, Instance Mix requires similar VM types, compatible architectures, and pre-checked quotas. It’s configured via Azure CLI or portal, with operational tips for optimal use. Avoid mixing very different VM types, and always verify availability and quotas before production deployment.

The End is Nigh for DES and an Update for hunting down RC4

Team Blog: Ask the Directory Services Team

Author: Chris_Cartwright

Published: 05/08/2026

Summary: Microsoft is finalizing the removal of DES and RC4 encryption types from Windows Kerberos authentication to enhance security. The article provides updated XML filters and event forwarding methods to help administrators identify and track the use of DES and RC4 in their environments. It also includes resources, scripts, and guidance for transitioning to stronger cryptography, with references to related Microsoft support articles and previous blog posts. Note: The described Event Forwarding methods are not yet compatible with Server 2025 but will be updated in the future.

Windows 365 for Agents: run AI agents in Cloud PCs across real applications

Team Blog: FastTrack

Author: JulieHersum

Published: 05/27/2026

Summary: Windows 365 for Agents, now in public preview, enables AI agents to autonomously execute real workflows across applications—including legacy and UI-based systems—within secure, policy-controlled Cloud PCs. This represents a shift from API-based automation, allowing agents to complete complex tasks like processing invoices or updating CRM data while maintaining enterprise security and control. Administrators can define boundaries and monitor agent activity, ensuring agents operate safely without impacting production systems. Windows 365 for Agents thus offers a secure, dedicated environment for scalable, autonomous AI workflow automation across diverse software environments.

From Scale to Breakthrough: Azure NetApp Files Sets a New Cloud Benchmark for EDA Performance

Team Blog: Azure Storage

Author: GeertVanTeylingen

Published: 05/22/2026

Summary: The article highlights Azure NetApp Files’ new “large volume breakthrough mode,” which sets a benchmark for cloud storage in Electronic Design Automation (EDA) workloads. Independently validated SPECstorage® 2020 benchmarks show this mode enables exceptional scalability and consistent sub-millisecond latency, supporting thousands of parallel EDA jobs without performance bottlenecks. Both single and scaled configurations demonstrated linear scaling in throughput and concurrency, empowering faster, more efficient chip design cycles. As a result, Azure NetApp Files transforms cloud storage from a limiting factor to a strategic enabler for modern, high-performance semiconductor design workflows.

Modernizing Azure Virtual Desktop with Nerdio and Azure Files

Team Blog: Azure Storage

Author: Vybava_Ramadoss

Published: 05/04/2026

Summary: The article discusses how organizations scaling Azure Virtual Desktop (AVD) face challenges with user profile storage, identity management, and cost efficiency. Nerdio Manager streamlines AVD deployment by integrating compute, storage, and identity management, reducing complexity and configuration drift. Azure Files Provisioned v2 enhances storage performance and cost efficiency, while Entra ID authentication simplifies identity architecture. Together, Nerdio and Azure Files enable faster, more reliable, and cost-effective AVD environments with improved user experience, especially during peak loads, and ensure consistent, audit-ready governance at enterprise scale.

Cutover Strategy for Azure PaaS Services: A Step-by-Step Guide to Near Zero-Downtime Migrations

Team Blog: Azure Migration and Modernization

Author: lapadman

Published: 05/06/2026

Summary: The article outlines a step-by-step cutover strategy for migrating enterprise applications to Azure PaaS with near zero downtime. Emphasizing phased parallel cutover, it recommends gradual traffic shifts, robust rollback plans, and continuous monitoring to minimize risk. High availability (HA) and disaster recovery (DR) must be integrated into each phase. Messaging systems, particularly Azure Service Bus, are highlighted as the most complex component. The guide details essential roles, tools, metrics, and checklists to ensure a safe, controlled migration, concluding that cutover and HA/DR should be treated as a unified process for successful Azure transitions.

[Preview] CIS Benchmarks on Azure; Now for Windows Server

Team Blog: Azure Governance and Management

Author: AmirB

Published: 05/28/2026

Summary: Microsoft is announcing the preview of built-in CIS Benchmarks for Windows Server within Azure Policy and Machine Configuration, initially supporting Windows Server 2025. This expands their compliance offerings, which already cover Linux, to Windows environments managed by Azure and Arc. The solution allows flexible configuration, exportable compliance as code, and unified management across machine types. The preview starts in audit-only mode, with auto-remediation and enforcement planned. Future updates will add support for more Windows editions, granular rule enforcement, STIG baselines, and retire older, overlapping policies for streamlined compliance management in Azure.

Introducing the Azure Resource Manager MCP Server!

Team Blog: Azure Governance and Management

Author: stevenbucher

Published: 05/07/2026

Summary: The article announces the public preview of the Azure Resource Manager MCP Server, a tool enabling AI agents to interact with Azure infrastructure via Azure Resource Manager. It allows agents to generate, validate, and execute Azure Resource Graph queries, deploy and manage ARM templates, and monitor deployments—all from natural language prompts. The server supports compliance audits, rapid provisioning, and policy checks, and integrates with GitHub Copilot. It respects Azure security policies and is initially available for VS Code, with more features and client support planned. Users can install and provide feedback during the preview phase.

The power behind AI: Your brain

Team Blog: Microsoft Learn

Author: Nency_Yera

Published: 05/11/2026

Summary: The article shares Nency Yera’s journey as a neurodivergent professional with ADHD who, despite having no coding background, leveraged AI tools like GitHub Copilot and VS Code by customizing them to fit her thinking style. With supportive leadership and a personalized, step-by-step approach, she built practical solutions for her workplace. The story emphasizes that neurodivergent brains are assets, and that AI becomes powerful when adapted to individual needs, enabling anyone—regardless of technical background—to create impactful tools and unlock new potential.

New Microsoft Certified: Intelligent Applications Builder Associate Certification

Team Blog: Microsoft Learn

Author: LibertyMunson

Published: 05/27/2026

Summary: Microsoft has introduced the Certified: Intelligent Applications Builder Associate Certification, aimed at professionals building AI-powered business solutions using Microsoft Power Platform, Copilot, and natural language tools. To earn the certification, candidates must pass Exam AB-410 (beta), which validates skills in creating intelligent applications, automation, data models, and integrating AI agents. The first 300 test-takers before June 17, 2026, receive an 80% discount. Candidates should have experience with Dataverse, Power Apps, Power Automate, and Copilot features. The certification becomes generally available in July 2026, with preparation resources and study guides provided by Microsoft.

Ansible + Azure Arc: Use Ansible modules to deploy and manage Azure Arc machine extensions at scale

Team Blog: Azure Arc

Author: alinetran

Published: 05/20/2026

Summary: Microsoft has introduced new Ansible modules in the azure.azcollection for managing Azure Arc machine extensions at scale. These modules allow teams to automate the deployment, update, and removal of Azure Arc extensions through Ansible playbooks, streamlining extension lifecycle management across hybrid and multicloud environments. This integration eliminates the need for separate tools, enforces consistent configurations, supports compliance scenarios like centralized SSH access, and enhances visibility into extension states. The update strengthens Azure Arc’s position as a unified management platform for Windows and Linux servers using familiar automation workflows.

Simplified access to Hotpatching enabled by Azure Arc for Windows Server 2025

Team Blog: Azure Arc

Author: sharmajyoti

Published: 05/19/2026

Summary: Windows Server 2025 introduces hotpatching enabled by Azure Arc, allowing security updates without reboots across hybrid and multicloud environments at no extra cost. Eligible servers must be connected to Azure Arc and have Virtualization-based Security enabled. Azure Update Manager and other tools enable centralized patch management, improving uptime and simplifying compliance. Hotpatching delivers monthly security updates, with quarterly cumulative updates requiring a restart. Existing enrolled machines continue receiving hotpatches without additional action, and hotpatching remains free for Azure-hosted servers. Azure Arc also provides unified governance, monitoring, and lifecycle management for diverse server environments.

What's new in FinOps toolkit 14 – April 2026

Team Blog: FinOps

Author: Michael_Flanakin

Published: 05/13/2026

Summary: FinOps toolkit 14 introduces AI integration via a Copilot Studio agent template, enabling users to query FinOps hub data in natural language. It adds support for ingesting Azure Advisor and custom optimization recommendations, simplifies hub deployment options, and previews a new dataset for commitment discount eligibility. The release also delivers various fixes and enhancements across guides, Power BI, workbooks, and the PowerShell module. Looking ahead, the toolkit will deepen AI features, expand data support, and offer premium services to further help organizations optimize and manage cloud costs in Microsoft Azure environments.

Azure CLI on macOS: Upcoming Installation Changes

Team Blog: Azure Tools

Author: Alex-wdy

Published: 05/11/2026

Summary: Microsoft is updating how Azure CLI is installed on macOS to better meet security and enterprise requirements. Starting with version 2.86.0 (Preview), Azure CLI will shift from Homebrew Core to new options: Homebrew Cask (recommended) and an offline tarball for air-gapped environments. These changes enable distribution of precompiled, signed, and notarized binaries, aligning with macOS security standards. Homebrew Core remains available during the transition, but users are encouraged to adopt the new methods and provide feedback. Full rollout details and installation instructions are available on Microsoft Learn.

From Prompt to Production: Open in VS Code for Terraform in Azure Copilot

Team Blog: Azure Tools

Author: Jingwei_Wang

Published: 05/12/2026

Summary: Microsoft has introduced "Open in VS Code" for Terraform in Azure Copilot, enabling users to move seamlessly from AI-generated Terraform code in Azure Portal to real deployments within an integrated, guided workflow. This feature supports immediate editing, validation, and deployment in a browser-based VS Code environment, with built-in guidance for backend configuration and deployment. Users can select from Azure Storage, Terraform Cloud, or a temporary workspace for state management. The solution streamlines Infrastructure as Code processes for both beginners and enterprises, now in public preview, with future plans for enhanced CI/CD and editor integrations.

Understanding and building an Azure Hybrid Meshed Hub-Spoke Topology

Team Blog: Azure Networking

Author: Svenbaeck

Published: 05/18/2026

Summary: The article explains how to design a secure, scalable Azure hybrid network using a meshed hub-spoke topology. Centralized hubs control all traffic and security, preventing uncontrolled lateral communication between spokes and supporting hybrid connectivity. Key design principles include controlled routing in gateways and spokes, proper VNet peering, and meshing hubs for multi-region setups. Azure Firewalls or NVAs in the hub enable traffic inspection and policy enforcement. The approach simplifies management, enhances security, and supports regional independence and fault isolation, making it suitable for enterprise-scale Azure environments. Clear address planning and consistent configuration are emphasized for effective operation.

Simplify Virtual WAN Spoke Connectivity at Scale with Azure Virtual Network Manager

Team Blog: Azure Networking

Author: Jay-Li

Published: 05/26/2026

Summary: Azure Virtual Network Manager (AVNM) integrates with Azure Virtual WAN to simplify and automate spoke connectivity, routing, and security policy management across large-scale hub-and-spoke network architectures. By grouping virtual networks and applying centralized connectivity and routing policies, AVNM reduces repetitive manual configuration, ensures operational consistency, and enables bulk onboarding, dynamic updates, and incremental deployments. This integration streamlines operations, enhances scalability, and provides robust security controls, making it easier for organizations to manage complex Azure networking environments confidently and efficiently.

Building resilient networks for AI supercomputers

Team Blog: Azure High Performance Computing (HPC)

Author: jithinjose

Published: 05/06/2026

Summary: The article details Microsoft’s networking innovations for the Fairwater AI supercomputer, focusing on resilience and efficiency at extreme GPU scale. Central to this is the Multipath Reliable Connection (MRC), a new, open-source transport protocol that distributes data across multiple paths, enabling robust, high-utilization GPU clusters even during routine network faults. Combined with a two-tier multiplane topology and static SRv6 routing, this approach minimizes disruptions, improves training throughput, and simplifies failure recovery. Microsoft, in partnership with industry leaders, is open-sourcing MRC and related tools to advance resilient AI infrastructure across the ecosystem.

Distributing model weights to your AI cluster: a faster pre-flight on AKS and Slurm

Team Blog: Azure High Performance Computing (HPC)

Author: pauledwards

Published: 05/06/2026

Summary: The article introduces "azcp-cluster", a tool for efficiently distributing large AI model checkpoints across multi-node GPU clusters on Azure. Instead of each node downloading the full dataset separately—causing slowdowns, increased costs, and potential Azure storage throttling—azcp-cluster shards the download across nodes, then broadcasts data at high-speed over InfiniBand. This approach reduces egress costs, maximizes fabric speed, and simplifies cluster setup on Slurm and AKS. Practical deployment examples, Docker integration, and Kubernetes scheduling strategies are provided, with recommendations for both merged-image and init-container patterns. Benchmarks show significant speedups and cost savings.

Share the Moment: Listen Together with Shared Audio

Team Blog: Windows OS Platform

Author: Steven Ilami

Published: 05/26/2026

Summary: The article introduces “Shared Audio,” a new Windows 11 feature that enables two users to wirelessly listen to audio from the same PC using separate Bluetooth LE Audio accessories, like headphones or hearing aids. This solves the longstanding limitation of one-audio-device connections, enhancing shared experiences during flights, study sessions, or road trips. Users can easily manage connections and individual volumes through Quick Settings. Shared Audio requires compatible LE Audio devices, Windows 11 (version 24H2 or newer), and suitable hardware. The feature aims to make group listening more accessible, convenient, and customizable for entertainment, productivity, and accessibility needs.

How to Secure Azure Databricks without Public Exposure using WAF + Private Endpoints

Team Blog: Azure Architecture

Author: FaizaanMerchant

Published: 05/11/2026

Summary: The article outlines how to secure Azure Databricks using a Zero Trust Architecture by combining Azure Application Gateway with Web Application Firewall (WAF) and Private Endpoints. This approach eliminates public internet exposure, ensures all traffic is inspected and routed securely, and aligns with strict compliance requirements. The recommended architecture uses a Hub-and-Spoke model, disabling public access and enforcing internal and external access through WAF and private endpoints, respectively. Key considerations include proper DNS configuration, SSL setup, and custom WAF rules, ensuring secure, compliant, and seamless access for both internal and external users.

Cloud Native Platforms: Evolve

Team Blog: Azure Architecture

Author: KishoreKumarPattabiraman

Published: 05/21/2026

Summary: The article argues that AI is transforming software engineering by augmenting workflows across the entire software development lifecycle—not just code generation. Success depends on disciplined adoption: turning individual AI prompts into reusable workflows, implementing robust guardrails, and maintaining clear boundaries for human judgment. Responsible AI, with practices ensuring fairness, transparency, safety, and accountability, is essential. Teams should measure AI by outcomes (like defect rates and lead time), not usage. The key is evolving engineering practices to leverage AI safely and effectively, making workflows, not individual suggestions, the core unit of value.

New Platform SSO with registration during Automated Device Enrollment on macOS

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 05/14/2026

Summary: Microsoft Intune now supports Platform Single Sign-On (PSSO) registration during Automated Device Enrollment (ADE) setup for macOS 26 and newer. With the new “Enable Registration During Setup” setting and Intune Company Portal version 5.2604.0+, users register their devices and sign in with Microsoft Entra credentials during Setup Assistant, enabling immediate access to work resources. This streamlines onboarding, reduces compliance gaps, authentication issues, and IT helpdesk tickets. The feature requires coordinated policies assigned to static user groups. Future updates aim to reduce multiple sign-in prompts for an even smoother enrollment experience.

Migrating frontline mobile devices: Aligning stakeholders before real-world testing

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 05/01/2026

Summary: The article outlines the crucial steps for migrating frontline mobile devices by emphasizing the need to align stakeholders and processes before conducting real-world testing with Microsoft Intune. It highlights translating discovery findings into actionable decisions, identifying and aligning key operational and technical stakeholders, and ensuring readiness across licensing, identity, and device lifecycle areas. Real-world testing should validate end-to-end workflows, security, and supportability in operational conditions, not just device enrollment. Standardization can evolve post-testing, and clear ownership of success criteria is essential to achieve meaningful pilot outcomes and support future device management decisions.

Microsoft Security Copilot: AI-Driven Security Operations at Greater Scale

edgarus71 — Thu, 18 Jun 2026 20:49:10 GMT

At its core, Security Copilot is built to enhance every facet of security operations at machine speed. It translates a vast array of inputs (Microsoft’s cloud-scale telemetry, threat intelligence feeds, security best practices, and enterprise-specific data) into tailored recommendations and summaries, helping security teams “catch what others miss,” respond faster, and strengthen their expertise. In the sections below, I explore the key security benefits of Security Copilot, its extensibility via third-party plugins and skills, and the value of its deep integration with Microsoft’s security ecosystem.

Key Benefits for Security Operations

Security Copilot meaningfully improves threat detection, investigation, response, correlation of signals, and analyst productivity. The table below summarizes these core security benefits and capabilities:

Security Operations Aspect	Benefit with Security Copilot
Threat Detection	Augmented detection of elusive threats: Security Copilot leverages broad threat intelligence and comprehensive signals to identify subtle threats, anomalies, and attack patterns that might be missed through manual analysis. By reasoning over Microsoft’s vast security graph and global threat telemetry, it helps analysts “catch what others miss,” ensuring unique or stealthy threats are surfaced.
Incident Investigation	Faster, context-rich investigations: Security Copilot can swiftly summarize and analyze incident data from multiple sources, enhancing incident details with additional context from logs, alerts, and threat intel. It correlates related events and highlights root causes, giving analysts a consolidated understanding of complex incidents in minutes. This enables quicker triage and deeper insights, so investigators know what happened and where to focus next.
Response & Remediation	Guided response and remediation: Security Copilot not only identifies issues but also provides prescriptive guidance on how to respond. It can suggest remediation steps and mitigation strategies in plain language, helping analysts act decisively. For example, it may outline containment steps or orchestrate automated actions through integrated tools, significantly reducing response time to incidents.
Signal Correlation	Holistic cross-domain correlation: Because it taps into signals across identities, endpoints, email, cloud workloads, and more, Security Copilot automatically connects the dots among disparate alerts and data streams. It presents unified incident narratives by linking related indicators (e.g., matching an endpoint malware alert with identity login anomalies and cloud logs), eliminating manual cross-tool correlation and uncovering hidden attack paths. Analysts get a single cohesive view of an incident across the kill chain.
Analyst Productivity	Boosted efficiency & skill elevation: By automating repetitive tasks (like scanning logs, writing KQL queries, or summarizing reports) and supporting natural language interaction, Security Copilot reduces manual workload and accelerates everyday tasks. This lets analysts focus on higher-value activities. In practice, teams using Security Copilot have seen significant productivity gains – a recent study found 23–47% improvement in SecOps task efficiency after adoption. Junior analysts ramp up faster (learning from Copilot’s guidance), while senior analysts can handle more incidents with less fatigue.

These improvements translate into measurable security outcomes. Incident response becomes faster and more consistent, with mean time to resolution reduced by 30% on average within a few months of use according to early research. Security Copilot’s ability to accelerate investigations and streamline tasks drives down risk exposure and helps organizations make the most of their security investments. Ultimately, it strengthens an organization’s security posture by augmenting human analysts with AI-driven speed, scale, and intelligence.

Seamless Integration with the Microsoft Security Ecosystem

Another key strength of Security Copilot is its deep native integration with Microsoft’s security portfolio. From day one, Security Copilot was “designed with integration in mind.” It plugs directly into a broad range of Microsoft security products — including Microsoft 365 Defender (XDR), Microsoft Sentinel (SIEM), Microsoft Entra (ID and access management), Microsoft Intune (endpoint management), Microsoft Purview (compliance), and more. In practice, Security Copilot is available as both a standalone portal and as an embedded side-by-side experience within these Microsoft security tools. This means a security analyst working in Microsoft Sentinel or Defender can access Copilot’s capabilities without switching context: Copilot is right there in the workflow, ready to answer questions or assist with tasks in real time.

Because of this close integration, Security Copilot can access data and signals from across all Microsoft security solutions that an organization uses. It operates over a unified security data estate encompassing endpoints, identities, emails, applications, cloud workloads, data repositories, and beyond. The result is truly end-to-end visibility and protection: Copilot can reason across diverse telemetry (e.g., correlating a device malware alert from Defender with cloud logs from Azure, or identity risk signals from Entra) to provide comprehensive insight. This unified approach eliminates silos and tool fragmentation — analysts spend less time pivoting between separate consoles or manually stitching together information because Copilot synthesizes it automatically.

Moreover, leveraging the Microsoft ecosystem means Security Copilot can immediately add value without requiring a rip-and-replace of existing tools. It acts as a “force multiplier” across the installed Microsoft Security stack, maximizing the return on those investments by making them more effective and easier to use. For example, Copilot can turn a collection of raw alerts from different Microsoft products into a single, coherent incident storyline with actionable next steps. This synergy leads to significant operational efficiency gains and a more streamlined SOC workflow, as analysts have a central AI assistant coordinating across all defenses on their behalf.

By providing unified insights, reducing tool sprawl, and bringing together Microsoft’s best-in-class security technologies, Security Copilot emerges as a valuable asset for modern security teams. It empowers organizations to practice “AI-first” security operations – enabling defenders to work faster and smarter, while fully utilizing an integrated security ecosystem to protect the enterprise from evolving threats. In summary, Microsoft Security Copilot offers a compelling combination of advanced AI capabilities, extensibility, and seamless integration that helps security teams achieve unprecedented speed, breadth, and efficiency in defending their organizations. It enhances human expertise with machine-scale intelligence, improving threat detection and response outcomes and transforming the way security operations centers operate for the better.

Open Extensibility with Third-Party Plugins and Skills

A standout capability of Security Copilot is its extensible plugin architecture, which allows it to incorporate external data sources and integrate with third-party security tools. Plugins in Security Copilot are modular connectors that bring in specific data or perform defined actions (each plugin encapsulates certain “skills,” such as running a KQL query, calling an API, or searching threat intel). Microsoft provides numerous pre-installed plugins out-of-the-box for common Microsoft security services and workflows, and administrators can easily add or develop custom plugins to connect 3rd-party systems or bespoke data sources. This design ensures that Security Copilot’s capabilities can expand and adapt to different environments.

Through both Microsoft-built and third-party plugins, Security Copilot can tap into a wide variety of security data beyond the Microsoft stack. For example, supported third-party plugins let Copilot pull context from external solutions such as IT service management tools (e.g., ServiceNow), vulnerability management platforms, identity providers, network security appliances, and others. Plugins feed additional logs, alerts, and intelligence into Copilot’s analysis, thereby enriching its understanding of incidents with non-Microsoft data and events. This means a SOC can leverage existing investments in third-party security products by having Security Copilot analyze and correlate those systems’ outputs alongside Microsoft’s telemetry.

Microsoft and its partners have already created an ecosystem of Security Copilot plugins. For instance, Microsoft announced 15+ new third-party plugins at Ignite 2024, spanning categories like threat intelligence (e.g., integrating feeds from providers like CrowdSec, Cybersixgill, GreyNoise) and device/network/identity management tools (e.g., Red Canary, Netskope, Tanium, CyberArk, etc.). These plugins bring rich external data on threat actors, indicators of compromise, vulnerabilities, device health, user activity, and more, allowing Copilot to provide even more comprehensive analyses and recommendations.

Crucially, customers can build their own plugins and skills if needed, using Security Copilot’s developer tools and APIs. This means an enterprise could integrate a proprietary threat feed, custom data store, or even trigger custom response workflows via Copilot, tailoring the AI assistant to their unique security environment. Thanks to secure design and admin controls, organizations maintain full governance over which plugins are enabled and how they consume resources. In summary, Security Copilot’s open, plugin-based extensibility ensures that it can grow with an organization’s needs, incorporating any relevant third-party data or workflow to further enhance threat analysis and incident response.

Technical Resources:

Security Copilot RBAC for Embedded Experience in Unified Security Platform

SantoshPargi — Wed, 17 Jun 2026 11:10:30 GMT

Introduction

The evolution of Security Operations Centers (SOC) is increasingly driven by AI-powered capabilities that improve efficiency, accuracy, and response time. Microsoft Security Copilot represents a significant advancement in this space by embedding AI-driven assistance directly within security platforms such as Microsoft Defender XDR, Microsoft Sentinel, and Microsoft Entra.

The concept of embedded experience is central to this transformation. Rather than operating as a standalone interface, Security Copilot is integrated within existing security tools, allowing analysts to invoke AI-generated insights directly during investigations. This reduces the need for tool switching and accelerates decision-making.

The purpose of this document is to define and explain the Role-Based Access Control (RBAC) model required to securely enable this embedded experience. It provides a structured understanding of how access is governed across multiple layers, how these layers interact, and how organizations can align permissions with SOC workflows while maintaining a least-privilege security posture.

Understanding Embedded Experience

Security Copilot in embedded mode operates within the context of the host platform. When invoked from Defender or Sentinel, it does not function independently but instead consumes data already accessible to the user. This model ensures that Copilot enhances visibility without expanding access boundaries.

This behavior is governed by an On-Behalf-Of (OBO) model, where Security Copilot leverages the permissions of the authenticated user. It does not introduce new entitlements or override existing RBAC configurations.

As a result, the insights generated by Copilot are always limited to what the user is already authorized to see, reinforcing Zero Trust principles and preventing unauthorized data exposure.

Prerequisites for Embedded Experience

To enable Security Copilot in an embedded environment, organizations must establish foundational prerequisites that ensure seamless and secure operation.

First, access to underlying platforms such as Microsoft Defender XDR, Microsoft Sentinel, and Microsoft Entra must already be provisioned. Since Copilot is not a standalone data source, it cannot function without these integrations.

Second, RBAC alignment across identity, platform, and service layers must be configured correctly. Misalignment can lead to incomplete results, restricted functionality, or inconsistent analyst experiences.

Finally, governance processes such as access review, monitoring, and adherence to least privilege principles should be implemented. These controls ensure that Copilot usage remains compliant, auditable, and aligned with organizational security policies.

RBAC Framework for Security Copilot

Security Copilot adopts a multi-layer RBAC model consisting of three tightly integrated layers. These layers collectively determine whether a user can access Copilot features and what data they can retrieve.

RBAC Layer Mapping

RBAC Layer	Role Type	Purpose	Example Roles	Access Impact
Security Copilot Platform	Feature access control	Determines who can use Copilot capabilities	Security Copilot Owner, Security Copilot Contributor	Enables use of Copilot features but does not grant data access
Microsoft Entra ID	Identity and directory governance	Controls access to identity data and reports	Security Reader, Reports Reader, Security Administrator	Governs identity insights and directory visibility
Service-Specific RBAC	Data access control	Defines access to security data within services	Defender Security Reader, Sentinel Reader	Determines what Copilot can retrieve and present

This layered approach ensures that no single role grants full access. All three layers must align for complete functionality.

Security Copilot Platform Roles

Security Copilot platform roles control who can interact with the Copilot interface and execute AI-driven workflows.

The Security Copilot Owner role provides administrative control over Copilot configuration, including access management and platform-level settings. This role is typically assigned to administrators responsible for governance and operational enablement.

The Security Copilot Contributor role enables analysts to run prompts, perform investigations, and interact with Copilot features during daily SOC operations. However, this role does not grant visibility into security data by itself.

This clear separation ensures that Copilot remains a controlled interface layer rather than a source of privilege escalation.

Microsoft Entra ID Roles

Microsoft Entra roles govern access to identity-related data, which is critical for security operations involving user behavior, sign-in logs, and directory insights.

Roles such as Security Reader provide read-only visibility into security data, while Reports Reader enables access to reporting and analytics capabilities. In certain advanced cases, the Security Administrator role may be required for configuration-level actions.

The document emphasizes avoiding excessive privilege assignment, particularly the use of Global Administrator roles for daily operations, as this conflicts with least privilege principles.

Service-Specific RBAC Roles

Service-level roles determine the data sources that Security Copilot can access when embedded in platforms.

In Microsoft Defender XDR, roles such as Security Reader allow access to alerts, incidents, and endpoint data. In Microsoft Sentinel, Sentinel Reader provides access to log data, analytics, and incidents. In Microsoft Entra, roles like Reports Reader provide access to identity insights.

Copilot cannot retrieve or analyze data beyond what these roles permit. The output it generates is always constrained to the user’s effective permissions across these services.

Unified RBAC Behavior in Embedded Experience

In an embedded scenario, all three RBAC layers are evaluated simultaneously.

When a SOC analyst invokes Copilot in Defender, the system validates whether the user has permission to use Copilot, access identity data, and retrieve Defender-specific insights. Only when all these conditions are satisfied does Copilot provide a comprehensive output.

This ensures that Copilot responses are both contextually rich and access-compliant, eliminating the risk of unauthorized data exposure while maintaining operational efficiency.

Security Copilot Core Use Cases

Security Copilot enables a layered set of capabilities that span both analyst interaction patterns and agent-driven execution models. These use cases collectively enhance SOC efficiency, decision-making, and operational scalability.

Use Case Mapping Table

Use Case	Description	Embedded / Agent Example	Value to SOC
Summarization	Transforms complex alerts, incidents, and telemetry into structured, human-readable insights by correlating signals across multiple sources	Summarizing a Defender XDR incident involving endpoint, identity, and cloud alerts into a unified attack narrative	Reduces analyst fatigue and significantly accelerates triage by eliminating manual data aggregation
Guided Response	Provides contextual, step-by-step investigative guidance and recommended remediation actions based on observed patterns and threat intelligence	Suggesting investigation paths in Sentinel, including pivoting to identity logs, device timeline, and lateral movement indicators	Improves consistency in investigations and enables less experienced analysts to operate effectively
Script Analysis	Evaluates scripts, queries, and command-line activities to identify malicious patterns, errors, or optimization opportunities	Analyzing PowerShell scripts or KQL queries used in threat hunting scenarios to detect obfuscation or suspicious logic	Enhances detection accuracy and reduces the risk of missing critical indicators
Reporting	Generates structured incident summaries, executive reports, and compliance-ready documentation with contextual insights	Producing incident summaries for leadership or compliance teams with both technical and business context	Improves communication, supports audit readiness, and reduces manual reporting overhead

Agent-Driven SOC Use Cases (Expanded Capabilities)

With the introduction of Security Copilot agents, the platform extends beyond assistance into orchestrated, intelligence-driven operations across SOC workflows.

Agent-Based Use Case	Description	Real Agent Example	SOC Impact
Dynamic Threat Detection	Continuously analyzes telemetry to identify previously undetected or weak signals across the attack surface	Dynamic Threat Detection Agent correlates signals across Defender workload telemetry to surface hidden threats	Improves detection coverage and reduces the likelihood of missed attacks
Threat Intelligence Correlation & Briefing	Aggregates internal and external intelligence sources to generate contextual threat insights aligned to organizational risk	Threat Intelligence Briefing Agent produces structured intelligence reports based on attack patterns and exposure context	Enhances situational awareness and supports proactive defense strategies
Advanced Threat Hunting	Enables hypothesis-driven and AI-assisted threat hunting by generating queries, exploring telemetry, and correlating historical data	Advanced Threat Hunting Agent builds and executes queries across Defender and Sentinel datasets for proactive investigation and telemetry exploration	Accelerates threat discovery and reduces reliance on manual query development
Security Analysis & Threat Prioritization	Performs AI-driven analysis of security telemetry to identify high-risk patterns, prioritize threats, assess risk exposure, and recommend investigative actions	Security Analyst Agent analyses password spray attacks, ransomware activity, malware campaigns, identity abuse, and other security risks by generating telemetry-driven assessments and recommendations	Improves analyst productivity, prioritizes high-impact threats, and enables faster decision making
Security Triage Automation	Automates alert prioritization and classification by adding contextual enrichment and reducing noise	Security Triage Agent / Phishing Triage Agent evaluates alerts and distinguishes between real threats and false positives	Reduces alert fatigue and improves prioritization accuracy in high-volume environments
End-to-End Investigation Orchestration	Performs multi-step investigation by gathering signals, correlating activity, and building attack timelines	Security Analyst Agent investigates incidents across identity, endpoint, email, cloud, and data signals to produce a consolidated incident narrative	Reduces Mean Time to Investigate (MTTI) and ensures consistent investigation outcomes
Cross-Domain Threat Correlation	Connects signals across identity, endpoint, cloud, email, and data domains to identify multi-stage attack chains	Agents operating across Defender, Entra, Sentinel, and Security Copilot correlate activities such as phishing leading to identity compromise and lateral movement	Breaks down silos and enables holistic threat visibility across the environment
Remediation & Response Enablement	Identifies vulnerable assets and supports remediation workflows through contextual recommendations	Agents integrated with endpoint and policy systems suggest patching actions, containment actions, and configuration changes based on detected risks	Improves response effectiveness and strengthens overall security posture

Each of these use cases operates within the RBAC boundaries defined earlier, ensuring secure and context-aware outputs.

Mapping Use Cases to SOC Processes

The four core use cases align directly with SOC operational stages, enabling a consistent and repeatable analysis model.

Summarization plays a significant role during the detection and triage phase, where analysts need quick clarity on incoming alerts. Instead of manually analyzing raw data, Copilot provides a structured overview, helping analysts determine priority and relevance.

Guided response becomes critical during the investigation and response phase, where decision-making speed is essential. By suggesting next steps and correlating data points, Copilot assists analysts in navigating complex attack scenarios.

Script analysis supports both threat hunting and investigation, allowing analysts to validate scripts, queries, or automation logic. This reduces the risk of overlooking malicious behavior embedded in scripts.

Reporting aligns with the post-incident and compliance phase, where structured documentation is required. Copilot generates summaries that can be shared with leadership or compliance teams, ensuring clarity and consistency.

Together, these use cases create a continuous cycle of detection, investigation, response, and reporting, fully integrated with SOC workflows.

Summary

Security Copilot’s embedded experience represents a transformative shift in how AI is integrated into security operations. By embedding intelligence directly within platforms such as Defender and Sentinel, it enhances analyst productivity while maintaining strict governance controls.

The three-layer RBAC model, consisting of Security Copilot roles, Microsoft Entra roles, and service-specific roles, ensures that access is both secure and compliant with least privilege principles. The On-Behalf-Of model further guarantees that Copilot does not expand access beyond existing permissions.

The inclusion of structured use cases such as summarization, guided response, script analysis, and reporting enables organizations to operationalize Copilot effectively across SOC processes.

When RBAC is properly aligned and integrated with SOC workflows, Security Copilot becomes a powerful enabler of faster investigations, improved accuracy, and enhanced security posture—all while maintaining strict control over data access and governance.

Automating Daily MDE Compliance Monitoring Across Azure VMs

SayanRoy — Mon, 15 Jun 2026 11:52:45 GMT

The Problem We’re Solving

Most security teams have no automated way to know when a VM silently falls out of MDE coverage, whether because the agent stopped, the VM was newly provisioned without onboarding, or the device stopped reporting. This Logic App closes that gap and puts the right information in front of the right people every day.

Disclaimer: This solution is designed for Azure Virtual Machines only. For non-Azure VMs onboarded to Microsoft Defender for Endpoint through Azure Arc, a separate companion blog will be published soon to cover that scenario.

What changes once you deploy this

Challenge Without This Logic App	How This Logic App Helps
Security gaps go undetected for days or weeks	Any VM that is not onboarded or has stopped reporting is caught within 24 hours of the daily run
No automated owner notification	The VM's ServerOwner tag is read automatically, and the owner is emailed directly with full compliance details
VMs with no owner fall through the cracks	Flagged explicitly in the IT summary report with instructions for how to assign the tag
Manual compliance reporting is time-consuming	Full CSV report auto-attached to every daily IT summary; no manual extraction needed
Agents silently stop reporting after onboarding	Detects "Onboarded, Not Reporting" as a distinct status, separate from "Not Onboarded"
Large multi-subscription environments are hard to cover	Paginated queries across all enabled subscriptions; every running VM is checked

Compliance States Detected

Compliance Status	Priority	What It Means
Not Onboarded	P2, High	The VM is running in Azure but has never appeared in MDE. There is zero security telemetry for this machine.
Onboarded, Not Reporting	P3, Medium	The VM was previously enrolled but has not checked in within the configured window. The MDE agent may be stopped or the VM may have lost network connectivity to MDE.
Compliant	No alert	VM is onboarded and checked in within the required time window. It is excluded from all notifications.

Running VMs Only: This workflow queries Azure Resource Graph with a filter of powerState == "VM running". Deallocated, stopped, and powered-off VMs are intentionally excluded — they are not expected to report to MDE while offline. Only machines that are turned on are evaluated.

Workflow Architecture

The workflow runs as a sequential daily pipeline. All Azure VM data and MDE device data are collected into memory first, then each VM is evaluated in a single For Each loop.

Execution Pipeline

Recurrence trigger fires daily at 08:00 IST.
CONFIG compose action reads MDE_LASTSEEN_HOURS (default 24). This defines the compliance window: how recently a VM must have reported to MDE to be considered Compliant.
Init-varITTeamEmail and Init-varSenderEmail load the configurable email addresses used for sending and receiving notifications.
Get-AllSubscriptions calls the Azure Management API to discover all subscriptions in the tenant.
ForEach-Subscription runs a paginated Azure Resource Graph query per enabled subscription, collecting all running VMs along with Private IP, OS Type, Location, ServerOwner tag, and VM UUID.
Init-MDEVariables then Paginate-MDEDevices call the MDE Security Center API in pages of 10,000 to load every enrolled device into the AllMDEDevices array.
ForEach-AzureVM looks each Azure VM up in AllMDEDevices and determines compliance status and priority.
Non-compliant handling builds HTML and CSV rows. If the VM has a ServerOwner tag, a compliance alert email goes to the owner with the IT Team CC'd. If there's no owner, the VM is appended to NoOwnerList.
IT Summary email is sent once all VMs are processed. If any non-compliant VMs were found, the consolidated IT report is sent with the CSV attachment. Otherwise an All Clear email is sent.

How Azure VM Data is Matched to MDE Data

Each Azure VM is matched against the MDE device list using a two-level strategy. Both checks run for every VM on every run.

Match Method	How It Works
Primary: Azure VM ID	Compares azureVmId from the MDE device record (lowercase) against the VmId captured from Azure Resource Graph (lowercase). Immune to hostname changes; this is the preferred match.
Fallback: Hostname + IP	Checks that MDE computerDnsName starts with the Azure VM name (case-insensitive) AND lastIpAddress matches the Azure Private IP. Both conditions must be true.
Not Found	A synthetic MDE record with onboardingStatus: "NotFound" is created. The VM is treated as Not Onboarded and a P2 High alert is raised.

Pagination Design

The workflow handles large environments through two independent pagination mechanisms that run before any compliance evaluation begins.

Data Source	Page Size	Mechanism
Azure Resource Graph	1,000 VMs per page	Uses $skipToken from the response. The Until loop re-queries with the token until no token is returned (last page). Variables VMSkipToken and VMFetchComplete manage loop state per subscription. Supports up to 50,000 VMs (50 pages).
MDE Security Center API	10,000 devices per page	Uses the $skip offset parameter. MDESkip is incremented by 10,000 each iteration. The loop stops when a page returns fewer than 10,000 records. Supports up to 500,000 MDE devices (50 pages × 10,000).

Prerequisites
Azure Resources

Resource	Requirement	Notes
Azure Logic App	Standard plan, Stateful workflow	Consumption plan also supported
Managed Identity	System-assigned on the Logic App	Enable under Logic App > Identity
Sender mailbox (varSenderEmail)	Licensed Microsoft 365 account	Emails are sent FROM this address
IT Team email (varITTeamEmail)	Valid email address or distribution list	Receives all reports; CC'd on owner alerts
Azure VMs	Running, with ServerOwner tag (recommended)	Tag value must be a valid email address
MDE licensing	Microsoft Defender for Endpoint P1 or P2	Tenant must be enrolled in MDE

The ServerOwner Tag

Server owner notifications rely on a VM-level Azure tag. Without it, the VM is included in the IT summary, but no individual alert is sent to an owner.

Tag Name	Expected Value	Effect
ServerOwner	Valid email, e.g. john@yourcompany.com	Compliance alert sent TO this address; IT Team CC'd

If the tag is missing or empty, the VM is flagged in the Action Required: No Owner Tag Found section of the IT summary email, with step-by-step instructions for tagging it in the Azure Portal.

Required Permissions & Why

The Logic App's Managed Identity must be granted three API permissions. These are Application permissions that cannot be assigned through the Azure Portal UI, so the PowerShell script in Section 4.3 must be used. Admin consent is required.

Permission Summary

Permission	API / Service	AppId	Why It Is Required
user_impersonation	Azure Management	797f4846-ba00-4fd7-ba43-dac1f8f63013	Allows the Managed Identity to call the Azure Resource Graph API to query VM inventory across all subscriptions. Without this, the workflow cannot discover VMs.
WindowsDefenderATP.Read.All	MDE Security Center	fc780465-2017-40d4-a0c5-307022471b92	Allows reading all device records from the MDE API (/api/machines). This returns onboarding status, last seen time, and health status — the core compliance data.
Mail.Send	Microsoft Graph	00000003-0000-0000-c000-000000000000	Allows sending emails via the Graph /sendMail endpoint on behalf of the varSenderEmail mailbox. Without this, no alerts or reports can be sent.

Important: The Azure Management and MDE permissions belong to separate service principals — they are NOT part of Microsoft Graph. Each permission must be assigned to its own service principal using the AppId shown above. The script in Section 4.2 handles this correctly.

Where to find the required values

Parameter	Where to find it in Azure Portal
$tenantID	Azure Portal > Microsoft Entra ID > Overview > Tenant ID
$managedIdentityObjectId	Logic App > Settings > Identity > System assigned tab > Object (principal) ID

Permission Assignment Script

Run this in Azure Cloud Shell or any terminal with the Microsoft.Graph PowerShell module installed. Update $tenantID and $managedIdentityObjectId before running.

# PowerShell # ── Update these two values before running ─────────────────────────── $tenantID = "<tenantID>" # Your Tenant ID $managedIdentityObjectId = "<objectID>" # MI Object ID # Install Microsoft.Graph if not already present if (!(Get-Module -ListAvailable -Name Microsoft.Graph)) { Install-Module -Name Microsoft.Graph -Scope CurrentUser -Force } # Connect to Microsoft Graph Connect-MgGraph -TenantId $tenantID ` -Scopes "AppRoleAssignment.ReadWrite.All","Application.Read.All" # MDE Compliance Logic App needs 3 permissions across 3 different service principals $permissions = @( @{ Permission="user_impersonation"; AppId="797f4846-ba00-4fd7-ba43-dac1f8f63013" }, @{ Permission="WindowsDefenderATP.Read.All"; AppId="fc780465-2017-40d4-a0c5-307022471b92" }, @{ Permission="Mail.Send"; AppId="00000003-0000-0000-c000-000000000000" } ) foreach ($entry in $permissions) { $sp = Get-MgServicePrincipal -Filter "AppId eq '$($entry.AppId)'" $appRole = $sp.AppRoles | Where-Object { $_.Value -eq $entry.Permission } if ($appRole -ne $null) { New-MgServicePrincipalAppRoleAssignment ` -ServicePrincipalId $sp.Id ` -PrincipalId $managedIdentityObjectId ` -ResourceId $sp.Id ` -AppRoleId $appRole.Id Write-Host "Assigned: $($entry.Permission)" -ForegroundColor Green } else { Write-Host "Not found: $($entry.Permission)" -ForegroundColor Yellow } } Write-Host "All permissions assigned." -ForegroundColor Green

Verify Permissions Assigned

# PowerShell # Run after the assignment script to verify all 3 permissions are present Get-MgServicePrincipalAppRoleAssignment ` -ServicePrincipalId $managedIdentityObjectId | Select-Object AppRoleId, PrincipalDisplayName | Format-Table -AutoSize

Note: You should see three assignment rows in the output — one for each permission. If any are missing, re-run the assignment script. An error saying the assignment already exists is normal and can be safely ignored.

Creating the Logic App
Create the resource

Azure Portal > search Logic Apps > + Create.
Select your Subscription and Resource Group. Logic App name: la-mde-compliance-monitor.
Plan type: Standard > Windows > select or create a Hosting Plan > Review + Create > Create.
Once deployed, click Go to resource.

Enable System-assigned Managed Identity

Open the Logic App > left menu: Settings > Identity.
On the System assigned tab, toggle Status to On.
Click Save > Yes on the confirmation dialog.
The Object (principal) ID appears. Copy this value for the PowerShell script.
Run the Permissions Assignment script to assign all three permissions to this identity.

Why Managed Identity: A System-assigned Managed Identity is automatically scoped to this Logic App and deleted when the Logic App is deleted. It authenticates to Azure Management API, MDE API, and Microsoft Graph without any stored passwords or client secrets.

Create the workflow and import the JSON

Logic App > left menu: Workflows > + Add.
Workflow name: MDEComplianceMonitor. State type: Stateful. Click Create.
Click the workflow name > left menu: Code.
Press Ctrl + A > Delete to clear the editor completely.
Paste the complete workflow JSON from the companion file (see Appendix A).
Click Save. It should succeed with no validation errors.

Important: Always use Stateful. Stateless workflows do not support run history, have a 5-minute timeout, and do not retain intermediate state — all of which are required by this workflow's pagination loops.

Configuration: What You Can Change

After importing the JSON, update only the values described below. Everything else runs automatically.

Email Address Variables

Variable	Description	Where to Update
varITTeamEmail	The IT Team email address. All IT Summary reports are sent TO this address. All per-VM owner emails CC this address.	3000
varSenderEmail	The Microsoft 365 licensed account that emails are sent FROM via Graph API. Must have Mail.Send permission granted to the Managed Identity.	3000

Compliance look-up window: MDE_LASTSEEN_HOURS

This setting in the CONFIG compose action defines how recently a VM must have reported to MDE to count as Compliant. Default is 24 hours.

Value	Behaviour
24 (default)	Compliant if the VM checked in with MDE within the last 24 hours. Recommended starting point.
12	Stricter check; suitable for high-security environments requiring near-real-time coverage.
48	More relaxed; suitable for environments with scheduled maintenance windows or intermittent connectivity.

Running VMs Only

The Azure Resource Graph query includes a filter for powerState == "VM running". This means:

Deallocated VMs are excluded (not expected to report to MDE while offline).
Stopped (allocated) VMs are excluded.
Newly started VMs are included and checked on the next daily run.

To Change the Filter: To change the power state filter, locate the "query" string inside the Build-VMQuery-Paged action and modify the | where powerState == clause. For example, removing the filter entirely will check all VMs regardless of state.

Sample Email Notifications

The screenshots below show actual emails generated by this workflow. All sensitive data (email addresses, VM names, subscription IDs, IP addresses) has been redacted.

Per-VM owner alert

Sent to the server owner (ServerOwner tag) when their VM is non-compliant. The IT Team is CC'd. The email contains full server details, compliance status, priority, last MDE check-in time, and resolution SLA.

Note: If no ServerOwner tag is set the VM is skipped here and included in the "No Owner Tag Found" section of the IT summary instead.

IT Team Daily Summary Report

Sent once per day to the IT Team after all owner emails are dispatched. Shows up to 20 VMs inline with a full CSV attachment containing the complete list, plus a dedicated section for VMs with no owner tag.

Note: The CSV attachment always contains the complete list of all non-compliant VMs regardless of count. The inline HTML table is limited to 20 rows to keep the email size manageable.

All Compliant VMs:

If all VMs are compliant, you’ll see email like this:

Post-Deployment Checklist

Before you leave the workflow running unattended, walk through this checklist once.

#	Item
1	Logic App resource created (Standard plan, Stateful workflow)
2	System-assigned Managed Identity enabled; Object ID copied
3	PowerShell script run; user_impersonation, WindowsDefenderATP.Read.All, and Mail.Send assigned
4	Permissions verified using Get-MgServicePrincipalAppRoleAssignment (3 rows expected)
5	Workflow JSON pasted into Code view; saved without validation errors
6	varITTeamEmail updated to your IT security team or distribution list address
7	varSenderEmail updated to a licensed Microsoft 365 mailbox
8	MDE_LASTSEEN_HOURS reviewed (default 24, adjust if needed)
9	At least one Azure VM has the ServerOwner tag set with a valid email
10	Manual run triggered: Logic App > Overview > Run Trigger > Run
11	Run history shows Succeeded; no 401 or 403 errors on any HTTP action
12	IT Team received the daily summary email with CSV attachment
13	Server owner received a per-VM alert with the IT Team CC'd
14	Recurrence trigger confirmed running daily at 08:00 IST

Wrapping Up

What I love about this is how much it accomplishes with so little: a Logic App, a Managed Identity, and three permissions. No connectors, no secrets to rotate, no third-party services. Yet every morning, your security team starts the day knowing exactly which VMs are out of MDE coverage and which owners have already been notified.

If you adopt this pattern, here are a few natural next steps to consider:

Hook into Microsoft Sentinel by writing non-compliant VMs to a custom table for trend analysis.
Auto-create ServiceNow or Jira tickets for VMs that remain non-compliant for more than 48 hours.
Extend the match logic to include Arc-enabled servers, not just Azure VMs.
Add a Teams adaptive card notification alongside email for faster response.

I'd love to hear how you're solving MDE coverage gaps in your environment.

Appendix A: Workflow JSON

The complete Logic App workflow definition is provided below. To import it: open the Logic App in Azure Portal, navigate to the workflow, click Code view, press Ctrl + A to clear the existing content, paste the entire JSON, then click Save.

{ "definition": { "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#", "contentVersion": "1.0.0.0", "triggers": { "Recurrence": { "recurrence": { "frequency": "Day", "interval": 1, "schedule": { "hours": [ "8" ], "minutes": [ 0 ] }, "timeZone": "India Standard Time" }, "evaluatedRecurrence": { "frequency": "Day", "interval": 1, "schedule": { "hours": [ "8" ], "minutes": [ 0 ] }, "timeZone": "India Standard Time" }, "type": "Recurrence" } }, "actions": { "CONFIG": { "runAfter": {}, "type": "Compose", "inputs": { "MDE_LASTSEEN_HOURS": 24 } }, "Set-ExcludedSubscriptions": { "runAfter": { "CONFIG": [ "Succeeded" ] }, "type": "Compose", "inputs": [] }, "Init-varITTeamEmail": { "runAfter": { "Set-ExcludedSubscriptions": [ "Succeeded" ] }, "type": "InitializeVariable", "inputs": { "variables": [ { "name": "varITTeamEmail", "type": "string", "value": "admin@contoso.onmicrosoft.com" } ] } }, "Init-varSenderEmail": { "runAfter": { "Init-varITTeamEmail": [ "Succeeded" ] }, "type": "InitializeVariable", "inputs": { "variables": [ { "name": "varSenderEmail", "type": "string", "value": "admin@contoso.onmicrosoft.com" } ] } }, "Get-AllSubscriptions": { "runAfter": { "Init-varSenderEmail": [ "Succeeded" ] }, "type": "Http", "inputs": { "uri": "https://management.azure.com/subscriptions?api-version=2022-12-01", "method": "GET", "headers": { "Content-Type": "application/json" }, "authentication": { "type": "ManagedServiceIdentity", "audience": "https://management.azure.com" }, "retryPolicy": { "type": "fixed", "count": 3, "interval": "PT60S" } } }, "Parse-AllSubscriptions": { "runAfter": { "Get-AllSubscriptions": [ "Succeeded" ] }, "type": "ParseJson", "inputs": { "content": "@body('Get-AllSubscriptions')", "schema": { "type": "object", "properties": { "value": { "type": "array", "items": { "type": "object", "properties": { "subscriptionId": { "type": "string" }, "displayName": { "type": "string" }, "state": { "type": "string" } } } } } } } }, "Init-AllVMs": { "runAfter": { "Parse-AllSubscriptions": [ "Succeeded" ] }, "type": "InitializeVariable", "inputs": { "variables": [ { "name": "AllVMs", "type": "array", "value": [] }, { "name": "VMSkipToken", "type": "string", "value": "INIT" }, { "name": "VMFetchComplete", "type": "boolean", "value": false } ] } }, "ForEach-Subscription": { "foreach": "@body('Parse-AllSubscriptions')?['value']", "actions": { "Check-SubscriptionEnabled": { "actions": { "Reset-VMSkipToken": { "type": "SetVariable", "inputs": { "name": "VMSkipToken", "value": "INIT" } }, "Reset-VMFetchComplete": { "runAfter": { "Reset-VMSkipToken": [ "Succeeded" ] }, "type": "SetVariable", "inputs": { "name": "VMFetchComplete", "value": false } }, "Until": { "actions": { "Build-VMQuery-Paged": { "type": "Compose", "inputs": { "subscriptions": [ "@{items('ForEach-Subscription')?['subscriptionId']}" ], "query": "Resources | where type == 'microsoft.compute/virtualmachines' | extend VMName = tostring(name), ResourceGroup = tostring(resourceGroup), Location = tostring(location), OSType = tostring(properties.storageProfile.osDisk.osType), VMSize = tostring(properties.hardwareProfile.vmSize), ServerOwner = tostring(tags.ServerOwner), Environment = tostring(tags.Environment), SubscriptionId = tostring(subscriptionId), nicId = tolower(tostring(properties.networkProfile.networkInterfaces[0].id)), VmId = tolower(tostring(properties.vmId)) | join kind=leftouter (Resources | where type == 'microsoft.network/networkinterfaces' | extend privateIP = tostring(properties.ipConfigurations[0].properties.privateIPAddress) | project nicId = tolower(id), privateIP) on nicId | join kind=leftouter (Resources | where type == 'microsoft.compute/virtualmachines' | extend powerState = tostring(properties.extended.instanceView.powerState.displayStatus) | project id, powerState) on id | where powerState == 'VM running' | project VMName, ResourceGroup, Location, OSType, VMSize, ServerOwner, Environment = 'Azure', SubscriptionId, PrivateIP = privateIP, VmId, CloudEnvironment = 'Azure'", "options": { "$skipToken": "@if(equals(variables('VMSkipToken'), 'INIT'), '', variables('VMSkipToken'))" }, "$top": 1000 } }, "Get-VMs-Paged": { "runAfter": { "Build-VMQuery-Paged": [ "Succeeded" ] }, "type": "Http", "inputs": { "uri": "https://management.azure.com/providers/Microsoft.ResourceGraph/resources?api-version=2021-03-01", "method": "POST", "headers": { "Content-Type": "application/json" }, "body": "@outputs('Build-VMQuery-Paged')", "authentication": { "type": "ManagedServiceIdentity", "audience": "https://management.azure.com" } }, "runtimeConfiguration": { "contentTransfer": { "transferMode": "Chunked" } } }, "ForEach-VM-Result-Paged": { "foreach": "@body('Get-VMs-Paged')?['data']", "actions": { "Append-SingleVM-Paged": { "type": "AppendToArrayVariable", "inputs": { "name": "AllVMs", "value": "@items('ForEach-VM-Result-Paged')" } } }, "runAfter": { "Get-VMs-Paged": [ "Succeeded" ] }, "type": "Foreach" }, "Check-VMSkipToken": { "actions": { "Set-VMFetchComplete": { "type": "SetVariable", "inputs": { "name": "VMFetchComplete", "value": true } } }, "runAfter": { "ForEach-VM-Result-Paged": [ "Succeeded" ] }, "else": { "actions": { "Set-VMSkipToken": { "type": "SetVariable", "inputs": { "name": "VMSkipToken", "value": "@body('Get-VMs-Paged')?['$skipToken']" } } } }, "expression": { "or": [ { "equals": [ "@string(body('Get-VMs-Paged')?['$skipToken'])", "" ] } ] }, "type": "If" } }, "runAfter": { "Reset-VMFetchComplete": [ "Succeeded" ] }, "expression": "@equals(variables('VMFetchComplete'), true)", "limit": { "count": 50, "timeout": "PT1H" }, "type": "Until" } }, "else": { "actions": {} }, "expression": { "and": [ { "equals": [ "@items('ForEach-Subscription')?['state']", "Enabled" ] } ] }, "type": "If" } }, "runAfter": { "Init-AllVMs": [ "Succeeded" ] }, "type": "Foreach" }, "Init-MDEVariables": { "runAfter": { "ForEach-Subscription": [ "Succeeded" ] }, "type": "InitializeVariable", "inputs": { "variables": [ { "name": "AllMDEDevices", "type": "array" }, { "name": "MDESkip", "type": "integer", "value": 0 }, { "name": "MDEFetchComplete", "type": "boolean", "value": false } ] } }, "Paginate-MDEDevices": { "actions": { "Get-MDEDevices-Page": { "type": "Http", "inputs": { "uri": "https://api.securitycenter.microsoft.com/api/machines?$select=computerDnsName,id,osPlatform,lastSeen,onboardingStatus,healthStatus,lastIpAddress&$top=10000&$skip=@{variables('MDESkip')}", "method": "GET", "headers": { "Content-Type": "application/json" }, "authentication": { "type": "ManagedServiceIdentity", "audience": "https://api.securitycenter.microsoft.com" }, "retryPolicy": { "type": "fixed", "count": 3, "interval": "PT60S" } }, "runtimeConfiguration": { "contentTransfer": { "transferMode": "Chunked" } } }, "Parse-MDEPage": { "runAfter": { "Get-MDEDevices-Page": [ "Succeeded" ] }, "type": "ParseJson", "inputs": { "content": "@body('Get-MDEDevices-Page')", "schema": { "type": "object", "properties": { "value": { "type": "array", "items": { "type": "object", "properties": { "computerDnsName": { "type": [ "string", "null" ] }, "id": { "type": [ "string", "null" ] }, "osPlatform": { "type": [ "string", "null" ] }, "lastSeen": { "type": [ "string", "null" ] }, "onboardingStatus": { "type": [ "string", "null" ] }, "healthStatus": { "type": [ "string", "null" ] }, "lastIpAddress": { "type": [ "string", "null" ] }, "azureVmId": { "type": [ "string", "null" ] } } } } } } } }, "Append-MDEPage-ToArray": { "foreach": "@body('Parse-MDEPage')?['value']", "actions": { "Append-SingleMDEDevice": { "type": "AppendToArrayVariable", "inputs": { "name": "AllMDEDevices", "value": "@items('Append-MDEPage-ToArray')" } } }, "runAfter": { "Parse-MDEPage": [ "Succeeded" ] }, "type": "Foreach" }, "Check-PageSize": { "actions": { "Set-FetchComplete-True": { "type": "SetVariable", "inputs": { "name": "MDEFetchComplete", "value": true } } }, "runAfter": { "Append-MDEPage-ToArray": [ "Succeeded" ] }, "else": { "actions": { "Increment-MDESkip": { "type": "IncrementVariable", "inputs": { "name": "MDESkip", "value": 10000 } } } }, "expression": { "and": [ { "less": [ "@length(body('Parse-MDEPage')?['value'])", 10000 ] } ] }, "type": "If" } }, "runAfter": { "Init-MDEVariables": [ "Succeeded" ] }, "expression": "@equals(variables('MDEFetchComplete'), true)", "limit": { "count": 50, "timeout": "PT1H" }, "type": "Until" }, "Init-Variables": { "runAfter": { "Paginate-MDEDevices": [ "Succeeded" ] }, "type": "InitializeVariable", "inputs": { "variables": [ { "name": "EmailsSent", "type": "array", "value": [] }, { "name": "NoOwnerList", "type": "array", "value": [] }, { "name": "NonCompliantList", "type": "array", "value": [] }, { "name": "SummaryStats", "type": "object", "value": { "TotalNonCompliant": 0, "P1Critical": 0, "P2High": 0, "P3Medium": 0, "P4Low": 0, "EmailsSent": 0, "NoOwnerFound": 0 } }, { "name": "HTMLRows", "type": "string" }, { "name": "NonCompliantCount", "type": "integer", "value": 0 }, { "name": "CSVRows", "type": "string", "value": "@{concat('\"VM Name\",\"Private IP\",\"OS Type\",\"Location\",\"Server Owner\",\"MDE Status\",\"Last Seen\",\"Priority\",\"Action Taken\",\"Subscription ID\"', decodeUriComponent('%0A'))}" }, { "name": "HTMLRowCount", "type": "integer", "value": 0 } ] } }, "ForEach-AzureVM": { "foreach": "@variables('AllVMs')", "actions": { "Find-VMInMDE-Filter": { "type": "Query", "inputs": { "from": "@variables('AllMDEDevices')", "where": "@or(and(not(equals(item()?['azureVmId'], null)), not(equals(item()?['azureVmId'], '')), equals(toLower(item()?['azureVmId']), toLower(items('ForEach-AzureVM')?['VmId']))), and(or(equals(item()?['azureVmId'], null), equals(item()?['azureVmId'], '')), startsWith(toLower(item()?['computerDnsName']), toLower(items('ForEach-AzureVM')?['VMName'])), equals(item()?['lastIpAddress'], items('ForEach-AzureVM')?['PrivateIP'])))" } }, "Find-VMInMDE": { "runAfter": { "Find-VMInMDE-Filter": [ "Succeeded" ] }, "type": "Compose", "inputs": "@if(greater(length(body('Find-VMInMDE-Filter')), 0), first(body('Find-VMInMDE-Filter')), json('{\"computerDnsName\":\"NOT_FOUND\",\"onboardingStatus\":\"NotFound\",\"lastSeen\":\"1900-01-01T00:00:00Z\",\"lastIpAddress\":\"N/A\",\"healthStatus\":\"Unknown\"}'))" }, "Get-ComplianceStatus": { "runAfter": { "Find-VMInMDE": [ "Succeeded" ] }, "type": "Compose", "inputs": "@if(equals(outputs('Find-VMInMDE')?['computerDnsName'], 'NOT_FOUND'), 'Not Onboarded', if(equals(outputs('Find-VMInMDE')?['onboardingStatus'], 'Onboarded'), if(greater(outputs('Find-VMInMDE')?['lastSeen'], addHours(utcNow(), mul(-1, outputs('CONFIG')?['MDE_LASTSEEN_HOURS']))), 'Compliant', 'Onboarded - Not Reporting'), 'Not Onboarded'))" }, "Get-Priority": { "runAfter": { "Get-ComplianceStatus": [ "Succeeded" ] }, "type": "Compose", "inputs": "@if(equals(outputs('Get-ComplianceStatus'), 'Not Onboarded'), 'P2 - High', if(equals(outputs('Get-ComplianceStatus'), 'Onboarded - Not Reporting'), 'P3 - Medium', if(equals(outputs('Get-ComplianceStatus'), 'Compliant'), 'Compliant', 'P4 - Low')))" }, "Is-NonCompliant": { "actions": { "Append-CSVRows": { "type": "AppendToStringVariable", "inputs": { "name": "CSVRows", "value": "\"@{items('ForEach-AzureVM')?['VMName']}\",\"@{if(equals(items('ForEach-AzureVM')?['PrivateIP'], ''), 'N/A', items('ForEach-AzureVM')?['PrivateIP'])}\",\"@{items('ForEach-AzureVM')?['OSType']}\",\"@{items('ForEach-AzureVM')?['Location']}\",\"@{if(equals(items('ForEach-AzureVM')?['ServerOwner'], ''), 'No Owner Tag', items('ForEach-AzureVM')?['ServerOwner'])}\",\"@{outputs('Get-ComplianceStatus')}\",\"@{if(equals(outputs('Find-VMInMDE')?['onboardingStatus'], 'Onboarded'), if(equals(outputs('Find-VMInMDE')?['lastSeen'], '1900-01-01T00:00:00Z'), 'Never', concat(convertTimeZone(outputs('Find-VMInMDE')?['lastSeen'], 'UTC', 'India Standard Time', 'dd-MM-yyyy HH:mm:ss'), ' (', string(div(sub(ticks(utcNow()), ticks(outputs('Find-VMInMDE')?['lastSeen'])), 864000000000)), ' days ago)')), concat(outputs('Find-VMInMDE')?['onboardingStatus'], ' - Last Seen: ', convertTimeZone(outputs('Find-VMInMDE')?['lastSeen'], 'UTC', 'India Standard Time', 'dd-MM-yyyy HH:mm:ss')))}\",\"@{outputs('Get-Priority')}\",\"@{if(equals(items('ForEach-AzureVM')?['ServerOwner'], ''), 'IT Team Notified', 'Email sent to Server Owner')}\",\"@{items('ForEach-AzureVM')?['SubscriptionId']}\"@{decodeUriComponent('%0A')}" } }, "Check-HTMLRowCount": { "actions": { "Append-HTMLRows": { "type": "AppendToStringVariable", "inputs": { "name": "HTMLRows", "value": "<tr><td style=\"padding:8px 10px;border:1px solid #ddd;font-weight:600;\">@{items('ForEach-AzureVM')?['VMName']}</td><td style=\"padding:8px 10px;border:1px solid #ddd;word-wrap:break-word;\">@{if(equals(items('ForEach-AzureVM')?['PrivateIP'], ''), 'N/A', items('ForEach-AzureVM')?['PrivateIP'])}</td><td style=\"padding:8px 10px;border:1px solid #ddd;word-wrap:break-word;\">@{items('ForEach-AzureVM')?['OSType']}</td><td style=\"padding:8px 10px;border:1px solid #ddd;word-wrap:break-word;\">@{items('ForEach-AzureVM')?['Location']}</td><td style=\"padding:8px 10px;border:1px solid #ddd;word-wrap:break-word;\">@{if(equals(items('ForEach-AzureVM')?['ServerOwner'], ''), 'No Owner Tag', items('ForEach-AzureVM')?['ServerOwner'])}</td><td style=\"padding:8px 10px;border:1px solid #ddd;color:#c80000;\">@{outputs('Get-ComplianceStatus')}</td><td style=\"padding:8px 10px;border:1px solid #ddd;word-wrap:break-word;\">@{if(equals(outputs('Find-VMInMDE')?['onboardingStatus'], 'Onboarded'), if(equals(outputs('Find-VMInMDE')?['lastSeen'], '1900-01-01T00:00:00Z'), 'Never', concat(convertTimeZone(outputs('Find-VMInMDE')?['lastSeen'], 'UTC', 'India Standard Time', 'dd-MM-yyyy HH:mm:ss'), ' (', string(div(sub(ticks(utcNow()), ticks(outputs('Find-VMInMDE')?['lastSeen'])), 864000000000)), ' days ago)')), concat(outputs('Find-VMInMDE')?['onboardingStatus'], ' - Last Seen: ', convertTimeZone(outputs('Find-VMInMDE')?['lastSeen'], 'UTC', 'India Standard Time', 'dd-MM-yyyy HH:mm:ss')))}</td><td style=\"padding:8px 10px;border:1px solid #ddd;word-wrap:break-word;\">@{outputs('Get-Priority')}</td><td style=\"padding:8px 10px;border:1px solid #ddd;word-wrap:break-word;\">@{if(equals(items('ForEach-AzureVM')?['ServerOwner'], ''), 'IT Team Notified', 'Email sent to Server Owner')}</td><td style=\"padding:8px 10px;border:1px solid #ddd;word-break:break-all;\">@{items('ForEach-AzureVM')?['SubscriptionId']}</td></tr>" } }, "Increment-HTMLRowCount": { "runAfter": { "Append-HTMLRows": [ "Succeeded" ] }, "type": "IncrementVariable", "inputs": { "name": "HTMLRowCount", "value": 1 } } }, "runAfter": { "Append-CSVRows": [ "Succeeded" ] }, "else": { "actions": {} }, "expression": { "and": [ { "less": [ "@variables('HTMLRowCount')", 20 ] } ] }, "type": "If" }, "Increment-NonCompliantCount": { "runAfter": { "Check-HTMLRowCount": [ "Succeeded" ] }, "type": "IncrementVariable", "inputs": { "name": "NonCompliantCount", "value": 1 } }, "Check-ServerOwner": { "actions": { "Send-OwnerEmail": { "type": "Http", "inputs": { "uri": "@{concat('https://graph.microsoft.com/v1.0/users/', encodeURIComponent(variables('varSenderEmail')), '/sendMail')}", "method": "POST", "headers": { "Content-Type": "application/json" }, "body": { "message": { "subject": "[@{outputs('Get-Priority')}] MDE Compliance Alert - @{items('ForEach-AzureVM')?['VMName']}", "body": { "contentType": "HTML", "content": "<html><body style=\"font-family:Segoe UI,Arial,sans-serif;color:#1a1a1a;\"><div style=\"max-width:680px;margin:24px auto;border:1px solid #e0e0e0;border-radius:8px;overflow:hidden;\"><div style=\"background:#c80000;padding:20px 28px;\"><h2 style=\"color:#fff;margin:0;\">MDE Compliance Alert</h2><p style=\"color:#ffcccc;margin:6px 0 0;font-size:13px;\">Priority: @{outputs('Get-Priority')}</p></div><div style=\"padding:28px;\"><p style=\"margin-top:0;font-size:14px;\">Your server <strong>@{items('ForEach-AzureVM')?['VMName']}</strong> has a Microsoft Defender for Endpoint compliance issue requiring immediate attention.</p><table style=\"width:100%;border-collapse:collapse;font-size:14px;\"><thead><tr style=\"background:#f5f5f5;\"><th style=\"text-align:left;padding:10px 14px;border:1px solid #ddd;width:38%;\">Field</th><th style=\"text-align:left;padding:10px 14px;border:1px solid #ddd;word-wrap:break-word;\">Value</th></tr></thead><tbody><tr><td style=\"padding:9px 14px;border:1px solid #ddd;font-weight:600;\">Server Name</td><td style=\"padding:9px 14px;border:1px solid #ddd;word-wrap:break-word;\">@{items('ForEach-AzureVM')?['VMName']}</td></tr><tr style=\"background:#fafafa;\"><td style=\"padding:9px 14px;border:1px solid #ddd;font-weight:600;\">Private IP</td><td style=\"padding:9px 14px;border:1px solid #ddd;word-wrap:break-word;\">@{if(equals(items('ForEach-AzureVM')?['PrivateIP'], ''), 'N/A', items('ForEach-AzureVM')?['PrivateIP'])}</td></tr><tr><td style=\"padding:9px 14px;border:1px solid #ddd;font-weight:600;\">OS Type</td><td style=\"padding:9px 14px;border:1px solid #ddd;word-wrap:break-word;\">@{items('ForEach-AzureVM')?['OSType']}</td></tr><tr style=\"background:#fafafa;\"><td style=\"padding:9px 14px;border:1px solid #ddd;font-weight:600;\">Location</td><td style=\"padding:9px 14px;border:1px solid #ddd;word-wrap:break-word;\">@{items('ForEach-AzureVM')?['Location']}</td></tr><tr><td style=\"padding:9px 14px;border:1px solid #ddd;font-weight:600;\">Compliance Status</td><td style=\"padding:9px 14px;border:1px solid #ddd;color:#c80000;font-weight:700;\">@{outputs('Get-ComplianceStatus')}</td></tr><tr style=\"background:#fafafa;\"><td style=\"padding:9px 14px;border:1px solid #ddd;font-weight:600;\">Priority</td><td style=\"padding:9px 14px;border:1px solid #ddd;font-weight:700;\">@{outputs('Get-Priority')}</td></tr><tr><td style=\"padding:9px 14px;border:1px solid #ddd;font-weight:600;\">MDE Onboarding Status</td><td style=\"padding:9px 14px;border:1px solid #ddd;word-wrap:break-word;\">@{outputs('Find-VMInMDE')?['onboardingStatus']}</td></tr><tr style=\"background:#fafafa;\"><td style=\"padding:9px 14px;border:1px solid #ddd;font-weight:600;\">Last Seen in MDE (IST)</td><td style=\"padding:9px 14px;border:1px solid #ddd;word-wrap:break-word;\">@{if(equals(outputs('Find-VMInMDE')?['lastSeen'], '1900-01-01T00:00:00Z'), 'Never', concat(convertTimeZone(outputs('Find-VMInMDE')?['lastSeen'], 'UTC', 'India Standard Time', 'dd-MM-yyyy HH:mm:ss'), ' (', string(div(sub(ticks(utcNow()), ticks(outputs('Find-VMInMDE')?['lastSeen'])), 864000000000)), ' days ago)'))}</td></tr><tr><td style=\"padding:9px 14px;border:1px solid #ddd;font-weight:600;\">Resource Group</td><td style=\"padding:9px 14px;border:1px solid #ddd;word-wrap:break-word;\">@{items('ForEach-AzureVM')?['ResourceGroup']}</td></tr><tr style=\"background:#fafafa;\"><td style=\"padding:9px 14px;border:1px solid #ddd;font-weight:600;\">Subscription ID</td><td style=\"padding:9px 14px;border:1px solid #ddd;word-break:break-all;\">@{items('ForEach-AzureVM')?['SubscriptionId']}</td></tr></tbody></table><br/><table style=\"width:100%;border-collapse:collapse;\"><tr style=\"background:#fff8e1;\"><td style=\"padding:10px 14px;border:1px solid #ffe082;font-size:13px;\"><strong>Resolution SLA:</strong> P1 Critical - 24hrs | P2 High - 48hrs | P3 Medium - 72hrs</td></tr></table><br/><p style=\"font-size:13px;color:#555;\">For assistance contact IT Security: <a href=\"mailto:@{variables('varITTeamEmail')}\">@{variables('varITTeamEmail')}</a></p></div></div></body></html>" }, "toRecipients": [ { "emailAddress": { "address": "@{items('ForEach-AzureVM')?['ServerOwner']}" } } ], "ccRecipients": [ { "emailAddress": { "address": "@variables('varITTeamEmail')" } } ] }, "saveToSentItems": "true" }, "authentication": { "type": "ManagedServiceIdentity", "audience": "https://graph.microsoft.com" }, "retryPolicy": { "type": "fixed", "count": 2, "interval": "PT60S" } }, "runtimeConfiguration": { "contentTransfer": { "transferMode": "Chunked" } } }, "Append-EmailsSent": { "runAfter": { "Send-OwnerEmail": [ "Succeeded" ] }, "type": "AppendToArrayVariable", "inputs": { "name": "EmailsSent", "value": "@{items('ForEach-AzureVM')?['VMName']} → @{items('ForEach-AzureVM')?['ServerOwner']}" } } }, "runAfter": { "Increment-NonCompliantCount": [ "Succeeded" ] }, "else": { "actions": { "Append-NoOwnerList": { "type": "AppendToArrayVariable", "inputs": { "name": "NoOwnerList", "value": "<tr><td style=\"padding:8px 10px;border:1px solid #ddd;font-weight:600;\">@{items('ForEach-AzureVM')?['VMName']}</td><td style=\"padding:8px 10px;border:1px solid #ddd;word-wrap:break-word;\">@{if(equals(items('ForEach-AzureVM')?['PrivateIP'], ''), 'N/A', items('ForEach-AzureVM')?['PrivateIP'])}</td><td style=\"padding:8px 10px;border:1px solid #ddd;word-wrap:break-word;\">@{outputs('Get-ComplianceStatus')}</td><td style=\"padding:8px 10px;border:1px solid #ddd;font-weight:700;\">@{outputs('Get-Priority')}</td></tr>" } } } }, "expression": { "and": [ { "not": { "equals": [ "@items('ForEach-AzureVM')?['ServerOwner']", "" ] } } ] }, "type": "If" } }, "runAfter": { "Get-Priority": [ "Succeeded" ] }, "else": { "actions": {} }, "expression": { "and": [ { "not": { "equals": [ "@outputs('Get-ComplianceStatus')", "Compliant" ] } } ] }, "type": "If" } }, "runAfter": { "Init-Variables": [ "Succeeded" ] }, "type": "Foreach", "runtimeConfiguration": { "concurrency": { "repetitions": 1 } } }, "Check-AnyNonCompliant": { "actions": { "Send-ITSummaryEmail": { "type": "Http", "inputs": { "uri": "@{concat('https://graph.microsoft.com/v1.0/users/', encodeURIComponent(variables('varSenderEmail')), '/sendMail')}", "method": "POST", "headers": { "Content-Type": "application/json" }, "body": { "message": { "subject": "MDE Compliance Report (Azure Workloads) - @{variables('NonCompliantCount')} Non-Compliant VMs Found", "body": { "contentType": "HTML", "content": "<html><body style=\"font-family:Segoe UI,Arial,sans-serif;color:#1a1a1a;\"><div style=\"max-width:1400px;margin:24px auto;border:1px solid #e0e0e0;border-radius:8px;\"><div style=\"background:#0078d4;padding:20px 28px;\"><h2 style=\"color:#fff;margin:0;\">MDE Compliance Daily Report</h2><p style=\"color:#cce4ff;margin:6px 0 0;font-size:13px;\">Generated: @{convertTimeZone(utcNow(), 'UTC', 'India Standard Time', 'dd-MM-yyyy HH:mm:ss')} IST</p></div><div style=\"padding:28px;\"><table style=\"border-collapse:collapse;font-size:14px;margin-bottom:28px;\"><thead><tr style=\"background:#f0f0f0;\"><th style=\"padding:10px 18px;border:1px solid #ddd;word-wrap:break-word;\">Metric</th><th style=\"padding:10px 18px;border:1px solid #ddd;word-wrap:break-word;\">Value</th></tr></thead><tbody><tr><td style=\"padding:9px 18px;border:1px solid #ddd;word-wrap:break-word;\">Total Non-Compliant VMs</td><td style=\"padding:9px 18px;border:1px solid #ddd;font-weight:700;color:#c80000;\">@{variables('NonCompliantCount')}</td></tr><tr style=\"background:#fafafa;\"><td style=\"padding:9px 18px;border:1px solid #ddd;word-wrap:break-word;\">Server Owners Notified</td><td style=\"padding:9px 18px;border:1px solid #ddd;color:#107c10;font-weight:600;\">@{length(variables('EmailsSent'))}</td></tr><tr><td style=\"padding:9px 18px;border:1px solid #ddd;word-wrap:break-word;\">No Owner Tag</td><td style=\"padding:9px 18px;border:1px solid #ddd;color:#e65100;font-weight:600;\">@{length(variables('NoOwnerList'))}</td></tr></tbody></table><p style=\"background:#fff3cd;border:1px solid #ffc107;padding:10px 14px;border-radius:4px;font-size:13px;margin-bottom:16px;\">This report shows the first <strong>20 non-compliant VMs</strong> only. <strong>Please check the attached CSV file</strong> for the complete list.</p><table style=\"width:100%;table-layout:fixed;border-collapse:collapse;font-size:13px;\"><colgroup><col style=\"width:120px\"><col style=\"width:90px\"><col style=\"width:70px\"><col style=\"width:100px\"><col style=\"width:160px\"><col style=\"width:110px\"><col style=\"width:165px\"><col style=\"width:80px\"><col style=\"width:90px\"><col style=\"width:195px\"></colgroup><thead><tr style=\"background:#0078d4;color:#fff;\"><th style=\"padding:10px 12px;border:1px solid #005a9e;\">VM Name</th><th style=\"padding:10px 12px;border:1px solid #005a9e;\">Private IP</th><th style=\"padding:10px 12px;border:1px solid #005a9e;\">OS Type</th><th style=\"padding:10px 12px;border:1px solid #005a9e;\">Location</th><th style=\"padding:10px 12px;border:1px solid #005a9e;\">Server Owner</th><th style=\"padding:10px 12px;border:1px solid #005a9e;\">MDE Status</th><th style=\"padding:10px 12px;border:1px solid #005a9e;\">Last Seen (IST)</th><th style=\"padding:10px 12px;border:1px solid #005a9e;\">Priority</th><th style=\"padding:10px 12px;border:1px solid #005a9e;\">Action Taken</th><th style=\"padding:10px 12px;border:1px solid #005a9e;\">Subscription ID</th></tr></thead><tbody>@{variables('HTMLRows')}</tbody></table><br/><h3 style=\"border-bottom:2px solid #e65100;padding-bottom:8px;\">Action Required - No Owner Tag Found</h3><div style=\"background:#fff8f0;border:1px solid #ffccbc;padding:16px;border-radius:4px;font-size:13px;margin-bottom:16px;\"><p style=\"margin:0 0 8px 0;\">The following <strong>@{length(variables('NoOwnerList'))}</strong> server(s) have no <strong>ServerOwner</strong> tag assigned.</p><ol style=\"margin:0;padding-left:20px;\"><li style=\"margin-bottom:6px;\">Identify the owner of each server below</li><li style=\"margin-bottom:6px;\">Go to the VM in Azure Portal → Tags → Add tag</li><li style=\"margin-bottom:6px;\"><strong>Tag Name:</strong> ServerOwner | <strong>Tag Value:</strong> owner email address</li><li>Once tagged, the next daily report will automatically notify the owner</li></ol></div><table style=\"width:100%;table-layout:fixed;border-collapse:collapse;font-size:13px;\"><thead><tr style=\"background:#e65100;color:#fff;\"><th style=\"padding:10px 12px;border:1px solid #bf360c;text-align:left;\">VM Name</th><th style=\"padding:10px 12px;border:1px solid #bf360c;text-align:left;\">Private IP</th><th style=\"padding:10px 12px;border:1px solid #bf360c;text-align:left;\">MDE Status</th><th style=\"padding:10px 12px;border:1px solid #bf360c;text-align:left;\">Priority</th></tr></thead><tbody>@{if(equals(length(variables('NoOwnerList')), 0), '<tr><td colspan=\"4\" style=\"padding:12px;text-align:center;\">None - All servers have owner tags assigned</td></tr>', join(variables('NoOwnerList'), ''))}</tbody></table></div></div></body></html>" }, "toRecipients": [ { "emailAddress": { "address": "@variables('varITTeamEmail')" } } ], "attachments": [ { "@@odata.type": "#microsoft.graph.fileAttachment", "name": "@{concat('MDE-Compliance-Report-', convertTimeZone(utcNow(), 'UTC', 'India Standard Time', 'dd-MM-yyyy'), '.csv')}", "contentType": "text/csv", "contentBytes": "@{base64(variables('CSVRows'))}" } ] }, "saveToSentItems": "true" }, "authentication": { "type": "ManagedServiceIdentity", "audience": "https://graph.microsoft.com" } }, "runtimeConfiguration": { "contentTransfer": { "transferMode": "Chunked" } } } }, "runAfter": { "ForEach-AzureVM": [ "Succeeded" ] }, "else": { "actions": { "Send-AllClearEmail": { "type": "Http", "inputs": { "uri": "@{concat('https://graph.microsoft.com/v1.0/users/', encodeURIComponent(variables('varSenderEmail')), '/sendMail')}", "method": "POST", "headers": { "Content-Type": "application/json" }, "body": { "message": { "subject": "[@{convertTimeZone(utcNow(), 'UTC', 'India Standard Time', 'dd-MM-yyyy')}] MDE Compliance Report - All VMs Compliant", "body": { "contentType": "HTML", "content": "<html><body style=\"font-family:Segoe UI,Arial,sans-serif;color:#1a1a1a;\"><div style=\"max-width:600px;margin:24px auto;border:1px solid #e0e0e0;border-radius:8px;overflow:hidden;\"><div style=\"background:#107c10;padding:20px 28px;\"><h2 style=\"color:#fff;margin:0;\">MDE Compliance Report</h2><p style=\"color:#c8e6c9;margin:6px 0 0;font-size:13px;\">Generated: @{convertTimeZone(utcNow(), 'UTC', 'India Standard Time', 'dd-MM-yyyy HH:mm:ss')} IST</p></div><div style=\"padding:28px;text-align:center;\"><h2 style=\"color:#107c10;\">All VMs Compliant</h2><p style=\"font-size:15px;color:#555;\">All Azure Virtual Machines are onboarded to Microsoft Defender for Endpoint and reporting within the required 24-hour window.</p><p style=\"font-size:13px;color:#888;\">No action required. The next report will be sent tomorrow at 08:00 IST.</p></div></div></body></html>" }, "toRecipients": [ { "emailAddress": { "address": "@variables('varITTeamEmail')" } } ] }, "saveToSentItems": "true" }, "authentication": { "type": "ManagedServiceIdentity", "audience": "https://graph.microsoft.com" } }, "runtimeConfiguration": { "contentTransfer": { "transferMode": "Chunked" } } } } }, "expression": { "and": [ { "greater": [ "@variables('NonCompliantCount')", 0 ] } ] }, "type": "If" } }, "parameters": { "$connections": { "type": "Object", "defaultValue": {} } } }, "parameters": { "$connections": { "type": "Object", "value": {} } } }

Analyse Intune Diagnostics Logs with GitHub Copilot

StefanRöll — Thu, 11 Jun 2026 12:15:59 GMT

Hello everyone! I’m Stefan Röll, Cloud Solution Architect at Microsoft Germany for Cloud Endpoints. I work closely with IT Admins to improve their experience with everything around Intune, W365 and Windows. I know that troubleshooting an issue can be time consuming and challenging. In this blog I would like to show you how your troubleshooting skills can be supercharged with AI.

TL;DR

The way I troubleshoot issues has completely changed with GitHub Copilot. I just provide it with Intune Diagnostics Logs, network traces etc. and let the magic happen. The output still requires deep technical skills, but finding the root cause of an issue is just way faster and easier now.

GitHub Copilot – not only for developers

GitHub Copilot is best known for helping developers to write and fix code.

But it also has tremendous debugging and troubleshooting skills. And the best part is that it only takes two minutes to set up and you will never go back trying to manually find an issue if you must work through a lot of log files.

Getting started in two minutes

Let’s get started:

Go to https://github.com/features/copilot/plans and get a GitHub Copilot Subscription. If you are interested in Business or Enterprise subscriptions, please reach out to your Customer Success Account Manager (CSAM) or sales team to get started. It is also likely that you company already has subscriptions that you can get internally.

Once you’ve got your subscription, Install GitHub Copilot CLI via terminal:

winget install GitHub.Copilot

Now you can start Copilot via the command:

copilot

Next, type

/login

and log in with your GitHub account.

Now you should add the Microsoft Learn MCP Server and the included skills. This helps Copilot to search through the Microsoft documentation.

You can do this with:

/plugin install microsoftdocs/mcp

Copilot is ready for your first troubleshooting session! 🎉

Example #1 – Why did our PCs restart during the day?

Let’s start with a typical scenario: “All our PCs restarted during business hours. Can you please find the root cause for this?”

Before Copilot, you had to manually check multiple places to find the root cause. Was it triggered by a Windows update, an app update, a driver issue, or another hidden background process?

Now the only thing we need are Intune Diagnostics logs. Simply go to your Intune Console and collect diagnostics:

Once they are uploaded, download the .zip file to a local folder like C:\Temp\CopilotAnalysis.

Next, open a command prompt and go to the folder with the extracted files and start Copilot

cd C:\Temp\CopilotAnalysis copilot

With “Shift + TAB” we switch over to the “Autopilot” mode of GitHub Copilot. This will tell Copilot to do its magic without asking for confirmation for each step. You can find more information about this mode here: https://docs.github.com/en/copilot/concepts/agents/copilot-cli/autopilot

If you don’t want that, you can also continue in normal mode, but expect a lot of confirmation prompts.

With a simple prompt, we can create a deep root cause analysis, and Copilot will use the provided diagnostics logs:

Based on the provided Intune Diagnostics logs, find out why the Windows 11 PC rebooted automatically during business hours. Once you have found the issue, confirm your findings with the configured Microsoft Learn MCP Server. Then create a Root Cause Analysis Report and save it as HTML in the same folder. Include a timeline with relevant events in the report. Extract all needed files like .zip, .cab that you need for the analysis.

Now you can watch Copilot working through the logs and after some minutes you will get a report like this:

Here we go. You can see that the reboot was caused by a misconfigured Intune app deployment.

⚠️Please be aware that AI can make mistakes. Never blindly trust the output, especially any recommendations for how to fix an issue. ⚠️

However, now we have a fantastic starting point. In this case, Copilot correctly identified the root cause and we can fix this in Intune

It also created the requested timeline

Example #2 – Why did the Autopilot deployment fail?

When Autopilot deployments fail, it can be hard to troubleshoot as you may not have the affected device in front of you. Therefore, it is great that Intune automatically uploads diagnostics logs when this happens. In this example, an Autopilot deployment failed, and we are going to analyse the logs with Copilot.

I downloaded the logs to a new folder, opened the terminal, navigated to the folder, and started Copilot:

Now I am going to analyse this with a different prompt:

Analyse the provided Intune Diagnostics logs and find out why this Windows 11 Autopilot deployment failed. Once you have found the issue, confirm your findings with the configured Microsoft Learn MCP Server. Then create a Root Cause Analysis Report and save it as HTML in the same folder. Include a timeline with relevant events in the report. Extract all needed files like .zip, .cab that you need for the analysis.

After a beverage of choice, I had much more clarity on what happened:

Root cause: Enrollment Status Page (ESP) remained blocked in Account setup by a required user-targeted WinGet app that did not complete download/install during the observed log window. The blocking app was Sysinternals Suite - Req - All Users (Win32App_9c514d25-f55e-4177-af53-ca5ebbcf2619, package 9P7KNL5RWT25).

Remarks

In this blog, I did not cover different models, credits, better prompting, and other improvements you can make to optimise the analysis. I wanted to give IT Pros a quick start with GitHub Copilot CLI.

Summary

I highly recommend that you try GitHub Copilot yourself the next time you need to troubleshoot an issue. You will be amazed at how good it is at finding the root cause of an issue. This works with all kinds of log files, network traces, and more.

GitHub Copilot does not replace endpoint expertise, but it can dramatically reduce the time needed to move from raw diagnostics to a validated root-cause hypothesis.

I hope this blog helped you get started😊

Stefan Röll

Cloud Solution Architect – Microsoft Germany

Helpful resources and references:

https://learn.microsoft.com/en-us/training/support/mcp

https://learn.microsoft.com/en-us/training/support/mcp-get-started

https://github.com/features/copilot/plans

https://github.com/features/copilot/cli

Disclaimer:

This posting is provided "AS IS" with no warranties and confers no rights

At-Scale Failure Reporting for Azure Update Manager

rajeshkumar30 — Thu, 11 Jun 2026 06:32:42 GMT

Introduction

Azure Update Manager simplifies patching across Azure virtual machines and Azure Arc-enabled servers by providing a centralized platform for patch assessment and installation. However, as environments scale, a key challenge emerges—efficiently identifying and troubleshooting patch failures across large fleets of machines.

While Azure Update Manager surfaces detailed error messages in the Azure portal, this information is typically available only at an individual machine level.

In enterprise environments managing hundreds or thousands of systems, drilling into each VM to find error details quickly becomes impractical.

In this article, we walk through a real-world use case and demonstrate how to leverage Azure Resource Graph (ARG) to extract failed machines along with their error details for a specific maintenance run—using a single query.

The Challenge: Scaling Patch Failure Visibility

In a large enterprise deployment, Azure Update Manager was configured to manage patching across:

Windows and Linux virtual machines
Azure cloud VMs and Arc-enabled on‑premises servers
Multiple regions and subscriptions

While patching operations were largely successful, a subset of machines experienced failures. The key challenges faced by the operations team were:

Error messages were visible only by drilling into each failed VM in the portal
No built‑in way to aggregate failures across all machines
Lack of a simple mechanism to export:
- Failed VMs
- Error codes
- Error messages

The team needed a scalable, query‑driven approach to analyze failures across an entire maintenance run.

Key Insight: Where Azure Update Manager Stores Data

Azure Update Manager does not rely on Log Analytics to store operational results. Instead:

Patch assessment and installation results are stored in Azure Resource Graph
Azure Resource Graph acts as a centralized, queryable store for update operations

This design enables powerful querying without requiring additional ingestion, configuration, or cost overhead.

Understanding Maintenance Runs and Correlation IDs

Each Azure Update Manager maintenance run generates a unique identifier:

properties.correlationId represents the maintenance (schedule) run ID
All machines involved in the same patch cycle share this ID

This allows all machines within a single patch execution to be correlated and queried collectively.

The Solution: Query Failed VMs with Error Messages

Azure Resource Graph allows querying failures at scale using the maintenanceresources dataset.

Core Query (Kusto Query Language)

1 maintenanceresources

2 | where type =~ "microsoft.maintenance/applyupdates"

3 | where tostring(properties.correlationId) contains "<YourMaintenanceRunID>"

4 | where tostring(properties.status) =~ "Failed"

5 | project properties.resourceId, properties.errorCode, properties.errorMessage

What This Query Delivers

All machines that failed in a specific maintenance run
Error codes for troubleshooting
Full error messages that are otherwise visible only in the Azure portal

Note: Property names for error information can vary by environment. Validate available fields using Azure Resource Graph Explorer and adjust the project clause if required.

Sample Output (Conceptual)

Resource ID	Error Code	Error Message
vm-01	0x80244007	Windows Update API failed
vm-02	0x80072f8f	Connectivity issue
vm-03	1C	WSUS configuration issue

Advanced Scenario: Automatically Detecting the Latest Failed Maintenance Run

In real-world scenarios, you may not always know the maintenance run ID. The following query dynamically identifies the most recent maintenance run that had failures, and then retrieves all failed machines from that run.

1 // Step 1: Identify the latest maintenance run ID with failures

2 let lastFailedRun = toscalar(

3 maintenanceresources

4 | extend runId = extract(@"applyupdates/(\d+)$", 1, properties.correlationId)

5 | where type =~ "microsoft.maintenance/applyupdates"

6 | where tostring(properties.status) =~ "Failed"

7 | order by tostring(properties.startDateTime) desc

8 | take 1

9 | project runId

10 );

11 // Step 2: Query all failed VMs from that run

12 maintenanceresources

13 | where type =~ "microsoft.maintenance/applyupdates"

14 | where tostring(properties.correlationId) contains lastFailedRun

15 | where tostring(properties.status) =~ "Failed"

16 | project properties.resourceId, properties.errorCode, properties.errorMessage

This approach is ideal for automation, scheduled reporting, and dashboard scenarios.

Why This Approach Matters

Operational Efficiency

Eliminates manual portal navigation
Provides consolidated failure insights in seconds

Scalability

Works across large, distributed environments
Supports both Azure and hybrid (Arc‑enabled) machines

Automation Ready

Can be integrated into scripts, dashboards, and reporting pipelines
Enables proactive monitoring and alerting scenarios

Best Practices for Enterprise Patch Reporting

To maximize the value of this approach:

Capture and track maintenance run IDs
Use Azure Resource Graph as the primary reporting layer
Build reusable queries for different patch scenarios
Export reports for compliance and auditing
Correlate failures with root‑cause trends over time

Conclusion

As organizations scale patching operations with Azure Update Manager, visibility, speed, and automation become essential. While the Azure portal is effective for per‑machine troubleshooting, it is not optimized for fleet‑level analysis.

Azure Resource Graph fills this gap by enabling a shift from manual troubleshooting to automated, query‑driven failure analysis at scale. By adopting this approach, teams can significantly improve operational efficiency, reduce mean time to resolution, and build a more mature patch management strategy.

Final takeaway:

Don’t rely only on the portal
Leverage Azure Resource Graph to operationalize patch insights at enterprise scale

References

Azure Update Manager – Query resources with Azure Resource Graph
https://learn.microsoft.com/azure/update-manager/query-logs
Azure Update Manager – Troubleshooting guide
https://learn.microsoft.com/azure/update-manager/troubleshoot
Sample Azure Resource Graph queries for Azure Update Manager
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/update-manager/sample-query-logs.md

Redefining Security for an AI Driven World

edgarus71 — Fri, 22 May 2026 21:14:55 GMT

Vendors are being challenged to help customers address these challenges not as a point-solution vendor but as an end-to-end security and AI platform partner. By integrating identity, data governance, threat protection, and AI services into a unified ecosystem, Microsoft can deliver coordinated defenses, continuous compliance monitoring, and operational efficiency gains that fragmented toolsets cannot match. The sections that follow examine each challenge in depth — why it persists, what makes it hard, and specifically how Microsoft helps organizations bridge the gap.

Challenge 1: Safeguarding Data Privacy in the AI Era

AI systems are voracious consumers of data, and their adoption is outpacing the governance structures meant to protect it. More than 80% of business leaders cite leakage of sensitive data as their primary concern with generative AI, and nearly 48% have responded by banning all use of GenAI in the workplace entirely. Meanwhile, AI is raising the value of human-generated data as a critical training input while introducing entirely new avenues for potential data leakage through models and AI-powered applications.

Why This Challenge Persists

Fragmented tooling is the most immediate obstacle. Organizations are managing security, compliance, and data governance through disconnected platforms, creating siloed visibility that undermines cohesive protection. Only 31% of organizations have established a global data architecture, and just 25% maintain a global data quality program — two foundations essential for trustworthy AI innovation. Without enterprise-wide data classification and access controls, AI systems cannot distinguish what is too sensitive to surface.

At the same time, shadow AI compounds the risk. When employees turn to unapproved AI tools to boost productivity, sensitive data can flow to services outside IT's purview. According to Microsoft's guide on securing the AI-powered enterprise, 80% of business leaders worry that sensitive data could slip through the cracks due to unchecked AI use. AI models also inherit the permissions of their users, meaning an over-permissioned employee can unknowingly expose critical data to an AI system. Gartner has estimated that by 2025, generative AI will account for 10% of all data produced, further blurring the boundary between what is corporate-controlled and what is AI-generated.

Regulatory stakes add urgency: Gartner projects that by 2027, at least one global company will see its AI deployment banned by a regulator for non-compliance with data protection or AI governance legislation.

How can organizations bridge the gap?

Microsoft Purview provides a unified platform that combines data classification, data loss prevention (DLP), and AI-specific posture management to address fragmentation head-on. Its Data Security Posture Management (DSPM) for AI centralizes visibility into how AI applications interact with sensitive data across the organization — including Microsoft 365 Copilot, enterprise AI apps, and third-party AI tools. Security teams can see, for example, how many unlabeled files were referenced by Copilot and where the greatest concentrations of unprotected data reside.

Sensitivity labels created in Purview travel with documents and are enforced at inference time: when an AI app retrieves a file labeled "Highly Confidential," the system ensures the requesting user holds the required EXTRACT and VIEW usage rights before returning data. In practice, an executive running a Copilot query on a labeled strategy document would see the sensitivity label clearly marked alongside the response. Purview's DLP policies now extend to AI scenarios directly, including inline browser protection that can block or warn users attempting to paste sensitive data into third-party generative AI sites such as ChatGPT in Microsoft Edge, Chrome, or Firefox.

For organizations handling the most sensitive workloads, Azure Confidential Computing protects data even while it is being processed, using hardware-based Trusted Execution Environments (TEEs) that keep information encrypted in memory — invisible even to cloud operators. This capability is especially relevant for AI training and inference on regulated data, where customers need verifiable proof that their information was never exposed in plaintext during processing.

The net result is defense-in-depth for data: discover where sensitive information lives, classify it so AI systems respect boundaries, enforce policies at the point of AI interaction, and encrypt data in use for the highest-risk scenarios — all governed through a single compliance surface.

Challenge 2: The AI-Weaponized Threat Landscape

Adversaries are using AI to accelerate, scale, and personalize attacks faster than traditional defenses can respond. In the past year, 67% of all phishing attacks employed some form of AI, and organizations now face an average of 66 data security alerts per day — up from 52 in 2023. Under this pressure, 73% of cybersecurity experts admit they have missed, ignored, or failed to respond to high-priority security alerts.

Why This Challenge Persists

The speed differential is the core problem. AI-enabled threat actors can now use models to autonomously discover, chain, and exploit vulnerabilities, compressing the window from discovery to exploitation from months to hours. Attackers leverage generative AI for malware generation, automated vulnerability scanning, customized exploits, password cracking, sophisticated phishing and social engineering, and deepfake-based impersonation of data, email, and voice.

At the same time, AI systems themselves introduce novel attack surfaces. A staggering 88% of organizations, according to a Gartner Peer Community survey of 332 participants, are concerned about indirect prompt injection attacks — where malicious instructions embedded in data manipulate an AI's behavior to reveal confidential information or bypass controls. AI models are also susceptible to fabrications, initially known as hallucinations, in essence biased outputs, and data poisoning — risks that traditional vulnerability management frameworks were never designed to address.

From an operational standpoint, SOC analysts already spend nearly three hours per day on incidents, accumulating costs that reach billions in aggregate. Layering AI-driven attacks on top of this existing overload threatens to break conventional security operations entirely.

How can organizations bridge the gap?

Microsoft counters the asymmetry with AI-powered defense at cloud scale, grounded in threat intelligence no single organization could replicate alone. Microsoft processes more than 100 trillion security signals per day from endpoints, cloud services, identity systems, and the edge, and tracks 1,500 unique threat actor groups — including 600 nation-state actors, 300 cybercrime groups, and 200 influence operations groups. This intelligence feeds directly into detection models and product updates, ensuring customers benefit from patterns observed across billions of users and devices worldwide.

Microsoft Security Copilot is the most visible expression of this strategy. A generative AI security assistant combining advanced OpenAI models with a Microsoft-developed security-specific model, it helps analysts investigate and remediate incidents in natural language — from triaging complex alerts into actionable summaries, to reverse-engineering malicious scripts, to generating KQL queries for threat hunting. Early deployment data shows that Defender XDR customers using Security Copilot experienced a 30% reduction in incident resolution time in just three months.

For securing AI models themselves, Microsoft Defender for Cloud now offers AI model security (in public preview since March 2026), which scans custom AI models in Azure Machine Learning registries and workspaces for embedded malware, unsafe operators, and exposed secrets — integrated directly into CI/CD pipelines so risky models are stopped before reaching production.

The Microsoft Digital Defense Report 2025 reinforced this posture with seven top recommendations, led by managing cyber risk at the boardroom level, prioritizing identity protection, and investing in people alongside tools. Microsoft's approach treats AI threats not as a separate domain but as an intensification of the broader threat landscape that demands coordinated, platform-level defense.

Challenge 3: Identity and Access Governance for AI Agents

AI is creating an entirely new class of digital actors that most identity systems were never designed to manage. According to IDC, there will be approximately 1.3 billion AI agents operating across enterprises by 2028. These agents — which range from simple automation bots to fully autonomous decision-making systems — require resource access, generate data, and interact with users and services in ways that fundamentally differ from traditional applications or human users.

Why This Challenge Persists

Most organizations lack lifecycle management, ownership models, and policy controls for non-human identities, and AI agents amplify these gaps significantly. Industry analysts argue that AI agents should not be treated as just another non-human identity; they introduce complex delegation chains between humans, agents, and services that require distinct identity, accountability, and audit models. Traditional human-in-the-loop controls may not scale for agentic systems, yet new identity-centric governance mechanisms are only beginning to emerge.

Compounding the issue, the indeterministic nature of large language models means that an AI agent with broad access privileges may behave unpredictably — potentially taking actions its developers did not anticipate. Without proper controls, forgotten or orphaned agent identities can become easy targets for attackers, and the resulting security incidents may be difficult to attribute or contain.

How can organizations bridge the gap?

Microsoft extends its identity-first Zero Trust architecture to AI through Microsoft Entra Agent ID (in public preview). The core idea: every AI agent receives a unique, first-class identity — discoverable, manageable, and securable alongside human users, applications, and devices. Once registered, an agent's access can be scoped using the same enterprise-grade controls as any other identity: conditional access policies, role-based access control, lifecycle governance, and risk-based protection.

Conditional Access for Agents allows organizations to evaluate an agent's context and risk level before granting a token. Policies can enforce controls such as restricting agents to specific network locations or blocking access when risk signals are elevated. Microsoft is also developing RBAC guardrails specifically tailored to AI agent behaviors, acknowledging that LLM-based agents present heightened risk when granted broad role assignments.

For lifecycle management, Microsoft provides mechanisms for IT administrators to create automated lifecycle policies for agent identities — including periodic attestation by designated sponsors, automated cleanup of unmonitored agents, and notifications when agent identities approach expiration. This directly addresses the "agent sprawl" problem identified by CISOs and security architects.

At a broader level, Microsoft Agent 365 delivers a unified control plane for agents, aggregating posture, and real-time risk signals from Defender, Entra, and Purview into a single dashboard — providing discovery of both Microsoft and third-party agents, AI posture tracking, and governance controls to delegate remediation tasks to the appropriate teams. The Security Dashboard for AI (in GA now) answers the executive-level questions: Which AI assets exist in our environment? What is their current security posture? Where must we take action? — covering Microsoft 365 Copilot, Copilot Studio agents, Foundry apps, and third-party AI including Google Gemini, OpenAI ChatGPT, and MCP servers

Challenge 4: Regulatory Compliance and Ethical AI Governance

The regulatory landscape for AI is evolving faster than most organizations can track, and the stakes — legal, financial, and reputational — are escalating. More than 52% of business leaders admit they are unsure how to navigate rapidly evolving AI regulations. Frameworks like the EU AI Act (whose first obligations took effect on February 2, 2025), GDPR, and sector-specific rules such as DORA are converging to create a compliance environment that demands continuous adaptation.

Why This Challenge Persists

The EU AI Act alone adopts a risk-based approach to AI regulation, classifying systems by their potential impact on health, safety, and fundamental rights and imposing corresponding obligations for documentation, transparency, human oversight, and testing. Organizations must map every AI deployment to the correct risk category — and misclassification can lead to regulatory violations. Simultaneously, the responsibilities of security leaders are expanding to include governance and regulatory compliance oversight that traditionally belonged to legal or compliance teams.

The NC State University Executive Perspectives on Top Risks survey of 1,540 board members and C-suite executives ranked regulatory uncertainty and fragmentation as the eighth-highest near-term risk (2026–2028), and AI implementation risks as sixth. Among AI-specific concerns, 24% of respondents identified lack of governance and accountability for AI deployments as a top three worry. Culturally, building internal consensus around what constitutes "responsible" AI use — across diverse business units with different risk appetites — remains a persistent organizational challenge.

How can organizations bridge the gap?

Microsoft's Responsible AI program, anchored by six durable principles established in 2018 — Fairness, Reliability & Safety, Privacy & Security, Inclusiveness, Transparency, and Accountability — provides a governance blueprint that has proven stable even as AI technology evolves rapidly. These principles shape design, deployment, and oversight choices across Microsoft's products, and the company shares the lessons openly through its 2025 Responsible AI Transparency Report and customer guidance.

In preparing for the EU AI Act specifically, Microsoft has taken a proactive, layered approach to compliance, conducting impact assessments and adversarial red teaming on high-risk models and systems, and extending its Sensitive Uses governance program to ensure additional oversight for the most consequential AI deployments. Microsoft has also documented its approach to EU AI Act implementation to help customers understand how its products and services are being built to comply.

Operationally, the Security Dashboard for AI provides board-ready analytics and compliance insights, aggregating risk signals across Entra, Defender, and Purview into a single executive view with recommendations and direct remediation paths. This makes AI governance visible and actionable within the same tools security leaders already use for broader risk management.

Microsoft also fosters community-driven governance through initiatives like the Security for AI Accelerated Collaboration Forum (ACF), which brings together CISOs, security architects, SOC leaders, identity and data owners, and platform engineers to share challenges, shape roadmap priorities, and develop reusable governance frameworks.

Challenge 5: Integration Complexity and Workforce Readiness

Even when the right AI security tools exist, most organizations struggle to integrate them into existing technology stacks and to equip their people to use them effectively. Among executives surveyed by NC State University, 31% identified integrating AI with existing technologies, business processes, and workforce as a top-three AI concern, 29% pointed to equipping the workforce to realize AI's value proposition, and 28% flagged the inability to deploy AI at a competitive pace.

Why This Challenge Persists

Years of tool proliferation have left enterprises with fragmented security architectures. Organizations rely on disconnected platforms for endpoint protection, cloud workload security, identity management, and data governance — and AI capabilities are now being added to each domain independently. Microsoft's own research notes that organizations using fragmented platforms across security, compliance, and data teams see exacerbated security outcomes. When a data loss prevention alert in one system cannot be correlated with an identity anomaly in another, threats slip through.

At the same time, AI security as a discipline lacks comprehensive resources and seasoned experts. Because major cloud AI platforms only became generally available in 2021–2023, organizations must often develop protective measures without much external guidance or established precedent. The cybersecurity workforce shortage is well documented; the additional demand for professionals who understand both machine learning and security compounds it further.

The broader threat environment amplifies the urgency: cyberthreats have grown 5X in scale, Microsoft now tracks over 1,500 threat actor groups (up from roughly 300 just a few years ago), and the median time for an attacker to access confidential data after a successful phishing attack is just 1 hour 12 minutes. Teams that cannot integrate and respond quickly are structurally disadvantaged.

How can organizations bridge the gap?

Microsoft's primary answer to integration complexity is a unified, cloud-native security platform in which AI, identity, data governance, and threat protection work as a coordinated system. Security Copilot, for instance, is embedded within and integrates across Microsoft Defender XDR, Microsoft Sentinel, Microsoft Intune, Microsoft Entra, and Microsoft Purview. An analyst can use a single natural language interface to investigate incidents drawing on data from any of these products, generate remediation steps, build reports for stakeholders, and automate routine tasks with autonomous Security Copilot agents — all without switching consoles.

The inclusion of Security Copilot in Microsoft 365 E5 and E7 licensing simplifies adoption further. Customers receive a monthly allocation of SCUs or Secure Computing Units to empower Security Copilot, eliminating the need for separate AI security procurement. This positions integrated, agentic AI-powered security as a default capability rather than an add-on.

For endpoint-level visibility into AI agent sprawl, Microsoft Defender for Endpoint now automatically discovers supported AI coding agents on onboarded Windows 11 devices — including OpenClaw, Claude Code, Codex, Cursor, GitHub Copilot CLI, ChatGPT Desktop, Gemini CLI, and others — and surfaces them in the Defender portal inventory for investigation and correlation with existing device telemetry.

On workforce enablement, Microsoft operates the Security Copilot Adoption Hub, which provides role-specific guidance for CISOs, threat intelligence analysts, IT admins, and data security administrators on how to embed AI into their daily workflows. The broader Microsoft Learn platform now offers modules on securing AI applications and responsible AI governance.

Microsoft's role here is as a force multiplier: by consolidating tools, reducing integration burden, and actively investing in customer readiness, Microsoft enables organizations to convert AI from a source of complexity into an operational advantage — without leaving security behind.

Conclusion: Turning AI Security into Competitive Advantage

The five challenges examined here — data exposure, adversarial threats, identity sprawl, regulatory uncertainty, and integration complexity — will only intensify as AI adoption accelerates. Yet for organizations that address them proactively, the payoff extends well beyond risk mitigation. Robust AI security has become a source of trust with customers and regulators, a prerequisite for bold innovation, and a differentiator in markets where competitors may still be scrambling to catch up.

Microsoft's contribution is structural: an integrated platform where identity, data governance, threat intelligence, and compliance converge — backed by principles of Responsible AI that have remained durable since 2018 and by threat visibility at a scale (more than 100 trillion signals per day, 1,500+ tracked threat actor groups) that no single enterprise can replicate. For executive leadership, the actionable imperative is to treat AI security not as a technical footnote but as a boardroom priority — one that spans the CIO, CISO, Chief Data Officer, and business-unit leaders working together. As Microsoft's own AI security guidance articulates, cross-team collaboration, employee training, and transparent governance are just as essential as firewalls and encryption in building a secure AI future. The organizations that internalize this lesson will be those best positioned to harness AI's full potential — securely, responsibly, and at scale.

Tech Resources:

Defense at AI speed: Microsoft’s new multi-model agentic security system tops leading industry benchmark

Securing AI and Navigating risks and compliance for the future

Entra agent Identities for AI agents

Secure Dashboard for AI

Microsoft Security Copilot

Microsoft Security Copilot FAQ

Build a Local Microsoft Sentinel Triage Agent in VS Code (Copilot + MCP)

absharan — Mon, 18 May 2026 04:28:02 GMT

Modern SOC work is not limited by data—it’s limited by the friction of collecting it. This post shows a local-first workflow that lets you investigate Microsoft Sentinel incidents from inside VS Code using GitHub Copilot Chat for reasoning and a small, deterministic MCP toolset for evidence retrieval and (optionally) approval-gated writeback.

What you’ll take away:

How to structure a Copilot + MCP triage loop that stays grounded in Azure evidence
A reliability pattern: fall back to KQL when Sentinel subresource APIs are flaky
A safety pattern: draft-first, explicit-approval writeback for incident comments

Why This Exists

Sentinel triage is powerful but fragmented: you jump between the portal, KQL, entity pivots, and case notes just to answer “what happened?” The goal here is to collapse that into a single, repeatable loop inside the editor.

Resolve the incident and pull the underlying alerts/entities
Pivot into AzureActivity (and other logs) to identify the actor and outcome
Use threat intelligence (TI) for context—not as the decision
Generate an evidence-backed narrative and draft comment; write back only on explicit approval

Design Principles

Evidence first: every claim must be traceable to Sentinel APIs or Log Analytics results
Small tool surface: fewer tools, clearer prompting, easier hardening
Reliability by design: if one API path fails, pivot to KQL and continue
Safety boundary: investigation and writeback are separate, and writeback is approval-gated

Architecture & Data Flow

A local TypeScript MCP server exposes a handful of triage tools to Copilot Chat in VS Code. Reads come from Sentinel + Log Analytics; writes (incident comments) are optional and require explicit approval.

Copilot Chat (VS Code) decides the next step and summarizes outputs
MCP server executes allowed tools: incident lookup, alert/entity retrieval, KQL queries, optional comment writeback
Evidence sources: Sentinel Incident APIs + Log Analytics tables (SecurityIncident, SecurityAlert, AzureActivity, TI tables)
Safety gate: writeback happens only after explicit approval; otherwise you get a draft

Tool Surface

MCP is useful here because it separates reasoning from execution: Copilot can decide what to do, but only the MCP server can do it—and only through tools you explicitly define and can audit.

list_incidents / get_incident (ground the case)
get_incident_alerts / get_incident_entities (fast path)
run_incident_kql (reliable fallback + pivots)
add_incident_comment (draft-first; writes only with approval)

The Investigation Loop (3 Steps)

Prompt used

sentinel-triage-local Investigate Sentinel incident 1478 end to end in workspace Subscription ID/Resource Group/Workspace Name. Resolve the incident ID first, collect underlying alerts and entities, enrich with AzureActivity and TI, determine whether the activity is malicious or benign, and return: 1. Investigation summary 2. Key evidence 3. Entity analysis 4. TI enrichment result 5. Risk assessment 6. Recommended disposition 7. Final incident comment draft Rules: - Use tool output only, no guessing. - If alert/entity subresource APIs fail, pivot to KQL and continue. - Do not submit the comment unless I explicitly say: APPROVE COMMENT.

1) Ground the incident

Resolve the human-friendly incident number to the Sentinel incident resource ID, then capture the metadata you need to drive every later pivot.

Incident numbers are convenient for analysts, but the actual investigation flow depends on the underlying incident resource ID. Resolving that first gives the workflow a concrete anchor for:

Title
Severity
Owner
Status
Alert count
Analytic rule IDs
Incident URL

This gives you the stable identifiers (and the URL) needed to retrieve alerts, entities, and supporting logs.

2) Collect alerts and entities (fast path)

Pull the alerts behind the incident and the entities they reference. When the incident subresource APIs behave, this is the fastest way to assemble the working set.

In the ideal path, the agent can call the incident alert and entity subresources directly. That gives fast access to:

Alert IDs
Alert names
Timestamps
Severities
Entities
Provider metadata

3) Stay reliable: pivot to KQL when APIs fail

In real environments, the incident subresource APIs for alerts/entities are not always dependable. When they fail, the workflow switches to Log Analytics and reconstructs the same evidence via KQL—so the investigation continues.

SecurityIncident to recover the incident record and alert IDs
SecurityAlert to retrieve alert details and entities
AzureActivity to determine who or what performed the operation
ThreatIntelligenceIndicator and ThreatIntelIndicators for enrichment

The High-Signal Pivot: AzureActivity

In the incidents I tested, AzureActivity was the fastest way to classify “suspicious deployment” alerts: it tells you who did the action, what operation ran, and whether it succeeded.

The evidence showed:

The caller was a single Microsoft Entra ID object ID
Claims_d.idtyp = "app"
Authorization_d.evidence.principalType = "ServicePrincipal"
The activity was tied to a policy assignment
The operation was MICROSOFT.RESOURCES/DEPLOYMENTS/WRITE
The result was BadRequest with InvalidTemplate

That pattern typically points to automation (service principal + policy-driven deployment) failing due to a bad template—not an interactive attacker.

Threat Intelligence: Use It as Context

Enrich observables against TI, but treat it as corroboration: a hit is not proof, and a miss is not a clean bill of health. In my test runs, TI mainly helped refine confidence after AzureActivity and alert evidence established the likely story.

Output: An Evidence-Backed Narrative (and a Draft Comment)

Once the tools return results, Copilot’s job is synthesis: turn structured evidence into a short narrative an analyst can paste into the case.

What happened, who/what triggered it, and whether it succeeded
Key supporting evidence (alerts, entities, AzureActivity pivots, TI context)
A recommended disposition and a draft incident comment

Incident comment written back automatically (after approval) (screenshot):

Safety + Reliability: Approval-Gated Writeback

The agent can draft a comment automatically, but it cannot change incident state unless the analyst explicitly approves. That boundary is what makes the workflow usable in real operations.

After approval, the tool submits the drafted comment directly to the Sentinel incident so the portal reflects the same evidence-backed narrative.

Default: return the draft comment only
On approval: acquire an ARM token via Azure CLI and submit via curl.exe (hardened with validation + retries)

Why This Is Worth Building

Less context switching: investigation happens where you already work
More consistency: the same loop runs every time, with deterministic tools
Better classification: AzureActivity pivots reduce false “user did X” assumptions
Safer automation: drafts are automatic; writes are explicit and auditable

Conclusion

AI is most useful in a SOC when it is constrained: deterministic tools fetch the evidence, the model synthesizes it, and humans keep control of state changes. A local Copilot + MCP workflow hits that sweet spot—faster triage for the SOC analysts.

TLS Certificate Pinning and Best Practices in Azure Open-Source Relational Databases

TameikaL — Mon, 15 Jun 2026 13:42:38 GMT

TLS certificate pinning in Azure Database for PostgreSQL and MySQL

Transport Layer Security (TLS) encrypts data in transit between client applications and the server and authenticates the service endpoint in client-server authentication.

Azure Database server certificates are issued by well-known trusted public Certificate Authorities (CAs), including Microsoft-issued certificates, and are validated by clients during the TLS handshake. Customers do not manage certificates on the server side.

Certificate pinning is a client-side security technique where an application restricts trust to a specific certificate, for example by thumbprint, public key, or CA, rather than relying solely on the default OS or platform trust store. The trust store contains pre-installed root CAs and may also include additional certificates configured by the client. During standard TLS validation, the client will trust any server certificate that chains to one of those root CAs.

When pinning is used, the client will only connect if the presented certificate chain matches exactly what it expects. However, the server has no visibility into whether pinning is configured on the client, and any certificate change (even a valid one) can cause connection failures.

Why detecting TLS certificate pinning is not possible by design

Certificate pinning is entirely client-side logic. From the server’s perspective, the client either completes the TLS handshake or aborts it. The server never sees:

Which certificate(s) the client trusts
Whether the client is comparing root CA, intermediate CA, leaf certificate or SPKI hash
Whether the trust decision was static or dynamic

TLS is designed so that trust evaluation happens entirely on the client, which is why the server has no visibility into the client’s software configuration or pinning behavior. If the client rejects the certificate (for example, due to pinning or trust validation failures), the connection is terminated before any application-level error or authentication occurs.

What the server can see is TLS handshake failure patterns, TLS protocol, and cipher negotiation.

TLS certificates in Azure OSS databases vs Azure SQL

The way TLS certificates are handled in Azure OSS databases versus Azure SQL is a core architectural difference.

In Azure SQL (including Azure SQL Database and Azure SQL Managed Instance), the database engine does not directly present a certificate bound to a specific server or host instance. Instead, client connections terminate at a service-managed endpoint. This abstraction allows certificates to be issued and rotated centrally by the service.

From the client’s perspective, it connects to a service-level endpoint (for example, <server>.database.windows.net), and the certificate chain represents the Azure SQL service rather than a specific machine. Clients are expected to trust the platform CA chain and validate the hostname. As a result, certificate pinning is generally not feasible or useful for Azure SQL, because the TLS endpoint is abstracted and managed by the service.

This is also why Azure SQL client configuration guidance emphasizes using Encrypt=True and TrustServerCertificate=False, ensuring that clients rely on standard TLS validation against the platform-managed certificate chain.

In contrast, Azure Database for PostgreSQL and MySQL expose a more traditional, database engine–level TLS surface where clients directly validate the server certificate chain, making certificate pinning possible. TLS is negotiated by the database engine itself, and the server presents a certificate chain anchored in public or regional certificate authorities.

This results in a fundamentally different trust model. In Azure OSS databases, TLS trust is primarily client-managed, whereas in Azure SQL it is platform-managed. While OSS customers have greater control over certificate validation, they are also responsible for appropriately managing trust configuration. Misconfigurations or overly rigid validation, such as pinning specific certificates, can increase operational risk, particularly during certificate rotations.

One of the most common complications during certificate rotations is certificate pinning.

Why certificate pinning is risky

While certificate pinning was historically used to reduce the risk of man-in-the-middle attacks, it introduces significant operational fragility in cloud environments, particularly during certificate rotations.

Server certificates and certificate authorities (CAs) must be rotated periodically to maintain security and compliance. In Azure Database for PostgreSQL and MySQL, when certificate pinning is used, clients bind trust to a specific certificate or CA. As a result, any change to the server certificate chain—including CA updates—can cause connection failures, even when the new certificates are fully valid and secure.

Recommended TLS certificate trust model for Azure OSS databases

Instead of pinning, adopt a CA‑based trust model that allows certificates to change safely.

Trust root CAs, not individual certificates.

Configure clients to use standard TLS validation against Azure-documented root CAs, rather than restricting trust to specific certificates or a narrowly scoped set of certificate authorities. Avoid configurations that effectively implement certificate pinning—such as trusting only a single certificate, public key, or limited CA set—unless explicitly required.

Maintain a flexible and up-to-date trust store

Clients rely on a trust store, key store, or equivalent certificate bundle to validate server certificates during TLS negotiation. While the exact format and configuration vary by client and environment, the same core principles apply across PostgreSQL and MySQL implementations.

Include the appropriate root and intermediate certificate authorities (CAs) required to validate the server certificate chain
Ensure that trust stores are periodically reviewed and updated in line with provider guidance and announced certificate authority changes.

For the current TLS certificates visit the Azure Database for PostgreSQL documentation and Azure Database for MySQL documentation.

Use certificate validation modes that rely on standard CA-based trust rather than pinning

For PostgreSQL client configurations, prefer:

sslmode=verify-ca
- Validates the server certificate chain against trusted CAs
sslmode=verify-full
- Verifies CA and hostname match

For MySQL client configurations, prefer:

ssl-mode=VERIFY_CA
- Validates the server certificate chain against trusted CAs
ssl-mode=VERIFY_IDENTITY
- Validates CA and hostname (like PostgreSQL verify-full)

These modes ensure that clients validate the server certificate chain against trusted CAs, and in stricter modes, verify hostname identity. They do not imply certificate pinning by themselves. They rely on standard CA-based trust.

Configurations only become rigid when trust is narrowly restricted, such as to a single certificate or limited CA set, often through custom or overly constrained trust stores. This effectively introduces certificate pinning.

When properly configured, these modes authenticate the service endpoint and protect against spoofing, while remaining resilient to certificate rotations.

Maintain a combined CA during certificate rotations

Azure may rotate root or intermediate CAs over time. When Azure announces a CA rotation:

Add the new root and intermediate CAs to the client trust store before the rotation begins
Retain existing root or intermediate CAs until the transition is fully complete
Avoid removing older certificates prematurely

This combined CA approach, using both the current and upcoming certificate authorities during the transition window, allows clients to continue validating the server certificate chain without interruption.

As you review your current client configurations, ensure your applications rely on CA-based trust, avoid overly restrictive certificate configurations such as certificate pinning, and are prepared to handle routine certificate rotations without disruption.

Check This Out! (CTO!) Guide (April 2026)

TysonPaul — Wed, 13 May 2026 03:25:05 GMT

Member: TysonPaul | Microsoft Community Hub

Announcing Public Preview for Essential Machine Management

Team Blog: Azure Governance and Management

Author: Meagan McCrory

Published: 04/06/2026

Summary: Microsoft has announced the public preview of Essential Machine Management within Azure’s Compute Infrastructure Hub. This new feature streamlines onboarding and management of servers and VMs across Azure and multi-cloud environments by enabling core capabilities like monitoring, updates, inventory, and configuration at the subscription level. It offers out-of-the-box best practices, automatic enrollment, and consistent operational coverage. Azure VMs and certain Arc-enabled servers can use these features at no extra cost, while other Arc-enabled servers will be charged $9 per server per month once billing begins. The preview is available in the Azure Portal.

New Local Management Group for ALZ & Updated Sovereign Policies for SLZ

Team Blog: Azure Governance and Management

Author: jtracey93msft

Published: 04/27/2026

Summary: Microsoft has introduced a new ‘Local’ Management Group in both Azure Landing Zone (ALZ) and Sovereign Landing Zone (SLZ) architectures to better govern Azure Local workloads and facilitate exit planning to Azure Local disconnected operations. Additionally, SLZ now uses new built-in policy initiatives aligned to sovereign control levels 1 (Data Residency), 2 (Encryption-at-Rest/Transit), and 3 (Encryption-in-Use), replacing previous broad baselines for clearer mapping, simplified compliance, and reduced maintenance. These updates improve governance, portability, and policy alignment for customers with sovereignty or resiliency requirements.

Copilot agents are scaling faster than most organizations expected

Team Blog: FastTrack

Author: JulieHersum

Published: 04/17/2026

Summary: The article discusses how Copilot agents are being adopted rapidly across organizations, moving from small pilots to broader enterprise use. While early adoption is smooth, scaling introduces new challenges, such as overlapping efforts, unclear ownership, and the need for coordination. The focus shifts from building agents to managing them effectively at scale, requiring clear frameworks and leadership alignment. Microsoft recommends a CIO-level framework to address these issues, helping organizations balance experimentation with coherence and guide responsible growth as Copilot agents become integral to business operations.

Copilot Chat in financial services: Is productivity moving faster than policy?

Team Blog: FastTrack

Author: JulieHersum

Published: 04/13/2026

Summary: The article discusses how financial services organizations adopting Copilot Chat are experiencing increased productivity, but this rapid progress is challenging existing governance and compliance policies. As usage expands beyond initial experimentation, leaders are seeking structured approaches to ensure responsible, repeatable adoption without increasing risk. Microsoft 365 Accelerator offers a planning kit to help organizations scale Copilot Chat while maintaining oversight, audit readiness, and governance, focusing on decision-making and risk management rather than just features. The article invites readers to reflect on their experiences and consider how to balance productivity with regulatory requirements.

Flexible Cooling for AI Growth: How Zonal Architecture Supports Diverse Hardware Needs

Team Blog: Azure Architecture

Author: stsolo

Published: 04/28/2026

Summary: Microsoft is introducing zonal cooling in its next-generation AI datacenters to address the diverse cooling needs of modern hardware, particularly AI accelerators requiring liquid cooling and general-purpose equipment relying on air cooling. Zonal cooling uses multiple independent water loops at different temperatures, improving energy efficiency, reducing carbon emissions, and supporting higher server density. This flexible architecture adapts to evolving hardware requirements, enhances performance, and aligns with Microsoft’s sustainability goals. Facility-level zonal cooling is expected to reduce Power Usage Effectiveness (PUE) by up to 10%, making datacenters more efficient and future-ready.

Running Diffusion Models at Scale on AKS

Team Blog: Azure Architecture

Author: PrabalDeb

Published: 04/29/2026

Summary: The article outlines best practices for running diffusion models at scale on Azure Kubernetes Service (AKS). It emphasizes separating API, dispatch, and GPU execution layers for flexible scaling, security, and observability. Key recommendations include isolating GPU workloads, leveraging Kubernetes-native or Service Bus/KEDA-based dispatch, using persistent storage for model caching, enforcing strong identity and secrets management, and instrumenting both application and hardware metrics. The architecture supports scalable, secure, and automated deployments, making AKS a robust platform for production-grade diffusion workloads beyond simple model hosting. Alternatives like KAITO suit less-customized scenarios.

Announcing Log Monitor v2.2.0 Release Candidate

Team Blog: Containers

Author: Bob_Sira

Published: 04/15/2026

Summary: Log Monitor v2.2.0 Release Candidate introduces a switch from Boost.JSON to the lightweight nlohmann/json library, reducing dependencies and build complexity while remaining backward compatible. This version adds an IIS on AKS deployment example, fixes several configuration parsing bugs, and addresses a path traversal vulnerability. The build system now uses CMake and vcpkg. Upgrading from v2.1.x requires no config changes, but output paths have changed. Updated CI/CD pipelines support the new dependency. Release binaries and documentation are available on GitHub, and user feedback is encouraged.

Simplifying gMSA for Windows Containers on AKS: Open-Source Tooling Now Available

Team Blog: Containers

Author: natashapolito

Published: 04/23/2026

Summary: Microsoft has released an open-source tool, available on GitHub, to simplify configuring Group Managed Service Accounts (gMSA) for Windows containers on Azure Kubernetes Service (AKS). This tooling helps organizations modernize Active Directory-dependent Windows applications for Kubernetes without major code changes, enabling secure AD authentication without domain-joined nodes. The repository includes a PowerShell module, automation scripts, and documentation to streamline gMSA setup and validation. Aimed at teams running or modernizing AD-integrated workloads on AKS, the tool reduces manual configuration and invites community feedback to further improve usability.

So, You’ve disabled Windows Hello for Business, but the User can still Sign-in using a PIN

Team Blog: Ask the Directory Services Team

Author: BrentCrummey

Published: 04/27/2026

Summary: Disabling Windows Hello for Business (WHfB) via Intune or Group Policy does not remove a user’s existing PIN sign-in if it was previously provisioned. The PIN option remains, and its removal button is greyed out due to policy design. To fully remove WHfB PIN sign-in, the user must manually delete their Windows Hello container using “certutil.exe -deleteHelloContainer,” after which they cannot re-enroll as long as the policy is disabled. This behavior is expected and documented by Microsoft.

Troubleshooting TPM Certificate: How to Fix the "Missing Stored Keyset" Error

Team Blog: Ask the Directory Services Team

Author: mdhabibnawaz

Published: 04/30/2026

Summary: The article explains the "missing stored keyset" error in TPM certificates, which occurs when applications can’t access necessary keys due to corrupted registry entries, permission issues, or misconfiguration. It provides a step-by-step troubleshooting guide: updating Windows and TPM firmware, verifying TPM status, checking certificate keysets, repairing certificates, resetting permissions, and re-enrolling certificates if needed. The article emphasizes maintaining backups, staying updated, and consulting official documentation or support if problems persist, highlighting the importance of proper TPM management for system security.

AHEAD helps us launch the Strategic Azure Storage Services Partner Program

Team Blog: Azure Storage

Author: karautenMSFT

Published: 04/30/2026

Summary: AHEAD, a premier Microsoft Cloud and AI Partner, has helped launch the Strategic Azure Storage Services Partner (SASS) Program, leveraging its extensive expertise in infrastructure, storage, and cloud solutions. AHEAD provides assessments, migration services, and access to best-of-breed ISV partners, ensuring Azure Storage customers receive optimal solutions for their needs. With over 1,000 Microsoft certifications and global reach, AHEAD delivers tailored guidance and implementation, driving innovation and resiliency for Azure users. Their collaboration has shaped the SASS channel strategy, benefiting customers with enhanced consulting, design, and migration services.

Prefix-scoped access for User Delegation SAS is now generally available for Azure Blob Storage

Team Blog: Azure Storage

Author: despindola

Published: 04/30/2026

Summary: Prefix-scoped access for User Delegation SAS is now generally available in all Azure regions for Azure Blob and Data Lake Storage. This feature allows administrators to grant access to all blobs within a specific prefix or virtual directory, rather than at the container or individual blob level. This simplifies permission management, especially for multi-tenant or organized data structures, and reduces the need for multiple tokens. Prefix-scoped SAS incurs no additional cost and is supported in the latest REST API and .NET SDK versions. Microsoft recommends using prefix-scoped SAS for more granular access control when SAS is required.

Announcing Native PowerShell Tooling for ReFS Snapshots

Team Blog: Storage at Microsoft

Author: Christina_Curlette

Published: 04/30/2026

Summary: Microsoft has released an open-source PowerShell module for native ReFS snapshot management, streamlining scripting and automation tasks. The module wraps the refsutil streamsnapshot utility, offering cmdlets for creating, listing, deleting, comparing, restoring, and exporting file-level snapshots with pipeline support and structured error handling. Designed for Windows Server 2019+ and Windows 10+, it simplifies operational safety, automated comparison, maintenance, and development workflows. Documentation and examples are available on GitHub, enabling easier integration of ReFS snapshots into PowerShell-based storage management.

Public Preview: Managed Identity support for graphical session recording

Team Blog: Azure Network Security

Author: aarontsang

Published: 04/30/2026

Summary: Azure Bastion now supports managed identities for graphical session recording in public preview. This feature allows Bastion to authenticate directly to an Azure storage account for saving session recordings using either a system-assigned or user-assigned managed identity, eliminating the need for manual credential management. Authentication is handled via Microsoft Entra ID, simplifying setup and aligning with Zero Trust principles. Administrators can centrally control access with Azure RBAC, streamlining management across multiple deployments. To use this feature, enable managed identity, assign appropriate roles, and configure the storage account as outlined in the Azure Portal.

General availability of Default Ruleset (DRS) 2.2 for Web Application Firewall

Team Blog: Azure Network Security

Author: andrewmathu

Published: 04/29/2026

Summary: Azure Web Application Firewall (WAF) now supports Default Rule Set (DRS) 2.2 for Azure Front Door and Application Gateway, offering enhanced security based on OWASP CRS 3.3.4 and Microsoft Threat Intelligence. DRS 2.2 improves detection for web vulnerabilities, reduces false positives with configurable paranoia levels, and provides broader, modern protection. Upgrading resets customizations, so planning is advised. DRS 2.2 delivers consistent and advanced security for internet-facing applications, enabling organizations to better defend against evolving threats while maintaining operational flexibility.

Join us at Microsoft Azure Infra Summit 2026 for deep technical Azure infrastructure content

Team Blog: ITOps Talk

Author: Pierre_Roman

Published: 04/07/2026

Summary: Microsoft Azure Infra Summit 2026 is a free, virtual event for IT professionals, platform engineers, SREs, and infrastructure teams, held May 19-21, 2026. Focused on advanced, engineering-led sessions (L300-400), it offers deep technical content on Azure infrastructure topics like hybrid operations, networking, storage, observability, and governance. The event emphasizes practical guidance, real-world examples, and peer-to-peer learning, aiming to equip attendees with actionable insights for building and operating Azure environments. Register at https://aka.ms/MAIS-Reg.

Internet Information Services Learning Path

Team Blog: ITOps Talk

Author: OrinThomas

Published: 04/14/2026

Summary: The "Internet Information Services Learning Path" provides a structured curriculum for learning to deploy, configure, manage, secure, and troubleshoot IIS on Windows Server and client systems. Covering both legacy and modern use cases, the modules include IIS installation, website and application configuration, administration, security best practices, and performance optimization. The learning path is relevant to most supported IIS versions and includes new features for Windows Server 2025, offering a comprehensive guide for effective IIS management and maintenance.

From Discovery to Executive Presentation: Plan Your Migration with Azure Migrate in Hours

Team Blog: Azure Migration and Modernization

Author: Shikher

Published: 04/03/2026

Summary: Azure Migrate streamlines the migration planning process by consolidating environment discovery, workload tagging, application grouping, and executive reporting into a single workflow. Using the Azure Migrate Collector, organizations can quickly scan their infrastructure offline, classify assets, and auto-group workloads into applications. The tool generates executive-ready PowerPoint reports with modernization, migration recommendations, security insights, and cost analysis, replacing manual processes that previously took weeks. Application-level assessments provide detailed migration strategies, supporting informed decision-making. This approach accelerates Azure migration planning for IT teams and partners, enabling rapid, data-driven presentations to stakeholders.

Production Cutover in Cloud-Native Migrations

Team Blog: Azure Migration and Modernization

Author: dhruti

Published: 04/15/2026

Summary: The article highlights that production cutover during cloud-native migrations, such as to Azure Kubernetes Service (AKS), involves more than just successful deployment—it requires coordinated runtime orchestration across compute, networking, storage, and integrations. Operational issues often arise only after traffic is routed, emphasizing the need for thorough validation and alignment of all dependencies, including disaster recovery, batch processing, and security. Effective cutover is an orchestrated event ensuring runtime readiness, not just deployment, with success dependent on continuous validation and system-wide coordination throughout the migration lifecycle.

Deploying DNS Private Resolvers and Private DNS Zones for Azure AI Supported Services

Team Blog: FastTrack for Azure

Author: munieswar_avulapalli

Published: 04/28/2026

Summary: The article explains how to deploy DNS Private Resolvers and Private DNS Zones for Azure AI-supported services within private networks. Private DNS Zones enable secure, internal domain resolution across global Azure VNets, while DNS Private Resolvers provide managed, regional DNS resolution between Azure and on-premises environments. It highlights the importance of linking VNets to DNS zones for name resolution and clarifies common misconceptions about VNet peering. The article includes a step-by-step end-to-end flow for DNS queries and emphasizes connectivity verification tools like PsPing. Public networks and DNS zones are mentioned but not discussed in detail.

AI-Powered Downtime Investigation for Azure VMs: Automating Root Cause Analysis

Team Blog: Azure Compute

Author: Jon_Andoni_Baranda

Published: 04/22/2026

Summary: The article describes how Microsoft Azure uses AI to automate and accelerate root cause analysis for virtual machine downtime. Leveraging the Model Context Protocol (MCP), the system automatically investigates incidents by querying live telemetry, analyzing logs, building recovery timelines, and generating structured reports. This reduces manual investigation time from up to an hour to under five minutes, ensures consistent, thorough analysis for every incident, and streamlines ownership assignment. The AI system encodes expert knowledge, allowing engineers to focus on decision-making rather than data gathering, significantly improving efficiency and incident response across Azure's infrastructure.

Designing Outbound Connectivity for "Private Subnets" in Azure

Team Blog: Core Infrastructure and Security

Author: alexeyn1

Published: 04/23/2026

Summary: Private subnets in Azure disable default outbound internet access, requiring architects to deliberately design outbound connectivity. Three main patterns exist: NAT Gateway for scalable, predictable egress; Azure Firewall for secure, governed, and audited flows; and Load Balancer Outbound for legacy scenarios. Each has strengths and limitations, with NAT Gateway suited for simple, high-scale egress, Azure Firewall for compliance and security, and Load Balancer for transitional or legacy architectures. The key principle is to choose the outbound method based on workload risk and requirements, ensuring intentional, documented, and governed internet access.

Running multimedia AI models on Container Apps with Serverless GPU (A100 & T4)

Team Blog: Core Infrastructure and Security

Author: HoussemDellai

Published: 04/20/2026

Summary: The article guides users on deploying multimedia AI models, like ComfyUI, on Azure Container Apps using serverless GPU profiles (A100 & T4). It details infrastructure provisioning with Terraform, model downloading, and monitoring via Azure Log Analytics. Key notes cover storage setup, manual creation of GPU profiles, and protocol choices (SMB vs NFS). Cost optimization tips are provided by right-sizing resources. Users can run text-to-image and text-to-video workflows. The article includes disclaimers about the sample scripts' support and reliability, and highlights the need for manual steps due to Terraform limitations.

Announcing Private Preview: Deploy Ansible Playbooks using Azure Policy via Machine Configuration

Team Blog: Azure Arc

Author: alinetran

Published: 04/01/2026

Summary: Microsoft has announced a private preview allowing Ansible playbooks to be deployed via Azure Policy using Machine Configuration on Azure and Azure Arc-enabled Linux machines. This integration enables organizations to automate configuration management and compliance enforcement for Linux servers without needing an Ansible control node. The solution offers centralized policy-based governance, drift detection, and automatic remediation, with compliance results visible in Azure dashboards. This unifies management across Windows and Linux environments, whether in the cloud, on-premises, or at the edge, leveraging existing Ansible investments within Azure Arc’s unified security and compliance framework.

Automating Arc-enabled SQL Server license type configuration with Azure Policy

Team Blog: Azure Arc

Author: TomClaes

Published: 04/12/2026

Summary: The article explains how to automate the configuration of SQL Server license types on Azure Arc-enabled resources using Azure Policy. It details steps for deploying and assigning policies via PowerShell, automating remediation tasks, and handling role assignments. The approach supports both existing (brownfield) and new (greenfield) environments, ensuring compliance and enabling pay-as-you-go billing. The policy can standardize, migrate, or selectively update license types at scale, and includes mechanisms for recurring billing consent. Tools for monitoring compliance, such as KQL queries and Azure Workbooks, are also provided.

App attach in Azure Virtual Desktop now supports Windows Server 2025 and Windows Server 2022

Team Blog: Azure Virtual Desktop

Author: Michelle_Moya

Published: 04/16/2026

Summary: App attach in Azure Virtual Desktop now supports Windows Server 2025 and 2022, allowing dynamic delivery of MSIX, AppX, and App-V applications to session hosts without embedding them in base images. This reduces image sprawl, simplifies management, and enables continued use of existing App-V packages as support for App-V Server ends in April 2026. Organizations can more easily onboard and update applications, manage a single golden image, and benefit from streamlined app delivery, especially in Azure Virtual Desktop Hybrid environments. For more details, users are encouraged to consult the App attach documentation.

Announcing public preview of redundant TCP support for RDP Multipath for Azure Virtual Desktop

Team Blog: Azure Virtual Desktop

Author: Rinku_Dalwani

Published: 04/21/2026

Summary: Azure Virtual Desktop (AVD) now supports redundant TCP transport paths for RDP Multipath, available in public preview. This enhancement improves session resiliency by enabling multiple network paths—both UDP and TCP—for reliable connectivity, even in restrictive or UDP-restricted environments. If a connection path degrades or fails, AVD automatically switches to the next best route without user intervention, ensuring session continuity. The feature is enabled by default for host pools in the validation ring and is supported on Windows App version 2.0.1069.0 or later. Users can opt out if needed.

Update host keys to use SFTP on Azure Blob Storage

Team Blog: Azure PaaS

Author: LuisFilipe

Published: 04/28/2026

Summary: Azure Blob Storage users may receive alerts to update SFTP host keys, which are used to verify server identity for secure connections. To avoid disruptions, users should update their trusted hosts list with new host keys, either by pre-loading both current and next keys or by accepting the new key after rotation. The article provides guidance on listing SFTP-enabled storage accounts, identifying connected clients, and automating updates. Monitoring and diagnostic tools can help track SFTP connections, and users authenticating via SSH key must ensure their known_hosts file is updated to maintain uninterrupted access.

Leveraging Azure Resource Graph Queries for Azure Redis Configuration

Team Blog: Azure PaaS

Author: Soma_Sekhara_Raju

Published: 04/21/2026

Summary: The article outlines how Azure Resource Graph Explorer streamlines the review of Azure Redis configurations across subscriptions using Kusto Query Language (KQL). It details queries for SKU tier, Redis version, TLS settings, public network access, and Microsoft Entra authentication, offering rapid, centralized visibility without the need for custom scripts. This approach accelerates audits, supports security compliance, and simplifies management compared to traditional methods like PowerShell or Azure CLI. The same methodology can be applied to other Azure resource types by querying their schemas.

AI at every career stage (start, grow, lead)

Team Blog: Microsoft Learn

Author: AshleyMastersHall

Published: 04/28/2026

Summary: The article explores how AI can support professionals at every career stage, from newcomers to senior leaders. It provides practical examples of using AI tools like Microsoft Copilot to accelerate learning, streamline workflows, and enhance decision-making. Early-career individuals can use AI for onboarding and communication; midcareer professionals can scale impact and manage complexity; experienced leaders can leverage AI for strategy, coaching, and process improvement. The article also recommends Microsoft’s AI Skills Navigator for tailored AI skill development, emphasizing that it’s never too early or late to adopt AI in your career.

What’s new in AI Skills Navigator: April 2026

Team Blog: Microsoft Learn

Author: Priya_V

Published: 04/20/2026

Summary: The April 2026 update to AI Skills Navigator introduces improvements based on user feedback, including enhanced skilling playlists for clearer, scalable learning paths, and more flexible skilling sessions with better progress tracking and control for learners. The platform now features a directory for Microsoft Training Services Partners to support tailored, local training, and offers new certifications like AI Transformation Leader and AI Business Professional. All training and credentials are unified in one place, making it easier to build, track, and validate AI skills for individuals and organizations.

Azure VNet Data Gateway for Secure Power BI & Power Platform Access in Enterprises

Team Blog: Azure Networking

Author: kirankumar_manchiwar04

Published: 04/22/2026

Summary: The Azure VNet Data Gateway is a Microsoft-managed service that enables secure, private access to data sources for Power BI, Power Platform, and Microsoft Fabric without customer-managed infrastructure. Running within a delegated Azure Virtual Network subnet, it eliminates the need for VMs or manual maintenance, ensuring all data traffic stays on the Azure backbone. The gateway supports enterprise-scale deployments, enforces private-only connectivity, and aligns with Zero Trust and governance requirements, making it ideal for organizations prioritizing security and operational efficiency. Setup involves configuring the VNet, private endpoints, and integrating with Power Platform or Power BI.

A demonstration of Virtual Network TAP

Team Blog: Azure Networking

Author: Marc de Droog

Published: 04/15/2026

Summary: Azure Virtual Network Terminal Access Point (VTAP), in public preview as of April 2026, enables agentless, out-of-band copying of full network traffic (including payloads) from designated Azure VMs to traffic analytics tools or collectors, using VXLAN encapsulation. Unlike VNET Flow Logs, which only capture metadata, VTAP provides full packet capture without impacting VM performance. The article demonstrates VTAP’s functionality by capturing and analyzing traffic from a source VM to a destination VM running Wireshark. VTAP integrates with third-party security and analytics solutions available on the Azure Marketplace.

Speed where it matters: How Microsoft Intune helps IT prioritize time-sensitive actions

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 04/30/2026

Summary: Microsoft Intune prioritizes and accelerates time-sensitive device updates, with 90% of actions completed in under an hour. Contrary to the “8-hour latency” myth, this delay applies only to routine maintenance check-ins, not critical updates. Intune uses notification-based, priority-driven processing to ensure high-impact actions like security and compliance changes are delivered quickly. Recent improvements focus on prioritization, resilience during bursts of changes, timely notifications, and optimized maintenance check-ins, enhancing speed and predictability for IT admins and security teams without requiring workflow changes.

Unpacking Endpoint Management is back - and we’ve got a lot to talk about

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 04/24/2026

Summary: "Unpacking Endpoint Management," a candid web series focused on practical strategies for managing and securing endpoints, is back with new episodes featuring Microsoft Intune experts and guest practitioners. Hosted by Danny Guillory and new co-host Rachelle Blanchard, the series offers live discussions, real-world insights, and answers to audience questions. Upcoming topics include policy transitions from hybrid to cloud-native. Episodes are streamed live on multiple platforms, and the community is encouraged to participate, submit questions, and suggest topics, ensuring content remains relevant and actionable for real-world endpoint management challenges.

Triggering Azure Functions from Blob Storage Using Event Grid

AndrewCoughlin — Mon, 11 May 2026 20:24:17 GMT

Overview

Modern workloads increasingly rely on reacting to files as soon as they arrive in Azure Blob Storage. While Azure provides multiple ways to trigger computing from blob operations, choosing the right event-driven pattern is not always straightforward—especially in enterprise environments where latency, reliability, and operational transparency all matter.

Introduction

Hello everyone, Andrew Coughlin here, a Cloud Solution Architect specializing in Infrastructure as a Service on Azure.

In this post, I am going to walk through how to implement a direct Event Grid to Azure Function pattern. This is the simplest and lowest-latency option when you want real-time reactions to blob uploads.

Scenario

Suppose you have a workload where files are continuously uploaded into Azure Blob Storage and you need to trigger downstream processing.

Typical requirements include avoiding polling, achieving near real-time execution, and maintaining strong observability.

Architecture

Blob Storage → Event Grid → Azure Function

The Process

Create and deploy the Azure Function
2. Validate the function
3. Create the Event Grid subscription
4. Upload a blob and validate the flow

Step 1 — Create and Deploy the Azure Function (Function First)

The Function must exist before creating the Event Grid subscription because Event Grid validates the endpoint during creation.

Steps:
1. Create a Function App (Consumption plan + storage account)
2. Open Function App → Functions → Create
3. Select Event Grid trigger
4. Provide function name
5. Create and save the function

Note: A storage account is required for all Function Apps and is created or selected during app creation.

Implement the Function

Below are examples of the HandleBlobCreatedEvent.cs, EventGridListenerFunction.csproj, Program.cs, and host.json

Example of HandleBlobCreatedEvents.cs:

namespace EventGridListenerFunction { public class HandleBlobCreatedEvent { private readonly ILogger _logger; public HandleBlobCreatedEvent(ILoggerFactory loggerFactory) { _logger = loggerFactory.CreateLogger<HandleBlobCreatedEvent>(); } [Function(nameof(HandleBlobCreatedEvent))] public void Run([EventGridTrigger] string data) { // Event Grid sends events as a JSON array using var doc = JsonDocument.Parse(data); if (doc.RootElement.ValueKind == JsonValueKind.Array) { foreach (var ev in doc.RootElement.EnumerateArray()) { HandleOneEvent(ev); } } else { HandleOneEvent(doc.RootElement); } } private void HandleOneEvent(JsonElement ev) { if (ev.TryGetProperty("eventType", out var eventType)) _logger.LogInformation("EventType: {EventType}", eventType.GetString()); if (ev.TryGetProperty("subject", out var subject)) _logger.LogInformation("Subject: {Subject}", subject.GetString()); if (ev.TryGetProperty("data", out var dataObj) && dataObj.ValueKind == JsonValueKind.Object && dataObj.TryGetProperty("url", out var urlProp)) { _logger.LogInformation("Blob URL: {Url}", urlProp.GetString()); } else { _logger.LogWarning("No data.url found in payload."); } } } }

Example of Program.cs:

var builder = FunctionsApplication.CreateBuilder(args); builder.ConfigureFunctionsWebApplication(); builder.Services .AddApplicationInsightsTelemetryWorkerService() .ConfigureFunctionsApplicationInsights(); builder.Build().Run();

Example of Host.json:

{ "version": "2.0", "logging": { "applicationInsights": { "samplingSettings": { "isEnabled": true, "excludedTypes": "Request" }, "enableLiveMetricsFilters": true } } }

Example of EventGridListenerFunction.csproj:

<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>net8.0</TargetFramework> <AzureFunctionsVersion>v4</AzureFunctionsVersion> <OutputType>Exe</OutputType> <ImplicitUsings>enable</ImplicitUsings> <Nullable>enable</Nullable> </PropertyGroup> <ItemGroup> <FrameworkReference Include="Microsoft.AspNetCore.App" /> <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.23.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="2.51.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="2.50.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.EventGrid" Version="3.5.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="2.1.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="2.0.7" /> </ItemGroup> </Project>

You will still need to publish this to the function app, which is outlined: Deployment technologies in Azure Functions | Microsoft Learn.

Step 2 — Create the Event Grid Subscription

Navigate to the Storage Account → Events → Create Event Subscription and select BlobCreated events targeting the Function.

Step 3 — Validate

Upload a blob and confirm the Function triggers and logs event data.

Common Pitfalls

Creating the subscription before the function exists
• Storage account misconfiguration
• Networking restrictions preventing Function access to storage

Conclusion

The direct Event Grid to Azure Function pattern provides a simple and reliable approach for real-time blob processing without additional infrastructure.

Disclaimer

The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.

Purpose For Your PKI (Practical PKI Part 3)

RonArestia — Mon, 04 May 2026 04:00:00 GMT

My name is Ron Arestia, and I am a Security Researcher with Microsoft’s Detection and Response Team (DART). We respond to customer cybersecurity incidents to assist with containment and recovery from threat actors. In this brief blog post, we will discuss the “why” behind your PKI. This is part 3 of a series on practical PKI implementation based on my experience with customer interactions working as a Microsoft engineer.

Feel free to catch up on previous blog posts or jump right into this one

Secure Configuration and Hardening of Active Directory Certificate Services

Implementing and Managing an ADCS Offline Root Certificate Authority (Practical PKI Part 1)

CRL & AIA Publishing Guidance (Practical PKI Part 2)

In Part 3 of our series, understanding why you are implementing and managing PKI is critical to understanding the level of effort you should endeavor to start using one or keep one going. This brief non-technical discussion is meant as a primer to determine if what you are about to implement is truly going to benefit your organization as a whole.

Determine Your Technical Outcomes

This subject is the target of much debate and disagreement across my peer groups. On the one side, you have engineers who argue for or against the very provisioning of a PKI while on the other side, you have engineers who argue that regardless of purpose, administration is more important. Far be it for me to be a fence-sitter, so I stand firmly in the former group arguing that if you do not need it, you should not bother standing it up in the first place.

A few years ago, I was working with a customer with a substantial PKI presence: three issuing CAs, fully redundant HTTP CRL publishing, CEP/CES, and cross-forest publishing. When we were assessing their environment, I noticed immediately that they had a scant few templates published across those three issuers, but they had over 100,000 issued, active certificates. I dug deeper and noticed that every one of their templates except two were configured with autoenrollment. Every user and every computer in their organization was getting a certificate that was published to Active Directory. They were issuing server authentication certificates with enrollee-supplied Subject Alternative Names (SANs) without manager approval. And they were even issuing code signing certificates without manager approval albeit to a constrained group.

After lengthy discussions with them about their reasons for managing a PKI, I discovered a few very telling things:

Despite aspirations to use 802.1x for user and computer authentication, the infrastructure was never implemented and remained in a state of development for the last few years.
Despite a project to setup smart card authentication, they never moved past a pilot group of developers and administrators who were not bothering to leverage this powerful method of authentication across most of their enterprise anyway.
Approximately 90% of their certificates issued for web endpoints were either development endpoints that never made it to production or misconfigured certificates that had to be reissued to correct spelling errors or to add or remove nodes from SANs that were not in the original configuration.
More than 1,000 code signing certificates were issued, but no official code was signed by their recollection.

By the end of the engagement, they realized how much administrative overhead was going into maintaining a massive solution with little actual value for the organization. They had short root CA CRL lifetimes requiring quarterly “signing parties,” and despite a very astute team of engineers maintaining the PKI, they had built in “automation” paths that left their environment vulnerable to attack if a threat actor ever found their way in. All told, we determined that less than 2% of the total number of issued certificates (approximately 2,500) were actively used for a regular production task.

Even after discussing options to downsize, streamline, and harden their PKI infrastructure, we eventually discussed options to offload much of their certificate needs to third-party solutions. Why would I convince a customer to rid themselves of an in-house PKI?

Are You Experienced?

I believe the most important fundamental question to ask as an enterprise is if you have the staff to manage and maintain a PKI, and if so, to what extent? I would argue that having at least two engineers dedicated to this task is critical for personnel fault tolerance. If one engineer goes on vacation or suddenly resigns, you have someone who can continue to operate the environment to the same level of fidelity expected of it. This guidance scales upwards the larger your PKI grows. If you are a multinational enterprise with issuing CAs spread around the globe, you need, at the least, regional expertise to navigate administration and maintenance tasks. Ideally, you would have a resource local to each environment to ensure someone can put hands on the systems without relying on global networking.

The second fundamental question you should ask: what is the primary purpose of my public key infrastructure? Are you using it to manage an 802.1x authentication scheme across your enterprise? Are you managing smart cards or certificate-based authentication for your organization? Are you looking to issue a large number of server authentication certificates to support internal web endpoints or development efforts? Or do you believe that by maintaining your own PKI you are maintaining some level of sovereignty over your cryptographic operations that you do not want to offload to a third-party or a cloud provider?

All of these are perfectly valid reasons to maintain your own PKI, but each comes with challenges and interoperability requirements that should be documented and thoroughly understood. In 802.1x configurations, you should ensure all of your subordinate infrastructure is prepared and up to the task of handling authentication traffic and overall maintenance. One network appliance outage overnight could mean an entire office is unable to work the next morning. Smartcard and certificate-based authentication require a robust infrastructure and a team of individuals dedicated to the task of identity attribution for assignment and provisioning of those certificates. Web endpoint certificate management can quickly grow into a full-time role for an engineer in an environment with rapid iteration, and there is a delicate balance to be struck between reasonable validity periods and the possibility of regular revocation due to changes that can balloon a CRL. Finally, the decision to maintain sovereignty over certificates is often driven by cost. A true cost-benefit analysis can aid in reinforcing or diminishing from the need to stand up a dedicated PKI, and the reality is that having publicly-trusted certificates is often a much simpler solution than relying on visibility to internal publishing endpoints that require a number of security solutions.

Decisions, Decisions

The decision to stand up a dedicated, in-house PKI is not one that should be taken lightly. Sit down with your management and leadership team to outline the high-level outcomes expected of the solution and be the sober voice in the room to explain both the benefits and disadvantages of the proposed solution. If the determination to proceed is not grounded in realistic capabilities of the enterprise, do not be afraid to pull the security card, at a minimum. The security of your PKI is paramount. Without it, you are paying money to power infrastructure that is, at best, churning out unnecessary certificates, and at worst, putting your entire enterprise at risk of a cybersecurity incident.

How do we secure and maintain your PKI once the decision is made to deploy one? In Part 4, we will get back into the technical discussions about your PKI security and how to maximize your security without compromising functionality.

Hardening OpenClaw on AKS: Mitigating Container Escapes with Kata microVM Isolation

jianshn — Thu, 30 Apr 2026 01:57:02 GMT

What is OpenClaw, and what security challenges does it pose with container escapes?

OpenClaw is an open-source autonomous AI agent designed for power users and developers to automate tasks, such as managing emails, files, and scheduling via chat apps like WhatsApp or Telegram.

While OpenClaw functions as a powerful autonomous assistant, its runtime model creates a massive security paradox: to be truly useful, the agent requires broad permissions to your filesystem and APIs, yet this "God Mode" access often lacks the rigorous containerized isolation typical of enterprise workloads. Because many users run the framework natively rather than within a hardened sandbox, the primary security challenge is that a single malicious "Skill" or an indirect prompt injection can escalate into full system compromise. This structural vulnerability, exemplified by high-profile exploits like CVE-2026-25253, transforms the agent from a helpful tool into a high-risk entry point for lateral movement and data exfiltration within a private network.

Why container escapes matter in OpenClaw-style deployments: because containers share the host kernel, a successful container escape turns a single compromised container into a host compromise (or at least a compromise of other co-located workloads). This is especially important when OpenClaw runs code from many tenants, many teams, or varying trust levels on the same worker nodes. That soft isolation is often permeable due to the following structural and configuration-based weaknesses:

Shared-kernel attack surface: the container boundary is not a hypervisor boundary. Kernel vulnerabilities (e.g., privilege escalation bugs) can allow a process in a container to gain host-level privileges.
Excessive privileges / misconfiguration: running with --privileged, broad Linux capabilities, hostPath mounts, access to the Docker socket, or device passthrough (e.g., /dev/kvm, /dev/fuse) can provide direct paths to host control.
Filesystem and namespace boundary breaks: mount namespace confusion, writable host mounts, or mistakes in chroot/pivot_root handling can expose host files and credentials.
Supply-chain and image risk: a malicious image or dependency can execute within the container and then attempt escalation/escape.
Blast radius: once the host is compromised, attackers can access node-level secrets (service account tokens, registry creds), tamper with the runtime, sniff traffic, or pivot to other containers and the broader cluster.

In short, OpenClaw’s security challenge is not that containers are inherently insecure, but that the isolation boundary is thinner than a VM boundary. When the threat model includes adversarial code execution, a “container-only” isolation strategy often requires additional hardening or a stronger sandbox.

What are MicroVMs and Kata Containers, and how do they help mitigate OpenClaw container-escape risks?

MicroVMs are lightweight virtual machines optimized for running short-lived or container-like workloads with much lower overhead than traditional VMs. They use hardware virtualization (via a hypervisor such as KVM) but keep the device model and boot path minimal, reducing startup time and the overall attack surface compared to a full general-purpose VM.

Kata Containers is an “OCI-compatible containers in a VM” approach: it runs each container (or pod sandbox) inside a dedicated microVM by default (implementation varies by runtime/config). To the orchestration layer (e.g., Kubernetes), it still looks like a container runtime, but isolation is provided by a hypervisor boundary rather than only namespaces/cgroups.

Stronger isolation boundary: a container escape that relies on Linux kernel exploitation is far less likely to directly compromise the host, because the workload’s “host” kernel is typically the guest kernel inside the microVM.
Reduced blast radius: compromise is contained to the microVM/pod sandbox; lateral movement to other workloads on the same node becomes significantly harder.
Smaller and more controllable attack surface: minimal device models, tighter default privileges, and fewer host mounts/devices exposed to the workload.
Defense-in-depth with container controls: you still can (and should) apply seccomp, capabilities dropping, read-only root filesystems, and LSMs inside the guest, but the hypervisor boundary becomes an additional layer.
Better fit for hostile multi-tenant workloads: when OpenClaw executes third-party jobs/plugins, Kata-style sandboxing aligns better with an adversarial threat model.

Solution overview

Figure 1 illustrates a Kubernetes-based sandboxing architecture for running OpenClaw workloads with stronger isolation. The design keeps the developer experience and packaging model of containers (OCI images, Kubernetes scheduling) while ensuring that untrusted agent code executes inside a microVM boundary using Kata Containers. This reduces the likelihood that a container escape can compromise the underlying node or other co-located workloads.

Key components: (1) Application gateway for HTTPS traffic to the backend, (2) Kubernetes as the orchestration, scheduling and policy enforcement plane, (3) a container runtime (e.g., containerd) configured with a Kata Containers runtime class, (4) KVM-backed microVMs that provide the isolation boundary for each untrusted workload and (5) Azure files for persistent storage which allows scaling of OpenClaw.

Figure 1: Solution architecture diagram

End-to-end flow:

Traffic Entry via Application Gateway: Incoming user requests (e.g., from WhatsApp or Discord) first hit the Azure Application Gateway.
Orchestration in AKS: The traffic is routed into an Azure Kubernetes Service (AKS) cluster, which manages the lifecycle of the OpenClaw agent and its associated "Skills."
Hardened Execution via Kata Containers: Instead of running in standard shared-kernel containers, the OpenClaw agent runs inside Kata Containers. This provides a dedicated lightweight VM for the agent, creating a hardware-level isolation boundary that prevents "container escapes" from compromising the host.
Stateful Storage in Azure Files: The agent interacts with Azure Files to read and write persistent data, such as conversation history, configuration files, and downloaded assets, ensuring data remains available even if the container is restarted.

Security posture: by shifting isolation from “shared-kernel containers” to “containers inside microVMs,” the architecture limits the blast radius of kernel-level exploits and common escape paths. Even if an attacker achieves code execution within an OpenClaw container, they must additionally break the microVM/hypervisor boundary to affect the node or neighboring workloads, providing a strong defense-in-depth improvement over standard container alone.

Implement the solution

This section describes how to deploy the solution architecture.

In this post, you’ll perform the following tasks:

Create a Kata VM-isolated AKS node pool
Mount a NFS persistent storage
Create the application ConfigMap
Deploy the OpenClaw gateway
Expose the gateway internally
Set up TLS termination
Route external traffic through the Azure application gateway for containers.

Ensure that you have the following prerequisites deployed before moving to the next section:

An AKS cluster provisioned in Azure
An Azure NFS File Share with private link enabled.
An Application gateway for containers managed by ALB controller
Kubectl configured and pointing to the cluster
Az CLI authenticated with the correct subscription

Initialise environment variables

In your Linux terminal, export these variables with your own values. They will be used in later commands.

export cluster_name=<CLUSTER_NAME> export resource_group=<RESOURCE_GROUP>

Create the AKS Node Pool with Kata VM Isolation

The OpenClaw gateway pods require Kata VM isolation (runtimeClassName: kata-vm-isolation). You must create a dedicated AKS node pool that supports this runtime before deploying any workloads.

Use the Azure CLI to add a node pool with the Kata VM isolation workload runtime to your existing AKS cluster:

az aks nodepool add \ --resource-group $resource_group \ --cluster-name $cluster_name \ --name katanp \ --node-count 2 \ --node-vm-size Standard_D4s_v3 \ --os-sku AzureLinux \ --workload-runtime KataMshvVmIsolation \ --labels agentpool=katanp

**Important:** The `--workload-runtime KataMshvVmIsolation` flag enables the `kata-vm-isolation` runtime class on the node pool. The VM size must support nested virtualization (D-series v3/v5, E-series v3/v5, etc.).

Create NFS Persistent Volume

The deployment uses an Azure Files NFS share for persistent workspace storage. The PersistentVolume must exist before the PVC can bind to it. Replace volumeHandle and volumeAttributes with your own Azure Files values.

cat <<EOF | kubectl apply -f - apiVersion: v1 kind: PersistentVolume metadata: name: openclaw-nfs-pv spec: capacity: storage: 100Gi accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain mountOptions: - sec=sys - noresvport - actimeo=30 csi: driver: file.csi.azure.com volumeHandle: <resource-group>#<storage-account>#<share-name> volumeAttributes: resourceGroup: <resource-group> shareName: <share-name> protocol: nfs server: <storage-account>.privatelink.file.core.windows.net EOF

Verify that the persistent volume is created.

kubectl get pv openclaw-nfs-pv

Figure 2: Persistent volume

Create the NFS PersistentVolumeClaim

The PVC binds to the PV created. The deployment references this PVC by name (`pvc-openclaw-nfs`).

cat <<EOF | kubectl apply -f - apiVersion: v1 kind: PersistentVolumeClaim metadata: # The name of the PVC name: pvc-openclaw-nfs spec: accessModes: - ReadWriteMany resources: requests: # The real storage capacity in the claim storage: 50Gi # This field must be the same as the storage class name in StorageClass storageClassName: "" volumeName: openclaw-nfs-pv EOF

Verify that the persistent volume claim is created successfully. The status should show bound.

Figure 3: Persistent Volume Claim

Create the ConfigMap

The ConfigMap provides the openclaw.json configuration file to the gateway pods. It configures allowed CORS origins for the control UI and the gateway token. Replace the allowed origins with your own ALB frontend URL. The ConfigMap also stores the gateway auth token, so DO NOT hardcode your token here. Always keep it as a variable rather than storing it in plain text so that, if attackers gain access to this file, they cannot see the OpenClaw gateway auth token.

cat <<EOF | kubectl apply -f - apiVersion: v1 kind: ConfigMap metadata: name: openclaw-config data: openclaw.json: | { "gateway": { "auth": { "token": "${AUTH_TOKEN}" }, "controlUi": { "allowedOrigins": [ "https://<YOUR ALB FRONTEND URL>.alb.azure.com" ] } } } EOF

Create the Auth Token Secret

The OpenClaw gateway requires an authentication token to secure access. The deployment references a Kubernetes Secret named openclaw-auth-token and injects it into the container as the AUTH_TOKEN environment variable via secretKeyRef.

Generate a random token (or use an existing one) and create the kubernetes secret.

# Generate a random 32-byte hex token AUTH_TOKEN=$(openssl rand -hex 32) echo "$AUTH_TOKEN" # save this — you'll need it to authenticate with the gateway kubectl create secret generic openclaw-auth-token \ --from-literal=token="$AUTH_TOKEN"

If the secret does not exist when the deployment is applied, pods will fail with `CreateContainerConfigError`.

Deploy the OpenClaw Gateway

This is the main application deployment. It depends on all previous steps:

- Kata node pool (pods require runtimeClassName: kata-vm-isolation and nodeSelector: agentpool=katanp)

- PVC (pvc-openclaw-nfs for persistent workspace data)

- ConfigMap (openclaw-config for openclaw.json)

Key details:

- Runs 2 replicas with a rolling update strategy

- Uses an init container to copy the config file to a writable volume

- Exposes port 18789

- Includes liveness and readiness probes on /health

- Resource requests: 500m CPU, 512Mi memory

- Resource limits: 2 CPU, 2Gi memory

cat <<EOF | kubectl apply -f - apiVersion: apps/v1 kind: Deployment metadata: name: openclaw-gateway spec: replicas: 2 selector: matchLabels: app: openclaw-gateway strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 maxSurge: 1 template: metadata: labels: app: openclaw-gateway spec: runtimeClassName: kata-vm-isolation nodeSelector: agentpool: katanp securityContext: fsGroup: 1000 initContainers: - name: copy-openclaw-config image: alpine/openclaw:latest env: - name: HOME value: /writable command: - sh - -c - | cp /config/openclaw.json /writable/openclaw.json \ && chown 1000:1000 /writable/openclaw.json \ && echo "--- Config file contents ---" \ && cat /writable/openclaw.json volumeMounts: - name: openclaw-config-volume mountPath: /config - name: openclaw-writable mountPath: /writable containers: - name: gateway image: alpine/openclaw:latest ports: - containerPort: 18789 env: - name: NODE_OPTIONS value: "--max-old-space-size=4096" - name: AUTH_TOKEN valueFrom: secretKeyRef: name: openclaw-auth-token key: token # Start gateway the way the tutorial indicates command: ["openclaw", "gateway"] args: ["run", "--allow-unconfigured", "--bind", "lan"] volumeMounts: - name: openclaw-writable mountPath: /home/node/.openclaw - name: openclaw-data mountPath: /home/node/workspace subPath: workspace resources: requests: cpu: "500m" memory: "2Gi" limits: cpu: "1000m" memory: "4Gi" livenessProbe: httpGet: path: /health port: 18789 initialDelaySeconds: 60 periodSeconds: 15 failureThreshold: 3 readinessProbe: httpGet: path: /health port: 18789 initialDelaySeconds: 10 periodSeconds: 5 volumes: - name: openclaw-data persistentVolumeClaim: claimName: pvc-openclaw-nfs - name: openclaw-config-volume configMap: name: openclaw-config items: - key: openclaw.json path: openclaw.json - name: openclaw-writable emptyDir: {} --- apiVersion: v1 kind: Service metadata: name: openclaw-gateway-service spec: type: ClusterIP selector: app: openclaw-gateway ports: - protocol: TCP port: 18789 targetPort: 18789 EOF

Verify that the deployment succeeds. Wait until all pods show `Running` and `READY 2/2`.

kubectl get deployment openclaw-gateway kubectl get pods -l app=openclaw-gateway

Figure 4: OpenClaw deployment

Create the TLS secret (for HTTPS)

The Application Gateway for Containers references a TLS secret (gateway-tls-secret) for HTTPS termination. This blog post uses a self-signed certificate; in a production environment, use a certificate signed by a certificate authority. Replace `<path-to-tls-cert>` and `<path-to-tls-key>` with paths to your TLS certificate and private key files.

kubectl create secret tls gateway-tls-secret \ --cert=<path-to-tls-cert> \ --key=<path-to-tls-key>

Create the Gateway

The Gateway resource defines the HTTPS listener on the Azure Application Load Balancer (ALB). Update the `alb.network.azure.com/application-gateway-id` annotation to match your ALB traffic controller resource ID. You will also need to reference the gateway-tls-secret to enable HTTPS.

cat <<EOF | kubectl apply -f - apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: https annotations: alb.network.azure.com/application-gateway-id: /subscriptions/<subscription id>/resourceGroups/mc_openclaw_openclaw-cluster_centralus/providers/Microsoft.ServiceNetworking/trafficControllers/<alb id> alb.networking.azure.io/alb-namespace: default alb.networking.azure.io/alb-name: alb-openclaw spec: gatewayClassName: azure-alb-external listeners: - name: https protocol: HTTPS port: 443 allowedRoutes: namespaces: from: All tls: mode: Terminate certificateRefs: - kind: Secret group: "" name: gateway-tls-secret EOF

kubectl get gateway https

Wait until the Gateway shows a `Programmed=True` condition.

Create the HTTPRoute

The HTTPRoute connects the Gateway to the backend Service. It routes all traffic (`/` prefix) from the HTTPS Gateway to `openclaw-gateway-service` on port 18789.

cat <<EOF | kubectl apply -f - kind: HTTPRoute apiVersion: gateway.networking.k8s.io/v1 metadata: name: http-route spec: parentRefs: - name: https rules: - matches: - path: type: PathPrefix value: / backendRefs: - name: openclaw-gateway-service kind: Service namespace: default port: 18789 EOF

Test OpenClaw application

Get the external endpoint.

kubectl get gateway https -o jsonpath='{.status.addresses[0].value}'

Paste the endpoint into your browser to reach the OpenClaw application. If you are using a self-signed certificate, you will see a “Not secure” warning; click Advanced to proceed. In a production environment with a certificate signed by a certificate authority, you should not see that warning.

Figure 5: OpenClaw Authentication

Paste in your Gateway Token (the auth token created earlier). You will notice that even though the token is valid, it throws back a “pairing required” error. Pairing is required in OpenClaw whenever a new device, browser profile, or CLI client attempts to connect to the gateway for the first time, ensuring only authorized clients can control the AI agent.

POD=$(kubectl get pod -l app=openclaw-gateway -o jsonpath='{.items[0].metadata.name}') POD2=$(kubectl get pod -l app=openclaw-gateway -o jsonpath='{.items[1].metadata.name}') TOKEN=$(kubectl get secret openclaw-auth-token -o jsonpath='{.data.token}' | base64 -d) kubectl exec "$POD" -c gateway -- openclaw devices approve --latest --token "$TOKEN" kubectl exec "$POD2" -c gateway -- openclaw devices approve --latest --token "$TOKEN"

You should see a message like the one in the image below. You can now open the OpenClaw application and start using it.

Figure 6: OpenClaw pairing success message

Figure 7: OpenClaw Application

You have successfully deployed OpenClaw within a microVM hosted on Azure Kubernetes Service.

Test microVM kernel isolation

From within the OpenClaw pod, try to read the host’s root filesystem via /proc/1/root. You should see an error like: ls: cannot access '/proc/1/root/etc/kubernetes': No such file or directory.

kubectl exec -it "$POD" -c gateway -- ls /proc/1/root/etc/kubernetes 2>&1

In a standard container deployment, PID 1 inside the container is still running on the host kernel, so traversing /proc/1/root/ exposes the host's root filesystem — including sensitive paths like /etc/kubernetes (which holds kubelet credentials). With Kata VM isolation, the picture is completely different. When we run ls /proc/1/root/etc/kubernetes from inside the OpenClaw pod, it returns "No such file or directory". This is because PID 1 is no longer a process on the host — it's running inside a dedicated guest VM with its own kernel. The /proc/1/root/ path leads to the microVM's root filesystem, not the host's, and that microVM has no knowledge of the node's Kubernetes configuration or machine identity. The host is simply invisible. This is the core security guarantee of Kata Containers: even if an attacker achieves a full container escape, there is nothing to escape to — they land inside a lightweight VM boundary, not on the shared host, making lateral movement to other pods or the node itself impossible.

Conclusion

This post discussed why running OpenClaw workloads in standard containers can be risky when the workload includes untrusted or semi-trusted code: containers share the host Linux kernel, so a single container escape or privileged misconfiguration can expand into node-level compromise and a much larger blast radius. To address this, we introduced microVM-based sandboxing with Kata Containers on Azure Kubernetes Service (AKS) and walked through an implementation approach (a node pool with Kata VM isolation, storage, gateway deployment, and ingress). Finally, we validated the isolation properties by demonstrating that common host-visibility techniques (for example, probing /proc/1/root) no longer reveal host paths when the workload runs inside a microVM.

Separate kernel boundary: Kata runs the container inside a microVM, so the workload executes against a guest kernel rather than the shared host kernel—kernel exploits and escape attempts don’t directly translate into host control.
Host filesystem is no longer “in scope”: paths that often leak host context in standard containers (for example, traversals via /proc) resolve inside the microVM’s filesystem, not the node’s root filesystem.
Reduced blast radius per workload: each sandbox has its own VM boundary, making it much harder to pivot from one compromised workload to other pods/containers on the same node.
Stronger default device and privilege separation: the hypervisor boundary and minimal virtual device model limit exposure to host devices and privileged interfaces that commonly enable breakouts.
Defense-in-depth still applies: you can keep container hardening (seccomp, capability dropping, read-only filesystems, restricted mounts) while gaining an additional isolation layer that is independent of Linux namespaces/cgroups.

Overall, this post helps you deploy OpenClaw on AKS with Kata microVM isolation so you can run agent workloads with a significantly reduced risk of host-kernel compromise from container escape techniques.

How to Manage RC4 Hardening – Definitive Guide

Elanor92 — Thu, 28 May 2026 12:20:17 GMT

How to Manage RC4 Hardening – Definitive Guide

This article is a technical continuation of the RC4 deprecation / Kerberos hardening work I covered in my previous article last month. If you already went through the “why” (risk of RC4, what changes Microsoft is rolling out, and the high-level migration approach), the goal here is to get hands-on and precise: what exactly changes across the three rollout phases, which registry keys and AD attributes drive KDC behavior, what you should expect to see in security logs, and how to turn those signals into concrete remediation steps.

Prerequisites: ensure the January update that introduces the RC4/Kerberos hardening telemetry is installed on all Domain Controllers. Without that patch, the Security log will not emit the new KDC events (201–209) and the Domain Controllers will not evaluate the related registry keys (RC4DefaultDisablementPhase and DefaultDomainSupportedEncTypes).

Note: The information in this article applies only to supported operating systems released before 2025. I haven’t had the time to validate how these keys behave on 2025 versions.

Hardening Phases

Let's begin with a brief walkthrough of the hardening phases. For a detailed walkthrough of the rollout phases, see my previous article. Below is a technical summary of each phase of the RC4 hardening update.

Phase 1 - Auditing - January 2026:
- starting from the January update, you can create the RC4DefaultDisablementPhase registry key. Set it to 1 to enable logging of the new events (201-209) on domain controllers.
- Nothing else changes, for now, the KDC will continue to issue RC4-encrypted tickets.
Phase 2 – Soft enforcement – April 2026: the KDC will reject automatically requests that only support RC4 if the key DefaultDomainSupportedEncTypes has not been manually set to one of the available values to allow RC4 before applying the April update. In this phase:
- RC4DefaultDisablementPhase is set to 2 but can be reverted to 1. If the value was previously set to 1, the patch won’t override the value.
- DefaultDomainSupportedEncTypes: if the value of this key was not set when Phase 2 starts, the value is automatically set to 0x18 by default (AES-only). You can roll it back to 0x1C, 0x24 or 0x3C (you will understand the difference between those two values later in this article) if needed. However, if you had previously defined this key, Microsoft will not override it.
Phase 3 – Hard enforcement – July 2026, note that this phase won't disable RC4 completely, only the ability to default RC4 will be removed.
- the key RC4DefaultDisablementPhase is no longer read
- In this phase, the only way to allow RC4 encryption is to manually set the msDS-SupportedEncryptionTypes attribute to 0x1C (to allow RC4 only for the account) while having the GPO SupportedEncryptionTypes set to support RC4. We can also set the DefaultDomainSupportedEncTypes to 0x1C or 0x24 to allow RC4 for the entire environment.

Note that, if you want to apply the msDS-SupportedEncryptionTypes to allow RC4 at AD object level, but at the same time have the DefaultDomainSupportedEncTypes set to 0x18 you’ll need to set the SupportedEcryptionType policy for the support of RC4 (more details in the scenarios section of this article).

Registry keys and attributes involved

In this section, you’ll find the list of all the registry keys, AD attributes, and GPOs involved in this hardening. The values shown are not exhaustive, I have listed only the specific values relevant to this hardening.

DefaultDomainSupportedEncTypes:

Path: HKLM\System\CurrentControlSet\Services\KDC (Server 2016, Server 2019, Server 2022, 4B.26 Server 2025)

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\ (Windows Server 2025 only)

This key need to be created manually if needed

Possible values:

0x27: enable DES, RC4 and AES session key (default before hardening for pre-2025 OSs)
- Flags enabled: DES-CBC-CRC, DES-CBC-MD5, RC4-HMAC, AES256-CTS-HMAC-SHA1-96-SK
0x24: Enable RC4 and AES session key:
- Flags Enabled: RC4-HMAC, AES256-CTS-HMAC-SHA1-96-SK
0x1C: allow RC4 and AES:
- Flags enabled: RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96
0x3C: enable RC4, AES and AES session key
- Flags enabled: RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96-SK
0x18: enable AES only (default value pre hardening for 2025)
- Flags enabled: AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96
0x38: enable AES and AES session key
- Flags enabled: AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96-SK

Possible values and their meaning during all the phases:

Phase 1:
- The value of this key won’t be changed during phase 1. if the key has not been manually set, you'll have the default value of you operating system during this phase
Phase 2:
- 0x18: default value for this phase. Block the use of RC4 encryption, only AES-128 and AES-256 are allowed. If this key was already explicitly set to any other value before the starting of phase 2, the patch won’t override its value.
- 0x24, 0x1C and 0x3C: these values can be used for manual rollback to allow RC4, I’ll advise using the value 0x1C for increased security. *
Phase 3:
- 0x18: default value for this phase. Block the use of RC4 encryption, only AES-128 and AES-256 are allowed. If this was already explicitly set to any other value, the patch won’t override its value.
- 0x24, 0x1C and 0x3C: these values can be used for manual rollback to allow RC4, I’ll advise using the value 0x1C for increased security. *

Later in this article, you’ll find common scenarios to help you choose the right values based on your audit findings.

* In our labs, setting the DefaultDomainSupportedEncTypes to 0x1C caused login issues on Windows Server 2003 and Windows XP. If you still have these operating systems, test this value carefully in your environment. We tried to set the key to 0x24 and we did not observe the same issues.

RC4DefaultDisablementPhase

Path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters

Note that this key must be manually created and set and will be evaluated only after the installation of the January 2026 update.

Here you can find all the possible values during all phases:

Phase 1:
- 1: audit mode enabled, the events 201-209 are logged onto the domain controller when RC4 is being used (see the table below for details)
- 2: Kerberos will start assuming that RC4 has been disabled and will start to negotiate AES encryption by default
Phase 2:
- The values are the same reported for phase 1. With the April patch the value will change to 2 only if the key was not explicitly set to 1 during phase 1. Anyway, it can be reverted to 1
Phase 3:
- The key is no longer evaluated

msDS-SupportedEncryptionTypes

This attribute is found on all domain objects in the attribute editor tab.

Value available for the attribute:

Null, not set or 0x0: the encryption used depends on the value reported on the DefaultDomainSupportedEncTypes key
0x3C: enables RC4 AES and AES encryption key
- Flags enabled: RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96-SK
0x1C: Enables RC4 and AES:
- RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96
0x38: enables AES and AES encryption key only
- Flags enabled: AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96-SK
0x18: enables AES only
- Flags enabled: AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96

See the section reporting the common scenarios to understand how to correctly use this attribute in your environment.

SupportedEncryptionTypes

This registry key is populated by a GPO on the DCs: “Network security: Configure encryption types allowed for Kerberos”. The path of the GPO is "Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options".

You can find the related registry key at the path: HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\

The values of the registry key depend on the GPO settings. The possible values are:

0x7FFFFFFC: this configuration is needed to support RC4 in your environment
- Encryption type supported: RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96-SK, FAST-supported, Compound-identity-supported, Claims-supported, Resource-SID-compression-disabled, Future encryption types
0x7FFFFFF8: this is value for the recommended configuration
- Encryption types supported: AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96-SK, FAST-supported, Compound-identity-supported, Claims-supported, Resource-SID-compression-disabled, Future encryption types

See the section with the common scenarios to understand how to use this key.

Audit

This section lists the auditing events for this hardening and briefly explains what each one indicates. Starting in January 2026, some existing events were enhanced to surface additional encryption details, and new events were introduced that are available only after installing the January 2025 patch. Microsoft also made two really helpful scripts to collect and analyze events, you can find more details about those scripts at the end of this section.

Existing enhanced events

Some existing events has been enhanced, and can be used for the auditing of RC4 usage, like:

4768: A TGT ticket has been requested
4769: A Kerberos service ticket has been requested

Beyond identifying the client and account requesting the ticket, both events include several fields that are useful for analysis:

msDS-SupportedEncryptionTypes: show the value of this attribute for the account reported in the event
Available keys: shows all the available keys that has been found in AD for that object
Ticket Encryption Type: the actual ciphers used for the ticket encryption:
- 0x17 = RC4
- 0x12 or 0x13 = AES
Session Encryption Type: the actual ciphers used for the session Encryption
- 0x17 = RC4
- 0x12 or 0x13 = AES
Advertised Etypes: lists the encryption types the client supports. If you see only RC4 or DES in this field, it means that we are looking at a legacy client; modern clients should advertise both RC4 and AES.

Note: 4768 events are not correlated with any 201-209 event, while for the 4769 events you can find the related 201-209 event to help you during the troubleshooting.

New events available

During the audit phase we can see the system event log:

Event ID	Type/Phase	Meaning
201	Warning	The client only supports RC4 and the target service's msDS-SupportedEncryptionTypes is not defined. This will fail under enforcement.
202	Warning	The target service account's msDS-SupportedEncryptionTypes is not defined and the service account only has insecure (RC4) keys.
205	Warning	The KDC detected that the domain controller has DefaultDomainSupportedEncTypes explicitly defined to include insecure encryption (RC4) Microsoft will not automatically override this
206	Warning	The target service's msDS-SupportedEncryptionTypes is explicitly set to AES-only, but the client doesn't advertise AES-SHA1
207	Warning	The target service's msDS-SupportedEncryptionTypes is explicitly set to AES-only, but the service account doesn't have AES-SHA1 keys (password not reset).

During the enforcement phase, you can find these events in the system event log:

Event ID	Type/Phase	Meaning
203	Error	The KDC blocked a service ticket because the client only supports insecure types and the service has no explicit encryption config.
204	Error	The KDC blocked a service ticket because the service account only has insecure keys and has no explicit encryption config.
205	Warning	The KDC detected that the domain controller has DefaultDomainSupportedEncTypes explicitly defined to include insecure encryption (RC4) Microsoft will not automatically override this
208	Error	The KDC denied a service ticket because the client doesn't support AES-SHA1 and the service requires it.
209	Error	The KDC denied a service ticket because the service requires AES-SHA1 but has no AES keys.

Below is a list of possible remediation steps based on the events you observe:

201 and 203: these events usually indicate that we are looking to a legacy device. My advice is to correlate this finding to the related 4769 event. The goal is understand if the device is legacy or not:
- The device is legacy: the device does not support AES and needs to be updated. If the update is not feasible now, you can set the msDS-SupportedEncryptionTypes to 0x1C to allow RC4
- The device is not legacy: investigate the reason why the device does not have any AES keys available. Maybe the password of the AD account has not been reset in a long time, or there may be a policy applied to this object to enforce the use of RC4 only
202 and 204: these events usually indicate that the password for the account is too old, so the account cannot generate any AES key for encryption.
- Reset the password and try the authentication again to confirm the resolution of the problem.
206 and 208: these events usually indicate a mismatch between the client and the account configuration. The account may be set to allow AES only but the client may be legacy one.
- You need to update the client, if the update is not feasible now, you can set the msDS-SupportedEncryptionTypes to 0x1C to allow RC4
207 and 209: the account is set to AES but cannot generate an AES ticket.
- Usually, you'll need to reset the password of the account to solve this issue.

See the common scenarios section for more details

Scripts

Microsoft provided two scripts to help us investigate the RC4 usage in our environment:

List-AccountKeys.ps1 to query event logs to enumerate available encryption keys for accounts.
Get-KerbEncryptionUsage.ps1 to identify Kerberos encryption types in use, with filtering options for specific algorithms like RC4.

The scripts are available in this repository: Microsoft's Kerberos-Crypto GitHub repository

Get-KerbEncryptionUsage.ps1

This script can identify the usage of RC4 encryption in the environment by analyzing the events recorded on the domain controllers. The info are collected primarily from the events 4768 and 4769. In the output you’ll find date and time of the event, the requestor and the type of ticket and session encryption used.

Example:

.\Get-KerbEncryptionUsage.ps1 -Encryption RC4 -Searchscope AllKdcs | Export-Csv -Path .\KerbUsage_DC01.csv -NoTypeInformation -Encoding UTF8

List-AccountKeys.ps1

This script is useful to identify which key are available for an object (service account, user, computer account).

Event forwarding

If you have a SIEM available on your environment: lucky you! There is a wonderful article that explains how to collect and forward the event to the SIEM to analyze them: So, you think you’re ready for enforcing AES for Kerberos? | Microsoft Community Hub

Common Scenarios

This section will cover the common scenarios that we may find in the customer’s environment and how to approach it

I have only few objects that are using RC4

Scenario:

During the audit phase I found few legacy devices and applications not compatible with AES
I cannot update those devices/applications before the July 2026 phase (enforcement phase)
I need to leave RC4 enabled for only those objects

DOs:

SupportedEncryptionTypes: you need to set this key to 0x7FFFFFFC to allow the support of RC4 using the GPO (see the "Registry keys and attributes involved" section of this article), otherwise even if the attribute msDS-SupportedEncryptionTypes is set to support RC4, the authentication will break, because the KDC won't know how to interpret RC4.
msDS-SupportedEncryptionTypes: this attribute needs to be set to 0x1C to support RC4
DefaultDomainSupportedEncTypes: can be set to 0x18, this sets AES as the default encryption type for the domain. So, all the account that have the msDS-SupportedEncryptionTypes not set, will use AES by dafault

In this scenario, new accounts and computers will use AES by default, while accounts with the attribute msDS-SupportedEncryptionTypes set to 0x1C will still use RC4. This works because the KDC is configured to allow RC4 even though AES remains the domain’s default.

Note that having devices and applications that rely on RC4, will lower the security posture of your environment, my advice would be to remediate those devices/applications asap.

Many services rely on RC4

Scenario:

During the audit phase I found many devices not compatible with AES
I cannot update those devices/applications before the July 2026 phase (enforcement phase)

If there are too many devices to be remediated using the msDS-SupportedEncryptionTypes attribute, you’ll need to keep RC4 enabled by default at the domain level:

DefaultDomainSupportedEncTypes: needs to be set to 0x1C to allow both AES and RC4
SupportedEncryptionTypes: needs to be set to 0x7FFFFFFC (see the "Registry keys and attributes involved" section for more information about this setting)
msDS-SupportedEncryptionTypes: this attribute does not need to be changed in this scenario.

In this scenario you can evaluate the possibility to use the attribute msDS-SupportedEncryptionType to secure some critical modern devices and applications by setting the attribute to 0x18 or 0x38 to allow only AES encryption for those objects.

No services rely on RC4

Congratulations!! This is the best scenario, you don’t have any legacy devices or applications that can rely only on RC4.

DOs:

DefaultDomainSupportedEncTypes: you can leave it to the July 2026 default (0x18)
SupportedEncryptionTypes: can be set to 0x7FFFFFF8 (see the "Registry keys and attributes involved" section for more information about this setting)
msDS-SupportedEncryptionTypes: there is no need to change this attribute in this scenario

Conclusion

The RC4 hardening rollout is one of those changes that looks simple on paper “move everything to AES”, but succeeds or fails based on how well you turn Kerberos telemetry into an inventory of real dependencies. Across the three phases (audit, soft enforcement, hard enforcement), the KDC gradually shifts from observing RC4 usage to actively rejecting it, and by Phase 3 the domain-wide “allow RC4” escape hatch is gone.

Use Phase 1 and the first part of Phase 2 to build a remediation backlog from the new KDC events (201–209) and the enhanced 4768/4769 fields.

Also keep in mind the blind spots: the absence of KDCSVC audit events does not guarantee that all systems will function correctly after enforcement. These events focus on service ticket requests involving default/implicit encryption behavior; explicitly configured accounts, TGT requests, and non-Windows or embedded Kerberos stacks can still fail in ways that are not surfaced by 201–209 alone.

FAQs

Are there impacts in the forest trusts?

Test external trusts for impact. Trusts between domains in the same forest have used AES since the November 2022 patch. Before enforcing AES-only across a forest, validate that the trusted forest supports AES.

I don’t see any 201-209 events in my environment, does it means that my environment won’t be impacted?

No, the absence of KDCSVC audit events does not guarantee that all systems will function correctly after enforcement. These events focus on service ticket requests involving default/implicit encryption behavior; explicitly configured accounts, TGT requests, and non-Windows or embedded Kerberos stacks can still fail in ways that are not surfaced by 201–209 alone.

Is the msDS-SupportedEncryptionTypes key evaluated by Windows XP and Windows 2003 OSs?

No, those operating systems are not capable to read the msDS-SupportedEncryptionTypes key. In this case, to allow the use of RC4 you’ll need to use the DefaultDomainSupportedEncTypes set to 0x24

Useful Resources

Encryption Type Calculator: Encryption Type Calculator - Kerberos in Active Directory
What is going on with RC4 in Kerberos? | Microsoft Community Hub
Supported Encryption Types Bit Flags [MS-KILE]: Supported Encryption Types Bit Flags | Microsoft Learn
How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 - Microsoft Support
Event 4769: 4769(S, F) A Kerberos service ticket was requested. - Windows 10 | Microsoft Learn
How to manage the Kerberos protocol changes related to CVE-2022-37966 KB5021131: How to manage the Kerberos protocol changes related to CVE-2022-37966 - Microsoft Support
Detect and remediate RC4 usage Detect and Remediate RC4 Usage in Kerberos | Microsoft Learn

Disclaimer

The content of this article is based on available public documentation and test performed on a personal lab environment. The information is provided AS IS without a warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use of the reported information contained in this documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the document be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the data in this documentation, even if Microsoft has been advised of the possibility of such damages.
In short: Every environment is different, please test the changes before the implementation in your production environment

Extracting and Auditing Azure DevOps Permissions at Scale with PowerShell

skissel — Tue, 28 Apr 2026 06:38:27 GMT

Introduction

Azure DevOps organizations accumulate permissions over time. Groups are created, users are added, Entra (Azure AD) groups are nested into project groups, and team structures evolve. For organizations subject to compliance requirements, security reviews, or simply wanting to understand who has access to what, the Azure DevOps portal provides a per-group, per-namespace view that does not scale.

The Azure DevOps REST APIs expose the underlying security model — security namespaces, Access Control Lists (ACLs), Access Control Entries (ACEs), and bitmask-encoded permissions — but consuming these APIs and translating raw data into actionable output requires significant effort.

The blog post introduces ADO Permissions Output, an open-source PowerShell toolset that extracts Azure DevOps security permissions across 30+ security namespaces, resolves cryptic tokens and GUIDs into human-readable names, and produces structured JSON and CSV output suitable for auditing, compliance, and import into Power BI.

The toolset is available on GitHub: ADO-Permissions-Output

The Problem

Consider a typical Azure DevOps organization with multiple projects, dozens of custom groups, Entra-backed security groups, and permissions set at the repository, build pipeline, release pipeline, area path, and service endpoint levels. An auditor needs to answer questions like:

Which groups have Deny permissions on a specific Git repository?
Who has Edit build pipeline access across all projects?
Are there disabled Entra users still showing as members of ADO groups?
Which users have access but have never logged in?

The ADO portal answers these one group at a time. The REST APIs answer them in bitmasks and GUIDs. This tool bridges the gap.

What the Tool Does

At a high level, the tool:

Authenticates to Azure DevOps using a Personal Access Token (PAT)
Enumerates all security namespaces in the organization
Fetches all groups, users, and teams
For each namespace, retrieves ACLs with extended info (effective and inherited permissions)
Decodes bitmask permissions against the namespace action list
Resolves security tokens (GUIDs, paths) to friendly names (project names, repo names, query paths, etc.)
Outputs structured JSON per project with Allow, Deny, Effective, and Inherited permissions clearly labeled
Optionally generates a group membership report with user entitlement status

Architecture Overview

Flowchart of PowerShell and JSON files, their purposes, the REST API endpoints that are called, and the outputs files.

The solution consists of three PowerShell files:

File	Purpose
SecurityMain.ps1	Entry point — loads modules, sets up directories, orchestrates execution
SecurityHelper.psm1	Core engine — namespace enumeration, ACL fetching, bitmask decoding, token resolution
ProjectAndGroup.psm1	Group membership reporting, user entitlement enrichment, directory setup

Configuration is driven by ProjectDef.json, which specifies output directories, filenames, and which namespaces to extract.

All REST API calls route through a centralized Invoke-AdoRestMethod wrapper that provides automatic retry with exponential back-off for HTTP 429 (throttle) and transient server errors.

Setting Up the Pipeline

The tool is designed for unattended execution in an Azure Pipelines pipeline. The included `main.yml` defines a parameterized pipeline that can be run manually from the ADO UI. Additionally, a trigger can be configured to run on a schedule.

Prerequisites

A Personal Access Token with read permissions across security, graph, build, release, work items, service endpoints, dashboards, and analytics scopes
A Variable Group named ADOPermissions containing the PAT as a secret variable
The Build Service identity needs Contribute permission on the repository (for committing output back)

Running the Pipeline

When you run the pipeline, the "Run pipeline" dialog presents parameters for the organization name, project name, and optional features like the membership report and AAD group recursion.

Azure DevOps Pipeline Run dialog from YAML configuration.

The pipeline extracts permissions, commits the output back to the repository, and optionally publishes the output as a pipeline artifact.

Understanding the Permissions Output

The primary output is a JSON file per project. Each entry represents a single permission assignment:

{ "Namespace": "Git Repositories", "Project": "MyProject", "Object": "my-repo", "Type": "Group", "UserGroupName": "Contributors", "PermissionType": "Allow", "Permission": "Contribute", "Bit": 4 }

Permissions are reported as:

Allow — Explicitly granted
Deny — Explicitly denied
Allow (Effective) — Granted through inheritance
Allow (Inherited) — Inherited from a parent scope
Deny (Effective) and Deny (Inherited) — Same patterns for deny permissions

Token Resolution

One of the most valuable features is that raw security tokens are resolved inline. Instead of seeing repoV2/c847308e-d632-4e7f-a7fb-6f4db280bbaa/a1b2c3d4-..., the output shows the actual repository name, build definition name, query path, area path, or service endpoint name.

This resolution covers:

Project names
Git repository names
Build and release definitions
Work item queries (including nested folder paths)
Area paths and iterations
Dashboards (project and team level)
Service endpoints
Variable groups and secure files
Agent pools
Environments
Plans and process templates
Analytics views

The Membership Report

When -IncludeMembership is enabled, the tool generates a separate report showing who belongs to each group and what parent groups each group belongs to.

JSON output of user and group memberships per Azure DevOps group.

Detecting Stale and Ghost Members

The membership report includes Status and LastAccessedDate from the User Entitlements API, along with a ResolvedVia field that indicates how each member was discovered.

ResolvedVia	Status	LastAccessedDate	Meaning
ADO Membership API	active	Recent date	Active user, using ADO
ADO Membership API	active	Null or very old	Has access, never logged in
ADO Membership API	disabled	Any	Admin disabled their ADO access
ADO Membership API	Null	Null	ADO identity exists but entitlement removed
Hierarchy Group Expansion	active	Recent date	Active user, also in an Entra group
Hierarchy Group Expansion	Null	Null	Ghost member — visible in ADO UI via Entra group but has no ADO entitlement

AAD/Entra Group Recursion

When -RecurseAADGroups is enabled, the tool resolves the actual members of Entra (Azure AD) groups that are nested inside ADO groups. This uses the ADO Contribution HierarchyQuery API — the same API that the ADO portal uses to display group members.

This is significant because the standard ADO Graph Memberships API does not return individual members of Entra groups — it only shows the Entra group itself as a member. The HierarchyQuery approach reveals the real users, including those whose Entra accounts have been disabled or deleted but still appear in the ADO UI through group membership.

Importing into Power BI

The JSON output is directly importable into Power BI for visualization and analysis.

Open Power BI Desktop
Get Data > JSON
Select the permissions or membership JSON file
The data loads as a table ready for filtering, pivoting, and visualization

Alternatively, use the -OutputFormat CSV parameter to produce CSV files for direct import via Data > From Text/CSV.

Power BI Dashboard layout of Namespaces, project permissions, user and group names, and count of project permissions.

Common Power BI analyses:

Permission heatmap by namespace and group
Users with Deny permissions across all projects
Group membership overlap between projects
Stale users (active entitlement but no recent access)
Ghost members from Entra group expansion

Key Design Decisions

Sequential execution. The tool processes namespaces sequentially rather than in parallel. This avoids the ADO API throttle penalty box (HTTP 429), which can delay an entire pipeline run. The retry wrapper handles transient 429s with Retry-After header respect, but sequential processing prevents them from occurring in the first place.

PAT authentication only. The tool uses Personal Access Token authentication with Basic auth headers. This keeps the solution simple — no Entra app registrations, managed identities, or module dependencies. The PAT is stored in an ADO Variable Group marked as secret.

Read-only operation. The tool does not modify any permissions, groups, or resources. All API calls are GET or POST (for subject lookups and HierarchyQuery). It is safe to run against production organizations.

Getting Started

Clone the repository: git clone https://github.com/sckissel/ADO-Permissions-Output.git
Create a PAT with the required scopes (see the README for the full list)
For pipeline execution, follow the setup instructions in the README to create the Variable Group and pipeline definition.
For local testing:

./SecurityMain.ps1 ` -PAT "<your-pat>" ` -VSTSMasterAcct "yourorg" ` -projectName "YourProject" ` -allProjects "False" ` -DirRoot "C:\ADOSecurity" ` -IncludeMembership "True" ` -RecurseAADGroups "True" ` -OutputFormat "Both"

Conclusion

Auditing Azure DevOps permissions at scale requires more than the portal provides. This toolset bridges the gap between the raw security APIs and actionable audit output, resolving cryptic tokens into readable names, surfacing effective and inherited permissions, and detecting stale or ghost group members through Entra group expansion.

The tool is open source, requires only PowerShell 7 and a PAT, and is designed for unattended pipeline execution with output committed back to the repository for version-tracked audit history.

Feedback, issues, and contributions are welcome on GitHub: ADO-Permissions-Output

Thanks for reading!

Disclaimer

Designing Outbound Connectivity for "Private Subnets" in Azure

alexeyn1 — Thu, 23 Apr 2026 21:28:09 GMT

Why Private Subnets Change Everything

Historically, Azure virtual machines relied on default outbound internet access, where the platform automatically assigned a dynamic SNAT IP from a shared pool. This was convenient but problematic:

❌ No deterministic outbound IP addresses
❌ No traffic inspection or filtering
❌ No FQDN or URL governance
❌ Difficult to audit for compliance
❌ Susceptible to noisy neighbor SNAT exhaustion

With private subnets, outbound access is disabled by default. This shifts the responsibility to the architect — deliberately. The result is an environment where:

✅ Every outbound flow is intentional
✅ Every outbound IP is known and documented
✅ Every egress path can be governed and logged
✅ Compliance evidence is straightforward to produce

The question is no longer "does my VM have internet access?" but rather "how exactly does my VM reach the internet, and is that path appropriate for this workload?"

The Three Outbound Patterns at a Glance

Option	Primary Role	Inspection	Scale	Cost	Best For
NAT Gateway	Managed outbound SNAT	❌ None	⭐⭐⭐ High	💲 Low	Simple, scalable egress
Azure Firewall	Secure governed egress	✅ Full L3–L7	⭐⭐⭐ High	💲💲💲 Higher	Security boundaries
Load Balancer	Legacy SNAT	❌ None	⭐⭐ Limited	💲 Low	Legacy / transitional

Scenario 1: NAT Gateway

What is NAT Gateway?

Azure NAT Gateway is a fully managed, zone‑resilient, outbound‑only SNAT service. It attaches at the subnet level and automatically handles all outbound flows from that subnet using one or more static public IP addresses or prefixes.

It is purpose‑built for one thing: providing predictable, scalable outbound internet access — without routing complexity or inline devices.

Key flow are depicted below:

VM → NAT Gateway: Automatic SNAT (no UDR required)

NAT Gateway → Internet: Static, deterministic public IP

Inbound: NOT supported (outbound only)

How it works (step by step)

VM initiates an outbound connection (e.g., HTTPS to an API)
NAT Gateway intercepts the flow at the subnet boundary
Source IP is translated to the NAT Gateway's static public IP
The packet is forwarded to the internet
Return traffic is automatically tracked and delivered back to the VM

No UDRs. No routing tables. No inline devices. It just works.

Strengths

Massive SNAT scale — no port exhaustion concerns at typical enterprise scale
Deterministic outbound IPs — easy to allowlist with external services
Zone resilient — survives availability zone failures
Subnet scoped — applies to all VMs in the subnet automatically
No routing configuration required

Limitations

❌ No traffic inspection or filtering
❌ No FQDN or URL policy enforcement
❌ No threat intelligence integration
❌ Cannot restrict which internet destinations are allowed

Best Fit Use Cases

✅ Application tiers calling external SaaS APIs
✅ VMs requiring OS updates and patch downloads
✅ CI/CD build agents and pipeline runners
✅ Spoke VNets in hub‑and‑spoke where east‑west goes through firewall, but simple internet egress is acceptable
✅ Dev/test environments

Scenario 2: Azure Firewall

What is Azure Firewall?

Azure Firewall is a cloud‑native, stateful, L3–L7 network security service. When used for outbound egress, it transforms the egress path from a connectivity function into a security enforcement boundary.

Unlike NAT Gateway, Azure Firewall inspects every packet, evaluates it against policy, and either allows or denies it based on network rules, application rules, and threat intelligence feeds.

KEY Flow are depicted below:

VM → UDR: Forces ALL outbound traffic to Firewall

Firewall: Evaluates against policy before allowing

Firewall → Internet: Only explicitly permitted flows pass

All denied flows: Logged and alertable

How it works (step by step)

VM initiates an outbound connection
UDR intercepts the flow and redirects to Azure Firewall's private IP
Azure Firewall evaluates the traffic:

Network rules (IP/port match)
Application rules (FQDN/URL match)
Threat intelligence (known malicious IPs/domains)

If allowed: traffic is forwarded via Firewall's public IP
If denied: traffic is dropped and logged
All flows (allowed and denied) are logged to Log Analytics / Sentinel

Strengths

✅ Full L3–L7 inspection
✅ FQDN and URL‑based filtering (application rules)
✅ Threat intelligence integration (Microsoft TI feed)
✅ TLS inspection (Premium SKU)
✅ Centralized governance across multiple VNets via Firewall Manager
✅ Rich logging — every allowed and denied flow is recorded
✅ IDPS (Intrusion Detection and Prevention) available in Premium

Limitations

❌ Higher cost (hourly + data processing charges)
❌ Requires UDR configuration on each spoke subnet
❌ Adds latency (small but non‑zero)
❌ Requires careful SNAT configuration at scale

Best Fit Use Cases

✅ Regulated industries (financial services, healthcare, government)
✅ Any workload where outbound internet is a security boundary
✅ Environments requiring egress allowlisting for compliance
✅ Hub‑and‑spoke architectures with centralized control plane
✅ SOC environments needing outbound flow telemetry

Scenario 3: Load Balancer Outbound

What is Load Balancer Outbound?

Azure Load Balancer outbound rules were historically the primary mechanism for providing SNAT to VMs behind a Standard Load Balancer. While newer patterns (NAT Gateway, Azure Firewall) have largely replaced this approach for new designs, outbound rules remain valid in specific scenarios.

Key flows are depicted below:

VMs → Load Balancer: Backend pool members get SNAT

LB Outbound Rules: Define port allocation per VM

⚠️ Port exhaustion risk at scale

⚠️ No inspection or policy enforcement

How it works (step by step)

VM in the backend pool initiates an outbound connection
Load Balancer applies SNAT using the frontend public IP
Ephemeral ports are allocated per VM from a fixed pool
Return traffic is tracked and delivered back to the correct VM
If port pool is exhausted: connections fail (SNAT exhaustion)

Strengths

Lower cost than NAT Gateway or Firewall
Tightly integrated with existing load‑balanced workloads
Familiar operational model for legacy teams

Limitations

❌ SNAT port pool is fixed and must be manually managed
❌ Risk of SNAT exhaustion at scale
❌ No traffic inspection
❌ Less flexible than NAT Gateway
❌ Not recommended for new designs

Best Fit Use Cases

✅ Existing architectures already built around Azure Load Balancer
✅ Low outbound connection volume workloads
✅ Transitional architectures during modernization to NAT Gateway

Decision Framework: Choosing the Right Outbound Pattern

Common Pitfalls to Avoid

⚠️ Pitfall 1: Forgetting SNAT scale limits

Load Balancer outbound rules allocate a fixed number of ephemeral ports per VM. At scale this exhausts quickly. Use NAT Gateway instead.

⚠️ Pitfall 2: Over‑securing low‑risk workloads

Not every workload needs Azure Firewall for outbound. Dev/test and patch traffic are better served by NAT Gateway — simpler, cheaper, faster.

⚠️ Pitfall 3: Mixing outbound models in the same subnet

NAT Gateway and Load Balancer outbound rules cannot coexist on the same subnet. NAT Gateway always takes precedence. Plan your subnet boundaries carefully.

⚠️ Pitfall 4: Blocking Azure platform dependencies

Many Azure services still use public endpoints (even when Private Link is available). Ensure your outbound policy allows required Azure service tags before enforcing egress controls.

⚠️ Pitfall 5: Relying on platform defaults

Default outbound access is retired for new VNets. Do not assume VMs can reach the internet without explicit configuration.

Summary and Key Takeaways

Scenario	Best Choice	Why
Simple internet egress at scale	NAT Gateway	Scalable, predictable, no complexity
Security boundary for egress	Azure Firewall	Inspection, FQDN rules, threat intel
Legacy load‑balanced workloads	Load Balancer Outbound	Transitional only
Regulated / compliance environments	Azure Firewall	Audit logs, policy enforcement
Dev / test / patch traffic	NAT Gateway	Low cost, low friction

The core principle

Private subnets make outbound access intentional. Choose the outbound pattern that matches the risk level of the workload — not the most complex option available.

References

https://learn.microsoft.com/azure/nat-gateway/nat-overview
https://learn.microsoft.com/azure/firewall/overview
https://learn.microsoft.com/azure/load-balancer/outbound-rules
https://azure.microsoft.com/blog/default-outbound-access-for-vms-in-azure-will-be-retired

Strengthening Identity Resilience: A Deep Dive into Microsoft Entra Backup and Recovery

Farooque — Tue, 21 Apr 2026 14:49:07 GMT

In the modern security landscape, we often say that "Identity is the new perimeter." We spend significant resources on Conditional Access, Phishing-Resistant MFA, and Identity Protection to keep the "bad guys" out. But what happens when the threat is already inside, or when a legitimate administrative action goes sideways?

If our identity data the "brain" of our Microsoft 365 and Azure ecosystem is corrupted or maliciously altered, usr entire security posture collapses. Today, we’re exploring the new Microsoft Entra Backup and Recovery capability, a native safety net designed to ensure usr identity infrastructure remains resilient against both accidents and attacks.

Why Native Backup Matters

For years, Entra ID administrators relied on the Recycle Bin for deleted objects. However, a major gap existed: Attribute Corruption. If a script accidentally wipes the department and manager attributes for 10,000 users, or if a malicious actor modifies our most restrictive Conditional Access policies to create a backdoor, the Recycle Bin can't help us the objects aren't deleted; they are just wrong. Restoring these specific states previously required complex PowerShell scripting or expensive third-party tools. Entra Backup and Recovery closes this gap by providing a native, automated way to "roll back" the state of usr objects.

Core Capabilities: How it Works

The service is currently available in Public Preview for customers with Entra ID P1 or P2 licenses. It operates on a simple yet powerful "Snapshot" model:

Automated Daily Snapshots

The system automatically captures a point-in-time view of our tenant every day. Currently, the service maintains a 5-day retention window. This allows us to look back at the state of our environment from yesterday or earlier in the week to find a "known good" configuration.

Visibility via Difference Reports

One of the most powerful features is the Difference Report. Before committing to a restoration, we can compare a specific snapshot against the live state of our tenant. The report provides a granular view of:

Object ID: Exactly which user, group, or policy is affected.
Attribute Changes: A side-by-side comparison showing the "Old Value" (from the backup) versus the "Current Value" (live in the tenant).
Metadata Loading: While the first report may take a moment to load metadata, subsequent reports are lightning-fast, allowing for quick triaging during an incident.

Granular Restoration

We aren't forced into an "all or nothing" recovery. We can choose to restore:

An entire object class (e.g., all Conditional Access Policies).
Specific object types (e.g., only Service Principals).
Individual Object IDs for targeted fixes.

The "Defense in Depth" Identity Strategy

Entra Backup and Recovery is not a standalone silo; it is the third pillar of a complete identity resilience strategy. To truly harden our tenant, we must coordinate these three features:

Pillar 1: Soft Delete (The Recycle Bin)

Used for Deleted Objects. If a user or Microsoft 365 group is deleted, it sits in the Recycle Bin for 30 days. We can restore these easily via the portal or Graph API to maintain the original Object ID and SID.

Pillar 2: Protected Actions (The Vault)

To prevent an attacker from "hard deleting" our objects (purging them from the Recycle Bin so they can't be recovered), we must implement Protected

Actions.

How it works: we assign a "Conditional Access Authentication Context" to sensitive actions like Microsoft.Directory/deletedItems/delete.
The Result: Even a Global Admin cannot permanently purge an object unless they meet strict requirements, such as using a Phishing-Resistant MFA key or working from a Secure Access Workstation (SAW).

Pillar 3: Backup and Recovery (The Time Machine)

Used for Corruption and Configuration Drift. When the object exists but its properties are compromised, this is our "Time Machine" to revert attributes and policy logic to a functional state.

Real-World Scenario: Recovering from a Bulk Logic Error

Imagine an admin runs a bulk update script intended to update the JobTitle for the Sales team. Due to a logic error in the CSV, the script instead clears the SecurityGroup memberships and ExtensionAttributes for the entire department.

Detection: Users lose access to apps because their group memberships are gone.
Analysis: The Admin generates a Difference Report between today and yesterday’s snapshot.
Validation: The report confirms that 500 users now have "null" values for the affected attributes.
Recovery: The Admin selects those 500 User IDs and hits Restore. Within minutes, the attributes are repopulated, and dynamic group memberships begin to recalculate automatically.

Conclusion and Next Steps

The preview of Microsoft Entra Backup and Recovery is a significant step forward in native tenant protection. By combining it with Protected Actions and the Recycle Bin, organizations can finally achieve a "circular" protection model for identity.

Ready to try it? Navigate to the Microsoft Entra Admin Center, look for Backup and Recovery in the left-hand navigation, and explore usr first snapshot today.

Running multimedia AI models on Container Apps with Serverless GPU (A100 & T4)

HoussemDellai — Mon, 20 Apr 2026 17:14:39 GMT

A video format is available for watching.

Prerequisites

- An Azure account with sufficient permissions to create resources.

- Terraform installed on your local machine.

Infrastructure Provisioning

Clone the Github repository and navigate to the project directory.
Initialize Terraform and apply the configuration to provision the necessary Azure resources, including a resource group, virtual network, log analytics workspace, container app environment, storage account, and container app for downloading models.

terraform init terraform apply --auto-approve

The following resources will be created:

ComfyUI Deployment

The ComfyUI application is deployed as a containerized workload on Azure Container Apps. The deployment includes a job that downloads the necessary models for ComfyUI to function properly.

The aca_job_download_models.tf file defines a job that runs a container with the necessary commands to download the models for ComfyUI. The job is configured to run on Consumption worksload profile and has a timeout of 1200 seconds.
The download-models-comfyui.sh script contains the commands to download the models from Hugging Face and save them to the appropriate directory in the ComfyUI application.

Monitoring and Analytics

The Azure Log Analytics workspace is set up to collect logs and metrics from the container app environment. You can use Azure Monitor to view and analyze the logs and metrics for your ComfyUI deployment.

To view the properties and the usage of the GPU behind Container Apps, the command nvidia-smi is helpful.

Start using ComfyUI

Now that ComfyUI is provisioned, accessible on the FQDN exposed by Container Apps and the models are downloaded, you can run the Text to Image workflow in ComfyUI. You can also change the parameters as needed like the prompt.

When ready, click the Run blue button at the top right to start generating the image. It will take some time depending on the size of the image and the complexity of the prompt. Then you should see the generated image in the output node.

Using ComfyUI for Text to Video

To use ComfyUI for Text to Video generation, you can select a Text to Video template from the Workflows section. Choose Wan 2.2 Text to Video as an example. This will open the workflow to generate a video based on a text input.

Important Notes

The storage account key is required to create the storage link in your Container Apps environment. Container Apps does not support identity-based access to Azure file shares. For that it is mandatory to disable Secure Transfer at the Storage Account (more details).

Because of an issue with the Terraform provider, it won't create the Serverless GPU (A100 & T4) workload profiles. You will need to create them manually in the Azure Portal after running terraform apply.

Azure File Shares supports both SMB and NFS. Container Apps also supports both.

To mount NFS Azure Files, you must use a Container Apps environment with a custom VNet. The Storage account must be configured to allow access from the VNet either using Service Endpoint or Private Endpoint (more details)

The NFS protocol can only be used from a machine inside of a virtual network, that is why we use a Private Endpoint.

🔍 SMB vs NFS — What’s the Difference?

SMB (Server Message Block) and NFS (Network File System) are two protocols used to provide shared file storage over a network.

They serve similar purposes but have different strengths, performance characteristics, and typical use cases. NFS is native for Linux.

Consumption profile details

Profile names	vCPU range	Memory range	GPU type	Regions
Consumption	0.25 - 4	0.5 - 8 GB	N.A	All supported regions
Consumption-GPU-NC8as-T4	0.25 - 8	0.5 - 56 GB	NVIDIA T4	To see a full list of available regions, see serverless GPU supported regions
Consumption-GPU-NC24-A100	0.25 - 24	0.5 – 220 GiB	NVIDIA A100

In Serverless GPU profiles, the GPU cost is in addition to the active usage vCPU and RAM prices for your Container App. You pay for the entire GPU cost, even if your Container App only uses a fraction of the GPU's resources. But, for CPU and Memory, you only pay for the resources your Container App actually reserves. To reduce cost, it is very important to right-size the vCPU and Memory for your Container App when using Serverless GPU profiles. You can use Azure Monitor to track the actual resource usage of your Container App and adjust the vCPU and Memory accordingly.

To get the supported profiles for a specific region, you can use the Azure CLI command:

az containerapp env workload-profile list-supported --location swedencentral -o table # Location Name # ------------- ------------------------- # swedencentral D4 # swedencentral D8 # swedencentral D16 # swedencentral D32 # swedencentral E4 # swedencentral E8 # swedencentral E16 # swedencentral E32 # swedencentral Consumption # swedencentral Flex # swedencentral Consumption-GPU-NC24-A100 # swedencentral Consumption-GPU-NC8as-T4

Here is the vCPU, Memory and GPU consumption for the NC A100 v4 and NC T4 v3 Serverless GPU profiles with ComfyUI when running typical workloads.

You can notice that ComfyUI doesn't consume the entire compute power in terms of vCPU and Memory. That is why in Terraform, it is specified that the resource request is less than what the VM offers. That allows to reduce the cost.

Disclaimer

Maintaining Azure Public IP Inventory by Retrieving Exact Deleted Public IP Using Activity Logs

AswiniSurendran — Fri, 17 Apr 2026 12:10:31 GMT

Azure Activity Logs provide strong visibility into resource lifecycle operations across a subscription. Among these are lifecycle events related to Azure Public IP addresses, including creation and deletion.

However, when a Public IP address is deleted, the corresponding delete operation in Azure Activity Logs includes only the Resource ID of the Public IP — not the actual IP address that was assigned to the resource.

Once deletion is complete:

The Public IP resource no longer exists

The Resource ID cannot be resolved

The assigned Public IP address is permanently unretrievable through Azure APIs

For organisations that rely on accurate IP inventory data for:

Security monitoring

Compliance audits

Incident response

Network forensics

This blog presents a production‑ready implementation approach that enables organisations to reliably capture and retain the assigned Public IP address of Azure Public IP resources — even after they are deleted — using Azure Activity Log alerts, Azure Automation, and a persistent resource mapping cache.

The Core Challenge

When a Public IP resource is deleted, Azure emits an Activity Log event like:

---

OperationName: Microsoft.Network/publicIPAddresses/delete

ResourceId:

/subscriptions/<subscription-id>/resourceGroups/<rg-name>/providers/Microsoft.Network/publicIPAddresses/<pip-name>

---

The alert correctly identifies the operation and the affected resource.

However:

The Activity Log does not include the assigned Public IP address.
After deletion, the associated Resource ID no longer resolves to a live Azure resource.

Maintaining Accurate IP Inventory

Enterprises rely on centralised Public IP inventories mapped to workloads and ownership. Since delete Activity Log events emit the Resource ID, inventory systems require the exact Public IP address associated with the deleted resource.

Preventing False Security Investigations

Azure Public IP addresses are globally reused. If a deleted IP remains recorded as owned internally, it may later be assigned to another tenant. This can lead to threat intelligence alerts and internal investigations against an IP address no longer under organisational ownership.

Supporting High‑Churn Dynamic Workloads

Ephemeral workloads such as Azure Machine Learning, CI/CD pipelines, and autoscaling deployments frequently create and delete Public IPs. In such environments, manual lifecycle tracking of assigned IP addresses is not operationally feasible.

Solution Overview

The recommended approach is based on the following principle:

Capture and persist the assigned Public IP address while the resource still exists and retrieve the stored value later when only the Resource ID is available.

This can be implemented using:

Azure Activity Logs
Log Analytics alerts
Azure Automation Runbooks
Persistent mapping cache of Resource ID to IP address

The solution comprises four primary components:

Azure Activity Logs routed to Log Analytics
Log Analytics alert rules detecting Public IP lifecycle operations
Azure Automation Runbooks triggered through webhook actions
Persistent cache storing Resource ID → IP address mappings

Implementation Guide

Step 1: Route Activity Logs to Log Analytics

Public IP lifecycle events are published through the Azure Activity Log under the Administrative category.

To enable lifecycle detection through KQL queries:

Navigate to: Azure Monitor → Activity Log → Diagnostic Settings
Select: Add Diagnostic Setting
Configure the following:

Category: Administrative
Destination: Send to Log Analytics Workspace

4.Select your target Log Analytics Workspace.

5.Click Save.

This allows lifecycle operations to be queried by alert rules from Log Analytics.

Step 2: Deploy an Azure Automation Account

Azure Automation will be used to execute runbooks that process Activity Log alerts and resolve Public IP address details during resource lifecycle operations.

To begin:

Navigate to the Azure Portal.
In the search bar, search for Automation Accounts.
Select Create, provide the following details and Select "Review + Create" to complete the deployment.

Subscription
Resource Group
Automation Account Name
Region

Once the Automation Account has been created:

Navigate to the Automation Account.
Go to Identity under the Account Settings section.
Enable System‑assigned Managed Identity.
Click Save.

This Managed Identity will later be used by the runbooks to securely retrieve Public IP metadata from Azure Resource Manager during alert execution.

Step 3: Assign Managed Identity Permissions

The Automation Account requires read‑only permissions to resolve Public IP resource information securely.

Navigate to:

Subscription → Access Control (IAM) → Add Role Assignment

Assign the following roles to the Automation Account Managed Identity:

Role	Scope
Reader	Subscription
Reader	Log Analytics Workspace

This ensures the runbooks are able to:

Query Public IP resources

Resolve resource metadata

Interpret Activity Log–driven lifecycle operations

Step 4: Create a Persistent Cache Variable

The assigned IP address must be captured and persisted in advance before it is deleted. To maintain this mapping, create a persistent Automation variable to store the following relationship:

Public IP Resource ID → Assigned IP Address

Within the Automation Account:

Navigate to: Shared Resources → Variables
Select + Add.
Configure the variable as follows:

Name: PipLastKnownIps
Type: String
Value: {}
Encryption: Disabled

4.Select Create.

This variable will act as a persistent cache that is dynamically updated during Public IP lifecycle events.

Step 5: Create Required Automation Runbooks

Two Azure Automation Runbooks are required for this implementation.

Runbook Name	Purpose
CacheSeedingRunbook	Builds initial Resource ID → IP mapping
MainLifecycleRunbook	Processes Activity Log alerts

Step 5.1: Create Cache Seeding Runbook

Create Cache Seeding Runbook

This runbook will enumerate all currently existing Public IP resources and populate the cache variable with their assigned IP address mappings.

Navigate to: Automation Account → Runbooks
Select Create a runbook.
Provide the following details:

Name: CacheSeedingRunbook
Runbook Type: PowerShell
Runtime Version: 7.2

4. After the runbook is created, paste the script here CacheSeedingRunbook.

Select Publish.

This runbook will initialise the cache by capturing the current state of all Public IP resources prior to enabling lifecycle‑based Activity Log processing.

Step 5.2: Create Main Lifecycle Runbook

This runbook will be triggered via webhook whenever a Public IP lifecycle event is detected through Activity Logs.

Navigate to: Automation Account → Runbooks
Select Create a runbook.
Provide the following details:

Name: MainLifecycleRunbook
Runbook Type: PowerShell
Runtime Version: 7.2
After the runbook is created, paste the required lifecycle processing script MainLifecycleRunbook

4. Select Publish once configuration is complete.

This runbook will process Activity Log‑based lifecycle events and dynamically update the PipLastKnownIps cache variable in response to Public IP creation or deletion.

Step 6: Create Runbook Webhook

Configure Runbook Webhook

To allow Activity Log alerts to invoke the runbook:

Navigate to: Automation Account → Runbooks → MainLifecycleRunbook
Go to: Resources → Webhooks
Select Add Webhook.
Provide the following details:

Webhook Name
Expiration Date

5. Copy the generated Webhook URL.

This URL will be used by the Alert Action Group in a later step to trigger the runbook upon detection of Public IP lifecycle events.

Step 7: Seed Cache with Existing Public IPs

Before activating the alert‑driven workflow, populate the cache with currently active Public IP resources.

Navigate to: CacheSeedingRunbook → Start and Run the job once.

This will initialise the PipLastKnownIps mapping with all existing Public IP resources. Future lifecycle events will update this cache dynamically.

Step 8: Create Activity Log Alert Rule

Navigate to: Azure Monitor → Alerts → Create Alert Rule
Scope the alert rule to the relevant Log Analytics Workspace.

Under Condition:

Select: Custom Log Search
Use the KQL query available here: query.json
Configure the following parameters as required:
- Evaluation Frequency
- Query Time Range

This alert rule will detect Public IP lifecycle events and trigger the associated Action Group for downstream runbook execution.

Please find the configuration in the attached screenshot below:

Step 9: Configure Action Group to Trigger Runbook

Create an Action Group that invokes the Lifecycle Runbook webhook.
Add a new action.
Configure the action with the following details:

Action Type: Webhook
Paste the previously generated Runbook Webhook URL

3.Enable:

Use Common Alert Schema

(Optional)
Add an Email Notification action to receive lifecycle alerts for troubleshooting or monitoring purposes.

4. Attach this Action Group to the alert rule.

Step 10: Validate the Implementation

To validate:

Create a Public IP resource.
Delete the same resource.
Navigate to: Automation Account → Jobs → MainLifecycleRunbook
Observe the runbook execution output related to:

Public IP creation
Public IP deletion

Although the delete alert contains only the Resource ID, the runbook retrieves the exact assigned Public IP address from the cache.

See the sample output below:

You can extend this workflow using Azure Logic Apps to forward events to Email , SIEM platforms or CMDB systems.

Conclusion

In addition to tracking Public IP deletions using Activity Logs, proactively capturing and persisting Resource ID–to–IP mappings through Automation‑driven lifecycle alerts, organisations can maintain an accurate Public IP inventory—ensuring traceability, reducing false‑positive security investigations, and strengthening audit and incident response readiness.

rss.livelink.threads-in-node

Authenticating AWS Workloads to Azure Functions using Workload Identity Federation

What you will learn:

Why this approach is needed

What is Workload Identity Federation?

Section 1: AWS side setup

Step 1–Enabling Outbound Identity Federation

Step 2– Create a role for your AWS resource (Lambda, EC2)

Section 2: Azure side setup

Step 3 — Register the AWS Caller App in Entra ID

Step 4— Create Federated Credentials

Step 5— Register your Function App in Entra ID

Step 6– Create an App Role in function-api-app

Step 7– Assign API Permissions to the aws-caller-app

Step 8— Configure Authentication on the Azure Function resource (aws-entra-federation-api)

Section 3: Validating the setup

Step 9 – Requesting Azure token and authenticating to the function app.

Conclusion

Check This Out! (CTO!) Guide (May/June 2026)

Microsoft Security Copilot: AI-Driven Security Operations at Greater Scale

Key Benefits for Security Operations

Seamless Integration with the Microsoft Security Ecosystem

Open Extensibility with Third-Party Plugins and Skills

Technical Resources:

Security Copilot RBAC for Embedded Experience in Unified Security Platform

Automating Daily MDE Compliance Monitoring Across Azure VMs

The Problem We’re Solving

What changes once you deploy this

Compliance States Detected

Workflow Architecture

Execution Pipeline

How Azure VM Data is Matched to MDE Data

Pagination Design

PrerequisitesAzure Resources

The ServerOwner Tag

Required Permissions & Why

Permission Summary

Where to find the required values

Permission Assignment Script

Verify Permissions Assigned

Creating the Logic AppCreate the resource

Enable System-assigned Managed Identity

Create the workflow and import the JSON

Configuration: What You Can Change

Email Address Variables

Compliance look-up window: MDE_LASTSEEN_HOURS

Running VMs Only

Sample Email Notifications

Per-VM owner alert

IT Team Daily Summary Report

All Compliant VMs:

Post-Deployment Checklist

Wrapping Up

Appendix A: Workflow JSON

Analyse Intune Diagnostics Logs with GitHub Copilot

TL;DR

GitHub Copilot – not only for developers

Getting started in two minutes

Example #1 – Why did our PCs restart during the day?

Example #2 – Why did the Autopilot deployment fail?

Remarks

Summary

Helpful resources and references:

Disclaimer:

At-Scale Failure Reporting for Azure Update Manager

Introduction

The Challenge: Scaling Patch Failure Visibility

Key Insight: Where Azure Update Manager Stores Data

Understanding Maintenance Runs and Correlation IDs

The Solution: Query Failed VMs with Error Messages

Core Query (Kusto Query Language)

What This Query Delivers

Sample Output (Conceptual)

Advanced Scenario: Automatically Detecting the Latest Failed Maintenance Run

Why This Approach Matters

Best Practices for Enterprise Patch Reporting

Conclusion

References

Redefining Security for an AI Driven World

Challenge 1: Safeguarding Data Privacy in the AI Era

Prerequisites
Azure Resources

Creating the Logic App
Create the resource