rss.livelink.threads-in-node

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

TysonPaul — Mon, 03 Aug 2026 19:03:30 GMT

Member: TysonPaul | Microsoft Community Hub

Enhanced host pool management for Azure Virtual Desktop is now generally available

Author: NeoCai

Published: 07/09/2026

Summary: Azure Virtual Desktop has introduced enhanced host pool management, now generally available, featuring session host configuration and update, dynamic autoscale, and ephemeral OS disks. These improvements streamline management, reduce operational overhead, and support secure, reliable, and scalable virtual environments. Session host configuration enables centralized settings and easy updates, ephemeral OS disks improve performance and rapid refresh for stateless workloads, and dynamic autoscale optimizes resource allocation and cost efficiency based on demand. Administrators can easily configure these features through the Azure portal for more efficient and consistent host pool management.

How SCBX built AI literacy at scale and made AI part of daily work

Team Blog: Microsoft Learn

Author: ToddMinor

Published: 07/30/2026

Summary: SCBX partnered with Trainocate and Microsoft to boost AI literacy and embed AI in daily work across thousands of employees. Through a phased, role-based training approach—combining foundational learning, practical application, and advanced technical tracks—SCBX ensured adoption at scale while maintaining governance standards. Over 15,000 participants engaged, with measurable gains in productivity and satisfaction as teams automated repetitive tasks and applied AI in their roles. SCBX’s experience highlights the value of structured, outcome-focused skilling to drive AI readiness and business transformation across a regulated enterprise.

New Microsoft 365 Certified: AI Services Administrator Associate Certification

Team Blog: Microsoft Learn

Author: LibertyMunson

Published: 07/28/2026

Summary: Microsoft has launched the Microsoft 365 Certified: AI Services Administrator Associate certification, validating skills to configure, manage, secure, and optimize Microsoft 365 and AI services like Copilot at enterprise scale. Candidates must pass Exam AB-650 (beta), which is discounted 80% for the first 300 test-takers before August 18, 2026, using code AB-650SkyClub. The certification is designed for experienced Microsoft 365 administrators with knowledge of Entra ID, Defender XDR, and Microsoft Graph PowerShell. Preparation resources and exam details are available online, with general availability expected in October 2026.

Hunting Local AI Tools on macOS with Microsoft Defender for Endpoint

Team Blog: Core Infrastructure and Security

Author: Vytas_Boyev

Published: 07/14/2026

Summary: The article discusses emerging security challenges as developers increasingly run AI tools locally on macOS, expanding the attack surface for organizations. It outlines how Microsoft Defender for Endpoint (MDE) can detect and inventory local AI agents, such as Ollama and OpenClaw, using advanced KQL queries for process, file, and network telemetry. Recommendations include establishing a baseline inventory, monitoring new AI tool usage, skill file changes, suspicious behaviors, and external network connections. The article emphasizes a layered, tuned detection strategy, practical limitations, and the importance of visibility over default blocking to manage AI risks effectively.

Azure Database Security Newsletter - July 2026

Team Blog: Core Infrastructure and Security

Author: PieterVanhove

Published: 07/07/2026

Summary: **Summary:** The July 2026 Azure Database Security Newsletter highlights the evolving impact of AI agents on database security, emphasizing identity-first access, least privilege, data-aware protection, and continuous monitoring. Key updates include support for AES keys in Transparent Data Encryption, Microsoft Entra server principals for Azure SQL Database, cross-tenant key management for PostgreSQL, and Defender security posture assessments. Best practices urge secure-by-default configurations, data classification, and ongoing vulnerability assessments. The newsletter also features recent blogs, events, and calls to review agent access as AI-driven workloads increase, stressing proactive database security adaptation.

Agent governance is organizational readiness

Team Blog: FastTrack

Author: AuzinAhmadi

Published: 07/30/2026

Summary: The article emphasizes that effective agent governance is essential for scaling AI in healthcare organizations. It argues that success depends less on technology and more on readiness—specifically, whether governance structures ensure agents fit clinical workflows, assign clear accountability, manage risk, and secure stakeholder trust. A governance triad (IT, Legal, Business) is needed to vet, approve, and monitor agents before deployment. A checklist ensures readiness by confirming ownership, data access, measurable outcomes, and shutdown conditions. Ultimately, strong governance—not just technical capability—determines whether AI agents are safely and successfully integrated into healthcare operations.

Understanding Copilot Risk: Mapping Exposure Across Zero Trust Pillars

Team Blog: FastTrack

Author: AuzinAhmadi

Published: 07/06/2026

Summary: The article examines Microsoft 365 Copilot’s impact on organizational data security, highlighting how Copilot accelerates data discovery based on existing user permissions. It maps Copilot-related risks across four Zero Trust pillars—identity, endpoints, apps, and data—emphasizing the importance of access governance, permission hygiene, and data protection. Copilot doesn’t grant new access but amplifies the exposure of overshared or poorly governed content. Organizations should assess who can access Copilot and what data it surfaces, using Zero Trust strategies to identify and mitigate risks before scaling deployments.

Azure Arc Server June Forum

Team Blog: Azure Arc

Author: Aurnov_Chattopadhyay

Published: 07/29/2026

Summary: The June 2026 Azure Arc Server Forum covered updates on Arc Server AI Agent integration, new multicloud connectors for GCP and EKS clusters, and ESU timelines for Windows Server 2016 and SQL Server 2016. Attendees received guidance on enrollment and licensing, and were informed about upcoming end-of-support dates. The forum will pause for July and August, resuming in September. Leadership of the community calls is transitioning to Mason Torres, Yunis Hussein, and Meagan McCrory. Registration and agent release notes are available online.

Plan for Upcoming Changes to Extended Security Updates on Azure Local

Team Blog: Azure Arc

Author: sydbruck

Published: 07/09/2026

Summary: Starting April 1, 2026, Microsoft will implement a uniform pricing model for Extended Security Updates (ESU) for SQL Server and Windows products, regardless of deployment location or purchasing channel. This affects new ESU offerings, such as Windows 10 Enterprise LTSB 2016 and Windows Server 2016, but not existing ESUs. Customers are encouraged to upgrade to newer versions before end of support; further ESU pricing and availability details will be announced. Existing ESUs remain free on Azure Local via Azure Verification for VMs.

Beyond the Canvas: The Azure Architecture Diagram Builder Becomes Agent-Ready

Team Blog: Azure Architecture

Author: arturoqu

Published: 07/10/2026

Summary: The Azure Architecture Diagram Builder has evolved from a click-based app to an agent-ready platform. Key updates include Architecture Chat for iterative, conversational design, Blueprint Diagrams for whiteboard-style visuals, and support for 14 AI models. The tool now operates as a Model Context Protocol (MCP) server, enabling agents to generate, validate, estimate costs, and render Azure architectures programmatically. Enhancements include deployment guides grounded in Microsoft Learn, cost badges, theme options, and metadata panels. The platform remains open-source, offering evidence-based model comparison and integration for both human users and AI agents.

Skill or Sub-Agent. Choosing AI Capabilities You Will Actually Reuse

Team Blog: Azure Architecture

Author: KishoreKumarPattabiraman

Published: 07/30/2026

Summary: The article advises cloud architects and engineering leaders to prioritize choosing the right AI capability shape—skill or sub-agent—over model selection. Skills are iterative, voice-driven, and require ongoing human involvement, ideal for craft and subjective tasks. Sub-agents handle structured, repeatable work with one-off outputs and minimal human gating. The recommended approach is to match the capability to the work's nature, sometimes combining both, to maximize reuse and effectiveness. Teams should assess iteration, output, blast radius, and frequency before building, avoiding the mistake of forcing all tasks into a single delivery shape.

Introducing Kubernetes-Native Policy Validation with CEL and VAP in Azure Policy

Team Blog: Azure Governance and Management

Author: stevenbucher

Published: 07/23/2026

Summary: Azure Policy for Kubernetes now supports Kubernetes-native policy validation using Common Expression Language (CEL) and Validating Admission Policy (VAP) with Gatekeeper integration. This enables faster, in-process policy enforcement directly in the Kubernetes API server, improving reliability and latency over previous OPA Rego-based webhook methods. Users write CEL constraint templates, package them as Azure Policy definitions, and deploy them for governance, audit, and enforcement. This approach enhances compliance tracking and centralized management for AKS clusters running Kubernetes v1.30+, combining native validation logic with Azure Policy’s robust governance capabilities.

Introducing Compliance Substate for Azure Policy Exemptions!

Team Blog: Azure Governance and Management

Author: stevenbucher

Published: 07/28/2026

Summary: Azure Policy now introduces a compliance substate for exempted resources, revealing their underlying compliance status even when exemptions are applied. Previously, exemptions hid whether a resource was compliant or not, making audits difficult. Now, resources show "Exempt" plus a substate ("Compliant" or "Non-compliant"), enabling easier exemption management and cleanup. The compliance substate can be viewed in the Azure Policy blade, added as a column, and queried across subscriptions using Azure Resource Graph, improving governance visibility and confidence in policy enforcement.

Reservation exchanges for Azure services covered by savings plans end starting Feb. 1, 2027

Team Blog: FinOps

Author: kyleikeda

Published: 07/30/2026

Summary: Starting February 1, 2027, Azure reservation exchanges will no longer be available for services covered by savings plans, aligning policies for greater clarity. Impacted services include several compute and database offerings. Existing reservations purchased before this date retain one final exchange right. Reservations remain available for stable workloads, while savings plans offer flexibility for dynamic needs. Instance size flexibility and cancellation policies are unchanged. Customers should review their reservation portfolios and consider savings plans for future flexibility. Policy details may evolve as savings plan coverage expands.

Introducing Cost Management and Pricing Toolsets in Azure Resource Manager MCP Server

Team Blog: FinOps

Author: demiajayi

Published: 07/29/2026

Summary: Microsoft has integrated Cost Management and Pricing toolsets into Azure Resource Manager MCP, allowing AI agents to access and analyze Azure cost, pricing, budget, and optimization data directly within cloud workflows. This enables users to estimate costs before deployment, track and explain spending, manage budgets, identify savings, and analyze AKS workloads without switching tools. The release provides APIs for querying costs, managing budgets, reviewing savings opportunities, and retrieving pricing details, making cloud operations more cost-aware and efficient. Installation requires VS Code, an Azure account, and specific configuration steps. Future enhancements and feedback opportunities are planned.

From hours to minutes: Rethinking Microsoft Intune compliance reporting with the Export API

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 07/24/2026

Summary: The article explains how Microsoft Intune’s Export API dramatically improves compliance reporting for large device fleets. By replacing thousands of per-device Graph API calls with a single bulk export, reporting jobs drop from ~100,000 calls and 2.5 hours runtime to ~15 calls and 15 minutes. The Export API delivers identical data in one file, simplifying maintenance, reducing failure points, and enabling scalability without downstream changes. It’s ideal for scheduled, bulk reports, while traditional endpoints remain best for real-time, single-device queries. Overall, the Export API offers faster, more reliable, and scalable compliance reporting.

Build a patch strategy for today’s threat pace with Microsoft

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 07/09/2026

Summary: Microsoft outlines a modern patch strategy to address today’s fast-paced threat landscape, leveraging AI and integrated tools like Intune and Microsoft Defender. The approach focuses on three stages: automating updates for quick mitigation, prioritizing remediation based on risk and exposure, and enforcing compliance to contain unpatched vulnerabilities. Intune centralizes management for Windows, Apple, and Android devices, supporting automated updates, risk assessment dashboards, and compliance controls. This operational discipline helps organizations reduce risk, accelerate response times, and maintain secure, up-to-date endpoints across diverse device fleets. Licensing requirements for advanced features vary by Microsoft 365 subscription.

Azure Elastic SAN: Pooled, Cloud-Native Block Storage That Actually Acts Like a SAN

Team Blog: ITOps Talk

Author: Pierre_Roman

Published: 07/17/2026

Summary: Azure Elastic SAN is Azure’s fully managed, cloud-native SAN storage, offering pooled block storage accessible via iSCSI. It enables IT pros to provision combined capacity and performance, dynamically sharing resources across multiple workloads, reducing over-provisioning and costs. Supporting up to petabyte-scale, millions of IOPS, and high throughput, Elastic SAN integrates with Azure VMs, Kubernetes, VMware, and container storage. It provides familiar SAN resource hierarchy, network isolation, encryption, snapshots, and cost-effective scaling. Best suited for consolidating many IO-intensive workloads, Elastic SAN delivers significant TCO savings and simplifies migration from on-prem SANs.

Premium SSD v2 and Instant Access Snapshots: A Better, Faster, Cheaper Disk for Your Azure VMs

Team Blog: ITOps Talk

Author: Pierre_Roman

Published: 07/20/2026

Summary: Premium SSD v2 (PV2) for Azure VMs offers significant improvements over Premium SSD v1, delivering up to 4x more IOPS, 2x more throughput, and 42% lower costs. Key features include independent scaling of capacity, IOPS, and throughput, sub-millisecond latency, and live resizing without VM downtime. Instant Access Snapshots enable near-instant restores and faster, lower-latency hydration. PV2 is ideal for I/O-intensive workloads like SQL, SAP, and analytics, and supports efficient scaling, rapid recovery, and cost optimization. However, it cannot be used as an OS disk or with host caching.

Microsoft Discovery: Where HPC meets agentic AI for the next era of EDA

Team Blog: Azure High Performance Computing (HPC)

Author: richpaw

Published: 07/21/2026

Summary: Microsoft Discovery is an enterprise agentic AI platform designed to enhance electronic design automation (EDA) by combining high-performance computing (HPC) with intelligent orchestration. Built on Azure, it coordinates specialized AI agents to reason, plan, execute, and learn across complex engineering workflows, optimizing tasks such as simulation, analysis, and documentation. Discovery integrates seamlessly with Azure HPC, storage, and automation tools, enabling hybrid workflows and improving engineering productivity. Its human-in-the-loop approach ensures transparency and validation through established EDA practices, allowing engineers to focus on creative problem-solving while repetitive tasks are automated.

Connecting Microsoft Discovery App to Azure HPC with Azure NetApp Files and CycleCloud

Team Blog: Azure High Performance Computing (HPC)

Author: richpaw

Published: 07/21/2026

Summary: The article outlines how to integrate Microsoft Discovery, an AI platform for R&D, with traditional Azure HPC environments using Azure NetApp Files and CycleCloud. By running Discovery on a Windows VM within the Azure network, mapping shared storage, and utilizing SSH for job submission, users can bridge AI-native and HPC workflows. This enables Discovery agents to manage files, submit jobs, and interact securely with HPC clusters, leveraging AI to automate and enhance engineering workloads without disrupting existing processes, while maintaining security, performance, and operational best practices.

Move a live GitLab project between groups without breaking Terraform state or CI/CD

Team Blog: Azure Infrastructure

Author: HimanshuYadav

Published: 07/31/2026

Summary: Moving a live GitLab project between groups can disrupt Terraform state, CI/CD variables, runners, and cloud authentication if paths are hardcoded or inherited resources aren’t handled. The project ID remains unchanged, but group-level variables and runners must be recreated or reconfigured. Key the Terraform backend to the project ID, not the project path, and update any cloud credentials mapped to the old namespace. Thorough inventory, backups, and a freeze window ensure a safe transfer and rollback. Validate everything post-move to avoid drift or broken pipelines. Proper preparation and verification prevent common pitfalls.

Azure Cobalt: Workload-Aware Power Management for More Efficient Datacenters

Team Blog: Azure Infrastructure

Author: redsa

Published: 07/16/2026

Summary: Microsoft’s Azure Cobalt CPUs introduce industry-first, per-VM power monitoring and capping, achieved through hardware/software co-design. This enables fine-grained, workload-aware power management, selectively throttling non-critical VMs while preserving performance for priority workloads. The approach allows up to 20% more power oversubscription and 24% higher performance compared to software-only capping, supporting more efficient datacenter operations and sustainability. End-to-end integration across Azure infrastructure enables optimized VM placement and real-time telemetry, demonstrating the benefits of deep hardware/software collaboration for balancing performance, efficiency, and sustainability in cloud environments.

Microsoft is headed to VMware Explore 2026 in Las Vegas

Team Blog: Azure Migration and Modernization

Author: KirstenMegahan

Published: 07/28/2026

Summary: Microsoft will participate in VMware Explore 2026 in Las Vegas, offering breakout sessions and expert roundtables focused on Azure and its partnership with VMware by Broadcom. Attendees can learn about streamlined migration of VMware workloads to Azure, maximizing on-premises investments, and leveraging AI innovation. Sessions will cover migration best practices, security, and unlocking data and AI capabilities, along with enticing migration offers. The event aims to help businesses gain a competitive edge by transitioning from on-premises to Azure.

Azure Front Door edge actions: programmable compute for a secure, resilient, AI-ready edge

Team Blog: Azure Networking

Author: AbhishekTiwari

Published: 07/30/2026

Summary: Azure Front Door edge actions introduces programmable compute at Microsoft's global edge, enabling customer-defined logic for secure, low-latency web experiences. Its architecture prioritizes hyperscale performance, strong security, tenant isolation, and resiliency using Hyperlight micro-VMs for hardware-backed isolation. Edge actions maintains local execution to minimize latency, employs fast-fail and circuit-breakers for stability, and continuously validates resiliency through Game Days. Designed for current and future intelligent workloads, it ensures programmability without compromising Azure Front Door’s reliability, security, or performance, making edge programmability a foundational capability for modern applications.

Scale limits in network security perimeter

Team Blog: Azure Networking

Author: shashankamalladi

Published: 07/31/2026

Summary: The article outlines updated hard limits for network security perimeters in PaaS deployments, including 1,000 perimeters per subscription, 200 profiles per perimeter, 200 rule elements per profile, and 2,500 associated PaaS resources. Rule elements per profile are now capped at 200 for new customers. Existing customers exceeding 200 can edit or reduce rules until October 31, 2026; after that, only reductions are allowed. These changes aim to enforce consistent security scalability and operational boundaries.

Secure Native Access to Azure Kubernetes Service (AKS) Private Clusters with Azure Bastion

Team Blog: Azure Network Security

Author: saikishor

Published: 07/09/2026

Summary: The article explains how Azure Bastion's native client tunneling (now in public preview) enables secure, simplified access to private Azure Kubernetes Service (AKS) clusters without needing VPNs or jump hosts. Bastion establishes an encrypted tunnel from engineers’ local machines to the private AKS API server, maintaining strong network isolation. It supports modern authentication methods, including Microsoft Entra ID and Azure RBAC, for centralized, auditable access control. This approach streamlines cluster management while enhancing security by removing public endpoints and reducing exposure to credential theft or infrastructure compromise.

Optimize Oracle workloads on Azure with Azure NetApp Files

Team Blog: Azure Storage

Author: GeertVanTeylingen

Published: 07/09/2026

Summary: The article details recent advancements in Azure NetApp Files that optimize Oracle workloads on Azure, focusing on predictable performance, flexible scaling, and enhanced data protection. Key features include flexible service level capacity pools, automated application volume group deployment, availability zone-aware volume placement, integrated migration tools, space-efficient short-term clones, cool access tiering, and rapid backup and test/dev refreshes. These improvements enable easier Oracle environment sizing, deployment, protection, and scaling, reducing costs and complexity while supporting business continuity and modernization of Oracle workloads in the Azure cloud.

Terraform AzureRM provider 5.0 now generally available

Team Blog: Azure Tools

Author: stevenjma

Published: 07/29/2026

Summary: Terraform AzureRM Provider 5.0 is now generally available, offering major improvements for managing Azure infrastructure as code. Key updates include greater control over Azure Resource Provider registration, optional Azure preflight validation to catch issues earlier, and removal of deprecated resources and properties. Users are advised to carefully review their configurations before upgrading due to breaking changes. The release aims to provide clearer provider behavior, faster feedback during workflows, and a cleaner foundation for future Azure features. Detailed migration guidance and changelog are available to assist with upgrading.

Securing Enterprise AI Agents with Microsoft Sentinel

SantoshPargi — Fri, 31 Jul 2026 02:30:39 GMT

1. Introduction

Enterprise adoption of Generative AI is accelerating rapidly through Microsoft 365 Copilot, Copilot Studio, Azure AI Foundry Agents, Security Copilot, and custom AI agents integrated with business applications.

Unlike traditional SaaS applications, AI agents can:

Access enterprise data
Query internal knowledge repositories
Invoke APIs and MCP tools
Execute workflows
Interact with business applications
Make decisions on behalf of users

While these capabilities improve productivity, they introduce a new attack surface that security teams must monitor and secure.

Common AI threats include:

Prompt Injection
Cross Prompt Injection Attacks (XPIA)
Jailbreak Attempts
Unauthorized Tool Invocation
Data Exfiltration through AI Agents
Agent Identity Abuse
Excessive Data Access
Malicious MCP Tool Execution

Traditional SOC monitoring platforms were designed for users, devices, applications and infrastructure—not autonomous AI systems.

To address this challenge, Microsoft provides a comprehensive AI security monitoring framework built around:

Agent 365 Observability
Microsoft Agent Identities
Microsoft Copilot Logs
Defender XDR
Defender for AI
Microsoft Sentinel

Together these components provide end-to-end observability of:

User prompts
Agent execution paths
Tool invocations
Safety signal detections
Agent identities
Security alerts

2. Reference Architecture

AI Security Monitoring Architecture

3. Integration Architecture

Microsoft provides multiple telemetry sources that complement one another.

3.1 Agent Runtime Telemetry

Sentinel Data Connector

Agent 365 Data Connector

Table

UnifiedAgentObservability

Captures runtime behavior of AI agents including:

User prompts
Session IDs
Conversation IDs
Agent identities
MCP tool invocations
Connector invocations
Tool arguments
Tool responses
Request payloads
Response payloads
Execution errors

This dataset provides the forensic trail of everything an AI agent performed.

3.2 Agent Governance and Asset Inventory

Sentinel Data Connector

Microsoft Agent Identities

Provides visibility into:

Agent inventory
Agent blueprint inventory
Ownership
Relationships
Governance metadata
Risk context

This allows SOC teams to answer:

Who owns this agent?
What permissions does it have?
Which business unit deployed it?
Which related agents exist?

3.3 Copilot Audit and Usage Monitoring

Sentinel Data Connector

Microsoft Copilot Logs Connector

Table

CopilotActivity

Provides:

Copilot usage auditing
Operational visibility
User interaction tracking

Useful for governance, compliance and adoption reporting.

3.4 AI Safety Telemetry

Sentinel Data Connector

Microsoft Defender XDR Connector

Table

CloudAppEvents

CloudAppEvents provides AI safety signals such as:

Prompt Shield detections
Prompt Injection attempts
Cross Prompt Injection Attacks (XPIA)
Jailbreak-related verdicts
Unsafe prompt classifications

Think of CloudAppEvents as answering:

"Was the prompt malicious?"

3.5 AI Security Alerts

Sentinel Data Connectors

Microsoft Defender XDR
Microsoft Defender for Cloud

Tables

SecurityAlert
SecurityIncident

Used for:

AI attack detections
Security incidents
Correlated investigation workflows

4. Understanding the Two Most Important AI Tables

CloudAppEvents

Focuses on AI Safety

Questions answered:

Was Prompt Shield triggered?
Was this a jailbreak attempt?
Was XPIA detected?
Was the prompt suspicious?

UnifiedAgentObservability

Focuses on Agent Runtime Behavior

Questions answered:

What tool was invoked?
Which connector executed?
What arguments were passed?
What data was returned?
What actions did the agent perform?

5. Advanced Threat Hunting Scenarios

The Agent365 Observability hunting guide contains several investigation scenarios that can be used directly in Microsoft Sentinel.

Reference: Agent 365 Observability — AI Agent Telemetry Hunting

https://github.com/SCStelz/security-investigator/blob/main/queries/cloud/agent365_observability.md

5.1 Prompt Injection Detection

Detect prompts containing indicators such as:

Ignore previous instructions
Reveal system prompt
Developer mode
Disregard safety controls

Investigation workflow:

Review Tool Activity

This allows analysts to determine whether a suspicious prompt resulted in downstream actions.

5.2 Session Reconstruction

One of the most powerful capabilities of UnifiedAgentObservability is session reconstruction.

Analysts can correlate:

This creates complete forensic timelines.

5.3 MCP Tool Auditing

Monitor all MCP activity including:

query_lake
Graph API tools
ServiceNow connectors
SharePoint connectors
Custom enterprise tools

Questions answered:

Which tool was used?
Who triggered it?
What parameters were supplied?
What data was returned?

5.4 Sensitive Data Access Monitoring

Monitor AI agent interaction with:

Employee records
Customer data
Financial information
SharePoint repositories
HR databases

Useful for identifying:

Data exfiltration attempts
Excessive access patterns
Sensitive data exposure

5.5 Query Lake Monitoring

The GitHub hunting guide introduces monitoring of:

query_lake
RunAdvancedHuntingQuery

Analysts can inspect:

Actual KQL submitted
Target workspaces
Data sources queried
Scope of access

This provides visibility into AI-driven security investigations.

5.6 New Tool Detection

Identify newly observed tool usage.

Examples:

Unauthorized MCP servers
Newly registered connectors
Unapproved tools
Unexpected integrations

This use case is particularly useful for governance programs.

5.7 Tool Failure Monitoring

Monitor:

Permission failures
Connector failures
Application errors
Access-denied responses

A sudden increase in failures may indicate:

Reconnaissance activity
Misconfiguration
Privilege abuse attempts

6. Detection Engineering Opportunities

Organizations can create Sentinel Analytics Rules for:

6.1 Prompt Injection Detection

Developer Mode prompts
Prompt Override attempts
System Prompt disclosure requests

6.2 Jailbreak Attempt Detection

Safety bypass attempts
Role manipulation prompts
Instruction override patterns

6.3 Unauthorized Tool Usage

New MCP tools
High-risk connectors
Rare tool executions

6.4 Sensitive Data Access

HR data queries
Identity information retrieval
Large-volume exports

6.5 Agent Identity Abuse

Ownership changes
Unexpected agent activity
Agent-to-agent anomalies

7. Data Lake Exploration and Long-Term Analytics

Because agent telemetry resides within Sentinel Data Lake, organizations can perform:

Long-term AI investigations
Historical AI attack analysis
Agent baselining
Governance reporting
Trend analysis
Tool inventory reporting

Example dashboards include:

Top Prompt Injection Attempts
Most Active Agents
High-Risk MCP Tools
Agent Ownership Analysis
AI Security Incidents
Sensitive Data Access Trends

8. Summary

AI agents represent the next major computing platform, but they also introduce a completely new attack surface.

To effectively secure enterprise AI solutions, organizations require visibility across:

User interactions
Agent execution paths
MCP tool usage
Prompt safety signals
Agent identities
Security detections

Microsoft Sentinel provides this unified view by integrating:

Agent 365 Observability
UnifiedAgentObservability
Microsoft Agent Identities
Microsoft Copilot Logs
CloudAppEvents
Defender XDR
Defender for AI

By combining AI runtime telemetry with AI safety signals and Defender detections, security teams can move beyond traditional monitoring and build a modern SOC capability for threat hunting, incident response, governance and forensic investigations across Microsoft 365 Copilot, Copilot Studio, Azure AI Foundry and future AI agent ecosystems.

Reference: https://github.com/SCStelz/security-investigator/blob/main/queries/cloud/agent365_observability.md

Device Code Flow: The Gift That Keeps on Giving — To Attackers

akyamaza — Mon, 27 Jul 2026 00:46:16 GMT

Tags: Microsoft Entra ID, Conditional Access, Device Code Flow, OAuth, Azure Arc, Azure Migrate, Identity Security, Zero Trust

Introduction

Device Code Flow was built for a good reason: helping users sign in on devices that cannot easily show a browser or accept a password. Smart TVs, consoles, kiosks, command-line tools, and headless systems all benefit from that design.

But the same design that makes it convenient also creates a serious enterprise risk. Attackers can initiate the flow themselves, send the user a legitimate Microsoft sign-in URL and code, and receive valid tokens once the user completes authentication. No password theft. No fake login page. MFA may still succeed. From the identity platform’s point of view, the protocol worked exactly as designed.

This post explains how Device Code Flow works, how it is abused in real attacks, why some Azure workflows still depend on it, and how administrators can reduce risk without treating it as a recommended authentication pattern for Azure services and tools.

Allow Device Code Flow only for documented constrained scenarios. Everything else should move to Managed Identity, brokered interactive sign-in, or certificate-based Service Principal authentication.

Let’s start with the version of Device Code Flow most people have already used, even if they did not know its name.

You may have experienced this. At night, you’re in a hotel room after surviving back-to-back meetings, and you just want to relax and watch something mindless on Netflix.

You grab the remote and navigate to the Netflix app on the room’s smart TV.

Now you need to log in.

You stare at the on-screen keyboard. It’s one of those alphabetical grids — not even QWERTY, which would be bad enough — and your password is something like C0llH0rs3@tt3ry&! because you read the right security blogs and you take this stuff seriously. You’re going to be clicking that remote for the next 10 minutes, and almost certainly making at least two typos.

But then the TV does something clever. It shows you a short alphanumeric code — let’s say ABCD-1234 — and tells you: Go to netflix.com/activate on your phone or laptop, type in this code, and you’re done.

So you do. You grab your phone, navigate to the URL, enter the code, authenticate normally (biometrics, password, MFA, whatever your setup requires), and within seconds — without touching that remote again — the TV lights up with your profile.

This is defined in RFC 8628 — the OAuth 2.0 Device Authorization Grant, colloquially known as Device Code Flow.

What’s Actually Happening Under the Hood

Device Code Flow exists to solve a genuinely hard problem: some devices don’t have a practical way to run a full browser-based authentication experience. Smart TVs. Streaming sticks. Gaming consoles. IoT devices. CLI tools. Printers. The kind of hardware that has a network connection and a purpose, but whose input methods were clearly designed by someone who has never had to type an email address using a D-pad.

Here’s the flow:

The TV (the “device”) contacts the authorization server — in this case, the identity provider — and says, “Hey, I’d like to get an access token on behalf of a user, but I can’t do a full browser login. Help me out.”
The authorization server responds with two things: a device code (a long, opaque string used internally) and a user code (that short, human-readable ABCD-1234 you saw on screen). It also provides a verification URI — the URL you go to on your other device.
The TV starts polling. It repeatedly asks the authorization server, “Has the user authenticated yet? What about now? Now?” — at a defined interval, patiently waiting.
You, on your trusted device, navigate to the verification URI, enter the user code, and complete a full, normal authentication flow — browser, password, MFA, the works.
The authorization server connects the dots. It sees that the user code has been satisfied by an authenticated session, and the next time the TV polls, it gets back a shiny access token.
The TV is now logged in. You watch your show. Everyone is happy.

The authentication burden is shifted entirely to a device that can handle it — your phone, your laptop, something with a proper browser and a keyboard. The TV never sees your password. The TV never needs to. It just waits, politely, for the authorization server to say “yes, that user is who they say they are, and they consented to this.”

Device Code Flow solves a real usability problem. It lets a constrained device complete sign-in through a second device that has a proper browser and keyboard.

And it is being weaponized against your users right now.

But What Happens When You’re the TV?

Here’s where I need you to shift your mental model — because this is the pivot that makes Device Code Flow so dangerously exploitable.

In the legitimate hotel TV scenario, you initiated the flow. You sat down in front of the TV. You opened Netflix. You decided you wanted to authenticate. The device code appeared because you asked for it, and the verification URI was presented in context, on a screen in a room you were physically occupying.

Now imagine this instead:

You receive a Teams message, or an email, or a LinkedIn DM from someone claiming to be from IT, or a vendor, or a colleague. They say they need you to help verify something, or access a shared resource, or complete an onboarding step. They send you a URL and a code. They ask you to go to — and here’s the thing — a completely legitimate Microsoft URL, enter the code, and sign in.

The URL is real. The sign-in page is real. Your MFA prompt fires and you approve it, because you’re authenticating to a genuine Microsoft identity endpoint. Everything looks exactly like a normal authentication flow.

Except you didn’t initiate it. An attacker did.

The attacker has the same role as the TV in the legitimate scenario: it starts the device authorization request and waits for the authorization server to return tokens. When the victim completes the sign-in, those tokens go to the attacker-controlled session.

No malware. No credential theft. No password phishing. Your MFA fired and you approved it. From the identity provider’s perspective, everything went exactly according to spec.

You just authenticated someone else’s session. You were the TV.

Welcome to Device Code Phishing.

The Attackers Who Love Your TV (How Device Code Flow Was Weaponized)

Remember that elegant, user-friendly device code flow we just finished praising? Turns out, the same properties that make it perfect for your Xbox also make it a gift-wrapped attack vector for threat actors. The absence of a browser on the authenticating device. The deliberate separation of code generation from authentication. The real Microsoft sign-in page that victims visit. Every single one of these “features” is a weapon in the right — or rather, wrong — hands.

Let’s walk through exactly how this works, because the mechanics are genuinely diabolical in their simplicity.

The Anatomy of a Device Code Phish

Step one: The attacker initiates a device code flow. Not on some sketchy custom app — on a legitimate, trusted client application like Azure CLI, Microsoft Graph PowerShell, or even the Microsoft Teams client. They call the device authorization endpoint and receive back two things: a device_code (which stays server-side) and an user_code — that friendly eight-character alphanumeric string like FPQR7WXT.

Step two: The attacker packages that user code into a phishing lure. An email. A Teams message. A LinkedIn DM. The lure is engineered to look like a legitimate IT notification, an MFA re-enrollment prompt, a SharePoint access request — anything that provides plausible context for why the recipient should navigate to microsoft.com/devicelogin and type in a code.

Step three: The victim visits microsoft.com/devicelogin. This is the actual, legitimate Microsoft authentication endpoint. The victim enters the code, authenticates with their credentials, satisfies MFA, clicks Approve, and goes about their day feeling completely fine about what just happened.

Step four: The attacker’s polling loop — which has been calling the token endpoint at the interval returned by the authorization server since step one — suddenly gets a 200 OK response. It receives a fully formed OAuth access token and may also receive a refresh token, depending on the client, scopes, tenant policy, and session controls. The attacker now has authenticated access to whatever Microsoft 365 services that token covers. No credentials were stolen. The user-facing authentication step may appear to originate from the victim’s normal device and location, while later token use may show different infrastructure depending on how the attacker operates.

Microsoft Entra guidance treats Device Code Flow as a high-risk flow that should be blocked unless users have a documented need to sign in to shared or input-constrained devices.

Storm-2372: When Nation-States Discovered the Phish

This isn’t theoretical. A threat actor tracked as Storm-2372 operationalized device code phishing at scale against high-value targets.

The Storm-2372 campaign followed the playbook described above — crafting contextually relevant lures delivered via email and messaging platforms, directing targets to the legitimate Microsoft device code authentication page, and harvesting the resulting tokens. Once armed with valid access tokens, and in some cases refresh tokens, the actors conducted reconnaissance across Microsoft 365 environments, accessed email, Teams conversations, SharePoint documents, and pivoted laterally through organizational infrastructure. Refresh tokens are particularly valuable when issued because they can be used to obtain new access tokens, subject to token lifetime, tenant policy, Conditional Access, Continuous Access Evaluation, revocation, sign-in risk, and downstream access patterns.

AI in the Loop: Dynamic Code Generation and the 15-Minute Problem

Device code flow has a natural defense built in: the user code expires after fifteen minutes. For manual phishing operations, this creates operational pressure — the attacker needs the victim to act quickly. The campaign solved this problem elegantly and unsettlingly.

Using automation and AI-assisted tooling, the campaign deployed phishing pages capable of dynamic code generation. Rather than embedding a static user code in the phishing lure, the infrastructure generated fresh device codes on demand as victims interacted with the page. A victim who hesitated, navigated away, or took longer than expected to authenticate would receive a freshly generated, fully valid code — the fifteen-minute clock reset transparently in the background. The victim experienced a seamless interaction. The attacker maintained a continuously valid polling session.

The campaign also employed role-aligned phishing lures — AI-generated pretexts tailored to the apparent role or organization of the target. An IT administrator received a message consistent with a service health alert. A finance employee received something that looked like an approval workflow notification. This contextual alignment dramatically increased conversion rates and reduced the likelihood of targets pausing to question the request.

The result was compromise of organizational accounts at scale, with the automation layer removing the human operational bottleneck that had previously limited the throughput of device code phishing campaigns.

Device Code Flow is not a new problem, but the risk has changed. Automation now makes these attacks easier to run at scale, and Conditional Access policies that ignore the flow leave a clean path for token theft.

The Azure Reality: Security Guidance and Operational Constraints

The Microsoft Entra guidance is clear: organizations should get as close as possible to a unilateral block on Device Code Flow, allowing it only in well-documented and secured use cases. In practical terms, Microsoft does not recommend Device Code Flow as the standard authentication pattern for Azure services, administration, automation, or onboarding workflows.

The nuance is that some Azure tools still expose or require Device Code Flow in constrained situations: Server Core, Linux terminals, headless appliances, remote shells, and migration or onboarding workflows where a local browser is not available. That is a compatibility reality, not a security recommendation. The presence of a Device Code Flow path in a tool should be read as an exception mechanism, not as guidance to prefer it over Managed Identity, brokered interactive sign-in, or certificate-based Service Principal authentication.

This is the Azure reality. Security guidance pushes administrators to block or tightly restrict Device Code Flow; some product workflows still need it in edge cases. The operational answer is not to normalize Device Code Flow across Azure, but to document the few cases that truly require it and move everything else to stronger identity primitives.

Azure Arc-Enabled Servers: DCF in Constrained Onboarding Scenarios

Let’s start with azcmagent connect, the command you run to onboard a server to Azure Arc-enabled servers. This is a core hybrid infrastructure workflow — the kind of thing organizations run at scale across hundreds or thousands of servers.

The official CLI reference documentation notes that Device Code Flow is the authentication method for azcmagent connect on Windows Server Core editions and on Linux distributions.

The reasoning is understandable: Server Core has no browser. Linux servers in an automated pipeline may have no interactive session at all. The arc agent needs some way to authenticate a human operator (or a service) during the initial onboarding handshake, and Device Code Flow conveniently sidesteps the need for a graphical environment. But “understandable” and “consistent with your Conditional Access policy” are two very different things.

When a Conditional Access policy blocks the Device Code Flow grant type — which aligns with the recommended security posture for most tenants — infrastructure teams may see onboarding failures for Linux servers or Windows Server Core nodes unless they have planned an alternate authentication path. This creates a real operational tension between strong tenant-level controls and some constrained onboarding workflows.

Azure Migrate: Known Registration Constraints

Azure Migrate’s standard appliance-registration experience still depends on Device Code Flow. The appliance Configuration Manager requires an operator to copy a device code, open a browser-based Azure sign-in prompt, and authenticate with an Azure user account. As a result, a Conditional Access policy that blocks Device Code Flow for the registering user and relevant resources prevents the default registration path.

Azure Migrate documentation identifies Device Code Flow restrictions as a common sign-in challenge and states that disabling DCF can block appliance registration. This is notable because our Entra guidance also recommends blocking Device Code Flow wherever possible, except for well-documented and secured use cases.

The alternative is not simply a Conditional Access exclusion or an additional user permission. It is a separate, certificate-based authentication model: an organization preconfigures a Microsoft Entra application and service principal, grants that principal Contributor access to the Azure Migrate project’s resource group, installs a certificate on the appliance, and completes registration using the application identity rather than an interactive user sign-in.

This removes the user-context Device Code Flow dependency, but it does not remove the appliance-registration process itself. It also introduces operational overhead: the application is effectively dedicated to one appliance, its certificate must be protected and rotated, and the approach does not apply to the Azure Site Recovery replication appliance.

Azure CLI and PowerShell: When DCF Appears as a Fallback

The Azure CLI and Azure PowerShell modules are more nuanced cases because they support multiple authentication paths. Both tools prefer modern, platform-integrated authentication flows — browser-based interactive login, Integrated Windows Authentication, managed identity — when those options are available. The operative phrase is “when those options are available.”

In headless environments, restricted execution contexts, containerized build agents with no browser dependency, or remote SSH sessions on machines that are not domain-joined, the preferred authentication hierarchy can become harder to use. In those cases, Device Code Flow may appear as a fallback when stronger approaches are not available or have not yet been implemented.

For individual developers this may be a minor inconvenience. For enterprise teams running automated pipelines in tightly controlled environments, it can become a recurring source of breakage that traces back to the gap between DCF-blocking Conditional Access policies and workflows that still rely on DCF as an exception path.

The Real-World Fallout: Exception Requests and Operational Friction

Security-mature enterprises that implement tenant-level blocks on Device Code Flow can discover this tension through production failures. An infrastructure engineer attempts to onboard a batch of Azure Arc servers. The azcmagent connect command fails. A ticket is raised. The security team investigates. The root cause is identified: DCF is blocked, as intended, by policy.

Now the organization has a decision to make: create a tightly scoped policy exception for the onboarding workflow, pre-provision service principal credentials and reconfigure the process, or pause the rollout while the right risk decision is made. None of those options is free. Each has security, operational, and ownership implications.

This is where guidance, product behavior, and customer operations need clearer alignment. Until that alignment is complete, customers need a practical operating model: block DCF by default, document the constrained cases, and move repeatable workflows to stronger identity primitives wherever possible.

The Clean Path Forward — A Five-Tier Authentication Hierarchy

The Azure authentication model has a clear order of preference: use platform-managed identity where possible, use certificate-based service principals where you need external automation, and reserve Device Code Flow for cases where no stronger option is available.

Here’s a five-tier decision framework for authenticating to Azure — ordered from preferred and durable to “only if you absolutely must.” This is also the practical interpretation of the guidance: Device Code Flow may exist in the toolbox, but it should sit at the bottom of the toolbox, not on the workbench.

Tier 1: Managed Identity — The Gold Standard

If your workload runs inside Azure — a virtual machine, an App Service, a Function App, an AKS workload using Microsoft Entra Workload ID, or an Azure Arc-enabled server — use the platform identity model wherever possible. There is no serious debate here.

Managed Identity works by giving the Azure platform itself the responsibility of credential issuance and rotation. The workload requests a token from the Instance Metadata Service (IMDS) endpoint (http://169.254.169.254/metadata/identity/oauth2/token), and Azure handles everything behind the scenes: certificate lifecycle, token signing, rotation. You never see a secret. You never store a secret. There is no secret to leak, rotate, audit, or accidentally commit to a GitHub repository.

System-assigned Managed Identities are scoped to the lifecycle of the resource itself — they live and die with the VM or service. User-assigned Managed Identities give you reuse across multiple resources and more fine-grained RBAC control. For Azure Arc-connected machines, the Arc agent provisions a Managed Identity backed by a locally managed certificate in a protected directory, giving even on-premises and multi-cloud workloads access to this same zero-secret model.

The operational rule: if your code or process runs on a platform that supports Managed Identity, using anything else is a conscious downgrade that requires justification.

Tier 2: Service Principal with Certificate — The Right Tool for Scale

ManagedIdentity isn’t available for every scenario. If you’re building a CI/CD pipeline in GitHub Actions, running an onboarding script from an on-premises orchestration platform, or automating Azure Arc server registration at scale across thousands of machines, you need a Service Principal — and you should be using certificate-based authentication.

Here’s why certificates are usually stronger than secrets in the Service Principal world: certificates are easier to govern through a managed issuance and rotation process, and they avoid long-lived shared strings being copied across scripts, repositories, and build systems. Microsoft Entra Conditional Access for workload identities can also apply to selected service principals, subject to licensing and feature scope, with controls such as location-based restrictions and risk-based blocking. That is not the same policy surface as user Conditional Access, and managed identities are not covered by those workload identity policies.

For Azure Arc onboarding specifically, scope your Service Principal to the minimum viable role: Azure Connected Machine Onboarding. This built-in role grants exactly what the azcmagent connect process needs — nothing more. It cannot read your Key Vault secrets, enumerate your subscriptions, or touch your production workloads. Least privilege isn’t just a best practice checkbox here; it’s your blast radius control.

Certificates should be issued from a managed PKI, stored in protected certificate stores (never in flat files on shared drives), and rotated on a defined schedule. Integrate certificate lifecycle management with your existing PKI or use Azure Key Vault-backed certificates where possible.

Tier 3: Service Principal with Secret — The Acceptable Compromise

Sometimes certificates are genuinely impractical. Legacy tooling, third-party integrations, or constrained environments may force your hand toward client secrets. This tier isn’t forbidden — but it carries an explicit operational contract.

Client secrets must be treated with the same discipline as passwords: stored in secrets management systems (Azure Key Vault, HashiCorp Vault, your CI/CD platform’s native secrets store), never hard-coded, never logged, and rotated on a defined cadence. Microsoft Entra ID lets you set expiration periods — use them. Ninety-day rotation is a reasonable baseline; shorter is better for high-sensitivity workloads.

Client secrets remain bearer credentials. If a secret is copied, an attacker can use it until it expires or is revoked, subject to workload identity controls and any other enforcement points in the environment.

Tier 4: Interactive Browser / Brokered Authentication — For Human Admins

When a human being is sitting at a keyboard performing administrative tasks — deploying resources, running az CLI commands, executing PowerShell modules against Azure Resource Manager — the right authentication pattern is interactive browser or brokered authentication.

The Azure CLI (az login), Azure PowerShell (Connect-AzAccount), and the Azure Portal all support this flow. On modern Windows workstations with the Web Account Manager (WAM) broker enabled, authentication is handled through the broker, which integrates directly with Windows Hello, device compliance state, and Primary Refresh Token (PRT) infrastructure. This means your Conditional Access policies — require compliant device, require MFA, require specific named locations — all apply and are enforced at login time.

This is authentication that knows who the user is, what device they’re on, and whether that device meets your security baseline. It’s the complete picture. Never suppress this flow with automation flags when a human is the actor.

Tier 5: Device Code Flow — The Last Resort

Device code flow (az login --use-device-code, Connect-AzAccount -UseDeviceAuthentication) should be treated as the last resort for Azure services and tools. It exists for a specific, narrow set of scenarios: headless Linux terminals, Windows Server Core deployments without a GUI, SSH sessions into remote systems where a browser genuinely cannot be launched, or constrained appliance and migration workflows where the product has no stronger supported option yet.

In these cases, the operator signs in on a separate device and the initiating workload receives the token after authorization completes. That separation creates a control gap: Conditional Access evaluates the sign-in context of the device used for authentication, not necessarily the posture of the headless server, appliance, or remote shell that initiated the request.

If you permit device code flow in your environment, do it deliberately: create a scoped Conditional Access exception, document the justification, and treat each use as a compliance event worth auditing. And ask yourself seriously whether Managed Identity or a Service Principal could solve the problem instead.

Put plainly: if a workflow can use Managed Identity, brokered interactive authentication, or a certificate-based Service Principal, that is the route Microsoft customers should prefer. Device Code Flow is the exception path for constrained environments, not the recommended operating model for Azure.

Quick Decision Table

When in doubt, consult this table before typing a single auth flag:

Scenario	Recommended Pattern	Avoid
Azure VM / App Service	System-assigned or user-assigned Managed Identity	Service Principal with secret; Device Code Flow
Azure Arc server process	Managed Identity via the Azure Arc agent identity model	Interactive login; hardcoded credentials
Azure Arc onboarding at scale	Service Principal with certificate and the `Azure Connected Machine Onboarding` role	Service Principal with secret; Global Administrator credentials
Azure Migrate registration	Preconfigured Microsoft Entra application with certificate-based authentication	Device Code Flow as the default path; over-privileged roles
Human admin task	Interactive browser or WAM brokered authentication with Conditional Access	Shared service accounts; suppressed MFA
Linux / Server Core / headless CLI	Managed Identity where available, or Device Code Flow with a scoped Conditional Access exception	Persistent CLI sessions with cached tokens and no expiry

The hierarchy is deliberate. Every tier down represents a trade-off — more operational burden, less platform-enforced security, more human discipline required to compensate. The goal is to push as many of your workloads as possible to Tier 1, use Tier 2 for what Managed Identity can’t reach, and treat everything below that as a documented exception rather than a default pattern.

Authentication choices are architectural decisions. Make them intentionally.

Hardening Your Tenant — What Administrators Must Do Today (And Why Your Cloud Is Not a Hotel TV)

The hardening work starts with visibility. Before blocking or allowing Device Code Flow, administrators need to know where it is already being used, which workflows depend on it, and which of those workflows can move to stronger authentication.

Action 1: Inventory Current Usage — Find Where DCF Is Active Right Now

You cannot harden what you cannot see. Start in Entra ID Sign-In Logs and filter for authentication protocol equals deviceCode. This will surface every user, application, and IP address currently relying on Device Code Flow across your tenant. Pay close attention to service accounts, unattended scripts, and any sign-ins originating from datacenter IP ranges — those are your highest-risk signals.

If you haven’t already, flip your Conditional Access policies targeting DCF clients into report-only mode first. This gives you a real-world blast radius assessment before you enforce a block. Surprises in production are exciting exactly once.

Action 2: Classify Every Use Case — Automation or Genuine Terminal Fallback?

Not every Device Code Flow invocation is malicious, or even wrong. Walk through what you find in the logs and ask one honest question for each entry: Is this a human logging into a device with no keyboard, or is this a script pretending it has no other option?

Genuine headless terminal scenarios — a shared kiosk, a network appliance with a PIN pad, a restricted industrial device — are legitimate. Everything else, especially recurring automated sign-ins from servers or pipelines, is a Service Principal waiting to be born.

Action 3: Replace Repeatable Workflows With the Right Identity Primitive

This is the most impactful action on the list. Every server onboarding script, appliance registration routine, and CI/CD pipeline that currently uses Device Code Flow should be migrated to one of two things:

Managed Identities — for anything running inside Azure. Zero credentials. No rotation. No excuses.
Certificate-based Service Principals — for workloads running outside Azure where Managed Identity isn’t available. Certificates are auditable, rotatable, and are not susceptible to this specific device-code phishing pattern.

If a team finds that migration difficult, treat it as an implementation gap to close, not as a reason to keep a weaker authentication pattern in place.

Action 4: Scoped Exceptions Only — No Tenant-Wide Free Passes

If you must allow Device Code Flow for a specific use case after completing Actions 1 through 3, then scope it surgically. Target specific named users, restrict to compliant or named network locations, and limit to the exact application that requires it. Attach strict sign-in monitoring alerts so that any deviation from the expected pattern pages someone immediately.

Granting tenant-wide exceptions because one team has a legacy appliance is the organizational equivalent of leaving the front door of your office building unlocked because the mailroom needs early access. Scope it. Monitor it. Review it quarterly.

Action 5: Improve Error Clarity — Make Failures Actionable

When Device Code Flow is blocked by a Conditional Access policy, the error experience can be difficult for operators to act on. If the message is opaque, teams either open a ticket without enough context or look for a workaround. Neither outcome helps the customer.

Internal scripts and tooling should catch Conditional Access block errors and surface clear, prescriptive guidance. Suggested runtime error wording:

“Device Code Flow authentication was blocked by your organization’s security policy. This workflow requires an identity with delegated permissions in an interactive session. For automated workloads, use a Managed Identity or a Service Principal with certificate-based authentication. Contact your identity platform team for migration assistance.”

For product and documentation improvements, language like the following would help customers make safer choices:

“Device Code Flow (RFC 8628) is designed for input-constrained devices such as smart TVs and kiosks. It is not recommended for automated scripts, CI/CD pipelines, or server-side processes. For unattended authentication scenarios, use Managed Identities for Azure-hosted workloads or certificate-based Service Principals for external workloads. Enabling Device Code Flow in enterprise environments without Conditional Access restrictions significantly increases phishing risk.”

Clear documentation prevents the next engineer from making the same mistake and helps customers choose the right authentication pattern earlier.

The Hotel TV — A Final Word

Let’s go back to where we started: you, in a hotel room, staring at a television that doesn’t have a keyboard, trying to log into Netflix. You pull out your phone, navigate to a short URL, type an eight-character code, and thirty seconds later you’re watching something you’ll regret staying up for. It is, genuinely, a delightful piece of user experience engineering. RFC 8628 solved a real problem elegantly, and for that use case — a constrained device, a human present in the room, a low-stakes personal account — Device Code Flow is perfectly appropriate.

The problem is not Device Code Flow. The problem is transplanting a mechanism designed for hotel televisions into environments where a compromised token can exfiltrate production databases, pivot across subscriptions, and trigger regulatory breach notifications at three in the morning.

Your enterprise Azure tenant is not a hotel TV. The stakes are not whether someone watches an extra episode before sleep. The stakes are your customers’ data, your company’s reputation, and in regulated industries, your legal exposure. Authentication mechanisms must be matched to the environment they protect — and an environment with that much at risk deserves better than a flow designed for leisure viewing.

Block Device Code Flow by default. Do not recommend it as the normal way to use Azure services or tools. Migrate automation to proper identity primitives. Grant exceptions only where the use case genuinely demands it, and monitor them relentlessly. The elegance of the original protocol is not a reason to leave the door open. It is simply a reason to appreciate it on the television where it belongs — while you protect everything else with something far more serious.

Understanding Microsoft 365 Copilot Risk Surface and Mitigations

AtilGurcan — Thu, 23 Jul 2026 15:37:20 GMT

It’s a shift that carries important security implications organizations should understand before scaling deployment. Customers with Microsoft 365 E5 licensing may already have access to many of the tools that can help identify and reduce Copilot-related risk, but licensing alone does not reduce exposure.

What’s often missing during early Copilot deployments is a clear understanding of the risk surface itself: what data is exposed, who can access it, and through which vectors.

Organizations beginning their Zero Trust journey can use the Zero Trust Workshop to assess their current posture, identify gaps, and better understand how existing permissions and governance impact Copilot readiness.

In this post, we take a broader look at the types of risks Copilot can amplify and how those risks align to key Zero Trust pillars.

Why Copilot changes the risk conversation

Before assessing specific risks, it's worth understanding why AI solutions like Copilot introduce a different risk conversation than traditional Microsoft 365 applications.

Most enterprise applications operate within a bounded context. A user opens a file, reads an email, or searches a SharePoint one item at a time. The time and effort required to manually locate, connect, and synthesize information across systems creates a natural friction layer.

While that friction was never designed as a formal security control, it did create a practical limit on how quickly users could surface and act on organizational data at scale.

Microsoft 365 Copilot removes much of that friction entirely. It operates at the speed of a prompt across the full scope of a user's access rights, synthesizing information from emails, files, meetings, chats, and other Microsoft 365 data sources into a single response.

The exposure is not the result of new permissions; it comes from how quickly and easily existing access can be discovered and aggregated. In short, Copilot makes data once hidden by volume discoverable by intent.

Use Zero Trust to assess Copilot risk

Zero Trust rests on three principles: verify explicitly, use least-privileged access, and assume breach. Rather than trusting users or devices by network location, it requires continuous validation of every user, endpoint, and request. This analysis focuses on the four pillars most directly involved in Copilot deployments.

Together, these pillars answer three questions: who can access Copilot; from which endpoints and applications; and what data Copilot can surface once access is granted.

The two-layer Copilot risk model

The foundation is simple: Copilot acts as a force multiplier for whatever access a user already has. If that access is governed well, Copilot improves productivity; if not, it amplifies exposure. Risk is therefore examined in two layers — access to the Copilot service itself, and access to the data Copilot can ground on and surface.

MICROSOFT 365 COPILOT · TWO-LAYER RISK MODEL

Layer-1 Access Risk
Identity	Device
Who can access copilot	From which devices
Under what conditions	Device compliance posture
Layer-2 Data & Governance Risk
Apps	Data
What copilot can access and surface	Sharing and permissions
Connected data sources	Labeling, classification, output context

Table-1: Two-layer model for Microsoft 365 Copilot risk

Risk Layer-1: Who can access Microsoft 365 Copilot?

The first layer of risk begins at the point of entry: the conditions that determine whether a user can access Copilot. Organizations don’t need to address every potential exposure point at once. Think of the following table as a map of where exposure can exist across identity and device controls. For details of how remediation works for this layer of risks; you may refer to the blog post: Mitigating Microsoft 365 Copilot access risk: Identity and device controls for Zero Trust.

The following risks are primarily governed by the Identity and Devices pillars of Zero Trust and define whether Copilot is being accessed by the right person, from a trusted device, under appropriate authentication and access conditions.

	Risk	Pillar	Description
R1	Unmanaged identity access	Identity	A compromised, shared, or former employee account can authenticate to Microsoft 365 and access Copilot. Because Copilot operates across the full scope of a user’s permissions, compromised accounts expose a much larger risk surface than before Copilot existed. Strong account hygiene and identity lifecycle management therefore directly reduce Copilot exposure.
R2	Weak or absent multi-factor authentication	Identity	If organizations do not enforce MFA, or if legacy authentication bypasses modern sign-in controls, users can start Copilot sessions using only a password. In environments with inconsistent MFA coverage, attackers may need only stolen credentials to gain access. Because Copilot synthesizes data across services, compromised accounts create significantly greater risk than access to a single application.
R3	Unmanaged or non-compliant devices	Devices	Users can access Copilot through browsers and native applications from any device where they can authenticate. Unmanaged devices without EDR coverage, disk encryption enforcement, or compliance posture evaluation can expose Copilot sessions and allow attackers or unauthorized users to store or exfiltrate outputs locally.
R4	License sprawl without role-based scoping	Identity & Apps	Enterprise Copilot pilots often start with broad license assignments across departments, floors, or business units instead of deliberate, security-reviewed pilot groups. When organizations assign licenses without reviewing each user’s access rights, permission posture, and role sensitivity, Copilot can amplify risk across both highly governed and minimally governed users. Broad pilot enrollment without access review is itself a risk factor.
R5	Missing real-time risk evaluation at sign-in	Identity & Devices	If Conditional Access does not evaluate sign-in and user risk signals—such as impossible travel, anomalous token activity, or identity protection alerts—high-risk sessions may still gain access to Copilot. Without real-time risk gating, controls respond only after access is granted, by which point Copilot may already have surfaced and synthesized sensitive content.
R6	App protection gap on mobile devices	Devices & Apps	Users can access Microsoft 365 Copilot mobile—and the broader Microsoft 365 mobile surface that exposes Copilot—from personal devices that are not enrolled in MDM or MAM. Without an application protection policy, organizations cannot prevent users from copying Copilot outputs into unmanaged apps, remotely wipe organizational data from lost devices, or restrict screenshots and screen recordings during Copilot sessions containing sensitive data.

Table - 2: Risks in Layer-1: Who can access Microsoft 365 Copilot

Key observations from Layer 1:

Identity appears most frequently across Layer 1 risks, reflecting how tightly Copilot access depends on authenticated user permissions and sign-in conditions. Device-related risks also play a major role because unmanaged or non-compliant endpoints can expose Copilot sessions and outputs beyond the organization’s trusted environment.

Together, these risks highlight a central theme: securing Copilot access is not just about controlling who can sign in, but also validating the devices, conditions, and access patterns associated with every session.

Risk layer 2: What data can Microsoft 365 Copilot reach?

The second layer of risk assumes that the user is already authenticated and actively using Copilot.

At this stage, the focus shifts from who can access Copilot to what data Copilot can surface on the user’s behalf.

These risks reflect the full scope of data exposure created by existing permissions, overshared content, connected systems, and governance gaps. Layer 2 risks are governed primarily by the Apps and Data pillar, with Identity playing a secondary role in defining the scope of data each user can access.

For mitigating risks in this layer, you may refer to the blog post: Limiting Microsoft 365 Copilot data exposure risk with Zero Trust apps and data controls.

	Risk	Pillar	Description
R7	Overshared SharePoint and OneDrive content	Apps & Identity	Content shared with "Everyone," "Everyone except external users," or broad groups becomes part of Copilot’s query able surface for any licensed user, even if that user would never have found those files manually. Years of SharePoint oversharing, combined with Copilot’s ability to traverse and synthesize content in a single prompt, can turn long-standing governance debt into immediate exposure. Copilot makes data once hidden by volume, discoverable by intent.
R8	Sensitivity label gaps	Apps & Data	Microsoft Purview sensitivity labels tell Copilot how to handle content, including whether it can summarize, cite, or include that content in responses. Leaving content unlabeled, mislabeling, or miss inheriting labels across containers such as SharePoint sites and Teams, Copilot treats the content as unclassified and may surface it freely. Many enterprise tenants still contain large volumes of unlabeled legacy content, and Copilot cannot infer classification on its own.
R9	Excessive user permissions	Identity & Apps	Like overshared content, Copilot follows each user’s existing Microsoft Graph permissions and does not surface content users cannot access. In many enterprise environments, however, users accumulate access far beyond their current role through leftover project permissions, broad temporary group memberships, and inherited rights from outdated organizational structures. Copilot does not create this overprovisioning, but it makes the full scope of that access immediately visible and usable.
R10	No DLP coverage on Copilot-generated outputs	Apps & Data	Copilot outputs—including summaries, drafts, and synthesized answers—are generated content, and traditional DLP policies do not always preserve links to original source data. Users may receive Copilot responses containing aggregated PII, financial data, or confidential project details and paste that information into emails, Teams messages, or external documents without triggering DLP policies designed to detect the original source files. As content shifts from source material to generated output, organizations often lose the underlying sensitivity context.
R11	Plugin and connector data surface expansion	Apps & Identity	Organizations can extend Microsoft 365 Copilot through plugins and Microsoft Graph connectors that pull external data from CRM systems, ITSM platforms, HR applications, and custom line-of-business tools. Each connector expands the data surface Copilot can query on a user’s behalf and often reaches into systems whose access control models do not align natively with Microsoft 365 permissions. As organizations add connectors, each connected source introduces governance and audit risk that expands alongside the broader Copilot data surface.
R12	Audit and visibility gap	Apps & Data	Organizations need visibility into what users asked Copilot, what data Copilot accessed, , and what responses it generated to maintain an effective security posture for both incident response and risk monitoring. Disabling Copilot interaction logging, retaining audit logs for too short a period, or failing to forward logs to a SIEM, obscures the organization’s visibility into how users interact with Copilot, whether Copilot surfaces unexpected content, and whether activity may indicate compromise. Without audit data, organizations cannot reliably detect misuse or investigate incidents.
R13	Privileged user data amplification	Identity, Apps & Data	Administrators, senior IT staff, and other privileged users often hold access that spans organizational boundaries, including mailboxes, site collections, security groups, and configuration data that most users never access. A compromised admin account with Copilot access gives adversaries an organization-wide view of data that far exceeds the exposure associated with a compromised end-user account. Organizations therefore need to apply the strictest Copilot access governance to privileged identities.

Table – 3: Layer-2 Risks: What data can Microsoft 365 Copilot reach?

Key observations from Layer 2:

Apps-related risks appear throughout Layer 2 because Microsoft 365 Copilot depends heavily on connected systems, accessible data sources, and governance over generated outputs. The Data pillar further emphasizes the need to protect not only sensitive source content but also AI-generated responses that aggregate and surface information across systems.

The table above maps each identified risk to its primary and secondary Zero Trust pillars. Primary pillars represent control areas that most directly govern a given risk, while secondary pillars represent contributing dimensions.

Conclusion & next steps

Copilot typically does not grant broader access than a user already has — it makes existing access easier to discover, connect, and use across Microsoft 365. Organizations that successfully scale Copilot are the ones that understand and govern that access first.

Reducing Copilot data exposure is not a one-time cleanup; it is a continuous governance posture. Oversharing accumulates, labels drift, permissions grow, and connectors are added. Together, the Layer 1 and Layer 2 controls in this guide create the feedback loops that keep the risk surface governed as the organization and its use of Copilot evolve — governing not only who can access the service, but what it can reach on their behalf.

WHERE TO GO NEXT

Assess your current posture: Zero Trust Workshop — http://zerotrust.microsoft.com
Understand the framework: Zero Trust Overview on Microsoft Learn (http://learn.microsoft.com/security/zero-trust)

Should You Use the New Microsoft Entra Tenant Governance or Azure Lighthouse? (part 3 of 3)

Preston_Romney — Thu, 23 Jul 2026 12:00:00 GMT

In Part 1 we built Azure Lighthouse the technical way. In Part 2, "Bring Your Partner In, Without Letting Their Identities In," we made the security case for it: let a service provider operate a customer's Azure resources without creating any identity in the customer's tenant.

This third part introduces another, newly available delegation model Microsoft Entra Tenant Governance and helps you to answer the question: which one do I use, and when?. If you already know Lighthouse, you have everything you need to follow along - If not, catch up on the previous two articles. While most of the focus will be on Microsoft Entra Tenant Governance, we will compare and contrast it with Azure Lighthouse.

There's one idea that makes the whole comparison click: the two models project access in opposite directions.

1. Azure Lighthouse, and its boundary

As a brief refresher, Azure Lighthouse lets a service provider manage a customer's Azure resources (subscriptions and resource groups) from the provider's own tenant. The provider's users never get an account in the customer's directory and never become guests there; instead, the customer's subscriptions and resource groups are delegated to the provider through Azure Resource Manager, and the provider operates them with their home credentials (Azure Lighthouse architecture). No identity sprawl, no extra license, no charge (Azure Lighthouse overview).

Lighthouse is scoped to the Azure Resource Manager control plane. It delegates resources from subscriptions or resource groups such as virtual machines, storage, networking, policy, and Sentinel workspaces. It does not grant Microsoft Entra directory roles, it does not reach resource data planes such as Storage blob data or Key Vault secrets, and it doesn't reach Microsoft 365 (cross-tenant management experience).

But it leaves a real question open. What happens when the partner (or an enterprise with multiple tenants) legitimately needs access to the directory, to read identity configuration, run security operations, administer users, or govern identities, and not just the resource estate? Lighthouse, by design, can't take you there. That's the gap the second model fills.

2. Two directions of projection

The easiest way to keep the two models straight is to consider the following:

Fig 1 - Access delegation direction of trust

Azure Lighthouse projects the customer's resources up into the provider's tenant. The provider manages those resources from its own context. The customer's subscription is, in effect, presented inside the provider's Azure portal.
Microsoft Entra Tenant Governance projects the provider's identity down into the customer's tenant. A principal from the provider tenant becomes usable inside the customer, and a provider user or service principal uses it there to do the work.

Each delegate cross-tenant access without local accounts, but the thing that moves is opposite. And who moves strongly shapes whose rules apply. When the customer's resources come up to the provider, the work happens in the provider's context. When the provider's identity goes down to the customer, the work happens in the customer's context.

Think of the word "projection" as a way to reason about trust direction, not a literal claim that objects are copied between tenants. Lighthouse is delegated management from the provider's context; Tenant Governance creates a governed principal in the customer's context that can hold directory roles and Azure RBAC.

3. What is Microsoft Entra Tenant Governance?

Microsoft Entra Tenant Governance is the capability that lets one tenant securely administer another. The connection between a specific pair of tenants is called a governance relationship: a directional link in which one tenant, the governing tenant (the provider), administers another, the governed tenant (the customer) (set up a governance relationship).

Throughout, this article is written from the provider's vantage point: when it says you, it means the provider (governing) side, and the other tenant is always referred to explicitly as the customer. The topics discussed here apply equally to Enterprises needing to manage many of their own tenants as well as Service Providers who manage many customer tenants.

You set it up in two steps:

A policy template in the provider tenant that declares which principal will be projected and which Entra roles it should receive. Note that RBAC assignments are not part of the governance relationship and must be completed by the customer in their tenant.
A handshake between the two tenants that establishes the trust boundary and provisions the access.

Now let’s dive into the details: what gets projected, and how it gets its powers.

4. What actually gets projected: one proxy principal

In the provider tenant you start with something completely ordinary, a security group (say, your "Cloud Operators" group), or a custom multitenant application. When you form the governance relationship, a proxy of that principal is created in the customer tenant:

A security group is projected in as a remote tenant group.
An application (a custom multitenant app) is projected in as a service principal, when the relationship is established, Tenant Governance automatically creates a service principal with the same permissions in the customer tenant (no manual step on the customer's side): "Tenant Governance creates a service principal with the same permissions in the governed tenant" (governance policy templates).

Using a multitenant app registration with Tenant Governance requires an Entra ID Governance license.

Fig 2 - Provider principal is projected into the customer tenant

It’s important to keep two things straight, neither is a local account or a guest:

The proxy, the remote tenant group (or, for an app, the service principal), is a new principal created in the customer tenant by the relationship. It is not a copy of the provider's group, not a local group created in the customer, and not a guest. It exists only because the relationship projects it, and it is what the provider grants roles to.
The people and apps that use it, the provider's users and service principals, stay in the provider tenant. They never receive a member account or a guest invitation in the customer; they reach the customer through the proxy.

Here is what that provider user or service principal is and isn't, from the customer's point of view:

The provider user or service principal is NOT…	…it IS…
A local member account created in the customer's directory	An identity that stays in the provider tenant and authenticates with provider credentials
A B2B guest invited into the customer	Reachable only through the projected proxy, a signed-in user shows in the customer's logs as the provider tenant's name + Technician (e.g. Contoso Technician)
A standing, permanent object listed among the customer's users	Present only as a governed session or principal, scoped by the relationship and revocable by the customer

To work in the customer tenant, a provider user opens a supported admin portal (Entra or Azure) and appends the customer's tenant ID, for example https://entra.microsoft.com/{customer-tenant-id}, then signs in with their provider-tenant credentials. The customer's logs then show them a directory display name of user_{object-id} (the provider object ID without dashes), and, in sign-in and audit logs, the provider tenant's name followed by Technician, so for a provider tenant named Contoso the entry reads Contoso Technician (use cross-tenant delegated administration). No local account, no guest object, the resource-plane property Lighthouse provides, now on the directory plane (cross-tenant delegated administration).

A note on the two projection mechanics, because they differ in a way worth understanding. A group projects as a remote tenant group, a cross-tenant reference back to the provider's group, with no new local membership stored in the customer. An application projects as a real service principal that is actually created in the customer with the consented permissions. Same idea, a governed proxy of a provider principal, but a group is a reference, while an app is an instantiated object.

5. How the proxy gets its powers: roles attach to the one principal

The proxy is one principal. You don't create separate identities for "directory access" and "resource access." Instead, you grant roles to that single proxy, and the roles can come from two different planes:

Directory roles govern the customer's Microsoft Entra directory. Think of well-known ones such as Global Reader (read-only across the directory), Global Administrator, or User Administrator, selected as built-in roles in the policy template (governance policy templates).
Azure RBAC roles govern the customer's Azure resources. Think of the familiar Reader, Contributor, or a service-specific roles like Virtual Machine Contributor, assigned to the remote tenant group at a subscription or resource-group scope. This is not done as part of the governance relationship as the Entra directory role is. This must be assigned after the relationship is established likely by a privileged customer admin.

The bridge from directory to resources is the remote tenant group itself: because the projected group can be referenced by Azure RBAC, the same proxy that holds Global Reader in the directory can also hold Reader or Contributor on a resource group. Critically, these are not separate identities, they are both roles held by the one remote tenant group, as the diagram above shows. And the directory role grants no Azure access on its own; the resource rights come entirely from the explicit RBAC assignment you choose.

That single design choice, roles branch off one proxy, is what lets one projected principal span both planes: the same remote tenant group can hold a directory role and a separate, explicit Azure RBAC grant, without ever issuing a local account.

What do these identities actually look like in the customer tenant? The only place you will see the security group is in the governance relationship. You will not find it among your other Entra groups.

Fig 3 - Governance relationship shows the projected principal in the customer tenant

Fig 4 - The projected principal does not appear in the customer tenant security groups

For RBAC purposes, you can find the proxy security group under resource Access Control (IAM) as a foreign group.

Fig 5 - The projected principal is available for RBAC assignments as a foreign group

6. The building blocks, and how they depend on each other

Now that the concept is in place, here's the assembly order. Each block depends on the one before it.

Fig 6 - Sequence of creating a governance relationship

A role-assignable security group in the provider tenant, the principal you intend to project.
A policy template that selects which directory roles that group should receive when projected (governance policy templates).
A governance relationship, established by a handshake. In the standard three-step flow the customer invites, the provider requests (carrying the template), and the customer accepts; a streamlined two-step flow (request → accept) applies when the two tenants already share a qualifying signal, such as a billing relationship or an existing governance relationship. At acceptance, the role assignments are provisioned in the customer (set up a governance relationship). The template's role set is projected onto the relationship, so later template edits require a fresh request and re-approval, the customer always gets to review what changes.
The projected proxy plus its role assignments in the customer, the remote tenant group (or service principal), now holding the directory and/or Azure RBAC roles you granted.

Under the hood: this cross-tenant delegation is powered by granular delegated admin privileges (GDAP), the same delegation technology behind Partner Center (cross-tenant delegated administration). You don't configure it directly; the relationship and the template do it for you. That's all you need to know about the plumbing.

The whole flow is also scriptable through the Microsoft Graph Tenant Governance APIs (API overview), and a default template can bring new add-on tenants under governance automatically at creation (deployment guide).

7. Key Features

Because the proxy can hold both directory roles and Azure RBAC, Tenant Governance unlocks delegated administration across the entire surface a partner might legitimately need:

Directory administration, read or manage the customer's Microsoft Entra directory with least-privileged built-in roles, using home credentials, no local accounts.
Identity governance, run access reviews, entitlement management, and lifecycle workflows across many customer tenants from one place.
Security operations, operate security and compliance tooling centrally. Microsoft Defender XDR and Microsoft Sentinel multitenant management for MSSPs is one prominent example built on this model (governance relationships for unified SecOps).
Azure resource management, the remote tenant group can carry Azure RBAC for any Azure service, exactly the way a local group would. That covers the management (control) plane only; neither model delegates the resource data plane (for example, blob data or Key Vault secrets), so those operations still require an identity native to the customer tenant.
Application management, project a custom multitenant app as a service principal with consistent, least-privileged permissions across tenants (governance policy templates).

The provider's users and service principals use their provider-tenant identities, and no local or B2B account is ever planted in the customer. The one object the customer does gain is in the application case, a governed service principal of the projected app, created and maintained through the relationship rather than as a standing local login.

8. Comparing Tenant Governance with Azure Lighthouse

Now that both models are understood, the comparison is straightforward. They operate on different planes and point in different directions.

Dimension	Azure Lighthouse	Microsoft Entra Tenant Governance
Direction of projection	Customer resources → provider	Provider identity → customer
Where the provider identity operates	From the provider tenant (customer resources projected up; no customer sign-in)	In the customer tenant, authenticated by the provider home tenant — as {Provider} Technician
Planes reached	Azure resource (ARM) plane only	*Directory plane and* Azure resource plane**
Data-plane access (e.g., blob data, Key Vault secrets)	Not supported (control/ARM plane only)	Not supported (the proxy can hold a DataActions role, but cannot obtain a data-plane token)
Identity footprint in customer	None	A projected proxy principal, no local or guest object
Conditional Access	Only the provider's policies apply (security practices)	The customer's policies apply, the customer is the resource tenant for the technician's sign-in (lab-verified; see below)
Where the privileged assignment lives	Provider tenant (JIT approvers in the provider) (eligible authorizations)	Customer tenant (the role assignment is owned customer-side)
Audit of provider actions	Customer Activity Log (view activity)	Customer audit log records the provider user’s actions; the authentication sign-in is recorded provider-side, it appears in the customer's sign-in log only when the customer's CA fires
Role types	Azure built-in roles only, no custom roles; Owner and roles with DataActions excluded, and Microsoft.Authorization/* writes excluded except User Access Administrator for managed-identity assignments (role rules)	Directory roles and Azure RBAC (including custom RBAC) on the proxy
Setup	ARM template / Marketplace offer (onboard)	Relationship handshake (invitation → request → acceptance)
Revocation	Remove the delegation, either party (remove)	Terminate the relationship, either party
Operational view	Single pane of glass, every delegated customer's resources surface in the provider's own portal	Per-customer, the admin signs in to each customer tenant individually
Best for	Scaled Azure resource operations	Directory / identity / security delegation plus resources

The sign-in, Conditional Access, footprint, and audit rows describe the human delegated-administration path (a projected group). In the application case the customer instead gets a governed service principal, so those rows read differently.

Direction of projection, the root cause. Everything else in the table is a consequence of this one row. Lighthouse brings the customer's resources up to the provider; Tenant Governance places a governed proxy of the provider's identity down in the customer. Decide which direction your scenario actually needs, and the rest mostly answers itself.
Conditional Access, the cleanest inverse. With Lighthouse, provider users authenticate in their own tenant, so the customer's Conditional Access never reaches them, "Only policies set on the managing tenant apply"(recommended security practices). With Tenant Governance the provider actually signs in to the customer tenant (use cross-tenant delegated administration), which makes the customer the resource tenant that evaluates Conditional Access, so the customer's policies govern the inbound provider login, not the provider's policies.

Two nuances to keep in mind: When the provider logs into the customer tenant, the authentication still happens with the provider’s tenant, but the conditional access policy applied to the login is in the customer tenant.

Where privileged access lives. Lighthouse offers just-in-time elevation through eligible authorizations, and the approvers sit in the provider (managing) tenant, "up to 10 users or user groups in the managing tenant who can approve"(create eligible authorizations). Tenant Governance inverts the ownership: the proxy's role assignment lives in the customer tenant, so privileged-access governance over that assignment is anchored customer-side. The useful contrast is simply where the assignment lives and who governs it, provider-side for Lighthouse, customer-side for Tenant Governance.
Audit and identity footprint. With Lighthouse, provider actions land in the customer's Azure Activity Log under a named user, with no customer sign-in and no directory object (view provider activity). Tenant Governance is more subtle. The provider user's authentication is handled and logged in the provider (home) tenant, so the bare sign-in appears there, not in the customer tenant. What does get logged in the customer directory is the provider user’s actions, in its audit log, where the actor shows as the <provider tenant's name + Technician> (e.g. Contoso Technician) (use cross-tenant delegated administration). A sign-in entry from the provider user only appears in the customer's logs when the customer's Conditional Access evaluates the session, for example, an MFA challenge. Without such a policy, that sign-in is only logged on the provider side. Either way, the customer keeps a full audit of what the technician does and gains no standing local or guest object (cross-tenant delegated administration).

Fig 7 - The providers activities on resources are logged in the customer's subscription activity log as "<provider name> Technician"

Fig 8 - When the provider logs into the customer tenant, their authentication is logged against the provider tenant while Conditional Access is logged against the customer tenant

One console vs. many: Operational reach. Because Lighthouse projects the customer's resources up, the provider works from a single pane of glass, every delegated customer's subscriptions appear in the provider's own Azure portal, and cross-tenant tooling, Azure Resource Graph, Microsoft Sentinel, Azure Policy, Azure Monitor, can span all of them at once. Tenant Governance points the other way: the provider's identity projects down into each customer, so day-to-day administration is per-customer, the admin signs in to each customer tenant in turn. (Service consoles such as Microsoft Defender XDR add their own aggregated multitenant views on top, but the underlying delegated-admin model is per-tenant.) When operating many customers' Azure estates from one console is the priority, that single-pane reach is a distinct Lighthouse strength.

9. Where the two models overlap

As is the case with other delegated access models, there is clear overlap between Azure Lighthouse and Tenant Governance:

Both eliminate local and B2B accounts in the customer. The partner's people stay in the provider tenant either way (Lighthouse architecture, cross-tenant delegated administration).
Both can ultimately place Azure RBAC on customer resources, Lighthouse directly through the delegation, Tenant Governance via the remote tenant group.
Both are limited to the control (management) plane, neither delegates resource data-plane access (for example, blob data or Key Vault secrets); that still requires an identity native to the customer tenant.
Both keep the customer in control of the audit record, provider actions are written to the customer's logs.
Both are revocable by either party, remove the delegation, or terminate the relationship.

10. What is complimentary with the two models?

Because they sit on different planes and point in opposite directions, you can use one or both.

Fig 9 - Azure Lighthouse and Entra Tenant Governance compared

Deciding between the two delegated access models:

Need only to operate the customer's Azure resources, especially across many customers? Choose Azure Lighthouse, no extra license or charge, a broad set of Azure built-in roles (Owner and custom roles excluded), just-in-time elevation with provider-side approval, zero directory footprint, and a single pane of glass: because customer resources project up into the provider's tenant, the provider manages every customer's estate from their own portal, with cross-tenant tooling spanning all of them at once.
Need directory, identity, or security reach, not just resources? Choose Microsoft Entra Tenant Governance, directory roles and Azure RBAC on one projected principal, with the customer's own sign-in controls in the loop. Because the provider's identity projects down into each customer, administration is per-customer: the admin signs in to each customer tenant in turn rather than from one aggregated console.
Need both on the same tenant? Use both. They coexist because they operate on different planes, Lighthouse for the resource estate, Tenant Governance for directory and security.

11. Key points to remember about Entra Tenant Governance

Least privilege. A directory role grants no Azure access, and an Azure RBAC role grants no directory access. Each plane is an explicit grant to the proxy, start with read-only (e.g., Global Reader in the directory, Reader on resources) and add only what's needed.
Directory ≠ resource. The two planes are independent. If the partner needs to operate Azure resources, that comes from an explicit RBAC assignment on the remote tenant group, not from any directory role. That RBAC is control-plane only; neither Tenant Governance nor Lighthouse delegates the resource data plane (for example, blob data or Key Vault secrets), which still requires an identity native to the customer tenant.
Tenant discovery is irreversible. Enabling related-tenant discovery is permanent (deployment guide). For a controlled pilot, run the handshake by tenant ID and skip discovery. Azure Lighthouse, by contrast, coexists with a governance relationship on the same customer, different mechanism, different plane.
Conditional Access is the customer's to enforce. Because the provider signs in to the customer tenant, the customer's Conditional Access governs that access.

12. Summary

Azure Lighthouse and Microsoft Entra Tenant Governance are two delegation models pointing in opposite directions. Lighthouse brings the customer's resources up to the provider and keeps the provider's Azure access clean and identity-free. Tenant Governance places a governed proxy of the provider down in the customer, extending the very philosophy from Parts 1–2, govern the relationship, not the people, from the resource plane all the way into the directory.

Choose by the direction the trust needs to flow: bring the resources to you (Azure Lighthouse), or place a governed proxy of yourself in the customer (Microsoft Entra Tenant Governance). When you need both, use both.

Azure Lighthouse: Bring Your Partner In, Without Letting Their Identities In (part 2 of 3)

Preston_Romney — Thu, 23 Jul 2026 15:40:21 GMT

See part 1 – Implementing Azure Lighthouse: A Technical Guide for Service Providers and Enterprises (part 1 of 2)

See part 3 – Should You Use the New Microsoft Entra Tenant Governance or Azure Lighthouse? (part 3 of 3)

The three traditional ways in, and what each leaves behind

When a provider needs to operate your Azure resources, there are three common patterns. Microsoft’s own cross‑tenant management guidance describes the starting point bluntly: “an administrator in the customer’s tenant must create and manage user accounts for the service provider.” (cross‑tenant management experience)

B2B guest accounts. You invite each provider engineer into your tenant through Microsoft Entra External ID and assign them Azure roles. A real user object is created in your directory (its UPN carries the #EXT# marker) and it can be “managed like an employee, for example, added to groups or assigned to applications.” Convenient, but now it’s your object to track, review, and eventually delete.
Member (local) accounts. You create internal accounts, sometimes licensed, for provider staff. Microsoft’s secure external access guidance lists the drawbacks of these “local credentials” plainly: “Access continues after external user terminates,” the Member user type “grants too much default access,” and you take on “password and multifactor authentication management… [and] identity cleanup.” Member users also receive broad default directory permissions, they can enumerate users, create security groups, and register applications.
Service principals with shared secrets. You register an app and hand the provider a client secret or certificate. Microsoft’s app‑registration security guidance is explicit: “Don’t use password credentials… they are often mismanaged and can be easily compromised,” and you must “roll over credentials frequently.” And because an app object and its service principal are governed separately from the Azure role assignments they hold, deleting the app won’t revoke the access it was granted in your subscriptions, those assignments persist as separate objects until you remove them.

Each of these makes the provider’s identity your operational problem, and the bill grows with every new vendor.

The hidden cost: you inherit an identity‑lifecycle problem

External identities have no HR signal inside your tenant. Microsoft’s identity governance overview notes that lifecycle automation is normally “tied to the representation of that person in an HCM or HR system”, but the provider’s joiners, movers, and leavers live in their HR system, not yours. When an engineer leaves the provider, nothing in your tenant knows.

So you compensate with machinery. To keep guest sprawl in check you run access reviews and entitlement management, capabilities that require a Microsoft Entra ID Governance or Entra Suite license. You watch for stale guest accounts, which Microsoft flags only after a 90‑day inactivity default. Because partner devices aren’t managed by you, device‑based Conditional Access blocks them whenever you enforce such a policy, so you build per‑partner exclusion lists. And you rotate service‑principal secrets on a schedule.

Now multiply all of that by every vendor.

Every vendor adds external identities, guests, members, and service principals, into your own Microsoft Entra tenant, where they become your responsibility to govern.

The result is external‑identity debt. Microsoft’s access‑reviews guidance warns that “excessive access rights can lead to compromises… [and] audit findings as they indicate a lack of control over access.” And it runs against Zero Trust, which treats identity as the primary security perimeter: every external account you hold is a piece of attack surface you now own.

A lesser‑known exposure: identities that can create subscriptions

There’s a subtler reason to keep external partners out of your directory, and it has nothing to do with the roles you assign them. By default, any identity that exists in your tenant, including a guest or a member account, can create new subscriptions in your tenant, or bring external ones into it, without holding any Azure permission you granted. Those subscriptions land inside your tenant and inherit your directory, yet they originate outside your procurement, billing, and governance, and it’s surprisingly easy to miss that it happened.

It’s a real gap, and closing it takes deliberate, tenant‑wide controls that many organizations simply haven’t put in place. (The specifics are best worked through privately with your Azure and billing administrators.) The point that matters here is about where the partner’s identity lives: the exposure exists only because there is an account in your tenant to exercise it. A Lighthouse provider has no identity in your tenant at all, so this entire class of exposure simply doesn’t apply to them. It’s one more thing you never have to govern when the partner never becomes a resident of your directory.

A better model: Azure Lighthouse

Azure Lighthouse takes a different approach called Azure delegated resource management. Instead of importing the provider’s people into your directory, it lets authorized users who remain entirely in the provider’s own tenant operate on your resources, “without having an account in that customer’s Microsoft Entra tenant or being a co‑owner of the customer’s tenant.”

Azure Lighthouse projects the provider’s identities onto your subscriptions through Azure Resource Manager. The only objects created in your tenant are two ARM resources you can audit and remove.

Mechanically, you (specifically, an Owner or equivalent in your tenant) deploy a small Azure Resource Manager template, or accept a private Marketplace offer, that creates two resources in your subscription: a registration definition (which managing tenant, and which built‑in roles for which provider principals) and a registration assignment (binding that to a subscription or resource group). From then on, when a provider user acts on your resources, Azure Resource Manager checks those two resources and authorizes the request. Access is one‑directional, from the managing tenant to yours, and it exists only because you deployed it.

Crucially, no provider user, guest, member, or service‑principal object is ever created in your directory. Provider identities, and the MFA, Conditional Access, and device‑compliance policies that govern them, stay where the provider already manages them. There is also no extra charge for Azure Lighthouse itself.

Conditional Access Policy Considerations

Because provider users authenticate in their tenant, your Conditional Access policies do not apply to them. Microsoft states it directly in the recommended security practices: “Conditional access policies on customer tenants don’t apply to users who access the customer’s resources through Azure Lighthouse. Only policies set on the managing tenant apply.”

That’s a natural consequence of the identity living with the provider. It just means the controls move from “policies you enforce” to “controls you require and verify”: insist the provider enforces MFA and Conditional Access on its own users, write it into the contract, and use Azure Policy to restrict which managing tenants can ever be delegated to. Think of it as a shared‑responsibility split:

You control	The provider controls	Joint
Delegated scope (subscription or resource group)	User lifecycle (joiner/mover/leaver)	Evidence & audit cadence
Which managing tenant is approved	MFA / Conditional Access	Incident response process
The exact built‑in roles granted	PIM activation policy	Security‑review schedule
Azure Policy guardrails, monitoring, log export	Device posture & group membership
Revocation, at any time

Side‑by‑side: it’s about who owns the work

The strongest argument for Lighthouse isn’t that it can do things the alternatives can’t, a well‑run B2B program can also use named identities, access reviews, and PIM. The difference is who owns the operational burden, and how much of it lands in your directory.

Consideration	B2B guest	Member account	Service principal	Azure Lighthouse
Identity object in your directory	Yes (#EXT#)	Yes	Yes (app + SP)	None
Identity‑lifecycle owner	You	You	You	The provider
Offboard the Azure access	Manual cleanup	Manual cleanup	Manual + rotate secret	Remove delegation (one action)
Privilege‑escalation prevention	Depends on roles + your IAM	Depends	Depends	Blocked by the platform
Per‑person audit trail (ARM)	Yes (named guest)	Yes	No (shared identity)	Yes (your Activity Log)
JIT for privileged roles	Possible, you configure & license	Possible, you configure	Usually not	Possible, provider configures
Your IAM blade stays clean	No	No	No	Yes
Governance‑licensing owner	You (Entra ID Governance)	You	You	The provider (for JIT)

The rest of this article walks the Azure Lighthouse column.

Benefit 1, Identity lifecycle stays with the provider

Because the identity lives in the provider’s tenant, the provider’s own joiner‑mover‑leaver process governs it automatically. When an engineer leaves, the provider disables that account in their directory, and the person’s access to your delegated scope is gone, with no lingering object in your tenant to find and remove. The best practice of assigning access to a security group makes this even cleaner: the provider adds and removes individuals from the group on their side, and you never touch the delegation.

Contrast that with the member‑account drawback, “access continues after external user terminates”, and the difference is stark. Provider turnover stops creating identity‑cleanup work in your directory; your job shifts to governing the delegation and verifying the provider’s lifecycle controls.

Benefit 2, Least privilege you don’t have to police

Azure Lighthouse won’t even let a provider hold the roles that would let them take over. Per the role‑support rules, delegation supports the Azure built‑in roles except:

The Owner role can’t be delegated.
Custom roles and classic administrator roles aren’t supported.
Roles with DataActions (data‑plane) permissions aren’t supported.
Roles carrying Microsoft.Authorization/* write/delete actions (role assignments, role definitions, locks, deny assignments) aren’t supported.
User Access Administrator is allowed only for the narrow purpose of assigning roles to managed identities, and you specify exactly which.

The practical effect: a delegated provider cannot grant itself more access, edit your role assignments, set resource locks, create deny assignments, or lock you out of your own resources. Least privilege here is enforced by the platform, not by your vigilance.

One honest nuance to scope carefully: Lighthouse operates at the Azure Resource Manager control plane only and grants no direct data‑plane access, no reading blob contents or Key Vault secret values, as the cross‑tenant documentation explains. But a few control‑plane actions can surface data indirectly (for example, a role that allows listKeys can return storage account keys), so choose the built‑in roles you delegate deliberately.

Benefit 3, One action ends it, for either party

Offboarding a whole vendor is normally a scavenger hunt across guests, accounts, secrets, and scattered role assignments. With Lighthouse it’s a single step. As the remove‑delegation guidance puts it, after a delegation is removed “no users in the service provider’s tenant will be able to access the resources that had been previously delegated.”

When a project ends, removing the single delegation instantly cuts off the provider’s access to your scope, and leaves nothing behind in your directory. Either party can perform the removal.

And importantly, either party can end it. You, an Owner in your tenant, can remove the offer from the Service providers page at any time, without involving the provider. The provider can also remove the delegation from their side when the engagement wraps up, provided they were granted the Managed Services Registration Assignment Delete Role during onboarding (a recommended practice). Removal is unilateral on either side, takes effect for all of the provider’s users at once, and touches only the Lighthouse delegation, any other access a vendor holds is separate.

Benefit 4, Complete, named visibility

Delegation doesn’t mean flying blind. Every action a provider takes is recorded in your Azure Activity Log, and the “Event initiated by” column shows the specific provider user by name, the same place you see your own administrators’ actions. Logs are retained 90 days in‑portal and can be exported for longer, and you can set activity‑log alerts on critical operations.

Interestingly, those provider users don’t clutter your Access Control (IAM) blade, “these users and their role assignments don’t appear in Access Control (IAM).” You manage them in the dedicated Service providers experience instead, so your native role assignments stay clean. You can also use built‑in Azure Policy definitions to audit existing delegations or deny delegation to any managing tenant that isn’t on your approved list.

Benefit 5, Just‑in‑time access, not standing privilege

Standing privileged access is a well‑documented risk: with a permanent assignment, as Microsoft’s PIM documentation describes, “a user can always use the role without performing any actions.” Lighthouse supports a better pattern through eligible authorizations, which use Microsoft Entra Privileged Identity Management so a provider user must activate a privileged role just‑in‑time. Activation is time‑bound (between 30 minutes and 8 hours), can require MFA, and can require approval.

Just‑in‑time elevation flows through Microsoft Entra PIM. When approval is required, the approver is in the provider’s tenant, not yours. Your safeguards are MFA, the bounded activation window, review at onboarding, and full Activity‑Log visibility.

Per the eligible‑authorizations documentation, you can designate “up to 10 users or user groups in the managing tenant who can approve or deny requests.” In other words, approval, when required, is granted by the provider’s own approvers, not by the customer. That’s a deliberate design choice, and your safeguards are real and layered: customers can “review all role assignments, including those in eligible authorizations, before the onboarding process,” you can require MFA on activation, the activation window is capped, and every elevation appears in your Activity Log. (Two practical notes: eligible authorizations need the provider to hold an Entra ID Governance/PIM license, and they aren’t supported in national clouds.)

Benefit 6, Scale without sprawl

Because each provider is a separate delegation, the model scales cleanly: add a vendor by adding a delegation, remove one without touching the others, and govern them all from one place. And the management happens with the Azure tools you already use, cross‑tenant. The cross‑tenant management experience spans Microsoft Sentinel, Microsoft Defender for Cloud, Azure Policy at scale, Azure Arc for hybrid servers and Kubernetes, and Azure Monitor, none of which require importing identities to make work.

For managed security providers in particular, this is significant: a single SOC can manage Sentinel workspaces across many customer tenants while each customer’s data stays in their own tenant, and the provider’s queries and playbooks stay in theirs.

Govern delegations, not people

Step back and the deepest benefit comes into focus. The traditional model asks you to govern external people, accounts, and secrets, forever, inside your directory. Lighthouse changes the unit of governance to a single approved delegation: a managing tenant, a scope, a set of roles, and a revocation switch.

That shift has four consequences worth internalizing:

Vendor turnover never becomes your identity churn.
Your directory doesn’t accumulate vendor identities as your vendor list grows.
Privilege escalation is blocked by the platform, not policed by your team.
The identity lifecycle, and the PIM/governance licensing for just‑in‑time access, sits with the provider, the party that actually employs the people.

“But we’ve already built all this”

If your team has invested in JML automation, recurring access reviews, Conditional Access exclusion lists, secret‑rotation pipelines, and entitlement management, that’s real and valuable work, and it works. The reframe is simple: those processes manage a problem that Lighthouse removes for Azure control‑plane partner access. You can keep spending effort, licensing, and residual risk to govern people you don’t employ, or you can retire that specific machinery for this use case. Keep your governance program for your own workforce; stop extending it to other companies’ staff.

Deploy it well: secure‑by‑design guardrails

Treat these as part of the design, not as caveats:

Require and verify provider MFA/PIM, your Conditional Access doesn’t apply to their users, so make it a contractual obligation and ask for evidence.
Delegate least privilege, use the narrowest built‑in roles, and avoid roles that can surface keys unless you truly need them.
Restrict approved managing tenants with Azure Policy (audit or deny).
Export Activity Logs beyond the 90‑day window to meet your retention requirements, and alert on critical operations.
Prefer JIT (eligible authorizations) for any privileged role.
Mind the boundaries, some scenarios (such as Microsoft Defender for Cloud) require whole‑subscription delegation, and Lighthouse can’t span a national cloud and the public cloud.

Where Lighthouse stops, and what to use instead

Lighthouse is deliberately scoped to the Azure Resource Manager control plane. It does not grant Microsoft Entra ID directory roles (like Global Administrator) and it does not cover Microsoft 365 workloads such as Exchange, SharePoint, Teams, or Intune. When a provider genuinely needs to manage identities consider Microsoft Entra Tenant Governance as described in part 3, or for managing Microsoft 365 the companion product is Microsoft 365 Lighthouse, a separate service with its own model.

Beyond MSPs: it’s not only for service providers

Two adjacent scenarios are worth knowing about:

Enterprises with multiple tenants. If your own organization spans several Microsoft Entra tenants (through acquisitions, or separation of dev/test from production), you can use Azure Lighthouse within the enterprise to manage resources across them from one place, the same delegation model, applied internally.
CSP partners. For partners transacting through the Cloud Solution Provider program, Lighthouse narrows the broad “Admin Agent” AOBO model. Instead of every Admin Agent having sweeping access to every customer, Lighthouse “helps improve security by limiting broad access” with granular, per‑customer, per‑role assignments.

Getting started: a low‑risk pilot

You don’t have to commit your production estate to prove the model. A sensible first step:

Delegate one non‑production subscription to the provider’s tenant.
Grant least‑privilege built‑in roles, with JIT (eligible authorizations) for anything privileged.
Require MFA for your own admins, and require the provider to enforce MFA on its delegated users (your Conditional Access doesn’t reach them).
Turn on activity‑log alerts and an Azure Policy that restricts approved managing tenants.
Review after 30 days, then expand.

The provider builds the onboarding ARM template (Microsoft publishes ready‑to‑use samples on GitHub), and you deploy it with an Owner account. Because you can remove the delegation at any time, the downside is bounded and reversible, while the upside compounds with every vendor you onboard this way.

Summary

Letting a partner operate your Azure environment doesn’t have to mean adopting their people into your directory. With Azure Lighthouse, the provider brings their own governed identities, you grant a scoped and fully revocable delegation that you approve, every action is attributed in your own logs, the platform itself prevents privilege escalation, and the identity‑lifecycle burden stays with the company that employs the staff. You stop governing other people’s employees, and start governing one clean, auditable relationship.

That’s a better deal for your security team, your auditors, and your partners alike.

Customer Offerings: Solution Optimization for GitHub Copilot

wernerrall — Wed, 15 Jul 2026 13:41:27 GMT

Introduction

As Microsoft Cloud Solution Architects, we are increasingly asked by engineering leaders, platform teams, finance stakeholders, and GitHub administrators how they can scale GitHub Copilot while keeping usage visible and costs predictable. The question is no longer simply how many licenses have been assigned. Agentic experiences, model choice, context size, reasoning level, and task complexity can all influence consumption.

To address this challenge, Microsoft customers can engage their account team to request a Solution Optimization for GitHub Copilot engagement. The engagement is designed to help customers create visibility, establish practical cost guardrails, and improve the quality and efficiency of GitHub Copilot usage. The objective is not to minimize every token; it is to help each interaction produce useful outcomes with the right level of capability and control.

What changed with GitHub Copilot billing?

As of June 1, 2026, GitHub Copilot moved from premium request units to usage-based billing with GitHub AI Credits. When a user interacts with an AI-powered Copilot feature, the interaction can consume input tokens, output tokens, and cached tokens. The model used and the number of tokens processed determine the AI credit consumption, where one AI credit represents $0.01 USD.

Area	What customers should know
Included usage	Copilot Business includes 1,900 AI credits per licensed user per month, while Copilot Enterprise includes 3,900. These credits are pooled at the billing entity level.
Promotional period	At the time of writing, existing Business and Enterprise customers receive higher promotional allowances through August 2026. Validate the current allowance before publishing or making financial decisions.
Included experiences	Code completions and next edit suggestions remain included on paid plans and do not consume AI credits.
Metered experiences	AI-powered features such as Copilot Chat, Copilot CLI, Copilot cloud agent, Copilot Spaces, Spark, and supported third-party coding agents consume AI credits.
Additional consumption	Some agentic experiences, including Copilot code review and cloud agent scenarios, can also consume GitHub Actions minutes in addition to AI credits.

Important:
Pricing, allowances, supported models, and product behavior can change. The official GitHub documentation and the customer’s commercial agreement remain the source of truth.

Why optimization is more than cost reduction

Token consumption is only the visible part of the problem. A poorly scoped task, unnecessary context, or the wrong model can cause an agent to misunderstand the request, make excessive changes, or require repeated attempts. In that situation, reducing the price of an individual request does not solve the underlying quality problem.

A better optimization strategy starts with agent quality. The right model, clear instructions, focused context, good repository guidance, and deterministic validation can help Copilot complete work in fewer attempts. Better outcomes and lower consumption frequently reinforce each other.

Introducing Solution Optimization for GitHub Copilot

The Solution Optimization for GitHub Copilot engagement provides customers with an opportunity to work with a Microsoft Cloud Solution Architect to review how GitHub Copilot is being adopted, consumed, governed, and measured. The final scope should be agreed with the Microsoft account team and may vary according to the customer’s licensing model, environment, maturity, and priorities.

A typical engagement can focus on the following areas:

Usage visibility: Establish a current-state view of adoption, AI credit consumption, model activity, license allocation, and the users or workflows driving demand.
Billing readiness: Review exported usage data, compare scenarios, and identify where the move to usage-based billing changes planning assumptions.
Cost guardrails: Design user-level, cost-center, organization, and enterprise budget controls that protect the shared pool without unnecessarily blocking productive users.
Agent quality and token optimization: Identify improvements to model selection, prompt structure, context management, reasoning levels, repository instructions, and validation steps.
Operating model: Define ownership, review cadence, escalation paths, reporting responsibilities, and a prioritized backlog of recommended actions.

Potential customer outcomes

Depending on the agreed scope, the engagement can help the customer develop:

A baseline of GitHub Copilot adoption, AI credit consumption, and cost drivers.
A view of heavy users, underused licenses, high-consumption models, and agentic workflows that need closer review.
A budget and guardrail design that balances shared-pool flexibility with predictable financial control.
Practical recommendations for improving agent quality and reducing avoidable retries or context overhead.
A prioritized optimization plan with owners, next actions, and measurable follow-up points.

A practical engagement approach

Discover: Review the customer’s goals, GitHub billing entity, Copilot plans, license assignment model, existing policies, cost centers, and available usage data.
Analyze: Use native GitHub reporting and approved accelerators to examine adoption, AI credit usage, model activity, user patterns, and potential cost drivers.
Optimize: Map the right model and reasoning level to each task, improve prompts and context, reduce unnecessary tool or repository context, preserve reusable cache, and plan before executing complex changes.
Govern: Define user-level budgets, power-user overrides, cost-center or organization controls, enterprise spending limits, alerts, and ownership responsibilities.
Measure: Document the baseline, agree on key indicators, and establish a regular review cycle to measure adoption, value, quality, and consumption over time.

Tools and accelerators

GitHub AI usage, billing exports, and budget controls

GitHub’s native AI usage pages and billing reports should be the starting point for understanding consumption. They provide the information required to identify model usage, users, features, and cost patterns. Native budget controls can then be applied at the appropriate user, cost-center, organization, or enterprise scope.

GitHub AI usage dashboard, exported usage report, and budget controls

GitHub Copilot Billing Preview

The GitHub Copilot Billing Preview is an open-source web application for analyzing Copilot billing CSV reports, comparing request-based and usage-based billing signals, and exploring usage and cost trends by user, organization, model, product, and cost center. CSV processing occurs locally in the browser. The application is a preview and planning tool, not the billing source of record.

GitHub Copilot Billing Preview showing usage and cost trends

Copilot Insights dashboard

The community-developed Copilot Insights dashboard provides centralized views of adoption, license allocation, AI credit consumption, model activity, productivity indicators, and team-level reporting. It can complement native GitHub data when a customer needs richer visualization or executive reporting. Customers should review the project’s security, deployment, support, and governance model before production use.

Copilot Insights adoption, license, and AI credit views

Agent quality and token optimization principles

GitHub’s guidance emphasizes that the most sustainable way to reduce AI credit consumption is to improve the quality and efficiency of each interaction. The following principles provide a useful starting point:

Choose the right model for the task. Reserve powerful reasoning models for complex architecture, debugging, and design work. Use mid-tier or lighter models for well-scoped implementation, documentation, formatting, and routine refactoring.
Provide clear guidance. State the goal, constraints, expected output, relevant files, and validation criteria. Ambiguous prompts often lead to exploration and rework.
Keep context lean. Supply the information needed for the task and avoid loading unrelated repositories, files, tools, or instructions into the context window.
Preserve reusable context. Stable instructions and cached context can reduce repeated processing, provided they remain relevant and accurate.
Research and plan before implementation. For complex work, separate discovery and planning from execution so the agent does not repeatedly rediscover the same information.
Add deterministic guardrails. Tests, linting, build validation, explicit stop conditions, and session limits help prevent long-running or low-quality loops.
Measure value, not only consumption. AI credit data should be considered together with adoption, developer experience, quality, delivery outcomes, and business impact.

Overview video

The on-demand session GitHub Copilot - Token Optimization [AMER/EMEA] explains the relationship between token usage and agent quality. The session covers how large language models, agent harnesses, context windows, and available controls influence agent behavior, quality, consumption, and cost.

https://www.youtube.com/live/LeALSSsbzHU?si=4RgxflItkQFAs9Qk

Helpful inputs before the engagement

The following inputs can help the Microsoft team and customer make the best use of the engagement:

A GitHub enterprise or organization owner, billing manager, and relevant engineering or platform stakeholders.
Current Copilot plan and license counts, including the billing entity and cost-center structure.
A representative GitHub AI usage or billing export, handled according to the customer’s data policies.
Existing budgets, spending policies, model policies, and reporting processes.
Examples of high-volume agent sessions, code review workflows, or teams reporting unexpected consumption.
The business outcomes the customer wants to improve, such as adoption, developer experience, delivery speed, quality, or cost predictability.

Conclusion

GitHub Copilot usage-based billing changes the conversation from license assignment alone to the broader discipline of operating AI-assisted software development. Customers need visibility into how AI credits are consumed, controls that prevent unexpected spend, and engineering practices that help agents complete work accurately and efficiently.

The Solution Optimization for GitHub Copilot engagement can help customers connect usage data to practical decisions, improve agent quality, establish appropriate financial guardrails, and create a repeatable approach for measuring and optimizing GitHub Copilot over time.

How do I book this engagement?

Microsoft Unified Support customers can contact their Customer Success Account Manager (CSAM) or Microsoft account team and ask about Solution Optimization for GitHub Copilot. The Microsoft team can confirm availability, eligibility, scope, prerequisites, and scheduling for the customer’s environment.

Resources

Disclaimer

Pricing, plan entitlements, AI credit allowances, supported models, and product behavior are subject to change. Always verify current information in the official GitHub documentation and the customer’s commercial agreement before making purchasing, budgeting, or technical decisions.

The sample applications, dashboards, and scripts referenced in this article are provided AS IS without warranty of any kind and may not be supported under a Microsoft or GitHub standard support program unless explicitly stated. Customers are responsible for reviewing security, privacy, compliance, deployment, and operational requirements before using community or open-source solutions in production. This blog post was drafted with the assistance of generative AI and should be reviewed and approved by the author and relevant Microsoft stakeholders before publication.

Hunting Local AI Tools on macOS with Microsoft Defender for Endpoint

Vytas_Boyev — Tue, 14 Jul 2026 16:42:42 GMT

AI tooling is moving fast. Developers are running models locally, agents are spinning up local servers, and frameworks are adding new ways to extend the endpoint with skills, tools, and memory. That creates a useful productivity surface, but it also presents new challenges for security and governance teams.

A set of AI focused detection and protective Defender for Endpoint features are now in preview – Local AI Agent and MCP detection and inventory as well as AI Agent security posture– both announced in detail here on the Microsoft Defender XDR blog .

Those capabilities are emerging, but defenders still need practical visibility now. The power of Microsoft’s XDR platform provides the capability to look at our endpoint telemetry and gather data from your existing environment today…. MDE already captures enough process, file, and network telemetry to start hunting for this activity with Advanced Hunting KQL.

Why Focus on macOS?

Many organizations have developers that have adopted macOS clients as development machines.

Developers are a population that are positioned to take advantage of and use AI in the course of developing Frontier and next generation apps, agents, and capabilities. Which increases their attack surface while maintaining their attractiveness for targeted supply chain attacks.

The capability to detect and have visibility on local AI tool usage, MCP server usage, malicious skill files, or AI-specific abuse patterns such as prompt injection are top of mind topics that I encounter routinely with my customers that I support.

This post walks through how I’d approach that problem: inventory first, then detect local AI servers, monitor skill/configuration files, and finally look for suspicious behavior that may indicate abuse. Keep in mind that though I am specifically addressing macOS in this post, the techniques can be shifted to Linux and other supported platforms through the power and flexibility of KQL and Advanced Hunting.

Why local AI on macOS matters

Most endpoint detection content has historically focused on malware, persistence, credential theft, and command execution. Local AI agents blur those lines.

An AI agent running on a developer workstation may legitimately:

Spawn shell commands.

Read source files and configuration files.

Write scripts.

Start a local server.

Pull packages or model files.

Maintain memory or context in local markdown files.

That same behavior can also become risky if the agent is compromised, misconfigured, or influenced by malicious instructions.

For macOS, two local AI frameworks stand out in the telemetry patterns I reviewed:

Ollama — a local LLM runtime that exposes a local API, commonly on port 11434.

OpenClaw — an autonomous AI agent platform that uses a local gateway, commonly on port 18789.

Both leave process, filesystem, and network artifacts that MDE can see.

Start with inventory, not alerts

Before turning anything into a detection rule, start by understanding where local AI tools already exist.

The first useful question is simple: Which macOS devices are running AI tooling?

A reporting query against DeviceProcessEvents can identify known AI-related processes such as ollama, openclaw, node, npx, codex, or claude-code. The important detail is that macOS platform filtering needs to come from DeviceInfo, as it is not present in the other KQL tables we will be using.

A practical inventory pattern looks like this:

KQL — macOS AI tool inventory

DeviceInfo | where OSPlatform == "macOS" | distinct DeviceId | join DeviceProcessEvents on DeviceId | where Timestamp > ago(30d) | where ( FileName in~ ( "ollama", "openclaw", "ollama_llama_server", "ollama-runner", "mcp-server", "codex", "codex-cli", "claude-code", "npx", "node", "deno" ) or ProcessCommandLine has_any ( "ollama", "openclaw", "ollama_llama_server", "ollama-runner", "mcp-server", "codex", "codex-cli", "claude-code", "npx", "node", "deno" ) ) | summarize FirstSeen = min(Timestamp), LastSeen = max(Timestamp), ExecutionCount = count(), DistinctUsers = dcount(AccountName) by DeviceName, FileName, FolderPath | sort by LastSeen desc

This gives you a baseline. Once you know what normal looks like, you can start asking more interesting questions:

Which devices are running AI tools for the first time?

Which users are adopting them?

Which tools are approved?

Which tools appeared without a change request or expected rollout?

That baseline becomes the foundation for alerting.

Detect first-time AI tool usage

A good first alert is “new AI tool on a macOS device.”

The key is to compare recent activity against historical activity by both device and tool name. If a Mac has already run OpenClaw but suddenly starts running Ollama, that should still be considered a new tool introduction.

KQL — first-time AI tool usage on macOS

DeviceProcessEvents | where Timestamp > ago(1d) | where FileName in~ ("ollama", "openclaw")     or ProcessCommandLine has_any ("ollama", "openclaw", "openclaw.mjs") | join kind=leftanti (     DeviceProcessEvents     | where Timestamp between (ago(30d)..ago(1d))     | where FileName in~ ("ollama", "openclaw")         or ProcessCommandLine has_any ("ollama", "openclaw", "openclaw.mjs")     | distinct DeviceId, FileName, ProcessCommandLine ) on DeviceId, FileName, ProcessCommandLine | summarize     FirstSeen = min(Timestamp),     LastSeen = max(Timestamp),     Count = count()     by DeviceName, FileName, ProcessCommandLine, AccountName | sort by LastSeen desc

This may be a good daily custom detection candidate, especially in environments where AI tooling needs to be explicitly approved.

Watch for local AI servers

Local AI frameworks often expose services on localhost. That makes network telemetry useful even when the tool is only listening locally.

Known ports worth watching:

Tool	Port	Purpose
Ollama	11434	Local HTTP API
OpenClaw	18789	Local WebSocket gateway

A targeted detection for those ports is straightforward:

KQL — local AI server listener detection

DeviceInfo | where OSPlatform == "macOS" | distinct DeviceId |join DeviceNetworkEvents on DeviceId | where Timestamp > ago(1d) | where ActionType == "ListeningConnectionCreated" | where LocalPort in (18789, 11434) | project     Timestamp,     DeviceName,     LocalIP,     Port = LocalPort,     ProcessName = InitiatingProcessFileName,     CommandLine = InitiatingProcessCommandLine,     User = InitiatingProcessAccountName | sort by Timestamp desc

For broader hunting, enumerate localhost listeners and exclude known system services. This helps find new or less common MCP servers before they show up in a curated indicator list.

Monitor AI skill and context files

The next detection surface is the filesystem.

AI agent frameworks increasingly use markdown-based instruction and context files. Examples include:

SKILL.md

SKILLS.md

SOUL.md

MEMORY.md

AGENTS.md

These files are powerful because they influence how the agent behaves. A malicious skill file can embed instructions, reference scripts, deliver payloads, or create persistence.

A weekly reporting query can monitor creation and modification of these files:

KQL — AI skill and context file monitoring

DeviceInfo | where OSPlatform == "macOS" | distinct DeviceId |join DeviceFileEvents on DeviceId | where Timestamp > ago(7d) | where ActionType in ("FileCreated", "FileModified") | where tolower(FileName) in (     "skill.md",     "skills.md",     "soul.md",     "memory.md",     "agents.md" ) | project     Timestamp,     DeviceName,     FileName,     FolderPath,     ActionType,

For alerting, I would focus on suspicious creators: curl, wget, python, bash, scp, or browser-downloaded files with FileOriginUrl populated.

DeviceInfo | where OSPlatform == "macOS" |distinct DeviceId |join DeviceFileEvents on DeviceId | where Timestamp > ago(1d) | where ActionType == "FileCreated" | where tolower(FileName) in ("skill.md", "skills.md", "soul.md") | where InitiatingProcessFileName in ("curl", "wget", "python", "python3","bash", "sh", "zsh", "nscurl", "scp") or isnotempty(FileOriginUrl) | project Timestamp, DeviceName, FileName, FolderPath,FileOriginUrl, FileSize, InitiatingProcessFileName, InitiatingProcessCommandLine

The signal is not “a skill file exists.” The signal is “a skill file appeared or modified in an unusual way.”

Look for prompt injection side effects

Prompt injection is hard to detect directly from endpoint telemetry because MDE does not see the prompt content inside encrypted sessions or local model interactions.

But endpoint telemetry can show the downstream effects.

If an AI agent is manipulated into doing something unsafe, you may see it:

Spawn a shell.

Run osascript.

Invoke launchctl.

Access the macOS Keychain via security.

Use curl, wget, or scp.

Read sensitive paths such as .ssh, .env, or credential files.

Make unexpected external network connections.

A useful behavioral detection is AI-related parent processes spawning sensitive child commands:

KQL — AI parent process spawning sensitive child commands

DeviceInfo | where OSPlatform == "macOS" | distinct DeviceId |join DeviceProcessEvents on DeviceId | where Timestamp > ago(1d) | where tolower(InitiatingProcessFileName) in ("ollama", "openclaw", "node", "npx", "deno")     or InitiatingProcessCommandLine has_any ("openclaw", "ollama", "openclaw.mjs") | where FileName in~ (     "sh",     "bash",     "zsh",     "python",     "python3",     "curl",     "wget",     "scp",     "osascript",     "launchctl",     "security",     "dscl" ) | project     Timestamp,     DeviceName,     ParentProcess = InitiatingProcessFileName,     ParentCmdLine = InitiatingProcessCommandLine,     ChildProcess = FileName,     ChildCmdLine = ProcessCommandLine,     User = AccountName | sort by Timestamp desc

This may not be suitable for use as an alert, as developers using AI coding assistants will legitimately run shell commands. The goal is not to block all shell execution. The goal is to identify suspicious combinations: encoded payloads, persistence commands, credential access, unexpected network transfer, or sensitive file access.

Don’t skip external network checks

Local inference should mostly stay local. Ollama may contact external services for model downloads or registry activity, and agents may call approved cloud AI APIs depending on configuration. But unexpected public destinations from local AI processes are worth reviewing.

Start with a narrow allowlist and expand based on your environment:

KQL — external network connections from local AI processes

DeviceInfo | where OSPlatform == "macOS" | distinct DeviceId |join DeviceNetworkEvents on DeviceId | where Timestamp > ago(1d) | where ActionType in ("ConnectionSuccess", "ConnectionAttempt") | where InitiatingProcessFileName in~ ("ollama", "openclaw", "node")     or InitiatingProcessCommandLine has_any ("openclaw", "ollama") | where RemoteIPType == "Public" | where RemoteUrl !endswith "ollama.com"     and RemoteUrl !endswith "openclaw.ai"     and RemoteUrl !endswith "anthropic.com"     and RemoteUrl !endswith "openai.com" | project     Timestamp,     DeviceName,     RemoteIP,     RemoteUrl,     RemotePort,     ProcessName = InitiatingProcessFileName,     CommandLine = InitiatingProcessCommandLine | sort by Timestamp desc

For alerting, consider thresholding on multiple distinct remote URLs from the same AI process over 24 hours. That helps separate one-off legitimate activity from suspicious multi-destination behavior.

KQL — OpenClaw LaunchAgent Plist Creation (Last 24 Hours)

This catches plist files appearing in ~/Library/LaunchAgents (or /Library/LaunchAgents) that reference OpenClaw by name or were created by an OpenClaw-related process. A matching result indicates that a persistent auto-start configuration has been installed for the AI gateway — which should be validated against approved deployment records.

DeviceFileEvents | where Timestamp > ago(1d) | where ActionType in ("FileCreated", "FileModified") | where FolderPath has "LaunchAgents" and FileName endswith ".plist" | where FileName has "openclaw"     or InitiatingProcessFileName in~ ("openclaw", "node")     or InitiatingProcessCommandLine has "openclaw" | where DeviceId in (     DeviceInfo | where OSPlatform == "macOS" | distinct DeviceId ) | project     Timestamp,     DeviceName,     FileName,     FolderPath,     InitiatingProcessFileName,     InitiatingProcessCommandLine,     User = InitiatingProcessAccountName

Recommended deployment model

I would not deploy every query as an alert on day one. A better operational model is:

Use case	Cadence	Deployment
AI process inventory	Weekly	Reporting dashboard
First-time AI tool per device	Daily	Custom detection
Known AI server ports	Daily	Custom detection
OpenClaw LaunchAgent persistence	Daily	Custom detection
Skill/context file monitoring	Weekly	Reporting dashboard
Suspicious skill creation	Daily	Custom detection
AI process spawning system commands	Daily	Custom detection after tuning
AI external network connections	Daily	Custom detection after tuning
Broad localhost listener discovery	Weekly	Threat hunt

The most reliable detections are inventory deltas, known listening ports, persistence artifacts, and suspicious skill creation. The highest-noise detections are behavioral heuristics, especially shell execution and external network activity.

Practical limitations

A few MDE/macOS realities matter:

MDE does not decrypt TLS traffic.

DeviceProcessEvents does not include OSPlatform, so use DeviceInfo to scope macOS devices. These queries can be used as a base to expand hunting into other OS platforms with minimal modification of the KQL.

A positive SKILL.md hit still requires content review.

DeviceFileEvents shows file metadata, not file contents.

That means these queries should be part of a broader defense-in-depth strategy, not the entire program.

Pair them with:

MDM and other controls restricting unsigned or unapproved AI apps- which may be problematic in a developer centric environment.

Network monitoring for known local AI ports.

Review processes for third-party skills.

Proxy/firewall correlation for suspicious external traffic.

Version-controlled detection content so query changes can be audited and rolled back.

Final thought

Local AI tools are becoming part of the endpoint reality. You can get a head start on understanding your org’s AI usage with KQL and Advanced hunting, especially on developer-heavy macOS fleets. Agent visibility in the XDR portal is in flight and arriving soon.

In the interim can start now with the telemetry we already have: processes, files, ports, and network connections. Build a baseline. Alert on meaningful change. Tune the noisy heuristics. Review skill files like executable content, because in practice that is what they can become.

Other artifacts that you can hunt for AI are the Defender for Cloud Apps leveraging the governance capability for monitoring or sanctioning and unsanctioning apps – which in this case - monitor the AI related apps.

This is not necessarily about blocking AI usage by default. It is about giving defenders enough visibility to distinguish normal local AI adoption from risky or compromised behavior.

Addendum:

I’ve created a Sentinel Workbook that incorporates these queries. Available at https://github.com/vboyev-MSFT/Microsoft-Sentinel-Workbooks

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

TysonPaul — Mon, 13 Jul 2026 20:50:04 GMT

Member: TysonPaul | Microsoft Community Hub

Triage vulnerabilities with the Vulnerability Remediation Agent, now in public preview

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 06/16/2026

Summary: Microsoft has launched the Vulnerability Remediation Agent for Security Copilot in Microsoft Intune, now in public preview. This agent automates the identification, prioritization, and remediation of vulnerabilities on Intune-managed Windows devices using data from Microsoft Defender. It provides prioritized recommendations, Copilot-assisted impact analysis, and step-by-step remediation guidance, all within the Intune admin center. The agent operates securely under a dedicated agentic identity, ensuring clear governance and accountability. The streamlined workflow helps IT teams quickly address critical threats, reduce exposure, and track progress, supporting a more proactive, AI-driven security posture.

Deploying Platform SSO for pre macOS 26 with Microsoft Intune: Lessons Learned

Team Blog: Intune Customer Success

Author: MikeGriz

Published: 06/18/2026

Summary: The article details Microsoft’s internal deployment of Platform Single Sign-On (PSSO) for pre-macOS 26 devices using Intune. It highlights the benefits of Secure Enclave-backed authentication—phishing-resistant MFA, device-bound tokens, and improved Conditional Access—while outlining setup steps, user experience, troubleshooting, and best practices. Key challenges included password policy mismatches and users dismissing registration prompts. The authors recommend starting with Secure Enclave, deploying during enrollment, aligning password policies, and piloting thoroughly. PSSO enables passwordless, hardware-backed SSO across Microsoft 365 apps, improving security and user experience for Mac fleets.

Scale On-Prem AI with Foundry Local on Azure Local: Multi-Node Inference and vLLM Support

Team Blog: Azure Arc

Author: LiranLyabock

Published: 06/02/2026

Summary: The article announces expanded capabilities for Foundry Local on Azure Local, including multi-node inference scheduling, vLLM runtime support, and a broader model catalog. These enhancements enable scalable, high-concurrency AI deployments fully on-premises—even in disconnected environments—using Kubernetes-native and OpenAI-compatible patterns. vLLM boosts throughput for large models and concurrent workloads, with automatic GPU tuning via vLLMplanner. Identity-based access is supported for multi-user scenarios. The platform now accommodates more models, including Mistral and Nemotron, and offers seamless integration and operation for regulated, sovereign, and edge environments.

Unlock On-Prem Productivity with Agentic Retrieval in Foundry Local

Team Blog: Azure Arc

Author: moran_assaf

Published: 06/02/2026

Summary: The article introduces Agentic Retrieval in Foundry Local, a new on-premises platform enabling advanced, context-rich AI interactions without relying on cloud connectivity. Powered by Azure Arc and Foundry models, it offers orchestration, governed knowledge management, and a production-ready chat UI for regulated, disconnected, and mission-critical environments. Key features include flexible deployment, auditable reasoning, multi-document synthesis, data sovereignty, and seamless user experience. This release supports Microsoft’s Adaptive Cloud vision, delivering resilient, intelligent GenAI solutions wherever customer data and operations reside, ensuring compliance and autonomy for enterprise and public sector users.

Microsoft 365 Copilot on mobile: What staged rollout plans can miss

Team Blog: FastTrack

Author: JulieHersum

Published: 06/02/2026

Summary: The article highlights that staged rollout plans for Microsoft 365 Copilot on mobile often miss how quickly real-world usage spreads. Mobile access accelerates adoption in “in-between” work moments, making usage less linear and more socially driven than planned. Desktop-focused governance and communication strategies may not apply to mobile-first behaviors, leading to early questions and confusion. IT teams should focus on rollout sequencing, setting user behavior expectations, governance/readiness, and clear communication to align planned deployment with actual adoption momentum. Early signals of mobile usage require proactive adjustments to maintain clarity and control.

Faster az login: introducing --skip-subscription-discovery and targeted --subscription

Team Blog: Azure Tools

Author: Alex-wdy

Published: 06/07/2026

Summary: The article introduces two new Azure CLI flags—`--skip-subscription-discovery` and targeted `--subscription`—which significantly speed up the `az login` process for users with many tenants and subscriptions. By skipping the post-authentication subscription enumeration, login times drop from minutes to seconds. These features, available from Azure CLI v2.86.0, are ideal for enterprise users or CI/CD scenarios needing quick access to specific subscriptions, but may not suit cases requiring access to multiple subscriptions or discovery.

Network security perimeter for Azure Service Bus & also now available in Azure Gov. Regions

Team Blog: Azure Networking

Author: shashankamalladi

Published: 06/08/2026

Summary: Network security perimeter support for Azure Service Bus is now generally available, including in Azure Government regions. This enables centralized security boundaries, perimeter-based governance, and secure PaaS-to-PaaS communication for messaging services. Customers can define explicit access controls, confine communications, and enhance audit/compliance visibility. The feature supports regulated and mission-critical workloads, ensuring consistent security across commercial and sovereign environments. Future plans include expanding onboarding to more PaaS services and improving access rule capabilities.

Migrating from MSEE Hairpin Routing to AVNM Mesh for Large-Scale VNet-to-VNet Connectivity

Team Blog: Azure Networking

Author: Jay-Li

Published: 06/18/2026

Summary: The article explains how large Azure deployments can migrate from MSEE hairpin routing to Azure Virtual Network Manager (AVNM) mesh for VNet-to-VNet connectivity. AVNM mesh enables direct, in-datacenter east-west traffic, eliminating MSEE as a single point of failure, reducing latency, and supporting up to 5,000 VNets and 20,000 Private Endpoints. Migration is incremental, reversible, and doesn’t disrupt existing network paths or security inspection, with AVNM centrally managing connectivity. The article details migration steps, scaling considerations, and validation processes, emphasizing operational simplicity and improved performance for large-scale Azure environments.

Azure Sets a New Performance Record for LLM Training Benchmark at Extreme Scale

Team Blog: Azure High Performance Computing (HPC)

Author: azinheidarshenas

Published: 06/16/2026

Summary: Azure set a new MLPerf Training benchmark record by training Llama 3.1 405B in just over seven minutes, scaling to 8,192 NVIDIA GB200 NVL72 GPUs across 128 racks. This was achieved through high operational efficiency, resilient networking, and topology-aware workload mapping. Azure’s Fairwater AI supercomputing infrastructure, with NVLink and MRC networking, minimized communication bottlenecks, enabling near-perfect scaling and stable step times. The result demonstrates Azure’s ability to handle massive, synchronous LLM training workloads efficiently, showcasing both hardware and system-level innovations for frontier-scale AI.

Scaling High-Performance CAD on Azure Virtual Desktop with NVIDIA RTX PRO 6000

Team Blog: Azure High Performance Computing (HPC)

Author: Sunita_AZ0708

Published: 06/17/2026

Summary: The study validates Siemens NX 2506 running on Azure Virtual Desktop with NVIDIA RTX PRO 6000 GPU, supporting up to 30 concurrent users with stable graphics and consistent performance. Single-host setups efficiently consolidate users, while multi-host configurations boost responsiveness and performance, especially for GPU-intensive tasks at higher user densities. All certification workloads passed successfully, confirming reliable GPU sharing and scalability. Azure AVD with RTX PRO 6000 proves suitable for enterprise CAD deployments, enabling centralized infrastructure, high user density, reduced hardware dependency, and scalable engineering workflows for real-world tasks and assemblies.

From Prompt to Provisioned: A Closer Look at the Azure Deployment Agent

Team Blog: ITOps Talk

Author: Pierre_Roman

Published: 06/23/2026

Summary: The article introduces the Azure Deployment Agent, showcased at the Microsoft Azure Infra Summit 2026. This AI-driven tool helps IT professionals design, review, and provision Azure workloads by conversing in natural language, grounding plans in the Well-Architected Framework, and generating production-ready infrastructure code. It enables consistent, efficient deployments, supports both Terraform and Bicep, integrates with Copilot and popular IDEs, and is open-source for customization. Currently focused on new workloads, the agent aims to simplify cloud architecture and standardize operations, with ongoing improvements for existing estates.

Deploy an Azure Landing Zone in About Twelve Minutes with the ALZ IaC Accelerator

Team Blog: ITOps Talk

Author: Pierre_Roman

Published: 06/24/2026

Summary: The article highlights the Azure Landing Zone (ALZ) Infrastructure as Code Accelerator, showcased at the Microsoft Azure Infra Summit 2026. The ALZ Accelerator drastically reduces deployment time for secure, governed Azure platforms from weeks to about twelve minutes using Bicep or Terraform modules. It automates setup, supports multiple scenarios and options, aligns with the Well-Architected Framework, and is open source. The accelerator enables rapid, production-grade deployments, saving IT pros from manual configurations, and supports both GitHub and Azure DevOps pipelines, making cloud adoption faster and easier.

Announcing the Path to Production for Agents Webinar Series

Team Blog: Azure Architecture

Author: brauerblogs

Published: 06/09/2026

Summary: The Path to Production for Agents Webinar Series, held July 27-28, helps organizations transition AI projects from prototypes to secure, scalable, production-ready systems. Sessions cover governance frameworks, production architecture, multi-agent design, operational best practices, security, observability, and optimization techniques. Attendees will learn practical, actionable patterns for deploying and managing AI agents at enterprise scale, with real-world examples and reference architectures. The series targets architects, engineers, and technical leaders seeking to operationalize AI, and offers follow-up engagements for Microsoft customers to implement these practices. Registration is available online.

Revolutionizing Document Intelligence: Scaling Construction Industries with AI-Driven Extraction

Team Blog: Azure Architecture

Author: gauravbhardwaj

Published: 06/18/2026

Summary: The article explores how Generative AI and Azure AI services are revolutionizing document extraction in the construction industry, addressing challenges like low productivity and high costs. By automating the analysis of design documents, AI increases accuracy, reduces manual labor, and improves coordination. The proposed hybrid architecture combines deterministic extraction with generative gap-filling for scalable, auditable workflows, resulting in cost savings, reduced errors, and faster project delivery. The solution emphasizes robust security and adaptability, offering a blueprint for AI-driven document intelligence across multiple sectors, including insurance, legal, healthcare, and finance.

Azure Availability Zone Mapping and VM Resilience Analysis Guidance using SRE.AZURE.COM Agent

Team Blog: FastTrack for Azure

Author: munieswar_avulapalli

Published: 06/08/2026

Summary: The article explains how SRE.Azure.com helps Azure engineers analyze Availability Zone mappings and VM resilience. Logical zone numbers (1, 2, 3) do not directly map to physical datacenter zones across subscriptions, impacting high availability and disaster recovery planning. The SRE agent enables discovery of zone mappings, VM distribution, resilience gaps, and generates reports. Understanding these mappings is essential for ensuring workload separation and compliance. The guidance includes suggested prompts for generating analysis and emphasizes that physical separation cannot be assumed based solely on logical zone numbers.

Azure Virtual Desktop supports greater application and identity functionality with latest updates

Team Blog: Azure Virtual Desktop

Author: Christian_Montoya

Published: 06/02/2026

Summary: Microsoft has announced new Azure Virtual Desktop updates, including general availability of FSLogix user profile management and Azure Role-based Access Control (RBAC) for external identities. SAML IdP can now be configured as domainless (public preview), easing integration for developers. External identity support is expanded to Android and macOS platforms in Azure public cloud and is generally available for US Government cloud. These enhancements streamline access for users outside organizations without needing new accounts and improve application and identity functionality. More technical details and resources are available on Microsoft’s Learn and Community pages.

A deep dive into Azure Bastion session recording

Team Blog: Azure Network Security

Author: juquint

Published: 06/11/2026

Summary: Azure Bastion Premium’s session recording feature captures RDP and SSH sessions for improved security, compliance, and forensic analysis. Recordings are stored in Azure Storage accounts, authenticated via either SAS URL or Managed Identity. While SAS URLs require manual token management and pose security risks, Managed Identity offers automated, secure authentication with no credentials to rotate, better RBAC integration, and improved compliance. The article details setup steps for both options and recommends Managed Identity for enterprise environments due to its simplicity and robust security. Session recordings are easily accessed within the Bastion resource’s Session recordings blade.

Designing Cloud Landing Zones by Traffic Flow: A Defence‑in‑Depth, DMZ‑First Architecture

Team Blog: Azure Network Security

Author: AvanishYadav

Published: 06/03/2026

Summary: The article advocates for a security-driven, DMZ-first cloud landing zone architecture in Microsoft Azure, emphasizing defense-in-depth and clear trust boundaries for traffic flows. It recommends multi-hub designs to separate Internet-facing (DMZ) and internal (Core) traffic inspection, improving security, scalability, and operational clarity. Scenarios using third-party firewalls, Azure Firewall, and Azure Virtual WAN illustrate approaches for inbound, outbound, East-West, and hybrid connectivity. The distributed hub-and-DMZ model reduces complexity, supports regulatory compliance, and enhances resiliency, making it essential for large, regulated, and multi-region enterprise workloads.

Kubernetes Center: Security & LTS/Out-of-Support Version Insights Now Available

Team Blog: Azure Infrastructure

Author: Harsha_Nair

Published: 06/01/2026

Summary: Kubernetes Center now offers enhanced security and cluster version support insights in the Azure portal. The new Security page provides an overview of vulnerabilities, runtime alerts, misconfigurations, and regulatory compliance, with actionable recommendations, requiring Microsoft Defender for Containers. The Cluster Version Support Status panel displays Kubernetes version support across clusters, highlighting those expiring soon, out-of-support, or eligible for Long Term Support (LTS), and enables easy remediation. These features help platform teams monitor security posture, prevent version drift, address misconfigurations, and report compliance efficiently across all AKS clusters.

Ginkgo Bioworks and Microsoft Discovery: Bringing agentic AI to biological discovery

Team Blog: Azure Infrastructure

Author: NihitPokhrel

Published: 06/09/2026

Summary: Microsoft and Ginkgo Bioworks are collaborating to integrate Microsoft Discovery’s agentic AI platform with Ginkgo’s autonomous lab infrastructure, enabling researchers to design, execute, and analyze biological experiments seamlessly. This integration supports iterative, Design–Make–Test–Analyze workflows, streamlining experiment planning, execution, and data analysis. The partnership aims to accelerate biological discovery by increasing speed, scale, transparency, and reproducibility, reducing manual effort and connecting AI-driven reasoning directly to real-world lab validation. The approach is extensible, supporting broader scientific and engineering research needs.

New ways to learn and demonstrate skills

Team Blog: Microsoft Learn

Author: CameronPercy

Published: 06/02/2026

Summary: Microsoft announced new ways for developers to learn and demonstrate skills, including Microsoft Pro Badges—credentials that recognize real-world proficiency without separate tests, assessed via Verified Proficiency telemetry. Pro Badges launch in June 2026, starting with GitHub Copilot. Microsoft Applied Skills lab assessments will soon award Pro Badges. New co-authored AI skilling paths, beginning with Anthropic, are available in AI Skills Navigator. The Microsoft AI Skills Fest (June 8–12, 2026) offers practical sessions, a hackathon, and opportunities to earn certification vouchers, all aimed at advancing developers’ real-world capabilities.

Deep-reasoning agents for academic research: The right tool for the task

Team Blog: Microsoft Learn

Author: DarcyOgden

Published: 06/23/2026

Summary: The article discusses how deep-reasoning agents, like Researcher and Analyst in Microsoft 365 Copilot, enhance academic research by supporting source comparison, assumption testing, and data analysis. It compares these specialized tools to general-purpose AI, highlighting their alignment with academic standards. The Academic Researcher’s Guide to Deep-Reasoning Agents offers practical advice for selecting and using these tools effectively, managing limitations, and improving outputs. Researchers are encouraged to treat these AI agents as supportive tools, document their processes, and critically evaluate results to ensure rigorous research practices.

Public preview: Automatic OS Image Upgrades for VMSS Flex

Team Blog: Azure Compute

Author: BMahboob

Published: 06/01/2026

Summary: Azure has launched a public preview of Automatic OS Image Upgrades for Virtual Machine Scale Sets (VMSS) using Flexible Orchestration Mode. This feature streamlines OS updates across VMSS fleets, enhancing security, performance, and compliance while reducing manual effort and operational complexity. It provides consistent, fleet-wide orchestration with health-based safety measures. To use it, prerequisites include registering the feature, installing health extensions, and enabling the upgrade policy. Azure is now expanding onboarding and validating the experience across more workloads. Feedback is encouraged during the preview.

Announcing Preview of Guest RDMA for Azure Boost

Team Blog: Azure Compute

Author: MengxiWu

Published: 06/02/2026

Summary: Microsoft has launched a preview of Guest RDMA in Azure’s UK South region, enabling high-throughput, ultra-low latency networking within guest virtual machines via Azure Boost. This allows VMs to bypass the traditional networking stack, reducing CPU usage and improving performance for AI, storage, database, and HPC workloads. Guest RDMA supports various VM series and Linux distributions, but is currently limited to direct VM-to-VM connections within a VNET. Broader network scenarios will be supported at general availability. Interested users can sign up for the preview and provide feedback to Microsoft.

Right‑sizing Azure Savings Plans, one hour at a time

Team Blog: FinOps

Author: Dirk_Brinkmann

Published: 06/11/2026

Summary: The article explains how FinOps teams can use Azure's Benefit Recommendations API and a companion PowerShell script to extract hourly Pay-As-You-Go (PAYG) usage and alternative Savings Plan commitment levels. This approach enables more accurate, data-driven decisions instead of relying on a single recommended figure. The script produces analyst-friendly outputs for deeper analysis, allowing teams to visualize demand patterns, optimize savings, and minimize wastage. Full documentation and code are available on GitHub, encouraging users to improve their Azure savings strategies with transparent, defensible data.

Introducing GitHub Pre-Purchase Plans: A Simpler Way to Plan Your GitHub Spend

Team Blog: FinOps

Author: kyleikeda

Published: 06/17/2026

Summary: GitHub Pre-Purchase Plans offer organizations a way to simplify and save on GitHub spending by committing upfront to a prepaid amount, which can be used across eligible services over 12 months. Larger commitments unlock higher discounts, up to 15%. This approach enables predictable budgeting for variable, usage-based costs like Copilot and AI Credits, and aligns GitHub billing with Azure subscriptions. Two plan types are available via Azure Reservations, providing flexibility for platform-wide or AI-specific usage. Pre-Purchase Plans do not replace existing purchasing methods but offer an additional budgeting option for commercial customers.

Automating Daily MDE Compliance Monitoring Across Azure VMs

Team Blog: Core Infrastructure and Security

Author: SayanRoy

Published: 06/15/2026

Summary: The article details a Logic App solution for automating daily Microsoft Defender for Endpoint (MDE) compliance checks across Azure VMs. It addresses gaps where VMs may silently lose MDE coverage and provides automated owner notifications, daily IT summary reports with CSV attachments, and explicit handling of VMs lacking owner tags. The workflow queries all running Azure VMs, matches them to MDE device records, and sends compliance alerts. It requires a Logic App, managed identity, specific API permissions, and proper tagging. The approach streamlines compliance monitoring, reduces manual effort, and ensures prompt visibility of security gaps.

Security Copilot RBAC for Embedded Experience in Unified Security Platform

Team Blog: Core Infrastructure and Security

Author: SantoshPargi

Published: 06/17/2026

Summary: The article explains how Microsoft Security Copilot integrates AI-powered assistance directly within security platforms like Defender XDR and Sentinel, streamlining SOC operations. It details a three-layer Role-Based Access Control (RBAC) model—Security Copilot, Microsoft Entra, and service-specific roles—to ensure secure, least-privilege access. Copilot uses an On-Behalf-Of model, limiting data access to user permissions. Key use cases include summarization, guided response, script analysis, and reporting, all mapped to SOC processes. Proper RBAC alignment enables Copilot to accelerate investigations, enhance accuracy, and strengthen security while maintaining compliance and governance.

Simpler, scalable file share management in Azure - now generally available

Team Blog: Azure Storage

Author: VincentLiu

Published: 06/02/2026

Summary: Microsoft Azure has announced the general availability of a new, simplified file share management experience for premium SSD NFS file shares. This update enables independent provisioning, security, and billing for each file share, aligning management boundaries to workload needs. Key benefits include faster provisioning, enhanced scalability (up to 10,000 shares per region), share-level security and networking, improved cost tracking, and robust data protection with snapshots. The new experience supports Infrastructure-as-Code automation and is designed to reduce complexity, improve operational agility, and facilitate easier chargeback and resource management for Linux workloads in Azure.

From File Data to AI‑Powered Knowledge Pipelines using Azure NetApp Files object REST API

Team Blog: Azure Storage

Author: GeertVanTeylingen

Published: 06/15/2026

Summary: The article explains how Azure NetApp Files, OneLake, Azure AI Search, and Azure OpenAI combine to create an AI-powered knowledge pipeline for enterprise file data. This pipeline indexes and semantically searches files in place, enabling retrieval-augmented generation (RAG) for accurate, traceable, and grounded AI responses without moving or duplicating data. The architecture ensures compliance, scalability, and seamless integration with existing workflows, transforming file data into a living, queryable resource. It prepares enterprises for AI-driven user experiences, like Copilot, by delivering controlled, authoritative answers with source citations.

Three lessons that make or break your AWS-to-Azure workload migration

Team Blog: Azure Migration and Modernization

Author: rhack

Published: 06/19/2026

Summary: The article highlights three crucial lessons for successful AWS-to-Azure workload migration: (1) Ensure ongoing stakeholder alignment through readiness assessments and clear approvals; (2) migrate workloads like-for-like before optimizing to avoid complexity and build confidence; and (3) use a blue-green cutover strategy to minimize risk and downtime, enabling easy rollback. Avoid common pitfalls like overengineering, misaligned stakeholders, and believing in instant cutovers. The article recommends Microsoft’s structured migration process and resources for further guidance.

Generate at scale code insights in Azure Migrate using GitHub Copilot Modernize CLI (preview)

Team Blog: Azure Migration and Modernization

Author: Nikita_Bajaj

Published: 06/19/2026

Summary: Azure Migrate now integrates with GitHub Copilot Modernize CLI (preview) to provide scalable code insights for .NET and Java web apps. This collaboration enables migration teams to assess multiple applications simultaneously, reduce analysis time, and make informed refactor-versus-replatform decisions. Users receive actionable code-fix recommendations and effort estimates, improving modernization planning and adherence to security guidelines. Setup involves downloading a configuration file from Azure Migrate, mapping repositories, and running the CLI. Code assessments are automatically reported back to Azure Migrate for centralized review and remediation guidance.

DoH is now generally available on Windows DNS Server

Team Blog: Networking

Author: JorgeCañas

Published: 06/11/2026

Summary: Microsoft has announced general availability of DNS over HTTPS (DoH) for Windows DNS Server on Windows Server 2025, enabling encrypted and authenticated DNS client-to-server traffic. This feature enhances privacy, reduces spoofing risks, and supports Zero Trust architectures without requiring new resolver infrastructure. Organizations can deploy DoH alongside traditional DNS, preserving compatibility and allowing incremental adoption. Built on IETF standards, DoH helps meet regulatory requirements and strengthens DNS security. Future updates will support encrypted server-to-resolver traffic, advancing fully secure DNS resolution. The release is production-ready, reflecting feedback from real-world enterprise deployments.

Announcing Windows CLAT Public Preview

Team Blog: Networking

Author: JimAlumbaugh

Published: 06/09/2026

Summary: Microsoft has announced the public preview of Windows CLAT, a feature designed to aid IPv6 adoption by enabling IPv4/IPv6 translation. Available in Windows Insider Canary build #29599-1000 and rolling out to other channels, it now supports Group Policy Object (GPO) configuration. The preview is for evaluation only, not production use, and feedback is encouraged. Notable limitations include lack of support for DHCPv6 Prefix Delegation and Windows Subsystem for Linux, with known issues in Wi-Fi roaming and diagnostics. Participant feedback from the private preview has shaped this release.

ARM MCP Server: A Catalog of 24 PoCs

Team Blog: Azure Governance and Management

Author: varghesejoji

Published: 06/19/2026

Summary: The article introduces the Azure Resource Manager MCP Server, a remote Model Context Protocol server enabling AI agents to perform Azure infrastructure operations using six core tools. It details the arm-mcp-poc-catalog, a public repository of 24 proof-of-concept agents covering governance, FinOps, platform engineering, and SRE scenarios. The catalog emphasizes deterministic, safe agent operations, with most PoCs focused on read-only tasks. Write-capable agents are carefully gated. The Reliability Posture Scorecard is highlighted as a reference implementation. The article encourages teams to explore and adapt these PoCs for practical cloud management needs.

When Arc Goes Silent: Turning Visibility Gaps into SOC Action

absharan — Fri, 10 Jul 2026 12:07:15 GMT

Hybrid blind spots rarely announce themselves. They appear when an Azure Arc-enabled server drops out, health signals go stale, and the SOC loses confidence in monitoring coverage. This playbook uses Microsoft Sentinel and Logic Apps to turn that noise into one clear daily signal the team can act on.

The problem: too much noise, not enough assurance

One unhealthy server, one alert, one more email—at scale, that does not help the SOC. What leaders need is assurance: where visibility is weakening, which systems matter, and when action is needed.

The use case: daily assurance for hybrid monitoring coverage

The use case is simple: identify Arc-enabled servers that stay unhealthy beyond a set threshold, such as 30 minutes, and send one consolidated summary each day. For a CISO, this improves assurance. For a SOC Manager, it cuts noise and helps teams prioritize faster.

Solution overview: simple automation, stronger operational signal

The workflow runs on a schedule, queries Log Analytics, filters Arc health issues, formats the results into a clean HTML report, and sends a single email through Office 365 Outlook. The outcome is not more telemetry—it is a better operational signal.

Prerequisites

One or more Azure Arc-enabled servers connected to Azure.
Azure Monitor Agent installed and sending heartbeat data to a Log Analytics workspace.
Microsoft Sentinel enabled on the target workspace if the playbook is being used as part of SOC operations.
A Logic App with permissions to run the query and send email through Office 365 Outlook.
A reviewed threshold, recipient list, and notification cadence aligned to your operating model.

How the workflow creates decision-ready visibility

In practice, this becomes a daily control: check Arc health, isolate persistent issues, and route one concise summary to the right teams. That gives the SOC a cleaner way to review monitoring gaps before they become bigger operational problems.

Why this matters to a CISO and SOC Manager

For security leadership, this is about confidence. If Arc health degrades on systems tied to monitoring, policy, or data collection, the risk is not just technical—it is a visibility gap. This playbook helps surface that gap early and in a form teams can act on quickly.

Three practical scenarios where this playbook delivers value

Reduce SOC noise.Replace scattered alerts with one daily summary.
Strengthen executive assurance.Highlight persistent blind spots before they turn into escalations.
Improve team coordination.Give security and infrastructure teams one shared view of the issue.

Sample KQL to identify persistent Arc monitoring gaps

This sample query uses the Heartbeat table to identify Azure Arc-connected machines whose latest heartbeat is older than the defined threshold. It is a practical starting point and can be tuned further based on the environment and data collection design.

let ThresholdTime = 30; AzureActivity | where TimeGenerated > ago(1d) | where CategoryValue == "ResourceHealth" | where parse_json(Properties).currentHealthStatus == "Unavailable" | where ActivityStatusValue == "Active" | extend ResourceType = Properties_d.resourceProviderValue | where ResourceType == "MICROSOFT.HYBRIDCOMPUTE" | extend StartTime = TimeGenerated | extend ServerName = Properties_d.resource | join kind=leftouter ( AzureActivity | where ActivityStatusValue == "Resolved" | extend ResourceType = Properties_d.resourceProviderValue | where ResourceType == "MICROSOFT.HYBRIDCOMPUTE" | extend EndTime = TimeGenerated ) on CorrelationId | extend Minutes_OfflineTillResolve = datetime_diff('minute', EndTime, StartTime) | project ServerName, StartTime, EndTime, CorrelationId, Minutes_OfflineTillResolve, Level, ActivityStatusValue1, ResourceGroup, OperationNameValue, SubscriptionId, ResourceProvider, Type, CategoryValue, ActivityStatusValue | extend TotalMinutes_Offline = datetime_diff('minute', now(), StartTime) | where TotalMinutes_Offline >= ThresholdTime and ActivityStatusValue1 !has "Resolved" | order by TotalMinutes_Offline desc

Operational flow

ARM Template: microsoft-security-operations-toolkit/Microsoft Sentinel/Automation/Playbooks/AzureArcServerMonitoring.playbook.json at 1e3aeff329e0d9b1d7caf2e4bfbc8476dfdb2ff2 · Abhishek-Sharan/microsoft-security-operations-toolkit

Customization Ideas:

Adjust the heartbeat threshold based on server criticality or business hours.
Route summaries to different teams based on subscription, resource group, or server tags.
Send notifications to Microsoft Teams in addition to, or instead of, email.
Enrich the output with owner, business service, or environment metadata.
Trigger incident creation only for high-priority or repeated visibility gaps.

Closing perspective

The best SOC automations do not just collect signals—they create clarity. This playbook helps security teams spot Arc-related monitoring gaps early, reduce noise, and act with more confidence.

Azure Database Security Newsletter - July 2026

PieterVanhove — Tue, 07 Jul 2026 11:47:08 GMT

AI agents are changing how applications interact with data, and database security needs to evolve with them. In this July 2026 edition of the Azure Database Platform Security Newsletter, we focus on what this shift means for identity, access, monitoring, and data protection, along with the latest security feature updates and practical resources to help teams strengthen their database security posture.

AI agents are quickly becoming a new layer in how applications interact with data. Unlike traditional applications that follow predictable workflows, agents operate with more autonomy. They can generate queries dynamically, explore data, and act on behalf of users or systems.

This shift changes the database security model.

Agents do not just introduce new risks, they amplify existing ones. Over-privileged access can scale quickly, identity boundaries can become harder to trace, and dynamically generated queries can increase the risk of unintended data exposure or manipulation.

In this new reality, every AI agent effectively becomes a database user with the ability to access, reason over, and act on sensitive data.

Securing data in an agentic world requires a shift in mindset:

Identity-first security: every agent should have a unique, traceable identity.
Least privilege by default: access should be tightly scoped to the task at hand.
Data-aware protection: only the data that is strictly required should be exposed.
Continuous monitoring: assume issues can occur and detect them early.

Azure SQL provides a broad set of security capabilities, from authentication and fine-grained access control to encryption, masking, auditing, and threat detection. Together, these capabilities enable a defense-in-depth approach for agent-driven scenarios.

Feature highlights 💡

Transparent Data Encryption in Azure SQL Database now supports AES keys (Preview)

Azure SQL Database now supports symmetric AES keys for Transparent Data Encryption (TDE) with customer-managed keys in public preview. This gives organizations another option for protecting data at rest while keeping control of key management.

For teams thinking about long-term cryptographic resilience, this preview is especially relevant. TDE with customer-managed keys has traditionally used asymmetric RSA-based key protectors, while broader industry guidance is increasingly focused on preparing for a post-quantum cryptographic future and adopting cryptographic approaches that are better aligned with that transition.

This update aligns with broader security guidance, including the NSA’s CNSA 2.0 recommendations, which emphasize modern cryptographic planning for a quantum-resistant future. For organizations building crypto agility into their platforms, AES support is a practical step in that direction.

Learn more: Transparent data encryption in Azure SQL Database now supports AES keys (Public Preview)

General Availability: Microsoft Entra server principals for Azure SQL Database

Azure SQL Database has historically lacked support for server-level Microsoft Entra principals, requiring customers to manage identities separately in each database. This has been a migration blocker for enterprise customers coming from SQL Server, where centralized login and access management is standard.

With this release, Azure SQL Database now supports server-level Microsoft Entra principals. Customers can create identities once, apply them consistently across databases, and operate with a unified, enterprise-grade identity and access model aligned with SQL Server and Azure SQL Managed Instance.

Learn more: Generally Available: Microsoft Entra Server Principals and Server Roles for Azure SQL Database.

Cross-tenant customer-managed keys for Azure Database for PostgreSQL Flexible Server (Preview)

This preview allows customers to encrypt data at rest using an Azure Key Vault key that resides in a different Microsoft Entra tenant than the database service. It is especially relevant for ISVs and customers in regulated industries that need clear separation of duties between key ownership and service operation.

Customers retain control over key lifecycle management, including rotation and revocation, while authentication to the customer-owned Key Vault is handled through federated identity with Microsoft Entra ID for cross-tenant access.

Learn more: Data Encryption - Azure Database for PostgreSQL | Microsoft Learn

Defender security posture assessments for Azure Database for PostgreSQL Flexible Server (GA)

Microsoft Defender Cloud Security Posture Management (CSPM) assessments for Azure Database for PostgreSQL Flexible Server are now available in general availability. This capability introduces built-in security assessments that continuously evaluate PostgreSQL server configurations against best practices, helping identify vulnerabilities and misconfigurations with actionable remediation guidance. A core set of assessments is available at launch, with additional coverage planned for future releases. Assessments are automatically available for PostgreSQL servers where Microsoft Defender for Cloud is already enabled, requiring no additional setup or costs.

Learn more: Microsoft Defender for Cloud - Azure Database for PostgreSQL | Microsoft Learn

Best Practices Corner ⚖️

Move to secure-by-default configurations

Modern data platforms should reduce the need for manual hardening by enabling strong defaults out of the box.

Enforce encrypted connections by default.
Disable insecure or legacy options where possible.
Adopt platform defaults that align with compliance standards.

This shifts security from being configuration-driven to posture-driven, reducing the risk of misconfiguration, which remains one of the leading causes of data exposure.

Classify data first, protect it second

You cannot secure what you do not understand. Start by identifying where sensitive data lives, then use that understanding to apply the right protections.

Use Data Discovery & Classification to identify sensitive data.
Apply labels and information types consistently.
Use those labels to drive masking, encryption, and governance policies.

Why this matters: Security controls are only effective when they are data-aware. Classification provides the foundation for applying the right protection to the right data, especially for regulated workloads.

Continuously assess and remediate vulnerabilities

Security posture is not static. It requires continuous validation and timely remediation.

Run Vulnerability Assessment scans regularly.
Track deviations from baseline security policies.
Act on remediation guidance proactively.

Why this matters: Even well-configured systems drift over time. Continuous assessment helps detect misconfigurations early and maintain a strong, compliant security posture without relying on manual reviews.

Blogs and Video Spotlight 🅱️

Over the last three months, we published several posts covering major releases, platform updates, and practical security guidance. These resources provide deeper technical context and implementation guidance for teams working across Azure SQL, Azure Database for PostgreSQL, Azure Database for MySQL, and Azure Cosmos DB.

Azure SQL Retiring The No Minimum TLS Option

Dynamic Data Masking – What it is, What it isn’t, and How to use it effectively | Microsoft Community Hub

TLS Certificate Pinning in PostgreSQL and MySQL: Risks, Rotations, and Best Practices

I'm Starting a New Cosmos DB App. What Security Do I Actually Need? - Azure Cosmos DB Blog

Transparent data encryption in Azure SQL Database now supports AES keys (Public Preview) | Microsoft Community Hub

Which Azure Cosmos DB Role Does My App Need? - Azure Cosmos DB Blog

Generally Available: Microsoft Entra Server Principals and Server Roles for Azure SQL Database | Microsoft Community Hub

Community & Events 👥

The data platform security team will be present at several community and industry events. If you are attending, come and say hello.

Where to meet us next

Microsoft Fabric and SQL Conference, Barcelona, 28 September to 01 October 2026

dataMinds Connect, Mechelen, 12 to 14 October 2026

Techorama, Utrecht, 26 to 28 October 2026

Recent community highlights

SQLBits, Wales, 22 to 25 April 2026

Azure SQL Bangalore User Group Meeting, Bangalore, 13 June

Call to action 📢

As AI agents become a more active layer between applications, users, and data, now is the right time to review how they access your database platform. Treat every agent as a database user: confirm that each one has a unique identity, validate that permissions follow least privilege, and monitor agent-driven activity for unusual access patterns. A focused access review today can help reduce the risk of unintended data exposure as agentic workloads continue to grow.

Turning Azure Policy Signals into Actionable Governance Insights

absharan — Mon, 06 Jul 2026 12:40:50 GMT

Most Azure Policy reporting stops at compliance status. Useful, yes — but not enough. When a control fails, teams need to know what failed, why it matters, and who should act.

That gap becomes obvious at enterprise scale. A failed policy evaluation is only a signal. By itself, it does not tell you whether the issue affects recovery, auditability, telemetry, or another control leaders care about.

That is why joining PolicyStates with PolicyAssignments matters. One tells you the outcome. The other tells you which control was applied, where, and in what governance context. Together, they turn Azure Policy from a compliance feed into a control intelligence layer.

The problem: PolicyStates alone tells you what is non-compliant, but not always why it matters

Microsoft’s sample ARG queries quickly show which resources are non-compliant. Helpful, but still incomplete. They show the result, not the business meaning.

At enterprise scale, that distinction matters. A storage account without blob soft delete is a recovery risk. Missing Azure Activity logs creates an audit gap. A virtual machine without Azure Monitor Agent creates a telemetry blind spot. Azure Policy shows the state. The join to PolicyAssignments explains why it matters.

There is also a technical reason to care about assignments. The same PolicyDefinitionId can appear in multiple assignments across different scopes. That makes PolicyAssignmentId the operational key.

How Azure Policy compliance data flows

Azure Policy evaluates resources against JSON-based rules. Those rules are packaged as policy definitions and can be grouped into initiatives. Once assigned to a scope, the policy engine evaluates matching resources during creation, updates, assignment changes, and regular compliance cycles. The results are exposed through PolicyStates and PolicyEvents, and can also be queried through Azure Resource Graph.

This is the architecture flow for turning the ARG query into a scheduled governance report through Logic App:

The key shift is operational. A Logic App can run the ARG query on a schedule, format the results, and email them to stakeholders. That turns a manual check into a repeatable governance report.

The analytical pattern: enrich compliance with assignment context

The analytical flow is straightforward:

Configure a Recurrence trigger in Logic App so the report runs on the schedule you need.
Use an HTTP action with managed identity to run the ARG query against PolicyStates and join it to PolicyAssignments.
Filter on the control assignments that matter to your organisation and shape the response into a compact HTML table or CSV.
Send the output by email to governance, engineering, or audit stakeholders so the insight reaches people without requiring them to open the portal.

In practice, the query starts with non-compliant resources and enriches them with assignment details such as the assignment name and optional metadata like owner. That is the shift from raw signal to governance insight.

A simple implementation pattern is: schedule the Logic App, run the ARG query with managed identity, format the output, and send the report. HTML works well for leadership emails; CSV is better for downstream analysis.

ARM template for the Logic App

If you want to deploy this pattern instead of building it step by step, I have also published an ARM template for the Logic App in my GitHub repository. The template is intended to help you stand up the scheduled policy compliance workflow faster and then customise the query, email recipients, and formatting for your own environment.

This makes the architecture in this post directly reusable: schedule the Logic App, run the ARG query, shape the output, and send a control-focused report without having to assemble the workflow from scratch. See the repository for the template and related Microsoft Sentinel automation content.

Reference ARG query

policyResources | where type =~ 'microsoft.policyinsights/policystates' | where properties.complianceState == 'NonCompliant' | extend ResourceId = tostring(properties.resourceId), PolicyAssignmentId = tolower(trim(@" ", tostring(properties.policyAssignmentId))), SubscriptionId = tostring(subscriptionId), LastEvaluated = todatetime(properties.timestamp) | extend ResourceName = tostring(extract(@"[^/]+$", 0, ResourceId)) | extend ResourceProvider = tostring(extract(@"providers/([^/]+)/", 1, ResourceId)) | extend ResourceCategory = case( ResourceId has "Microsoft.Compute/virtualMachines", "VM", ResourceId has "Microsoft.Storage/storageAccounts", "Storage", ResourceId has "Microsoft.Network/virtualNetworks", "Network", ResourceId has "Microsoft.Sql/servers", "SQL", ResourceId has "Microsoft.KeyVault/vaults", "Key Vault", ResourceProvider =~ "Microsoft.Compute", "Compute", ResourceProvider =~ "Microsoft.Storage", "Storage", ResourceProvider =~ "Microsoft.Network", "Network", ResourceProvider =~ "Microsoft.KeyVault", "Key Vault", "Other" ) | project ResourceId, ResourceName, ResourceCategory, SubscriptionId, PolicyAssignmentId, LastEvaluated | join kind=inner ( policyResources | where type =~ 'microsoft.authorization/policyassignments' | extend AssignmentName = tostring(properties.displayName), AssignmentId = tolower(trim(@" ", tostring(id))), Scope = tostring(properties.scope), PolicyOwner = tostring(properties.metadata.owner) | where AssignmentName has "CSTM--Configure blob soft delete on a storage account" or AssignmentName has "Configure Azure Activity logs to stream to specified Log Analytics workspace" or AssignmentName has "Audit diagnostic setting for selected resource types" | project AssignmentId, AssignmentName, Scope, PolicyOwner ) on $left.PolicyAssignmentId == $right.AssignmentId | project SubscriptionId, ResourceId, ResourceName, ResourceCategory, AssignmentName, AssignmentId, Scope, ['LastEvaluated[UTC]'] = LastEvaluated

What this query is doing — in plain English

This query finds Azure resources that are currently NonCompliant with Azure Policies by reading data from the PolicyStates table in Azure Resource Graph.
It extracts useful details such as Resource ID, Resource Name, Resource Type/Category, Subscription ID, Policy Assignment ID, and the last evaluation timestamp.
Resources are categorized into groups like VM, Storage, Network, SQL, and Key Vault based on their resource type/provider.
It then joins the non-compliant resources with specific policy assignments (three named policies) to show which policy caused the non-compliance, along with the policy scope, and evaluation time.

Why CISOs and governance leaders should care

For a CISO, this is not about counting failed evaluations. It is about knowing whether critical controls are drifting, where the risk sits, and who owns the response.

Three use cases stand out:

Audit readiness: show control-focused evidence instead of a flat list of resource IDs.
Ownership: enrich assignments with metadata so findings can be routed to the right team faster.
Prioritization: focus on the controls that matter now, not every non-compliant resource in the estate.

Operational benefits: scalable, repeatable, and security-friendly

From an engineering perspective, this pattern is attractive because it is repeatable, scalable, and aligned to the native Azure Policy data model.

It also fits naturally into operational tooling. The enriched output can feed workbooks, dashboards, Sentinel content, and alerting workflows.

Closing thought

At small scale, Azure Policy can be reviewed in the portal. At enterprise scale, that quickly becomes noise. The better question is not Which resources are non-compliant? It is Which important controls are failing, where, and who should act?

That is what makes this pattern powerful: it turns Azure Policy from a compliance dashboard into a control intelligence layer that works for both engineers and executives.

Windows 365 Boot

MichaelHildebrand — Sat, 04 Jul 2026 17:01:23 GMT

Hi folks – Mike Hildebrand here! It’s the July 4^th holiday here in the good 'ol USA and happens to also be our country’s 250^th birthday … and where I live, that means it’s probably hot. VERY hot. So, I’m taking some time to enjoy the A/C and type up a ‘cool’ post about a ‘cool’ solution.

In the land of Windows 365, there are a couple of physical endpoint connectivity options – the Windows App or browser from any device and thin-client or other purpose-built devices, like our own Link (and one soon coming from Asus).

We also have another option called Windows 365 Boot. In this nifty little situation, we take a full-throated Windows 11 device and apply policy from Intune to transform the shell and other settings into a Link-like experience.

NOTE: For a long time, the Boot configuration process was only configurable via a ‘black-box’ guided flow in the Intune portal – and that works just fine. However, after an update of docs and the Intune Settings Catalog, the W365 Boot configurations can now be hand-carved like all of your other Intune configuration policies.

Recently, I was part of a customer conversation where they had a substantial quantity of Flex Dedicated CPCs used by rotating call center staff and accessed from a fleet of Windows 11 PCs deployed at hot-desk stations. They wondered about a model to simplify and streamline access directly to the CPCs, bypassing the local Windows OS, which wasn’t used/needed and sometimes caused confusion.

The physical devices were still ‘current’ and had a lot of life left (i.e. warranty coverage, driver and firmware support, parts availability, etc.) - and due to the price-jumps of new devices, it made ‘dollars and sense’ ( 🙂 ) to leverage that investment and re-purpose them.

They also wondered if they could use Autopilot in ‘Self-deploy’ mode to further automate the deployment process for these endpoints.

“Let’s try it out”

I proposed a rapid, off-the-cuff ‘right now’ PoC to try out the W365 Boot scenario in their environment and they were up for it. These days, it’s common and easy to perform carefully controlled ‘production pilots’ to more accurately validate the proposed experience.

NOTE: Since the customer already had Entra, Intune, and modern management in steady-state operations for quite some time, we were able to make this idea very real, very fast.

We reset a few of the test PCs they use for their hot-desks and uploaded them into Autopilot via the Get-WindowsAutopilotInfo PowerShell script and the -online switch.

Entra – Create a Device Group

We created a device group in Entra for the PoC Boot devices and added the Autopilot-uploaded test devices into it as members

This group was used by Intune to target several different elements of the PoC:

o An Autopilot Self-deployment Profile - for an almost zero-touch rollout

o An Enrollment Status Page (ESP) profile - to prevent access to the Boot device until the Windows App is installed

o The Windows App – used by the Boot device to connect to Cloud PCs

o A W365 Boot Configuration Profile to transform the Windows 11 OS into a W365 Boot device

Intune - Autopilot Self-deploy Profile

We created an Autopilot ‘self-deployment’ profile via Intune, to automatically enroll the physical endpoints at the call center desks.

Autopilot self-deploy requires very little interaction at the endpoint - plug in power, connect to network and turn it on.

o There are some specific URLs and other requirements for Autopilot Self-deploy devices so be sure to check this (i.e. you can’t use Hyper-V VMs)

https://learn.microsoft.com/en-us/autopilot/self-deploying

Intune – Enrollment Status Page

We created an ESP targeted at the device group to block access to the Boot devices until the Windows App is installed.

Intune – Windows App

They already deploy the Windows App to ‘All Devices,’ so this step was easy 😊

The key thing here is make sure it installs in the ‘System’ context:

Intune - Boot Device Configuration Policy

We created a very simple Configuration Policy (two settings from the Settings Catalog – that’s it) in Intune to transform these self-deployed endpoints into “Shared PC Mode” Windows 365 Boot devices. These have minimal ‘end user’ configurations/apps because they boot to the W365 purpose-specific ‘cloud shell’ – which allows the user to sign in to the Boot device and be directly SSO’d into their CPC.

NOTE: The ‘Boot to Cloud PC Enhanced’ setting includes many other settings/behaviors but they’re all bundled up which makes it super easy to deploy this
NOTE: If the ‘Personalization > Company Name’ setting isn’t used, you’ll see ‘Cloud PC’ at the sign in screen

Self-deploy…oh the joy!

Plug it in; turn it on … Autopilot Self-deploy OOBE screen, followed by a brief ESP

NOTE: As part of the Autopilot deployment profile, a device naming template was applied and the devices were renamed; this was reflected in various portals/UIs

Before:

After:

“So, what does it look like for the users?”

I thought you’d never ask! A PIN, a touch and TA DA!

NOTE: The org already was using FIDO2 for these users, so they insert their FIDO2 key to the Boot device, enter the PIN for it, touch it for ‘proof of presence’ - and that’s it. No long username to type in; no long password to remember/type; no additional prompts. The users glide right through to their CPC desktop.

NOTE: Hello for Business (H4B) is supported for the “Dedicated Mode” Boot deployment option but since we used the “Shared PC Mode” setting, where H4B is not supported, we didn’t test. Maybe official H4B support will come later to Shared PC Mode, but given how easy FIDO2 is, and the fact that the target users already use FIDO keys, we didn’t spend any more time on H4B.

At the end of the shift, disconnect the session from the CPC desktop to get back to the Boot sign in screen:

A few FAQs

“What if a user has more than one CPC?”

Connection Center is supported via Boot – here’s one of my demo users, using Boot w/ more than one CPC:

Further, you can select ‘Connect automatically’ from the three dots of a specific CPC’s card; then you’ll always bypass the Connection Center and get SSO’d right into that one.

o To get back to the Connection Center from the Cloud PC, you can use the hotkey combo of <Ctrl> + <Windows key> + <Up Arrow>

o BONUS SECRET HOTKEY COMBO (just between us) – For detailed connection info, from the Cloud PC: <Ctrl> + <Windows key> + <Down Arrow>

“Can I customize the look and feel of the Boot sign in experience?”

Yes – There are policy settings for a custom icon, company name and wallpapers to help differentiate Boot devices from other PCs/devices.

o Personalization CSP | Microsoft Learn

- - TIP: those docs indicate needing to use a URL for files – you can use this syntax for local content already on the device: file:///C:/Folder/File.jpg

There you have it, folks … Windows 365 Boot (or, DAS BOOT!! as I like to sometimes yell) … in the form of a quick PoC.

P.S. A special shout-out is in order for Mr. Liu for his assistance and appreciation of the Boot scenarios.

Stay cool out there…

Hilde

Building C# and C++ Apps with GitHub Copilot CLI and Visual Studio 2026

hewagen — Thu, 02 Jul 2026 08:00:00 GMT

Most engineers learned Visual Studio through a mouse-driven workflow — New Project — open a project, click through a few dialogs, press F5. The GitHub Copilot CLI inverts that workflow: you describe the desired outcome in plain English (or any other language Copilot supports), and the agent scaffolds the project, drives MSBuild, resolves its own compiler errors, and explains the result. By the way: this style of working — you describe what you want and the AI does the actual programming and takes care of the rest — is also known as Vibe Coding. For Microsoft FTEs, this translates into measurably faster proofs of concept for customer escalations, reproduction builds, and internal tooling. Engineers outside Microsoft benefit in exactly the same way, as long as their organization — or their personal subscription — provides the corresponding Copilot entitlement.

This article documents the setup and workflow recommended for engineers onboarding to the CLI. The guidance is deliberately opinionated, assumes a clean Windows 11 installation, and has been verified end-to-end against the current Visual Studio 2026 Community (18.6.2) and Copilot CLI 1.0.56.

Why use the CLI at all?

Copilot is available inside Visual Studio, inside VS Code, in the browser, and on the command line. These front-ends share the same underlying model, but the user experiences differ significantly.

The CLI is the preferred choice in the following scenarios:

You want a single tool that drives the whole machine — installer flags, MSBuild, winget, certificates, registry, even vswhere — rather than only the files open in an editor.
You are working on a throwaway repro for a customer issue, where opening the full IDE is disproportionate.
You want repeatable, scriptable workflows. The CLI accepts instructions, plans and prompts that can be checked in, reviewed, and shared with the rest of your team.
You need to build small tools or short projects without deep programming expertise.

Prerequisites

Windows 11 (or Windows 10 22H2) with administrator rights for the install step.
Microsoft FTE GitHub account linked through the Open Source @ Microsoft portal and a Copilot Business or Enterprise seat assigned by your org. Engineers at other organizations use whichever GitHub identity their employer has assigned a Copilot seat to; individuals can substitute a personal GitHub account that holds a Copilot Pro or Pro+ subscription.
A modern terminal — Windows Terminal with PowerShell 7 is the supported combination.

Note Everything in this guide is built on supported, GA components. Nothing here requires private previews, MSIT exceptions, or non-public flags. If your tenant has additional Conditional Access policies, you may be prompted for MFA the first time you sign in.

Recommended: Run it all in a virtual machine

Before installing anything, an important recommendation: don't run the agent on your primary, company-managed laptop. The CLI — especially with --yolo — has full read, write and execute access to any directory you have trusted. A well-intentioned prompt such as "clean up the temp files in my projects folder" may delete production work if it is pointed at the wrong root. Compliance tooling, OneDrive Known Folder Move, and on-access antivirus on the corporate image also routinely conflict with build outputs and cause agent runs to fail in opaque ways.

The safe, repeatable pattern is to host Visual Studio 2026 and the Copilot CLI inside an isolated environment that can be snapshotted, reset, or discarded. The following options are all suitable:

A Microsoft Dev Box (preferred — already domain-joined, already monitored, and easily recreated from an image).
An Azure VM in your sponsored subscription, ideally with the Visual Studio image from the Marketplace.
A local Hyper-V or WSL2/Windows Sandbox-based Windows 11 VM for offline experimentation.

Important Treat the VM as ephemeral. Retain customer artifacts, screenshots and reproductions only within the VM (or in a dedicated OneDrive/SharePoint location outside the trusted Copilot directory). If something goes wrong, you reset the VM — not your corporate laptop.

Setting up the workspace

Select a workspace folder before performing any other step, and observe two rules:

Use a local path under your profile.
Do not place it on OneDrive, Known Folders Move, or any other sync root.

The rationale is mundane but consequential: the Copilot agent writes files, MSBuild writes obj\ and bin\, and OneDrive's file-system filter will conflict with all of them. You will observe ghost lock files, partially rewritten .cs files, and "the process cannot access the file" errors that are extremely difficult to diagnose.

# Recommended workspace root mkdir "$env:USERPROFILE\AppData\Local\Projects" cd "$env:USERPROFILE\AppData\Local\Projects"

Warning Also avoid %TEMP% for build output. MSBuild emits warning MSB8029, and cleanup tasks in some scheduled jobs may delete your intermediates mid-build.

Installing the Copilot CLI

Open an elevated PowerShell window — the package needs to register PowerShell 7 as a dependency on first run:

winget install GitHub.Copilot

Winget downloads the CLI itself (currently 1.0.56) and, on a fresh installation, also installs PowerShell 7 as a dependency. Once the installation completes, the elevated shell can be closed — do not run Copilot as administrator for day-to-day work.

Confirm the install in a normal (non-elevated) terminal:

copilot --version

Installing Visual Studio 2026 Community

The CLI does not require Visual Studio — it strictly requires only MSBuild and the appropriate toolchain. However, the Community edition is the most straightforward way to obtain a known-good, fully Microsoft-signed installation of MSBuild 18.6.x, the MSVC v145 toolset, and the Windows 10/11 SDK, all in a single step. Select the variant that matches your target workload:

Variant A — C# only (≈ 2.4 GB)

winget install --id Microsoft.VisualStudio.Community -e --source winget ` --override "--add Microsoft.VisualStudio.Workload.ManagedDesktop \ --add Microsoft.Net.Component.4.8.1.SDK \ --add Microsoft.Net.Component.4.8.1.TargetingPack \ --add Microsoft.VisualStudio.Component.CSharp \ --includeRecommended --passive --norestart"

Variant B — C# + native C++ + C++/CLI (≈ 4.3 GB)

winget install --id Microsoft.VisualStudio.Community -e --source winget ` --override "--add Microsoft.VisualStudio.Workload.ManagedDesktop \ --add Microsoft.VisualStudio.Workload.NativeDesktop \ --add Microsoft.VisualStudio.Component.VC.CLI.Support \ --add Microsoft.Net.Component.4.8.1.SDK \ --add Microsoft.Net.Component.4.8.1.TargetingPack \ --add Microsoft.VisualStudio.Component.CSharp \ --includeRecommended --passive --norestart"

A brief description of each component:

Component	Why it's there
Workload.ManagedDesktop	Brings WPF, WinForms, the .NET Framework 4.8.1 target packs and Roslyn analyzers.
Workload.NativeDesktop	Native C++ with the MSVC v145 toolset, Windows 10/11 SDK 10.0.26100, ATL/MFC if you add them.
VC.CLI.Support	The "C++/CLI support" component. Without it, anything with <CLRSupport>true</CLRSupport> fails to compile.
Net.Component.4.8.1.*	SDK + targeting pack for the .NET Framework 4.8.1 surface that ships with Windows.

As a Microsoft FTE you have access to Visual Studio Proffessional or Visual Studio Enterprise. If you already have installed a different version of Visual Studio, you don't need to install 2026 Community.

Important Visual Studio 2026 ships the new v145 platform toolset, not v143. Old .vcxproj files copied in from VS 2022 must be retargeted, otherwise the build fails with MSB8020 — build tools for v143 cannot be found. Copilot can perform this retargeting on request, but the requirement must be stated explicitly.

First launch & sign-in

Change into your project folder and start Copilot. The default invocation recommended for day-to-day FTE work is:

cd "$env:USERPROFILE\AppData\Local\Projects\Repro-12345" copilot --yolo --no-ask-user --model "claude-opus-4.8" --effort "medium"

The flags are defined as follows:

Flag	What it does
--yolo	Pre-approves tool execution, file writes and shell commands for the session. Equivalent to --allow-all-tools --allow-all-paths --allow-all-urls. Use only within trusted folders.
--no-ask-user	Suppresses the interactive confirmation prompts mid-task — the agent continues without interruption.
--model	Pins a specific model. Useful when determinism across a team is required or when comparing runs. To see, which model best fits your needs, take a look at the model comparison at https://docs.github.com/en/copilot/reference/ai-models/model-comparison
--effort	low, medium, or high. Higher values allocate more reasoning tokens per turn — slower, but advantageous for complex build errors and architectural work.

Copilot first prompts you to confirm that you trust the current folder. Select "Yes, and remember this folder for future sessions" only for workspaces you control. Then run /login if you have not yet authenticated — this opens a browser tab in which you sign in with your FTE GitHub identity.

Sign in to Copilot on an unmanaged / non-FTE-domain machine

The Copilot CLI signs in with a GitHub identity, not directly with your Microsoft corporate account. On a company-managed device this is transparent — your Enterprise Managed User (EMU) account <alias>_microsoft is accepted without further action.

On a fresh VM, an Azure VM image, or any other unmanaged device, /login will refuse the EMU account unless you have explicitly linked a personal GitHub account to your EMU and granted it Copilot entitlement. The same pattern holds for engineers at other enterprises: they sign in with the GitHub identity their organization has provisioned with a Copilot seat. Individuals on a Copilot Pro or Pro+ plan can sign in directly with their personal GitHub handle, without any linking step.

For Microsoft FTEs, linking is performed once, from any browser, at:

https://aka.ms/copilot

Sign in with your Microsoft corporate account, link your personal GitHub handle (creating one first if necessary), and accept the prompts. When complete, the page should display every checkbox in green:

A correctly linked account ataka.ms/copilot. The first green check confirms Copilot on the EMU account; the bottom green check is the one that is relevant for unmanaged VMs — "GitHub Copilot enabled for your personal GitHub account for use everywhere", granted through your MicrosoftCopilot organization membership.

Once that bottom row is green, run copilot inside your VM, use /login, and select your personal GitHub handle when the browser device-code flow opens. From that point onward, every CLI session in that VM uses your linked personal identity, your Copilot entitlement follows you, and your activity remains attributable through the MicrosoftCopilot organization for audit purposes.

Tip The link between the EMU and the personal account is per-user, not per-device. Once it is established, every new VM you provision will work after a single /login — there is no need to revisit aka.ms/copilot again unless you change your personal handle.

The bootstrap prompt

This is arguably the most valuable step in the entire setup. Before asking Copilot to build anything, instruct it to profile your machine and write itself a memory file. Paste the following verbatim:

I have Visual Studio 2026 Community Edition installed with C#, .NET Framework 4.8.1 targeting pack, native C++ and C++/CLI. Locate the installation paths using vswhere, verify that you can create and compile a C# app, a native C++ app, and a C++/CLI app. Then create a global copilot-instructions.md under %USERPROFILE%\.copilot\ that documents the VS environment so future sessions don't have to rediscover it.

The behavior that follows is informative to observe. Copilot uses vswhere.exe to locate the installation, reads setup.config.json, generates three disposable projects in your temp folder, builds them with MSBuild, parses the output, and on success writes a structured Markdown file to your user profile. That file is then automatically picked up by every future Copilot CLI session on this machine. The discovery work is performed exactly once.

What a good copilot-instructions.md looks like

Copilot CLI reads instructions from several well-known locations, in this order of precedence:

.github/copilot-instructions.md in the repo

AGENTS.md (or CLAUDE.md, GEMINI.md) in the repo root

.github/instructions/**/*.instructions.md for path-scoped rules

%USERPROFILE%\.copilot\copilot-instructions.md as a global fallback

The machine-level file should be concise, declarative, and contain exact paths. A verified skeleton is shown below:

# Build environment on this PC (Visual Studio 2026) - Visual Studio Community 2026, version **18.6.2** - MSBuild **18.6.3** - MSVC toolset **14.51.36231**, platform toolset name **v145** - Windows 10/11 SDK: **10.0.26100** - Default .NET Framework target: **net481** ## Key paths | Purpose | Path | |--------------------|------| | VS install root | `C:\Program Files\Microsoft Visual Studio\18\Community` | | vswhere.exe | `C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe` | | MSBuild.exe | `...\18\Community\MSBuild\Current\Bin\MSBuild.exe` | | MSVC cl.exe (x64) | `...\VC\Tools\MSVC\14.51.36231\bin\Hostx64\x64\cl.exe` | | vcvars64.bat | `...\VC\Auxiliary\Build\vcvars64.bat` | ## Conventions - For SDK-style csproj, always run `Restore` together with `Build`. - New `.vcxproj` files must use `<PlatformToolset>v145</PlatformToolset>`. - For C++/CLI: `<CLRSupport>true</CLRSupport>` and `<TargetFrameworkVersion>v4.8.1</TargetFrameworkVersion>`. - Never put build output under `%TEMP%`.

Tip Treat copilot-instructions.md as a configuration file. Commit a repo-local version to your .github/ folder for projects with non-standard build flags (custom response files, signing scripts, and similar). The repo-local version overrides the global one.

Worked example: a C# console app on .NET Framework 4.8.1

Consider a task representative of customer-engineering work — a small utility that reads a registry key and emits JSON. Inside Copilot, enter:

Create a new C# console project targeting net481 in .\RegistryProbe\. The app should accept a registry key path as its single argument, read all values under it, and print them as JSON to stdout. Add a few unit tests with MSTest. Build the project with MSBuild in Release and show me the dotnet run output.

Behind the scenes Copilot will:

Use vswhere to locate MSBuild (already cached via the instructions file).

Generate RegistryProbe.csproj with <TargetFramework>net481</TargetFramework>.

Write Program.cs with appropriate argument parsing and a Microsoft.Win32.RegistryKey reader.
Add an MSTest project, wire it up via a .sln file.

Run MSBuild /t:Restore,Build /p:Configuration=Release and read the output.

Run the binary against a safe key like HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion and present the JSON output.

For a more deliberate workflow, press Shift+Tab to toggle Plan mode. Copilot will produce an implementation plan first and wait for approval before writing to disk — a recommended practice for any work involving a customer reproduction.

Worked example: a native C++ command-line tool

The same approach applied to native C++. Prompt:

Create a new native C++ console project ".\PortPing\" targeting x64, Release, using the v145 platform toolset and Windows SDK 10.0.26100. The tool takes "host:port" on the command line and prints "open" or "closed" depending on whether a TCP connect succeeds within 1 second. Build it with MSBuild and run it against microsoft.com:443.

The agent generates a PortPing.vcxproj that looks roughly like:

<PropertyGroup Label="Globals"> <PlatformToolset>v145</PlatformToolset> <WindowsTargetPlatformVersion>10.0.26100.0</WindowsTargetPlatformVersion> <ConfigurationType>Application</ConfigurationType> </PropertyGroup>

…and builds it with:

& $msbuild "PortPing.vcxproj" /p:Configuration=Release /p:Platform=x64

Tip If you want Copilot to compile a single .cpp with cl.exe instead of going through MSBuild, instruct it to load vcvars64.bat first. This sets INCLUDE, LIB and PATH for the MSVC toolchain so that direct compiler invocations succeed.

Worked example: a C++/CLI interop assembly

C++/CLI is the workload that most commonly causes confusion in practice, because it requires the optional VC.CLI.Support component and a few non-obvious project properties. With Copilot, the task reduces to:

Create a C++/CLI class library ".\InteropBridge\" that targets .NET Framework 4.8.1, uses the v145 toolset, and exposes a managed wrapper around the native function CreateFileW. Add a small C# console app in the same solution that consumes the wrapper. Build everything Release|x64 and run the C# app to prove the interop works.

The two critical lines that Copilot adds to the .vcxproj are:

If the C++/CLI support component is not yet installed, Copilot will detect the corresponding "Cannot find <CLRSupport>" error, suggest the correct winget command to add the component, and offer to re-run the build.

Models, effort, and custom agents

Copilot CLI allows the model to be selected per session, and this selection should be made deliberately. The appropriate choice depends on the task at hand:

Profile	Recommended invocation	When to use
Fast iteration	copilot --yolo --model "claude-opus-4.8" --effort "medium"	Day-to-day work: scaffolding, small refactors, and build fixes.
Hard problems	copilot --yolo --model "claude-opus-4.7-1m-internal" --effort "high" --context "long_context"	Cross-file analysis, large reproductions, and complex C++ template errors.
Maximum autonomy	copilot --allow-all-urls --allow-all-tools --allow-all-paths --no-ask-user	Sandboxed Dev Box or VM only — never on a production laptop.

To determine which model best suits your purpose, consult the model comparison at https://docs.github.com/en/copilot/reference/ai-models/model-comparison. And if you have ever wondered what skills, tools, plugins and similar concepts actually are — or what an MCP server is for — the answers are available at https://docs.github.com/en/copilot/concepts/agents/copilot-cli/comparing-cli-features.

Useful slash commands within Copilot CLI

/plan — produce an implementation plan before any code is written.
/review — run the code-review subagent against the local diff.
/diff — display the changes Copilot has made to the working tree.
/agent — select a custom agent (explore, task, general-purpose, rubber-duck, code-review, research).
/mcp — register an MCP server (useful for Azure CLI, Kusto, or internal tooling).
/instructions — show which instruction files are currently loaded — useful when investigating unexpected agent behavior.

Tip Press Shift+Tab at any time to toggle Plan mode. For any action that would be recorded in a change ticket, planning first is inexpensive insurance.

Security & compliance for Microsoft FTEs

GitHub Copilot CLI falls within the scope of Microsoft's standard "responsible use of AI" guidance. Engineers at other enterprises should substitute the equivalent policy of their own employer, and individuals using a personal Copilot subscription should still treat these principles as a sensible default. The condensed guidance for engineers is:

Do not paste customer data into prompts unless your engagement explicitly permits it. The agent will faithfully transmit such data to the model.
Do not use --yolo on shared infrastructure. The flag pre-approves shell execution and file writes. Reserve it for personal workspaces or sandboxed Dev Boxes.
Review the diff. Use /diff or git status before committing — Copilot will, on occasion, refactor files you did not anticipate.
Secrets stay out of source. If you ask Copilot to test something that requires credentials, direct it to use azd, the Az module, or your Key Vault — never inline secrets.
Telemetry and logs from the CLI reside under %USERPROFILE%\.copilot\logs. If a customer escalation requires evidence of agent actions, those logs serve as your audit trail.

Important Any action Copilot performs on your machine still runs as you. Treat agent sessions with the same care you would extend to a teammate with full access to your development machine.

Beyond Visual Studio: where else Copilot CLI helps

The Visual Studio scenarios in this article are the most obvious use case, but they are by no means the only one. The following list covers additional areas in which Copilot CLI has proven productive on real engagements.

Generating and maintaining tests — Ask Copilot to write MSTest, NUnit or xUnit tests for an existing class, including mocks and boundary cases, or to fill coverage gaps in methods that were touched in the last commit.
Refactoring across files — Rename a public API, extract an interface, or restructure a folder hierarchy and have Copilot propagate the change consistently throughout the solution, including project file references and unit tests.
Modernizing legacy code — Port code from .NET Framework 4.8.1 to .NET 8/9, replace WebClient with HttpClient, or swap manual JSON parsing for System.Text.Json. Copilot handles the boilerplate; you review the deltas.
Building customer reproductions from scratch — Translate a bug description from a support ticket into a minimal repro project. Copilot scaffolds the solution, simulates the failing call path, and runs it to confirm the symptom matches.
Reviewing the local diff — The /review slash command analyses staged or unstaged changes and surfaces real issues — race conditions, off-by-one errors, missing input validation, dropped exceptions — while suppressing style-only noise.
Writing and optimizing database code — Generate Entity Framework Core models and migrations from an existing schema, draft complex LINQ or raw SQL queries, and ask Copilot to inspect an execution plan and propose targeted indexes or query rewrites.
Interpreting performance and memory profiles — Hand Copilot a PerfView trace summary, a dotnet-counters capture, or a BenchmarkDotNet result table. It identifies hot paths, allocation spikes, and contended locks, then suggests concrete code changes to address them.
Generating documentation — Produce XML doc comments for public APIs, README sections, architecture overviews, or migration guides — written directly from the current code, not from a stale design document.
Investigating unfamiliar codebases — Drop into a foreign repository and ask "what does this service do?", "where is authentication enforced?", or "which class handles cache invalidation?". The explore subagent answers with file and line references rather than vague summaries.
Analyzing logs and traces — Point Copilot at an ETW trace, an Event Viewer export, a Fiddler capture, or a multi-megabyte server log. It groups errors, identifies the dominant failure pattern, and suggests next steps for the investigation.
PowerShell, Bicep and other operational scripting — Beyond compiled applications, Copilot writes and debugs PowerShell modules, Bicep/ARM templates, Terraform configurations, and shell scripts — useful, among other things, for provisioning the very Dev Box or Azure VM described earlier in this article.
Drafting technical communication — Generate the first draft of a customer-facing root-cause analysis, a pull request description, a release-note entry, or an internal incident retrospective directly from a diff or a chat transcript. The final wording remains yours; the boilerplate does not.

On a slightly meta note: GitHub Copilot CLI can also take a surprising amount of work off your hands when, for instance, you set out to write a blog post like this one. :-)

A note on customer data. Several of the scenarios above — building customer reproductions and analyzing customer-supplied logs in particular, but also any review, database or profiling task that involves production samples — may rely on material provided by a customer. Such data must always be handled with care: depending on the engagement, the customer's data-classification level, or the applicable regulatory regime, sharing it with a Copilot model may be restricted or outright prohibited. Public Sector engagements warrant particular caution. When in doubt, redact, reproduce against synthetic data, or confirm with your account team or compliance contact before pasting anything into a prompt.

Wrapping up

A clean Windows installation, two winget commands, one bootstrap prompt, and a global copilot-instructions.md are all that separate you from a fully working, AI-driven C# / C++ / C++/CLI workflow on Visual Studio 2026. From that point, the agent does what agents do best — it handles the routine work while you remain focused on the customer problem. The list of additional scenarios in the previous section is intentionally non-exhaustive — most engineering tasks that can be described in plain English are candidates, provided the agent has the relevant context and the required permissions.

Productive prompting — and may your builds remain evergreen.

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