Core Infrastructure and Security Blog articles

Redefining Security for an AI Driven World

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

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

Challenge 1: Safeguarding Data Privacy in the AI Era

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

Why This Challenge Persists

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

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

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

How can organizations bridge the gap?

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

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

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

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

Challenge 2: The AI-Weaponized Threat Landscape

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

Why This Challenge Persists

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

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

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

How can organizations bridge the gap?

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

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

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

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

Challenge 3: Identity and Access Governance for AI Agents

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

Why This Challenge Persists

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

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

How can organizations bridge the gap?

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

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

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

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

Challenge 4: Regulatory Compliance and Ethical AI Governance

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

Why This Challenge Persists

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

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

How can organizations bridge the gap?

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

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

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

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

Challenge 5: Integration Complexity and Workforce Readiness

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

Why This Challenge Persists

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

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

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

How can organizations bridge the gap?

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

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

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

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

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

Conclusion: Turning AI Security into Competitive Advantage

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

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

Tech Resources:

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

Securing AI and Navigating risks and compliance for the future

Entra agent Identities for AI agents

Secure Dashboard for AI

Microsoft Security Copilot

Microsoft Security Copilot FAQ

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

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

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

What you’ll take away:

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

Why This Exists

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

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

Design Principles

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

Architecture & Data Flow

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

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

Tool Surface

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

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

The Investigation Loop (3 Steps)

Prompt used

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

1) Ground the incident

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

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

Title
Severity
Owner
Status
Alert count
Analytic rule IDs
Incident URL

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

2) Collect alerts and entities (fast path)

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

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

Alert IDs
Alert names
Timestamps
Severities
Entities
Provider metadata

3) Stay reliable: pivot to KQL when APIs fail

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

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

The High-Signal Pivot: AzureActivity

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

The evidence showed:

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

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

Threat Intelligence: Use It as Context

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

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

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

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

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

Safety + Reliability: Approval-Gated Writeback

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

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

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

Why This Is Worth Building

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

Conclusion

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

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

TameikaL — Thu, 14 May 2026 00:53:22 GMT

TLS certificate pinning in Azure Database for PostgreSQL and MySQL

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

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

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

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

Why detecting TLS certificate pinning is not possible by design

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

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

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

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

TLS certificates in Azure OSS databases vs Azure SQL

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

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

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

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

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

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

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

Why certificate pinning is risky

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

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

Recommended TLS certificate trust model for Azure OSS databases

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

Trust root CAs, not individual certificates.

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

Maintain a flexible and up-to-date trust store

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

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

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

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

For PostgreSQL client configurations, prefer:

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

For MySQL client configurations, prefer:

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

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

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

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

Maintain a combined CA during certificate rotations

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

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

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

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

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

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

Member: TysonPaul | Microsoft Community Hub

Announcing Public Preview for Essential Machine Management

Team Blog: Azure Governance and Management

Author: Meagan McCrory

Published: 04/06/2026

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

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

Team Blog: Azure Governance and Management

Author: jtracey93msft

Published: 04/27/2026

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

Copilot agents are scaling faster than most organizations expected

Team Blog: FastTrack

Author: JulieHersum

Published: 04/17/2026

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

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

Team Blog: FastTrack

Author: JulieHersum

Published: 04/13/2026

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

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

Team Blog: Azure Architecture

Author: stsolo

Published: 04/28/2026

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

Running Diffusion Models at Scale on AKS

Team Blog: Azure Architecture

Author: PrabalDeb

Published: 04/29/2026

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

Announcing Log Monitor v2.2.0 Release Candidate

Team Blog: Containers

Author: Bob_Sira

Published: 04/15/2026

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

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

Team Blog: Containers

Author: natashapolito

Published: 04/23/2026

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

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

Team Blog: Ask the Directory Services Team

Author: BrentCrummey

Published: 04/27/2026

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

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

Team Blog: Ask the Directory Services Team

Author: mdhabibnawaz

Published: 04/30/2026

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

AHEAD helps us launch the Strategic Azure Storage Services Partner Program

Team Blog: Azure Storage

Author: karautenMSFT

Published: 04/30/2026

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

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

Team Blog: Azure Storage

Author: despindola

Published: 04/30/2026

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

Announcing Native PowerShell Tooling for ReFS Snapshots

Team Blog: Storage at Microsoft

Author: Christina_Curlette

Published: 04/30/2026

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

Public Preview: Managed Identity support for graphical session recording

Team Blog: Azure Network Security

Author: aarontsang

Published: 04/30/2026

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

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

Team Blog: Azure Network Security

Author: andrewmathu

Published: 04/29/2026

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

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

Team Blog: ITOps Talk

Author: Pierre_Roman

Published: 04/07/2026

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

Internet Information Services Learning Path

Team Blog: ITOps Talk

Author: OrinThomas

Published: 04/14/2026

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

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

Team Blog: Azure Migration and Modernization

Author: Shikher

Published: 04/03/2026

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

Production Cutover in Cloud-Native Migrations

Team Blog: Azure Migration and Modernization

Author: dhruti

Published: 04/15/2026

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

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

Team Blog: FastTrack for Azure

Author: munieswar_avulapalli

Published: 04/28/2026

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

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

Team Blog: Azure Compute

Author: Jon_Andoni_Baranda

Published: 04/22/2026

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

Designing Outbound Connectivity for "Private Subnets" in Azure

Team Blog: Core Infrastructure and Security

Author: alexeyn1

Published: 04/23/2026

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

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

Team Blog: Core Infrastructure and Security

Author: HoussemDellai

Published: 04/20/2026

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

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

Team Blog: Azure Arc

Author: alinetran

Published: 04/01/2026

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

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

Team Blog: Azure Arc

Author: TomClaes

Published: 04/12/2026

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

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

Team Blog: Azure Virtual Desktop

Author: Michelle_Moya

Published: 04/16/2026

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

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

Team Blog: Azure Virtual Desktop

Author: Rinku_Dalwani

Published: 04/21/2026

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

Update host keys to use SFTP on Azure Blob Storage

Team Blog: Azure PaaS

Author: LuisFilipe

Published: 04/28/2026

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

Leveraging Azure Resource Graph Queries for Azure Redis Configuration

Team Blog: Azure PaaS

Author: Soma_Sekhara_Raju

Published: 04/21/2026

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

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

Team Blog: Microsoft Learn

Author: AshleyMastersHall

Published: 04/28/2026

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

What’s new in AI Skills Navigator: April 2026

Team Blog: Microsoft Learn

Author: Priya_V

Published: 04/20/2026

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

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

Team Blog: Azure Networking

Author: kirankumar_manchiwar04

Published: 04/22/2026

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

A demonstration of Virtual Network TAP

Team Blog: Azure Networking

Author: Marc de Droog

Published: 04/15/2026

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

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

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 04/30/2026

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

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

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 04/24/2026

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

Triggering Azure Functions from Blob Storage Using Event Grid

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

Overview

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

Introduction

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

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

Scenario

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

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

Architecture

Blob Storage → Event Grid → Azure Function

The Process

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

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

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

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

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

Implement the Function

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

Example of HandleBlobCreatedEvents.cs:

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

Example of Program.cs:

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

Example of Host.json:

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

Example of EventGridListenerFunction.csproj:

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

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

Step 2 — Create the Event Grid Subscription

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

Step 3 — Validate

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

Common Pitfalls

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

Conclusion

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

Disclaimer

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

Purpose For Your PKI (Practical PKI Part 3)

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

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

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

Secure Configuration and Hardening of Active Directory Certificate Services

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

CRL & AIA Publishing Guidance (Practical PKI Part 2)

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

Determine Your Technical Outcomes

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

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

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

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

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

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

Are You Experienced?

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

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

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

Decisions, Decisions

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Solution overview

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

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

Figure 1: Solution architecture diagram

End-to-end flow:

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

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

Implement the solution

This section describes how to deploy the solution architecture.

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

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

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

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

Initialise environment variables

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

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

Create the AKS Node Pool with Kata VM Isolation

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

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

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

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

Create NFS Persistent Volume

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

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

Verify that the persistent volume is created.

kubectl get pv openclaw-nfs-pv

Figure 2: Persistent volume

Create the NFS PersistentVolumeClaim

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

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

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

Figure 3: Persistent Volume Claim

Create the ConfigMap

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

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

Create the Auth Token Secret

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

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

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

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

Deploy the OpenClaw Gateway

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

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

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

- ConfigMap (openclaw-config for openclaw.json)

Key details:

- Runs 2 replicas with a rolling update strategy

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

- Exposes port 18789

- Includes liveness and readiness probes on /health

- Resource requests: 500m CPU, 512Mi memory

- Resource limits: 2 CPU, 2Gi memory

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

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

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

Figure 4: OpenClaw deployment

Create the TLS secret (for HTTPS)

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

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

Create the Gateway

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

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

kubectl get gateway https

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

Create the HTTPRoute

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

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

Test OpenClaw application

Get the external endpoint.

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

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

Figure 5: OpenClaw Authentication

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

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

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

Figure 6: OpenClaw pairing success message

Figure 7: OpenClaw Application

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

Test microVM kernel isolation

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

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

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

Conclusion

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

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

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

How to Manage RC4 Hardening – Definitive Guide

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

How to Manage RC4 Hardening – Definitive Guide

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

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

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

Hardening Phases

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

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

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

Registry keys and attributes involved

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

DefaultDomainSupportedEncTypes:

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

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

This key need to be created manually if needed

Possible values:

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

Possible values and their meaning during all the phases:

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

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

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

RC4DefaultDisablementPhase

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

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

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

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

msDS-SupportedEncryptionTypes

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

Value available for the attribute:

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

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

SupportedEncryptionTypes

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

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

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

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

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

Audit

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

Existing enhanced events

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

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

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

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

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

New events available

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

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

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

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

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

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

See the common scenarios section for more details

Scripts

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

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

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

Get-KerbEncryptionUsage.ps1

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

Example:

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

List-AccountKeys.ps1

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

Event forwarding

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

Common Scenarios

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

I have only few objects that are using RC4

Scenario:

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

DOs:

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

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

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

Many services rely on RC4

Scenario:

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

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

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

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

No services rely on RC4

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

DOs:

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

Conclusion

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

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

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

FAQs

Are there impacts in the forest trusts?

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

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

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

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

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

Useful Resources

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

Disclaimer

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

Extracting and Auditing Azure DevOps Permissions at Scale with PowerShell

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

Introduction

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

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

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

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

The Problem

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

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

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

What the Tool Does

At a high level, the tool:

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

Architecture Overview

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

The solution consists of three PowerShell files:

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

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

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

Setting Up the Pipeline

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

Prerequisites

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

Running the Pipeline

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

Azure DevOps Pipeline Run dialog from YAML configuration.

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

Understanding the Permissions Output

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

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

Permissions are reported as:

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

Token Resolution

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

This resolution covers:

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

The Membership Report

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

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

Detecting Stale and Ghost Members

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

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

AAD/Entra Group Recursion

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

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

Importing into Power BI

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

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

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

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

Common Power BI analyses:

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

Key Design Decisions

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

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

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

Getting Started

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

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

Conclusion

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

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

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

Thanks for reading!

Disclaimer

Designing Outbound Connectivity for "Private Subnets" in Azure

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

Why Private Subnets Change Everything

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

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

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

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

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

The Three Outbound Patterns at a Glance

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

Scenario 1: NAT Gateway

What is NAT Gateway?

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

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

Key flow are depicted below:

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

NAT Gateway → Internet: Static, deterministic public IP

Inbound: NOT supported (outbound only)

How it works (step by step)

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

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

Strengths

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

Limitations

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

Best Fit Use Cases

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

Scenario 2: Azure Firewall

What is Azure Firewall?

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

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

KEY Flow are depicted below:

VM → UDR: Forces ALL outbound traffic to Firewall

Firewall: Evaluates against policy before allowing

Firewall → Internet: Only explicitly permitted flows pass

All denied flows: Logged and alertable

How it works (step by step)

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

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

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

Strengths

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

Limitations

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

Best Fit Use Cases

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

Scenario 3: Load Balancer Outbound

What is Load Balancer Outbound?

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

Key flows are depicted below:

VMs → Load Balancer: Backend pool members get SNAT

LB Outbound Rules: Define port allocation per VM

⚠️ Port exhaustion risk at scale

⚠️ No inspection or policy enforcement

How it works (step by step)

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

Strengths

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

Limitations

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

Best Fit Use Cases

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

Decision Framework: Choosing the Right Outbound Pattern

Common Pitfalls to Avoid

⚠️ Pitfall 1: Forgetting SNAT scale limits

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

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

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

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

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

⚠️ Pitfall 4: Blocking Azure platform dependencies

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

⚠️ Pitfall 5: Relying on platform defaults

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

Summary and Key Takeaways

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

The core principle

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

References

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

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

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

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

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

Why Native Backup Matters

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

Core Capabilities: How it Works

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

Automated Daily Snapshots

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

Visibility via Difference Reports

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

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

Granular Restoration

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

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

The "Defense in Depth" Identity Strategy

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

Pillar 1: Soft Delete (The Recycle Bin)

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

Pillar 2: Protected Actions (The Vault)

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

Actions.

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

Pillar 3: Backup and Recovery (The Time Machine)

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

Real-World Scenario: Recovering from a Bulk Logic Error

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

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

Conclusion and Next Steps

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

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

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

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

A video format is available for watching.

Prerequisites

- An Azure account with sufficient permissions to create resources.

- Terraform installed on your local machine.

Infrastructure Provisioning

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

terraform init terraform apply --auto-approve

The following resources will be created:

ComfyUI Deployment

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

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

Monitoring and Analytics

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

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

Start using ComfyUI

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

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

Using ComfyUI for Text to Video

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

Important Notes

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

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

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

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

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

🔍 SMB vs NFS — What’s the Difference?

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

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

Consumption profile details

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

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

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

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

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

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

Disclaimer

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

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

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

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

Once deletion is complete:

The Public IP resource no longer exists

The Resource ID cannot be resolved

The assigned Public IP address is permanently unretrievable through Azure APIs

For organisations that rely on accurate IP inventory data for:

Security monitoring

Compliance audits

Incident response

Network forensics

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

The Core Challenge

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

---

OperationName: Microsoft.Network/publicIPAddresses/delete

ResourceId:

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

---

The alert correctly identifies the operation and the affected resource.

However:

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

Maintaining Accurate IP Inventory

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

Preventing False Security Investigations

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

Supporting High‑Churn Dynamic Workloads

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

Solution Overview

The recommended approach is based on the following principle:

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

This can be implemented using:

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

The solution comprises four primary components:

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

Implementation Guide

Step 1: Route Activity Logs to Log Analytics

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

To enable lifecycle detection through KQL queries:

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

Category: Administrative
Destination: Send to Log Analytics Workspace

4.Select your target Log Analytics Workspace.

5.Click Save.

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

Step 2: Deploy an Azure Automation Account

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

To begin:

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

Subscription
Resource Group
Automation Account Name
Region

Once the Automation Account has been created:

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

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

Step 3: Assign Managed Identity Permissions

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

Navigate to:

Subscription → Access Control (IAM) → Add Role Assignment

Assign the following roles to the Automation Account Managed Identity:

Role	Scope
Reader	Subscription
Reader	Log Analytics Workspace

This ensures the runbooks are able to:

Query Public IP resources

Resolve resource metadata

Interpret Activity Log–driven lifecycle operations

Step 4: Create a Persistent Cache Variable

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

Public IP Resource ID → Assigned IP Address

Within the Automation Account:

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

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

4.Select Create.

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

Step 5: Create Required Automation Runbooks

Two Azure Automation Runbooks are required for this implementation.

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

Step 5.1: Create Cache Seeding Runbook

Create Cache Seeding Runbook

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

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

Name: CacheSeedingRunbook
Runbook Type: PowerShell
Runtime Version: 7.2

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

Select Publish.

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

Step 5.2: Create Main Lifecycle Runbook

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

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

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

4. Select Publish once configuration is complete.

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

Step 6: Create Runbook Webhook

Configure Runbook Webhook

To allow Activity Log alerts to invoke the runbook:

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

Webhook Name
Expiration Date

5. Copy the generated Webhook URL.

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

Step 7: Seed Cache with Existing Public IPs

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

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

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

Step 8: Create Activity Log Alert Rule

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

Under Condition:

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

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

Please find the configuration in the attached screenshot below:

Step 9: Configure Action Group to Trigger Runbook

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

Action Type: Webhook
Paste the previously generated Runbook Webhook URL

3.Enable:

Use Common Alert Schema

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

4. Attach this Action Group to the alert rule.

Step 10: Validate the Implementation

To validate:

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

Public IP creation
Public IP deletion

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

See the sample output below:

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

Conclusion

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

Microsoft Defender for Endpoint (MDE) — Custom Role Design for Troubleshooting Mode–Only Access

SantoshPargi — Mon, 13 Apr 2026 05:43:59 GMT

1) Introduction

In customer environments, Security Operations (SOC) teams and Windows infrastructure teams frequently need to investigate endpoint issues in the Microsoft Defender for Endpoint portal—often under time pressure—while still preserving strong governance over who can change security controls.

Because Troubleshooting Mode can enable temporary modification of Defender Antivirus settings even when devices are governed by organizational policies (for example, when policy protections are in place using Tamper protection settings), granting this capability broadly can introduce configuration drift, increase operational risk, and blur accountability.

To address this, customers typically require a least‑privilege, scoped access model that enforces Segregation of Duties (SoD):

Investigators (Security Reader) retain visibility and investigation capability but cannot create or modify MDE security policies.
Only an explicitly authorized group is granted the minimum permissions required to enable Troubleshooting Mode, and that access is restricted to a defined device scope using device groups—supporting both risk reduction and clear governance.

This approach ensures teams can perform required investigations and controlled troubleshooting while maintaining least privilege, SoD, and predictable operational impact across the customer’s environment.

This document describes an approach to providing controlled access to Troubleshooting Mode on a scoped set of devices.

- An Entra ID user group to collect eligible users

- A custom Defender XDR role with only the minimum required permissions

- Microsoft Defender for Endpoint device groups to scope where those permissions apply

The goal is to enable safe troubleshooting while maintaining least privilege and preventing unintended policy changes.

2) Prerequisite & Coverage

- An Entra ID user group to collect eligible users

- A custom Defender XDR role with only the minimum required permissions

- Microsoft Defender for Endpoint device groups to scope where those permissions apply

The goal is to enable safe troubleshooting while maintaining least privilege and preventing unintended policy changes.

This setup is necessary to:

- Enforce least privilege (only the permissions needed for Troubleshooting Mode and limited operational actions)

- Scope powerful actions to a defined device group instead of all devices

- Support a split model where one Security Reader group gets Troubleshooting Mode access and another Security Reader group remains view/operate without TS Mode

- Preserve governance: users can investigate and perform limited actions but cannot create or modify MDE policies

- Improve auditability by ensuring key actions are observable via device telemetry and the Action Center (while acknowledging that some telemetry may not include the initiating username).

3) Implementation Steps for Troubleshooting Mode (TO BE PERFORMED IN MICROSOFT DEFENDER PORTAL / ENTRA ID)

3.1 Prepare Entra ID User Group

Identify an existing Entra ID user group that contains users (IT Infra Team) with the Security Reader role or create a new dedicated Entra ID user group for this purpose.

- This group will be used consistently for:

- Assigning the custom Defender XDR role

- Scoping access to Defender for Endpoint device groups

3.2 Create and Assign Custom Defender XDR Role

Create a custom Defender XDR role with Microsoft Defender for Endpoint (MDE) Security Settings Management permissions.

- While creating the custom role, select only the minimum required permissions to maintain a least-privilege model.

- Assign this custom Defender XDR role to the Entra ID user group identified in Step 1.

Reference: See screenshots below for role creation, permission selection, and Entra ID group assignment.

3.3: Assign Entra ID User Group to Device Group

Assign the same Entra ID user group (used in Steps 1 and 2) to a Microsoft Defender for Endpoint device group.

- Devices in the device group should be dynamically grouped using supported criteria such as:

- Device tags

- Device name patterns

- Other supported device attributes

- This scoping ensures that the custom role permissions apply only to the intended set of devices.

Reference: See screenshot under below showing device group creation and Entra ID group-to-device group assignment.

3.4 Resulting User Experience and Permissions

After completing Steps 3.1 through 3.3, users who sign in with:

- Security Reader role, and

- Custom Defender XDR role

will observe the following behavior in the Microsoft Defender portal:

- Troubleshooting Mode is available on the scoped devices

- Users cannot create or modify MDE policies

- Users have access only to a controlled set of operational and investigative actions, including:

- Exclude

- Go hunt

- Download force release from isolation script

- Ask Defender Experts

This configuration enables safe troubleshooting while preventing configuration drift or unauthorized security policy changes.

Reference: See screenshot under below illustrating the available actions and the absence of policy creation/modification options.

Reference: See screenshot below where creation of AV policy failed as User will not have access to Intune to create policy.

4. In an alternate scenario, two separate Security Reader groups are maintained: one group requires access to Troubleshooting Mode, while the other should have no Troubleshooting Mode access. Users in the latter group (no TS Mode requirement) can continue to use standard Microsoft Defender for Endpoint (MDE) operational capabilities such as managing tags, setting device criticality, running antivirus scans, collecting an investigation package, reporting device inaccuracy, initiating advanced hunting (Go hunt), triggering policy sync, and running automated investigations. Users in the Troubleshooting Mode-enabled Security Reader group must also be assigned to the appropriate MDE device group to ensure their device-level access and workflows continue to function as expected.

Reference: See the screenshot below, which illustrates the additional MDE capabilities available to users who also have access to the device group

5: Auditing and Event Visibility

- Events related to Tamper Protection changes and Troubleshooting Mode enablement are captured in Microsoft Defender for Endpoint telemetry.

- These events are logged and visible for audit and investigation purposes.

- The username is not recorded in these specific event entries, which is expected behavior in the current Defender auditing model. However, the activation of Troubleshooting Mode is still logged and visible in the device Action Center, which allows confirmation that the mode was enabled on the device and the username.

Reference: See screenshot under Step 6 showing the relevant audit and event records in Timeline of Device Page. Similarly ,correlate using KQL across two Event Tables (DeviceEvents & EntraIdSignInEvents).

Below is the KQL query

let TimeWindow = 10m;

let Lookback = 7d;

// Portal sign-ins (Security & Compliance Center)

let DefenderPortalSignins =

materialize(

EntraIdSignInEvents

| where Timestamp >= ago(Lookback)

| where Application == "Microsoft 365 Security and Compliance Center"

| project

SignInTime = Timestamp,

PortalUserUpn = AccountUpn,

PortalUserObjectId = AccountObjectId,

SignInIP = IPAddress,

CorrelationId

| extend TimeBucket = bin(SignInTime, TimeWindow)

);

// Tamper-protection related events (broaden as needed)

let TamperEvents =

materialize(

DeviceEvents

| where Timestamp >= ago(Lookback)

| where ActionType has "Tamper" or ActionType == "TamperingAttempt"

| project

TamperTime = Timestamp,

DeviceId,

DeviceName,

ActionType,

AdditionalFields

| extend TimeBucket = bin(TamperTime, TimeWindow)

);

// Output rows: (UPN, TamperTime) within +/- window

TamperEvents

| join kind=inner (DefenderPortalSignins) on TimeBucket

| where abs(datetime_diff("minute", TamperTime, SignInTime)) <= toint(TimeWindow / 1m)

| project

PortalUserUpn,

TamperTime,

SignInTime,

DeviceName,

DeviceId,

ActionType,

SignInIP,

CorrelationId,

AdditionalFields

| order by TamperTime desc

This query correlates by time proximity. It indicates “user signed into the portal around the time a tamper event happened.”
It does not prove that the portal user caused the tamper event (that requires audit telemetry for the action). If you later want attribution (“who enabled troubleshooting mode / changed settings”), we should pivot to Defender Action Center message and then confirm the user.
The query can be used for generating alert using custom detection rule and take this alert to Security Operations center using API integration.

Below is reference to the sample output of the query.

6) Summary

Option 3 enables a controlled Troubleshooting Mode experience by combining Entra ID group-based user assignment, a custom Defender XDR role with minimal permissions, and device group scoping in MDE.

With this approach, eligible users can troubleshoot only the intended devices and perform a limited, operationally safe set of actions, while policy creation/modification remains restricted.

Audit and investigation are supported through MDE telemetry and device Action Center visibility, with the known limitation that certain telemetry entries may not include the initiating username.

Customer Offerings: Azure Local - Implementation, Migration, and Management

BrandonWilson — Sun, 12 Apr 2026 19:55:01 GMT

Hi everyone!

Brandon here, back once again to talk to you about a couple of new offerings that have just been released to assist our Unified customers with their on-premises virtualization needs! I continue to have the privilege of leading a great program and team helping customers to migrate from VMware to more cost-effective and/or modern solutions. These new offerings are <drum roll>:

Hyper-V - Implementation, Migration, and Management
Azure Local - Implementation, Migration, and Management

NOTE: These offerings do not provide hands on keyboard support, do not create custom documentation for customers, and cannot provide direct support for any 3^rd party products that may be used in the process of migrations.

Many customers are reassessing their virtualization strategies and are actively exploring alternatives to VMware that align with long‑term hybrid cloud goals. Azure Local offers a purpose‑built platform that combines proven Windows Server–based virtualization with Azure services and management tooling, enabling customers to modernize on‑premises infrastructure while maintaining tight integration with Azure management, security, and governance capabilities.

Whether driven by changing licensing models, cost optimization, or the need for deeper hybrid cloud integration, a successful transition requires more than a technology shift—it requires a structured, outcome‑focused approach. While we are providing these new offerings to customers, you do also have the option of more extended engagements as well that are broader in scope and more tailored to the end goals while we work side by side with you.

If you are a Unified customer and looking to move off of VMware to Azure Local, or you just need help with your on-premises Microsoft virtualization technologies in general, have your account manager (CSAM) reach out to me!

Planning to go at it alone??

Virtually (no pun intended) every environment reviewed by my team (and that is a LOT) that was set up prior to our review will have configuration issues, at times warranting extensive efforts to correct.

Problem 1: There are some potentially significant differences between the way VMware and Azure Local are architected from the start, especially in areas of networking and storage, where mimicking methods used in the VMware world can actually lead to performance degradation in your target Azure Local environment.

Problem 2: Your management method must also change. Additionally, if you are converting/migrating to Azure Local, the available methods need to be determined, the terminology and functional differences identified and learned…there can be a lot to unpack in this area.

Problem 3: Perhaps the most obvious is that this may be a new platform for your team, and its important for them to gain experience through guided actions and knowledge transfer on the fly for those questions they really have, which is exactly what we aim to provide in guiding implementations and migrations!

A Structured Engagement Model

Successful Azure Local implementations are built around a guided engagement model rather than a one‑size‑fits‑all checklist. Each engagement is tailored to the customer environment, acknowledging that differences in scale, workloads, hardware, and operational maturity directly influence the migration approach. The framework emphasizes collaboration, clarity of expectations, and incremental progress instead of disruptive “lift‑and‑shift” execution. Whether we are talking about migration from another virtualization platform, or simply trying to reduce costs by implementing a new virtualization infrastructure, we’re here to help!

Key Phases of an Azure Local Implementation and/or Migration

Most Azure Local implementation and migration engagements progress through a common set of phases:

Engagement scoping and technical discovery to understand goals and current state (this is the conversation I, or one of the TZ Leads in the VMware Migration Program have with customers)
Planning and design aligned to business and operational outcomes, with a limited scope
Deployment and configuration validation to ensure platform readiness
Security and migration testing to reduce risk and confirm workload compatibility
Feature enablement, including Azure Arc, to extend governance and management

While these phases provide structure, the sequence and depth of each stage are adapted based on the customer environment and objectives.

Key Outcomes for Customers

Organizations that engage in Azure Local implementation or migration efforts commonly achieve:

Deeper familiarity with Microsoft virtualization technologies
Successful deployment of PoC, pilot, or production environments
Validated test migrations of virtual machines
Identification and resolution of technical blockers
Increased confidence in operational readiness

These engagements are advisory and collaborative in nature, prioritizing customer enablement and success.

Knowledge Transfer and Operational Readiness

A central focus of the Azure Local engagements is ensuring that IT teams are prepared to operate the platform long after deployment completes. Knowledge transfer is embedded throughout the engagement through working sessions and direct participation in implementation activities. This approach helps organizations move confidently into steady‑state operations without relying on long‑term external support. As I mentioned above, if you do feel you will need longer term support, we have your back on that front as well.

Looking Beyond Migration

An Azure Local migration is often the first step in a broader transformation journey. Many organizations use this transition to enable hybrid management, strengthen security posture, and prepare for future application or cloud modernization initiatives. When approached strategically, Azure Local becomes a platform for long‑term innovation and a step to modernizing your infrastructure, not just a replacement hypervisor.

Conclusion

Moving from VMware to Azure Local is not simply a technical migration—it is an opportunity to modernize how infrastructure is managed and governed. With structured planning, guided execution, and a focus on operational readiness, organizations can transition with confidence to a virtualization platform built for today’s hybrid cloud realities and tomorrow’s growth.

Thanks for reading, and maybe we’ll talk soon!

Customer Offerings: Hyper-V - Implementation, Migration, and Management

BrandonWilson — Mon, 13 Apr 2026 02:50:50 GMT

Happy April everyone!

Hyper-V - Implementation, Migration, and Management
Azure Local - Implementation, Migration, and Management

Many customers are taking a closer look at Microsoft Hyper‑V as a strategic alternative to traditional virtualization platforms. Whether driven by changing licensing models, cost optimization, or the need for deeper hybrid cloud integration, a successful transition requires more than a technology shift—it requires a structured, outcome‑focused approach. While we are providing these new offerings to customers, you do also have the option of more extended engagements as well that are broader in scope and more tailored to the end goals while we work side by side with you.

If you are a Unified customer and looking to move off of VMware to Hyper-V, or you just need help with your on-premises Microsoft virtualization technologies in general, have your account manager (CSAM) reach out to me!

Planning to go at it alone??

I’m starting here for a very good reason… Virtually (no pun intended) every environment reviewed by my team (and that is a LOT) that was set up for a VMware migration, will have configuration issues, many times warranting a complete redesign and re-deployment.

Problem 1: There are some potentially significant differences between the way VMware and Hyper-V are architected from the start, especially in areas of networking and storage, where mimicking methods used in the VMware world can actually lead to performance degradation in your target Hyper-V environment.

Problem 2: To achieve feature parity, or near feature parity, your management method must also change. Additionally, if you are converting/migrating to Hyper-V, the available methods need to be determined, the terminology and functional differences identified and learned, well, honestly, I could go on for awhile on this, but I’ll spare you until we talk…

You mentioned management and conversion tools, what do you mean??

Hyper‑V has several methods for management, which can vary based on the feature needs and environment size. As a simple example, if I have 1500 virtualization hosts and 30,000 virtual machines spread out globally, its probably not going to be as efficient to manage everything only through locally available consoles. The capabilities of these management methods are continuing to grow and improve based on customer feedback, along with feedback from the field team. Let’s take a quick look at these options:

Native Windows tools: Hyper-V management console, Failover Clustering management console, Server Manager, etc
- This management method is typically used for small labs or smaller production environments (for migrations/conversions these methods do not provide feature parity with VMware).

System Center Virtual Machine Manager (SCVMM)
- This management method is fully supported for environments of all sizes. For migrations/conversions this method provides feature parity with VMware for management and features, along with offering VMware migration/conversion capability (offline). If you are already using any product from the System Center suite (SCCM, SCOM, SCORCH, SCSM, or DPM) then this can prove to be a great no cost option for you!

Windows Admin Center: Administration Mode (aMode)
- This management method is fully supported for environments of all sizes, however, is not designed as an infrastructure wide virtualization management method, but for server management and administration. If your environment isn’t extremely large, and VMware feature parity is not a necessity, this can provide a great no cost option for management of your physical and virtual servers. In addition, this method provides an online conversion option (currently public preview), allowing for a more seamless migration from VMware.

Windows Admin Center: Virtualization Mode (vMode) (currently public preview)
- This management method is fully supported for environments of all sizes, and is designed solely for the purpose of managing the Hyper-V virtualization infrastructure, tying together the primary needs for virtualization fabric into an easy to navigate web-based UI.

Azure
- You can Arc enable any Windows host or virtual machine and have a method of management and integration with cloud based services. In addition, these can work in conjunction with all of the above options to improve your management experience for your platform, and allows for the easy implementation and integration of many cloud based technologies (such as Hyper-V replica backups to ASR)

NOTE: You can learn more about Windows Admin Center evolution here: Windows Admin Center Architectural Changes | Microsoft Community Hub

A Structured Engagement Model

Successful Hyper‑V implementations are built around a guided engagement model rather than a one‑size‑fits‑all checklist. Each engagement is tailored to the customer environment, acknowledging that differences in scale, workloads, hardware, and operational maturity directly influence the migration approach. The framework emphasizes collaboration, clarity of expectations, and incremental progress instead of disruptive “lift‑and‑shift” execution. Whether we are talking about a migration from another virtualization platform, or simply trying to reduce costs by implementing a new virtualization infrastructure, we’re here to help!

Key Phases of a Hyper‑V Implementation and/or Migration

Most Hyper‑V engagements progress through a common set of phases:

Engagement scoping and technical discovery to understand goals and current state (this is the conversation I, or one of the TZ Leads in the VMware Migration Program have with customers)
Planning and design aligned to business and operational outcomes, with a limited scope
Deployment and configuration validation to ensure platform readiness
Security and migration testing to reduce risk and confirm workload compatibility
Optional feature enablement, including Azure Arc, to extend governance and management

While these phases provide structure, the sequence and depth of each stage are adapted based on the customer environment and objectives.

Key Outcomes for Customers

Organizations that engage in Hyper-V implementation or migration efforts commonly achieve:

Deeper familiarity with Microsoft virtualization technologies
Successful deployment of PoC, pilot, or production environments
Validated test migrations of virtual machines
Identification and resolution of technical blockers
Increased confidence in operational readiness

These engagements are advisory and collaborative in nature, prioritizing customer enablement and success.

Knowledge Transfer and Operational Readiness

A central focus of a Hyper‑V engagement is ensuring that IT teams are prepared to operate the platform long after deployment completes. Knowledge transfer is embedded throughout the engagement through working sessions and direct participation in implementation activities. This approach helps organizations move confidently into steady‑state operations without relying on long‑term external support. As I mentioned above, if you do feel you will need longer term support, we have your back on that front as well.

Looking Beyond Migration

A Hyper‑V migration is often the first step in a broader transformation journey. Many organizations use this transition to enable hybrid management, strengthen security posture, and prepare for future application or cloud modernization initiatives. When approached strategically, Hyper‑V becomes a platform for long‑term innovation, not just a replacement hypervisor.

Conclusion

Moving from VMware to Hyper‑V is not simply a technical migration—it is an opportunity to modernize how infrastructure is managed and governed. With structured planning, guided execution, and a focus on operational readiness, organizations can transition with confidence to a virtualization platform built for today’s hybrid cloud realities and tomorrow’s growth.

Thanks for reading, and maybe we’ll talk soon!

Auditing FIDO2 authentication for Windows Sign-in

LijuV — Thu, 09 Apr 2026 11:10:08 GMT

Hello everyone, my name is Liju and I am a Cloud Solutions Architect helping customers secure their cloud and hybrid identities. With this post, I would like to show how FIDO2 security key authentication for Windows sign‑in can be audited on client devices.

Recently, a customer of mine asked how they could:

Audit each use of a FIDO2 security key on a Windows client device
Track all PIN verification attempts on the security key, including both successful and unsuccessful attempts
Determine which user successfully authenticated to a Windows device using a FIDO2 security key

While standard Windows logon events such as 4624 and 4625 report the user and logon type, they do not indicate whether a FIDO2 security key was used. We can find this information in the Microsoft‑Windows‑WebAuthN/Operational event log, although interpreting these events requires additional decoding and correlation.

Entra ID
FIDO2 Security Key authentication in Windows
- Authentication flow (high-level)
- Mapping the steps to WebAuthN events
WebAuthN Events
Tying it all together

But first, let us see how Entra ID stores the information when a user registers a FIDO2 security ley as an authentication method.

Entra ID

For each user that has registered a FIDO2 security key, the keys are represented as a fido2AuthenticationMethod resource on the user object. The identifier for the key is stored with a Base64URL encoding.

In the example below the value is 7ebzDmVTSreLsJkrjm1mNA2

When a FIDO2 key is registered, an audit event is generated in Entra ID. The KeyIdentifier is stored using standard Base64 encoding.

In the example below the value is 7ebzDmVTSreLsJkrjm1mNA==

If diagnostic logging is enabled for Entra ID and if the AuditLogs are sent to a Log Analytics Workspace, this information can be queried using KQL.

AuditLogs | where Category == "UserManagement" | where OperationName == "Add Passkey (device-bound)" | extend UserUPN = tostring(TargetResources[0].userPrincipalName) | extend FIDOkeyId = tostring(TargetResources[0].displayName)

Top👆

FIDO2 Security Key authentication in Windows

When a user signs in with a FIDO2 security key, Windows is trying to answer one question:

Can this authenticator (security key) prove possession of the private key associated with a registered credential for this user?

This proof is provided in the form of a WebAuthN assertion, which is a cryptographic response generated by the authenticator.

Authentication flow (high-level)

Challenge generation
During FIDO2 authentication for a Microsoft Entra user, a challenge is generated by the relying party (for example, login.microsoft.com) and provided to the client (Windows).

Request construction
Windows initiates a WebAuthN GetAssertion request, which is encoded using CBOR (Concise Binary Object Representation), a compact binary format used by the FIDO2 protocol.
The request contains the clientDataHash which is a hashed JSON object containing the challenge sent by Entra (along with other parameters).

Authenticator processing
The request is sent to the authenticator using CTAP (Client to Authenticator Protocol).
The authenticator then locates a matching credential for the relying party, performs user verification if required (for example, PIN or biometric) and constructs the authenticatorData, which includes the hash of the relying party ID (rpIdHash)
The authenticator finally generates the assertion by signing (authenticatorData + clientDataHash) using the credential’s private key

Response processing
The authenticator returns the assertion (encoded in CBOR) to Windows.
Windows then decodes the CBOR response, extracts the assertion components (credential ID, authenticatorData, signature), evaluates the result and completes the WebAuthN operation.

Top👆

Mapping the steps to WebAuthN events

Before we take a look at the WebAuthN events on the Windows client, let us see how the logon process maps directly to the Event Log task categories.

Step	Details	Event entry
Challenge generation	Windows initiates authentication using a FIDO2 credential A TransactionId is created that ties all related events together.	WebAuthN Ctap GetAssertion started (Event ID 1003)
Request construction	Windows builds the CTAP2 request to send to the key Encoded in the request are the rpId and clientDataHash. For Entra ID, the rpId is login.microsoft.com	Cbor encode GetAssertion request (Event ID 1103)
Authenticator processing	Windows transitions from WebAuthN to the CTAP layer, and authenticator interaction begins	Ctap GetAssertion started (Event ID 2100)
Authenticator processing	Windows exchanges CTAP commands with the key This includes: PIN verification (authenticatorClientPIN / getPINToken) Authentication request (authenticatorGetAssertion)	Ctap Usb Send Receive (Event ID 2225)
Response processing	Authenticator returns result to Windows	Ctap GetAssertion completed (Event ID 2102 / 2103)
	Windows interpret the authenticator’s response	Cbor decode GetAssertion response (Event ID 1104)
	Windows completes WebAuthN operation	WebAuthN Ctap GetAssertion completed (Event ID 1004 / 1005)

Top👆

WebAuthN Events

Challenge generation

The WebAuthN Ctap GetAssertion started event (Event ID 1003) indicates that Windows has initiated a WebAuthN authentication operation and is beginning the process of requesting an assertion from an authenticator. This marks the start of the FIDO2 authentication flow but does not yet involve communication with the security key or indicate whether authentication will succeed.

Request construction

The Cbor encode GetAssertion request event (Event ID 1103) shows Windows encoding a targeted WebAuthN GetAssertion request.

When the Request begins with 0x02, it indicates that this is a authenticatorGetAssertion CTAP command.

Note that whether or not a credential ID is present in this event depends on the scenario. When AllowCredentialCount is greater than zero, the request includes one or more specific credential IDs (making it a “targeted” WebAuthN GetAssertion request). When it is zero, the authenticator is performing a credential discovery.

The description may be parsed to get the credential Id and will match the key identifier from Entra ID when Base64 encoded.

The Cbor encode GetAssertion request event (Event ID 1103) is generally the most useful event for auditing each authentication attempts of a FIDO2 security key on a Windows client device.

Top👆

How to parse the CBOR-encoded request

Let us take the Cbor Encode GetAssertion Request event (ID 1103) and parse the CBOR-encoded data in its description

TransactionId: {3443b0f7-a6a2-4b1c-9026-aea3ab93f662}
RpId: login.microsoft.com
ClientDataHashAlgId: S256
ClientDataLength: 176
ClientDataHash: 0x0E3A6FC2C6941563481563AFADF439276A2280A9F59E85197478BB748E625DF3
AllowCredentialCount: 1

Request: 0x02A401736C6F67696E2E6D6963726F736F66742E636F6D0258200E3A6FC2C6941563481563AFADF439276A2280A9F59E85197478BB748E625DF30381A262696450EDE6F30E65534AB78BB0992B8E6D663464747970656A7075626C69632D6B657905A1627570F5

The first byte gives us the CTAP command.
- In this case it is 0x02 which means authenticatorGetAssertion (Client to Authenticator Protocol (CTAP))
Everything after that first byte is the CBOR payload (A401736C6F67696E2E6D6963726F736F66742E636F6D0258200E3A6FC2C6941563481563AFADF439276A2280A9F59E85197478BB748E625DF30381A262696450EDE6F30E65534AB78BB0992B8E6D663464747970656A7075626C69632D6B657905A1627570F5).
- Note that The CBOR payload starts with A4. This means that the CBOR body is a map with 4 entries or named fields.
If you do not want to decode the bytes by hand, a simple way to inspect the payload is to paste it into an online CBOR decoder such as CBOR Playground. The site accepts hex input and can parse it into a readable CBOR structure.
Paste the CBOR payload into the input area. Make sure the input mode is Hex, then use Parse.

For this example, the decoded result is:

{
1: "login.microsoft.com",
2: h'0E3A6FC2C6941563481563AFADF439276A2280A9F59E85197478BB748E625DF3',
3: [
    {
      "id": h'EDE6F30E65534AB78BB0992B8E6D6634',
      "type": "public-key"
    }
],
5: {
    "up": true
}
}

This output is still using the CTAP numeric field keys (1-5), so the next step is to translate those numbers into the field names used by the GetAssertion request based on the table at Client to Authenticator Protocol (CTAP):
- 1 = rpId
- 2 = clientDataHash
- 3 = allowList
- 5 = options
So in plain English, the payload says:

{
"rpId": "login.microsoft.com",
"clientDataHash": "0E3A6FC2C6941563481563AFADF439276A2280A9F59E85197478BB748E625DF3",
"allowList": [
    {
      "id": "EDE6F30E65534AB78BB0992B8E6D6634",
      "type": "public-key"
    }
],
"options": {
    "up": true
}
}

For a bit more detail about each field:
- Key 1 contains the relying party ID
- Key 2 contains the 32-byte clientDataHash
- Key 3 contains an allowList array with one credential descriptor
- Key 5 contains an options map
- Inside options, up: true means user presence was requested

For details on how to decode the CBOR payload yourself see RFC 8949: Concise Binary Object Representation (CBOR)

Top👆

Translating Entra key identifier to WebAuthN Credential Id

The key identifier from Entra ID when Base64 decoded will match the CredentialId in the event.

A sample PowerShell function that does this is given below:

function Convert-Base64UrlToBytes { param( [Parameter(Mandatory=$true)] [string]$Base64Url ) # Convert Base64url to normal Base64 $b64 = $Base64Url.Replace('-', '+').Replace('_', '/') # Add padding if required switch ($b64.Length % 4) { 2 { $b64 += "==" } 3 { $b64 += "=" } 0 { } # already aligned 1 { throw "Invalid Base64url string length" } } # Decode Base64 → byte array return [Convert]::FromBase64String($b64) } cls # Conversion from Base64URL encoded identifier (user object) $bytes = Convert-Base64UrlToBytes "7ebzDmVTSreLsJkrjm1mNA2" ($bytes | ForEach-Object { $_.ToString("X2") }) -join "" # Conversion from Base64 encoded identifier (audit log) $bytes = Convert-Base64UrlToBytes "7ebzDmVTSreLsJkrjm1mNA==" ($bytes | ForEach-Object { $_.ToString("X2") }) -join ""

Top👆

Authenticator processing

The Ctap GetAssertion started event (Event ID 2100) shows Windows starting a CTAP GetAssertion operation against a specific FIDO2 key.

Authenticator PIN Validation

All PIN attempts generate a Ctap Usb Send Receive event (Event ID 2225) where the Request starts with 0x06A401010205

06 means this is a PIN-related command
If the request starts with 06A401010205 this denotes a getPinToken flag, meaning a PIN verification attempt.

If the Response starts 0x00, it indicates a Success.

Other possible values for the response field are:

0x31 - Incorrect PIN
0x33 - PIN Auth Invalid
0x34 - PIN Required

Therefore, Ctap Usb Send Receive events (Event ID 2225) where the Request starts with 0x06A401010205 will report all security key PIN attempts, both successful and unsuccessful, on the client device.

Top👆

How to parse the CBOR-encoded request

Let us try and parse the CBOR-encoded data in the event’s description once again.

TransactionId: {3443b0f7-a6a2-4b1c-9026-aea3ab93f662}
Request Command: 0x90
Response Command: 0x90

Request: 0x06A40101020503A5010203381820012158206F67957900E6BBEC39838F015E3F5D6918F5A8D76E401828363E51F6C256541222582027E8B11854CE667B8EE19DF3A3DEE4A3F0DB43809811C3A93F2E9C0293E466AA0650746BE172CD2402CFFCC94734BC98D16A

Response: 0x00A1025093B2EE5307CC81EA08684FEBE22D536D

The first byte in the request (0x06) gives us the authenticatorClientPIN CTAP command (Client to Authenticator Protocol (CTAP))
Everything after that first byte is the CBOR payload (A40101020503A5010203381820012158206F67957900E6BBEC39838F015E3F5D6918F5A8D76E401828363E51F6C256541222582027E8B11854CE667B8EE19DF3A3DEE4A3F0DB43809811C3A93F2E9C0293E466AA0650746BE172CD2402CFFCC94734BC98D16A).
- As before A4 means that the CBOR body is a map with 4 entries or named fields.
Parsing this payload using CBOR Playground we get:

{
1: 1,
2: 5,
3: {
    1: 2,
    3: -25,
    -1: h'6F67957900E6BBEC39838F015E3F5D6918F5A8D76E401828363E51F6C2565412',
    -2: h'27E8B11854CE667B8EE19DF3A3DEE4A3F0DB43809811C3A93F2E9C0293E466AA'
},
6: h'746BE172CD2402CFFCC94734BC98D16A'
}

Using the table at Client to Authenticator Protocol (CTAP) to translate the numeric keys we have:
- key 1 = pinUvAuthProtocol
- key 2 = subCommand
- key 3 = keyAgreement
- key 6 = pinHashEnc
After the translation, the payload says:

{

"pinUvAuthProtocol": 1,
"subCommand": 5,
"keyAgreement": {
    1: 2,
    3: -25,
    -1: h'6F67957900E6BBEC39838F015E3F5D6918F5A8D76E401828363E51F6C2565412',
    -2: h'27E8B11854CE667B8EE19DF3A3DEE4A3F0DB43809811C3A93F2E9C0293E466AA'
},
"pinHashEnc": h'746BE172CD2402CFFCC94734BC98D16A'
}

The information most useful for us here is "subCommand": 5, which as you can see from the second table in Client to Authenticator Protocol (CTAP) tells is a getPinToken subcommand.

In summary, when the request begins with 06 A4 01 01 02 05, it can be identified as a PIN verification attempt. The leading byte 0x06 indicates the CTAP authenticatorClientPIN command. The next byte A4 shows that the CBOR payload is a map with four fields. Within that map, the sequence 01 01 corresponds to pinUvAuthProtocol = 1, and 02 05 corresponds to subCommand = 5. In the Client PIN command set, subcommand 5 represents getPinToken, which is used during PIN verification. Together, this byte pattern reliably indicates that the operation is a PIN-based authentication step rather than a standard assertion request.

Turn on Annotate if you want the CBOR Playground site to show how each byte is interpreted.

Top👆

Authenticator GetAssertion operation

Ctap Usb Send Receive events (Event ID 2225) where the Request begins with 0x02 indicate an authenticatorGetAssertion CTAP2 Operation. The encoded payload includes the RpId and ClientDataHash.

If the Response begins with 0x00 it was successful. Included in the CBOR payload is the id (Credential ID) and the rpIdHash

Top👆

Response processing

The Ctap GetAssertion completed event (Event ID 2102) tells us that the authenticator successfully completed a GetAssertion operation and returned a valid signed assertion to Windows.

Included in the response payload are security key device information, status of the operation (6673746174757300 stands for status = 0), the credential used and authenticator data.

The Cbor decode GetAssertion response event (Event ID 1104) is logged when the authenticator successfully returns a WebAuthN assertion for the relying party using a particular credential.

This is one of the best events to track successful authentication because the important fields are already parsed out.

The RpIdHash of 356C9ED4A09321B9695F1EAF918203F1B55F689DA61FBC96184C157DDA680C81 is the SHA-256 hash of “login.microsoft.com”
A Flags value of 0x85 means 0x80 + 0x04 + 0x01
- 0x01: UP (the user was present and interacted with the key)
- 0x04: UV (user verification succeeded, which in this scenario means PIN was successfully validated)
- 0x80: ED (extension data was included in the assertion)
The CredentialId of EDE6F30E65534AB78BB0992B8E6D6634 when Base64 encoded, will match the key identifier in Entra.

Therefore, Cbor decode GetAssertion response events (Event ID 1104) will tell you which users successfully authenticated to the Windows device using a FIDO2 security key.

Finally, the WebAuthN Ctap GetAssertion completed event (Event ID 1004) tells us that WebAuthN GetAssertion operation completed successfully for this TransactionId.

Top👆

Tying it all together

I started out by outlining what my customer’s monitoring goals were; the table below summarizes the events recommended for monitoring:

What to Monitor	Event	Notes
Each use of a FIDO2 security key on a Windows client device.	Cbor encode GetAssertion request (Event ID 1103)	Filter for events where: Request begins with 0x02 AllowCredentialCount is greater than zero. Parse Request for credential Id. Base64 encode credential Id to match key identifier and user in Entra ID.
All attempts, both successful and unsuccessful, when a PIN was tried to unlock a credential on the FIDO2 security key on the device.	Ctap Usb Send Receive (Event ID 2225)	Filter for events where Request starts with 0x06A401010205. The Response property indicates result.
Which user successfully authenticated to the Windows device using their FIDO2 security key.	Cbor decode GetAssertion response (Event ID 1104)	Base64 encode credential Id to match key identifier and user in Entra ID.

The techniques outlined in this document show how to identify individual FIDO2 credentials, track PIN verification attempts, and conclusively determine which user authenticated to a Windows device using a security key. With this approach, passwordless authentication becomes not only more secure, but also more observable and supportable in enterprise environments.

Azure Database Security Newsletter - April 2026

PieterVanhove — Wed, 01 Apr 2026 08:08:13 GMT

Welcome to the quarterly edition of Azure Database Platform Security Newsletter. In this newsletter we highlight the importance of strong encryption for data security, and call out recent encryption, key management, and auditing enhancements designed to help you strengthen your security posture while simplifying operational management.

Data is one of the most critical assets organizations manage, and protecting it is essential to maintaining trust, resilience, and long‑term success. As cyber threats continue to evolve and regulatory expectations increase, strong encryption has become a foundational requirement rather than an optional safeguard.

Encryption protects sensitive data across its entire lifecycle. Data is encrypted at rest using Transparent Data Encryption (TDE) to protect stored information, in transit using Transport Layer Security (TLS) to secure data as it moves across your application and server, and in use through Always Encrypted to help ensure data remains protected even from high-privileged users. Together, these capabilities reduce risk and support compliance obligations.

Feature highlights 💡

Customer-Managed Keys in Fabric SQL Database

Customer-Managed Keys (CMK) are now generally available for Fabric SQL Database, allowing you to use Azure Key Vault keys to encrypt all workspace data, including all SQL Database data. This feature gives organizations greater control over key management and helps meet data governance and encryption requirements. More information on How to encrypt Fabric SQL Database with Customer Managed Keys (Video).

Versionless keys for Transparent Data Encryption in Azure SQL Database

Azure SQL Database now lets you use versionless key URIs for Transparent Data Encryption (TDE) with customer-managed keys, automatically applying the latest enabled key from Azure Key Vault or Managed HSM. This update simplifies encryption management.

Auditing in Fabric SQL Database

Auditing for Fabric SQL Database is now generally available. Organizations can track and log database activities, addressing questions about data access for compliance, threat detection, and forensic analysis. Audit logs are stored in One Lake, and access is controlled by Fabric workspace roles and SQL permissions.

Best Practices Corner

Retain all historical TDE keys and key versions

Always keep all historical Transparent Data Encryption (TDE) keys and their versions. Databases and backups remain encrypted with the key version that was active at the time of encryption. Restoring an older database requires access to the exact key version used. Deleting older keys or versions can make database restore impossible and result in permanent data loss. See Everything you need to know about TDE key management for database restore.

Apply the Principle of Least Privilege

Always grant users, applications, and services the minimum level of access required to perform their database tasks. Avoid broad administrative or owner-level permissions unless absolutely necessary. Regularly review, restrict, and remove excessive or unused privileges to reduce the attack surface and limit the impact of compromised credentials or configuration errors. This control aligns with established security standards such as NIST SP 800‑53 (AC‑6: Least Privilege), CIS Critical Security Controls, ISO/IEC 27002, and OWASP database security guidance.

Enable Auditing on Azure SQL and SQL Server

Always enable auditing on Azure SQL to record database activities for security monitoring, compliance, and forensic investigation. Auditing provides visibility into database access and changes, helping detect unauthorized or suspicious behavior and supporting incident response and regulatory requirements. See Auditing - Azure SQL Database.

Blogs and Video Spotlight 🅱️

In the last three months, we've published blog posts on major releases and features. These updates offer practical insights and highlight the latest in data security and database management.

Why ledger verification is non-negotiable

How to Enable Microsoft Entra ID for Azure Cosmos DB (NoSQL)

Why Developers and DBAs love SQL’s Dynamic Data Masking (Series-Part 1)

Announcing Preview of bulkadmin role support for SQL Server on Linux

Zero Trust for data: Make Microsoft Entra authentication for SQL your policy baseline

Community & Events 👥

The data platform security team will be on-site at several upcoming events. Come and say hi!

Previous events

SQL Konferenz

FABCON 26 - Microsoft Fabric Community Conference - FABCON

SQLCON - Microsoft SQL Community Conference - SQLCON

Upcoming events

SQLBits

DataGrillen

Call to action 📢

Take 15 minutes this week to validate your database encryption posture: confirm TDE is enabled, review your key management plan (including retaining historical key versions), and ensure TLS is enforced for all connections. If you are using Fabric SQL Database, consider enabling Customer-Managed Keys and turning on Auditing to strengthen governance and investigation readiness. Share this newsletter with your security and DBA partners and align on one concrete improvement you can complete.

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

TysonPaul — Mon, 30 Mar 2026 18:45:30 GMT

Member: TysonPaul | Microsoft Community Hub

Automating Large‑Scale Data Management with Azure Storage Actions

Team Blog: ITOps Talk

Author: 1Nataraj

Published: 02/25/2026

Summary: Azure Storage Actions is a fully managed, serverless automation platform that simplifies large-scale data management in Azure Blob and Data Lake Storage. It enables users to automate tasks such as tagging, tiering, deletion, and applying immutability based on customizable conditions—without custom code or infrastructure. Administrators can centrally define tasks and assign them across multiple storage accounts, with built-in preview, monitoring, and audit features. Use cases include compliance, cost optimization, and metadata management, making it ideal for organizations managing millions of items across vast storage estates. Azure Storage Actions is available in over 40 Azure regions.

Migration, Modernization & Agentic Tools

Team Blog: ITOps Talk

Author: OrinThomas

Published: 02/25/2026

Summary: The article discusses how agentic tools, such as those in Azure Copilot and GitHub Copilot, transform cloud migration and modernization from one-time projects into ongoing, autonomous systems. These tools dynamically discover environments, recommend modernization paths, automate migration steps, and continuously optimize workloads for cost, performance, security, and compliance. By embedding governance and leveraging real-time telemetry, agentic tools reduce manual effort, minimize errors, and ensure migrations are efficient, secure, and aligned with enterprise standards, providing continuous improvement post-migration.

What’s new in FinOps toolkit 13 – January 2026

Team Blog: FinOps

Author: Michael_Flanakin

Published: 02/09/2026

Summary: The January 2026 update to the FinOps toolkit focuses on stability, usability, and community engagement. Key enhancements include improved documentation, new features like configurable Key Vault purge protection, and expanded support for Parquet format and compression in Cost Management exports via PowerShell. Security, reliability, and extensibility have been strengthened for FinOps hubs, with numerous bug fixes across Power BI reports, workbooks, and the Azure Optimization Engine. The release highlights ongoing community involvement, upcoming features like AI automation, and premium services to help organizations deploy and scale the toolkit effectively.

Managed Identity on SQL Server On-Prem: The End of Stored Secrets

Team Blog: Core Infrastructure and Security

Author: RyadB

Published: 02/23/2026

Summary: **Summary:** The article explains how SQL Server 2025 on-premises, when connected to Azure Arc, can use Managed Identity to access Azure resources without storing secrets like SAS tokens or keys. This approach eliminates risks of secret storage, rotation, and auditing complexity by leveraging Microsoft Entra ID for identity management and RBAC for permissions. The article details configuration steps, migration from stored credentials, troubleshooting, and current limitations, highlighting improved security and simplified management for on-prem SQL Server accessing Azure services.

Running Text to Image and Text to Video with ComfyUI and Nvidia H100 GPU

Team Blog: Core Infrastructure and Security

Author: HoussemDellai

Published: 02/27/2026

Summary: This article provides a step-by-step guide for setting up and running ComfyUI, a node-based interface for AI-powered text-to-image and text-to-video generation, on Azure VMs with Nvidia H100 GPUs. It details both automated (Terraform) and manual setup methods, including installing drivers, dependencies, and downloading required models. The guide explains accessing ComfyUI’s web portal, workflow configuration, and model management to create high-quality images and videos efficiently. It also includes important notes about GPU driver compatibility and offers links to official documentation and scripts for further reference.

Unlock outbound traffic insights with Azure StandardV2 NAT Gateway flow logs

Team Blog: Azure Networking

Author: cozhang

Published: 02/06/2026

Summary: The article introduces Azure’s StandardV2 NAT Gateway, highlighting its new features such as zone-redundancy, enhanced performance, dual-stack support, and, notably, flow logs. Flow logs provide detailed visibility into outbound traffic, enabling security auditing, compliance, usage analytics, and troubleshooting. The article explains how to enable and use flow logs to diagnose connectivity issues and optimize network architecture. It emphasizes the importance of flow logs for monitoring established outbound connections and offers troubleshooting steps for connection drops, recommending best practices for resilient Azure deployments.

Centralized cluster performance metrics with ReFrame HPC and Azure Log Analytics

Team Blog: Azure High Performance Computing (HPC)

Author: jimpaine

Published: 02/06/2026

Summary: The article outlines how to integrate ReFrame HPC, a flexible high-performance computing testing framework, with Azure Log Analytics for centralized performance monitoring across diverse clusters and environments. It details deploying necessary Azure resources, configuring ReFrame for HTTP logging, and running performance tests with results sent to Log Analytics. This integration enables unified, standardized metrics collection, cross-cluster comparisons, trend analysis, and improved system visibility—supporting migration, development, and operational assurance in heterogeneous HPC environments.

Azure Recognized as an NVIDIA Cloud Exemplar, Setting the Bar for AI Performance in the Cloud

Team Blog: Azure High Performance Computing (HPC)

Author: Fernando_Aznar

Published: 02/18/2026

Summary: Microsoft Azure has been recognized as the first NVIDIA Exemplar Cloud for its world-class, end-to-end AI workload performance, now validated for both H100 and next-generation GB300 (Blackwell) systems. This designation reflects Azure’s optimized full-stack infrastructure—including compute, networking, and software integration—delivering predictable, efficient, and scalable AI training at production scale. Customers benefit from faster time-to-train, improved ROI, and confidence in Azure’s readiness for advanced AI workloads, ensuring consistent high performance from proof-of-concept to deployment without sacrificing cloud flexibility or manageability.

Reference Architecture for Highly Available Multi-Region Azure Kubernetes Service (AKS)

Team Blog: Azure Architecture

Author: rgarofalo

Published: 02/03/2026

Summary: The article presents a reference architecture for highly available, multi-region Azure Kubernetes Service (AKS) deployments. It compares active/active, active/passive, and deployment stamp models, detailing their trade-offs in availability, complexity, and cost. Key components include Azure Front Door for global traffic routing, geo-replicated data services, centralized monitoring, and consistent security controls. The architecture emphasizes resilience through fault isolation, automated recovery, and regular testing. It offers practical guidance for cloud architects to design AKS platforms that withstand regional outages, ensuring business continuity and scalable operations across Azure regions.

Reactive Incident Response with Azure SRE Agent: From Alert to Resolution in Minutes

Team Blog: Azure Architecture

Author: Sabyasachi-Samaddar

Published: 02/18/2026

Summary: **Summary:** The article details how Azure SRE Agent revolutionizes incident response by automating investigation and triage as soon as an alert fires, reducing resolution times from hours to minutes. Through two real-world scenarios—a SQL connectivity outage and a VM CPU spike—the agent autonomously diagnosed issues, proposed remediations, and required minimal human intervention. Custom Incident Response Plans and instructions enable context-aware, consistent, and rapid resolutions, with automated post-incident documentation. Key benefits include faster MTTR, reduced manual toil, and improved knowledge capture, though some technical challenges remain. Azure SRE Agent is currently in preview.

Cross Forest Enrollment – PKISync.PS1

Team Blog: Ask the Directory Services Team

Author: Manuel_Alvarez_V

Published: 02/19/2026

Summary: The article explains how to use the PKISync.ps1 PowerShell script for cross-forest certificate enrollment in Active Directory environments. PKISync synchronizes PKI-related objects, such as certificate templates and CA configurations, from a source forest to a target forest, enabling certificate requests across forests. It details the setup requirements, including two-way forest trusts, LDAP referral configuration, and certificate publishing. Although PKISync is considered legacy, automating its use can facilitate simple cross-forest enrollment, but CEP/CES is recommended for modern, secure deployments. The article concludes with best practices and automation tips for PKISync.

What’s New in Windows Group Policy Preferences Debug Logging

Team Blog: Ask the Directory Services Team

Author: TagoreN

Published: 02/27/2026

Summary: The article outlines a new feature in Windows 11 24H2 and 25H2 (from February 2026 preview updates) that allows administrators to enable Group Policy Preferences (GPP) debug logging directly through Local Group Policy, not just domain-based GPOs. This simplifies troubleshooting by allowing detailed logging on client devices without domain reliance. The article explains how to configure logging, manage trace file locations, and set necessary permissions. Overall, this update enhances flexibility and efficiency for IT professionals managing and debugging GPP issues on Windows client devices.

Public Preview: Restrict usage of user delegation SAS to an Entra ID identity

Team Blog: Azure Storage

Author: ellievail

Published: 02/26/2026

Summary: Microsoft has announced the public preview of user-bound user delegation SAS for Azure Storage, enhancing security by restricting SAS token usage to a specific Microsoft Entra ID identity. This feature extends user delegation SAS, requiring the end user to authenticate with Entra ID to access storage resources. It supports cross-tenant scenarios and incurs no additional cost beyond standard storage transactions. User-bound SAS is available via REST APIs, SDKs, PowerShell, and CLI for all GPv2 storage accounts in public regions, with detailed steps provided for setup and role assignment.

Azure Migrate: Now Supporting Premium SSD V2, Ultra and ZRS Disks as Targets

Team Blog: Azure Storage

Author: Lakshya_Jalan

Published: 02/18/2026

Summary: Azure Migrate now supports Premium SSD v2, Ultra Disk, and ZRS Disks as migration targets, with Premium SSD v2 and ZRS generally available and Ultra Disk in public preview. This update enhances assessment and migration by enabling tailored recommendations based on workload performance needs, offering greater flexibility, performance, and resiliency. Users can now migrate demanding, mission-critical workloads to Azure using these advanced disk options, benefiting from features like zonal redundancy and customizable performance. The enhancements streamline migrations and ensure optimal resource alignment, supporting petabytes of data already migrated during the preview phase.

Public Preview: Automatic zone balance for Virtual Machine Scale Sets

Team Blog: Azure Compute

Author: HilaryWang

Published: 02/17/2026

Summary: Azure has introduced the public preview of automatic zone balance for Virtual Machine Scale Sets, which automatically monitors and redistributes VM instances across availability zones to maintain optimal resiliency. This feature addresses imbalances that can occur over time, minimizing the impact of zone failures without manual intervention. The system uses health checks, respects instance protection policies, and ensures workload capacity during rebalancing. Automatic instance repair is also enabled by default. Users can join the preview by enabling the feature and meeting specific prerequisites. This capability reduces operational overhead while enhancing workload reliability and zone-level resilience.

Azure Automated Virtual Machine Recovery: Minimizing Downtime

Team Blog: Azure Compute

Author: Jon_Andoni_Baranda

Published: 02/04/2026

Summary: Azure Automated Virtual Machine Recovery is a built-in Azure feature that minimizes VM downtime through fast, intelligent, and automated recovery processes. Without requiring customer setup, it continuously monitors VM health, rapidly detects failures, diagnoses issues, and applies the optimal recovery action, all without customer intervention. Leveraging detailed recovery event annotations, it provides deep visibility into incident timelines and helps optimize recovery strategies. Over the past 18 months, this system has halved average VM downtime, strengthening business continuity, reducing financial impact, and reinforcing customer trust in Azure’s reliable cloud platform.

Support tip: Resolve device noncompliance with Mobile Threat Defense partner apps

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 02/02/2026

Summary: This article provides guidance for resolving device noncompliance issues when using Mobile Threat Defense (MTD) partner apps, like Microsoft Defender for Endpoint, with Microsoft Intune. It outlines troubleshooting steps for users to restore compliance—installing, activating, refreshing, or reinstalling the MTD app—and checking compliance status. It also details simplified remediation workflows for iOS/iPadOS and methods for resetting the MTD connection on Android if sign-out is blocked, helping users regain access to work or school resources and reducing support overhead.

How to enable HTTPS support for Microsoft Connected Cache for Enterprise and Education

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 02/20/2026

Summary: Starting June 16, 2026, Intune will require HTTPS for Microsoft Connected Cache when delivering Win32 apps. To maintain caching benefits and reduce bandwidth, administrators must configure HTTPS on Connected Cache nodes using a CA-signed TLS certificate. The guide details generating a CSR on the node, signing and importing the certificate, and validating HTTPS on both Windows and Linux hosts. It also covers troubleshooting, maintenance, and renewal. Without HTTPS, devices will revert to using the CDN for Intune app downloads. Other content types remain unaffected. Early configuration ensures seamless transition and continued performance benefits.

The Copilot resource guide to share with your employees

Team Blog: FastTrack

Author: JulieHersum

Published: 02/19/2026

Summary: The article introduces the "Essential Copilot resource hubs for employees," a centralized guide designed to streamline Microsoft Copilot onboarding and support. It helps adoption leaders structure learning paths, IT admins share resources efficiently, and all employees access consistent guidance. The guide consolidates key Microsoft Copilot resources, making it easier for organizations to accelerate adoption and customize internal policies. Additional support is available through FastTrack and the Microsoft 365 Accelerator site, offering expert guidance, templates, and personalized assistance to boost Copilot deployment and change management efforts.

Copilot adoption: Move your org from pilot to production with this guide

Team Blog: FastTrack

Author: JulieHersum

Published: 02/19/2026

Summary: The article introduces a comprehensive guide for IT admins and Copilot adoption leads to streamline the rollout of Microsoft 365 Copilot. Organized around the adoption lifecycle (plan, build, operate), the guide highlights eight essential resource hubs, practical rollout steps, and audience-specific resources to ensure effective, governed adoption. It also promotes Microsoft FastTrack, which offers expert support, self-service resources, and personalized assistance to accelerate and scale Copilot deployment at no extra cost.

Azure Virtual Desktop is now available in US Gov Texas in Azure Government

Team Blog: Azure Virtual Desktop

Author: Ron_Coleman

Published: 02/04/2026

Summary: Azure Virtual Desktop is now available in the USGov Texas region of Azure Government, offering customers a new option for deploying secure and flexible virtual desktop environments. This expansion enables improved connection performance, reduced latency, and enhanced responsiveness by allowing host pool creation directly in the region. It supports mission needs, geographic distribution, and regulatory requirements, while maintaining Azure Government’s compliance and security standards. Customers can now leverage multiple regions for greater flexibility and performance in their virtual desktop deployments.

RDP Shortpath (UDP) over Private Link is now generally available

Team Blog: Azure Virtual Desktop

Author: Rinku_Dalwani

Published: 02/17/2026

Summary: Azure Virtual Desktop now supports UDP-based RDP Shortpath over Private Link, enabling direct, high-performance RDP connections between session hosts and clients using private IPs. This complements existing TCP connectivity, helping customers with strict private network boundaries. Administrators must explicitly enable UDP in Azure portal settings to use this feature. The opt-in model ensures secure and predictable transport, giving full control over UDP introduction. This enhancement is recommended for customers needing precise routing and policy enforcement in regulated environments, while standard AVD connectivity remains suitable for most deployments. Full configuration guidance is available in Azure documentation.

Migrating Workloads from AWS to Azure: A Structured Approach for Cloud Architects

Team Blog: Azure Migration and Modernization

Author: rhack

Published: 02/18/2026

Summary: The article outlines a structured, five-phase approach for migrating workloads from AWS to Azure, emphasizing a like-for-like architecture to minimize risk and maintain operational stability. Key phases include planning, preparation, execution, evaluation, and decommissioning, each requiring thorough documentation, stakeholder alignment, testing, and validation. The recommended migration strategy is blue/green deployment for risk mitigation. The workload team should lead the migration, supported by external Azure experts. Success depends on careful planning, phased execution, and post-migration optimization, with organizational knowledge-sharing encouraged for future improvements.

Modernizing for the AI Era: Accelerating Application Transformation with Agentic Tools

Team Blog: Azure Migration and Modernization

Author: MarcoB

Published: 02/12/2026

Summary: The article highlights the urgent need for organizations to modernize legacy applications to thrive in the AI era. Legacy systems drain resources and hinder innovation, but new agentic tools—such as GitHub Copilot, Azure Migrate, and Azure Copilot—use AI to automate and accelerate application transformation. These tools reduce manual effort, boost accuracy and safety, and make modernization accessible, empowering teams to focus on innovation. The result is faster, safer, and more consistent modernization, enabling organizations to continuously evolve their applications for intelligent, cloud-optimized environments. Practical steps and resources are provided to guide organizations in getting started.

Secure DNS with DoH: Public Preview for Windows DNS Server

Team Blog: Networking

Author: JorgeCañas

Published: 02/09/2026

Summary: Microsoft has launched a public preview of DNS over HTTPS (DoH) for Windows DNS Server, enabling encrypted and authenticated DNS queries within on-premises networks. This upgrade enhances security and privacy by preventing DNS traffic from being exposed or intercepted, aligning with Zero Trust principles and U.S. federal requirements. The DoH feature, included in the February 2026 update for Windows Server 2025, is disabled by default and currently intended for evaluation only. Existing DNS functionality remains unchanged, with new tools added for DoH management. Feedback is encouraged to improve the feature before general availability.

Announcing Public Preview: Simplified Machine Provisioning for Azure Local

Team Blog: Azure Arc

Author: PragyaDwivedi

Published: 02/26/2026

Summary: Microsoft has announced the Public Preview of Simplified Machine Provisioning for Azure Local, streamlining edge infrastructure deployment. The new process centralizes configuration in Azure, requiring minimal on-site expertise—staff only need to rack, power on hardware, and insert a prepared USB. Secure provisioning uses industry standards like FIDO Device Onboarding and Azure Arc Site for consistent, automated deployments across multiple locations. IT teams manage and monitor provisioning remotely, reducing errors and speeding up setup. Once complete, machines are ready for cluster creation and workload deployment, significantly simplifying and scaling Azure Local deployments.

Azure CLI Windows MSI Upgrade Issue: Root Cause, Mitigation, and Performance Improvements

Team Blog: Azure Tools

Author: Alex-wdy

Published: 02/03/2026

Summary: The article discusses a critical issue affecting Azure CLI upgrades on Windows using the MSI installer, where users upgrading from version 2.76.0 (or earlier) to 2.77.0 (or later) encountered startup crashes due to missing Python extension files. The root cause was a versioning conflict during upgrade, leading to incomplete installations. The article details recovery steps, recommends upgrading to version 2.83.0, and highlights improvements to the MSI upgrade process, making installations faster and more reliable by simplifying file replacement logic and eliminating slow version checks. Users are encouraged to upgrade and report issues if encountered.

Navigating the 2025 holiday season: Insights into Azure’s DDoS defense

Team Blog: Azure Network Security

Author: Jdasari

Published: 02/18/2026

Summary: During the 2025 holiday season, Azure observed a rise in burst-style DDoS attacks, with high-intensity, short-lived surges targeting packet processing and connection-handling layers. Most attacks were automated and brief, but the cumulative impact was operationally draining, especially for latency-sensitive sectors like gaming. Botnet-driven attacks rapidly shifted targets, exploiting inconsistent defenses. Azure DDoS Protection mitigated over 174,000 attacks, underscoring the need for always-on, automated, and layered security. Organizations are urged to standardize protections, proactively monitor, and adopt Zero Trust and multi-layered defense strategies to ensure resilience against evolving threats in 2026.

A Practical Guide to Azure DDoS Protection Cost Optimization

Team Blog: Azure Network Security

Author: SaleemBseeu

Published: 02/18/2026

Summary: The article provides strategies for optimizing Azure DDoS Protection costs. It explains the differences between DDoS Network Protection (best for large-scale, centralized management) and DDoS IP Protection (for few, specific endpoints). Key recommendations include consolidating protection plans to reduce base costs, selectively applying protection based on workload exposure, preventing unnecessary spend via regular reviews, and using cost management tools and tagging for visibility. The guide emphasizes aligning protection with actual risk and criticality, and offers scripts and checklists to support ongoing cost-efficient DDoS defense.

Implementing Intune RBAC and Scope Tags for Zero Trust and Least Privilege

ChrisVetter — Mon, 30 Mar 2026 12:48:45 GMT

If you’re rolling out Microsoft Intune at scale, the hardest part usually isn’t creating policies—it’s making sure the right people can manage the right things, without turning every admin account into a “keys to the kingdom” risk. In this guide, you’ll learn how to use Intune RBAC and Scope Tags to enforce least privilege, build clear management boundaries by region/agency/environment, and pair device compliance with Entra Conditional Access to strengthen a Zero Trust posture—plus a practical RACI approach so ownership stays clear as your environment grows.

TL;DR

Use Intune RBAC to align admin permissions to job responsibilities, reducing standing privilege and limiting who can change policies, apps, and security settings.
Use Scope Tags to create visibility/management boundaries (region, agency, environment) so admins only see and manage what they own.
Pair Intune compliance + Entra Conditional Access to enforce “access only from compliant devices / protected apps,” which supports a Zero Trust posture.
Establish a RACI model so ownership is explicit across Endpoint, Identity, Security, Apps, AD, Help Desk, and Compliance teams.
Track outcomes (compliance rates, blocked risky sign-ins, RBAC audit events, scope boundary effectiveness, GPO migration progress) and review on a regular cadence.

Zero Trust and Least Privilege in Modern Endpoint Management

Zero Trust is an approach to security that treats every access attempt as untrusted until it is proven otherwise. Rather than relying on “inside the network = safe,” organizations evaluate each request using signals such as user identity, device health, location, and risk, and they re-check those signals over time. In an endpoint program, Microsoft Intune supports this model by establishing device compliance, applying app protection where appropriate, and working with Conditional Access so that access decisions can depend on verified user and device posture.

A practical way to describe Zero Trust is through three recurring themes: (1) make access decisions using explicit verification (strong authentication plus context and risk signals), (2) minimize privilege by granting only the access needed and reducing standing admin rights where possible, and (3) design for compromise by limiting lateral movement and reducing the impact of any single breach. These concepts align with Microsoft’s published Zero Trust guidance.

Role-Based Access Control (RBAC) in Intune allows organizations to delegate administrative permissions based on roles, responsibilities, and scope. For modern endpoint environments, RBAC ensures that only authorized personnel can manage devices, deploy configurations, or access sensitive data, which is a foundational control in a Zero Trust model where access is granted based on least privilege and verified identity.

By combining Intune's RBAC capabilities with Scope Tags, organizations can create visibility boundaries that align with their organizational structure, whether by region, department, business unit, or function. This prevents over-allowing permissions by assigning only the rights needed for each role, supports Zero Trust by enforcing least privilege and role-based access, and improves operational security by limiting who can manage devices and policies.

Understanding Intune RBAC Roles and Permissions

Microsoft Intune provides nine built-in RBAC roles designed to address common administrative scenarios. Each role has predefined permissions that determine what actions users can perform within the Intune environment, helping organizations delegate administrative tasks while maintaining control over access to sensitive information. The built-in roles include Intune Administrator with full access to all Intune features and settings (This role should not be used for every day management tasks and should be limited to only a few individuals who would be responsible for performing more elevated tasks in the Intune Portal), Policy and Profile Manager who manages device configuration profiles and compliance policies, Application Manager who manages mobile and managed applications, Endpoint Security Manager who manages security and compliance features, Help Desk Operator who performs remote tasks on users and devices, Read-Only Operator with view-only access, School Administrator for Windows 10 devices in Intune for Education, Intune Role Administrator who manages custom roles and assignments, and Cloud PC roles for managing Cloud PC features and Windows Autopatch roles for managing updates.

Built-in Role	Primary Permissions	Use Case
Application Manager	Manages mobile and managed applications, app configuration policies, and app protection policies	Teams responsible for deploying and managing organizational apps across devices
Policy and Profile Manager	Manages device configuration profiles, compliance policies, and conditional access policies	IT administrators configuring device settings and ensuring compliance across the organization
Endpoint Security Manager	Manages security baselines, endpoint detection and response, and BitLocker policies	Security teams focused on device protection and threat mitigation
Help Desk Operator	Performs remote tasks including device restart, password reset, and remote lock	First-line support staff assisting end users with device issues
Read-Only Operator	View-only access to all Intune data and reports without modification rights	Auditors and stakeholders needing visibility without administrative capabilities

Beyond built-in roles, Intune supports custom roles that allow administrators to define specific permissions for users or groups based on their responsibilities. Custom roles enable fine-grained access control by selecting granular permissions for each role, ensuring users have access only to the features and data they require. For example, a custom role could grant only the 'Rotate local administrator password' permission to a specific Helpdesk Managers group, demonstrating the principle of least privilege in action.

Create Custom Roles

Login to the Intune Admin Portal with the Intune Administrator Role and navigate to Tenant Administration> Roles > All Roles > Create then select the type of role you want to create. I will select “Intune Role”

Give your Custom Role a Name and a brief description.

Scroll through the list of permissions as they will all be set to no by default and select the permissions relevant to the responsibility of the custom role.

If you have already created your Scope Tag add it here, then review and select create

Once the role is created you can select the new role and create an assignment. Give it a name and description, then select the admin group to be assigned to the role.

Add the groups that the role will be managing.

Add your relevant Scope Tags then select create.

To take things one step further I would recommend leveraging Privileged Identity Management (PIM) for groups so that you can leverage Just-in-Time Assignments for the Intune roles.

One last note on custom roles if you do not want to start from scratch with the permission sets, you can also duplicate a built-in role and modify the permissions as needed. Just select the 3 dots to the right of the role and select Duplicate

Implementing Scope Tags for Distributed IT Management

Scope Tags are labels that help control what different admins can see and manage in Microsoft Intune. By adding scope tags to Intune items like configuration profiles, apps, policies, or device groups and assigning the same labels to admins, organizations create clear boundaries, so each admin only sees the devices and settings they are responsible for. This capability is essential for distributed IT environments where different teams manage different locations, departments, or business units.

Every Intune tenant includes a default scope tag that is automatically applied to all objects and admins, ensuring everything continues working smoothly even without custom tags configured. The key benefits of using scope tags include enabling distributed IT management by allowing regional or departmental admins to manage their specific resources, controlling access by limiting admin visibility to specific resources, enhancing security by preventing unauthorized access, improving organization by grouping resources by scope, and providing flexibility to support multiple administrative models.

Scope tags work together with RBAC role assignments through three components: the role defining what actions admins can perform, scope tags determining which objects admins can see, and scope groups limiting which users and devices they can affect. Common use cases for scope tags include managed service providers limiting access to specific customer resources, regional IT administrators ensuring teams only manage and see objects relevant to their region, separating testing versus production environments when a dedicated test tenant is not available, and separating Azure Virtual Desktop resources for AVD administrators.

Creating Scope Tags

While still under Tenant Administration> Roles select Scope Tags Then Create.

Give it a name and description.

Assign the proper groups then select create.

If this is all implemented properly, the admin will only be able to see items and devices that have the Scope tag that has been assigned to their role. Here are views of the apps in my tenant when signed in as a Intune Administrator (which Scope tags do not apply t

And here are the same views when logged in with an admin with the iOS admin role that we created.

Establishing a RACI Model for Intune Management

While establishing a RACI model is not something done in the Intune portal, it is crucial in my opinion for enterprise customers since Intune covers such a vast number of capabilities that should not all be done by one team if we are practicing least privilege and zero trust.

A RACI matrix is a powerful tool for defining organizational roles and responsibilities, identifying who is Responsible, Accountable, Consulted, and Informed for each activity. In Microsoft Intune management, implementing a RACI model eliminates ambiguity about which teams handle security policies, application management, patch compliance, Conditional Access, and GPO migration.

The RACI framework defines four key roles: Responsible individuals execute the task or deliverable, Accountable is the single person ultimately answerable for correct completion and decision-making authority, Consulted are experts or stakeholders whose feedback is sought during the task, and Informed are those kept up to date on progress or decisions without actively contributing.

For Intune environments, a well-designed RACI matrix promotes organizational alignment by mapping all key stakeholders across central IT and individual agencies or departments, clarifies decision rights by defining who approves, who executes, and who provides input for each Intune activity, ensures accountability by assigning a single accountable party for each deliverable to prevent diffusion of responsibility, and improves communication by identifying upfront who needs to be consulted and kept informed.

Based on internal implementation experience and with Microsoft Federal customers, organizations should list deliverables not just activities, define roles not individual names to ensure the matrix remains relevant as people change positions, enforce exactly one Accountable person per task, assign Responsible, Consulted, and Informed roles thoughtfully, validate in a short review session, publish where work happens, and evolve the matrix as the project evolves.

RACI Matrix for Security Policies and Compliance

The following are just generic examples of some of the workloads and how they could be managed with a RACI matrix.

Security policies and compliance management in Intune require clear ownership across multiple teams. Organizations must define who creates compliance policies requiring device encryption and minimum OS versions, who deploy security baselines like the Microsoft Defender for Endpoint Security Baseline, who manages Conditional Access policies that require device compliance, and who responds to non-compliant devices. A typical RACI model for security policies assigns the Cloud Security Team as Accountable for overall security policy strategy and compliance requirements, the Endpoint Team as Responsible for creating and deploying compliance policies and security baselines in Intune, the Application Team as Consulted for application-specific security requirements, the Help Desk as Informed about policy changes that may affect device compliance status, and the Compliance Team as Consulted to ensure policies meet regulatory requirements and as Informed about compliance status reports.

For patch management and application compliance, the RACI model shifts slightly with the Endpoint Team becoming Accountable for patch deployment strategy and timing, the Application Team becoming Responsible for testing application compatibility with updates, the Help Desk becoming Responsible for addressing user-reported issues after patches, and the Cloud Security Team becoming Consulted for security update prioritization. Organizations implementing Windows Autopatch benefit from Microsoft managing problematic quality and feature update deployment cancellations using telemetry, automatically splitting devices into rings based on percentage of total devices, and managing patching behavior for Windows, Microsoft 365 Apps, Edge, Teams, and Drivers. This shifts some Accountable and Responsible designations to Microsoft while keeping internal teams Informed and Consulted.

Intune Activity	Accountable	Responsible	Consulted	Informed
Security Policy Creation	Cloud Security Team	Endpoint Team	Application Team, Compliance Team	Help Desk
Compliance Policy Deployment	Cloud Security Team	Endpoint Team	Compliance Team	Help Desk, Application Team
Security Baseline Management	Cloud Security Team	Endpoint Team	Application Team	Help Desk, Compliance Team
Patch Management Strategy	Endpoint Team	Application Team	Cloud Security Team	Help Desk, Compliance Team
Non-Compliance Response	Cloud Security Team	Endpoint Team, Help Desk	Compliance Team	Application Team

Application and Conditional Access Management Responsibilities

Application management and Conditional Access in Intune span multiple organizational functions requiring coordinated responsibility. For application lifecycle management, the Application Team is both Accountable and Responsible for deployment strategy, app protection policies, creating and testing app packages and configurations. The Endpoint Team is Consulted for deployment targeting and device compatibility, while the Help Desk is Informed about new applications and support procedures.

For Conditional Access policy management, multiple teams coordinate their expertise. The Cloud Security Team is Accountable for overall Conditional Access strategy and Zero Trust implementation. The Endpoint Team is Responsible for ensuring device compliance status feeds correctly into Conditional Access decisions. The Identity Team is Responsible for configuring Conditional Access policies in Microsoft Entra ID. The Application Team is Consulted about application-specific access requirements, and the Help Desk is both Informed about access restrictions and Responsible for assisting users blocked by Conditional Access policies.

Conditional Access integration with Intune creates a powerful Zero Trust security model where Intune evaluates device compliance based on compliance policies, compliance status is reported to Microsoft Entra ID, Conditional Access policies check device compliance status, and access is granted or blocked based on compliance status.

For mobile application management, the Application Team is both Accountable and Responsible for app protection policies including data protection settings, access requirements like PIN and biometric authentication, and integration with Conditional Access. The Cloud Security Team is Consulted for security requirements, and the Endpoint Team is Informed about app-level controls that complement device-level policies.

GPO Migration to Intune: Roles and Responsibilities

Migrating Group Policy Objects from on-premises Active Directory to Microsoft Intune represents a critical transformation requiring clear ownership and phased execution. The migration process uses Group Policy Analytics, a built-in tool in Intune that analyzes on-premises GPOs by importing them as XML exports and translating them against the Settings Catalog to determine which policies are supported, deprecated, or unsupported in Intune.

Organizations export GPOs from the Group Policy Management Console by right clicking the GPO, selecting Save Report, and saving as XML format. After importing to Intune via Devices > Group Policy Analytics, the tool generates a percentage-based report showing exactly how many settings have a direct 1:1 mapping to modern Intune settings.

The Group Policy Analytics tool categorizes settings into three distinct types: Supported settings that have a direct counterpart in Intune and can be migrated via Settings Catalog policies, Deprecated settings no longer applicable to modern Windows versions, and Not Supported settings that do not currently have a CSP mapping and often require alternative management methods like PowerShell scripts or Proactive Remediations. Approximately 45% of GPOs can be successfully migrated to Settings Catalog, 30% require alternative approaches via PowerShell remediations, and 25% can be deprecated and retired based on typical migration outcomes.

RACI Model for GPO Migration

For the RACI model, the Endpoint Team is Accountable for the overall GPO migration strategy and timeline, the Active Directory Team is Responsible for exporting GPOs and documenting current policy structures, the Application Team is Consulted to validate that application-specific GPOs migrate correctly and that applications continue functioning, the Cloud Security Team is Consulted to ensure migrated policies maintain security posture, and the Help Desk is Informed about changes to device configurations and becomes Responsible for user communication about policy transitions.

Integrating Conditional Access with Device Compliance

Conditional Access integration with Intune device compliance creates an additional layer of security by enforcing access controls based on device compliance status and app protection policies. This integration ensures that only compliant devices and protected apps can access organizational resources, forming a cornerstone of Zero Trust architecture.

Device-Based Conditional Access Implementation

Device-based Conditional Access uses device compliance status from Intune to control access to organizational resources through a four-step process:

Intune evaluates device compliance based on compliance policies
Compliance status is reported to Microsoft Entra ID
Conditional Access policies check device compliance status
Access is granted or blocked based on compliance status

To implement device compliance Conditional Access, organizations first create and assign device compliance policies in Intune requiring elements like BitLocker encryption, Microsoft Defender antivirus enabled, Windows Firewall enabled, and minimum OS version requirements. Then in the Microsoft Entra Admin Center under Security > Conditional Access, administrators create policies specifying:

Users as target groups like Corporate Users
Cloud apps as All cloud apps or selected Microsoft 365 apps
Device platform as Windows or other platforms
Access control requiring device to be marked as compliant

Measuring Success and Continuous Improvement

Organizations implementing Intune RBAC and Scope Tags should establish metrics to measure success and identify areas for continuous improvement. Key performance indicators include percentage of devices compliant with security policies, time to resolve non-compliance issues, number of unauthorized access attempts blocked by Conditional Access, percentage of GPOs successfully migrated to Intune Settings Catalog, and administrative efficiency measured by reduction in time spent on routine management tasks.

Compliance reporting in Intune provides visibility into device compliance status across the organization, with reports showing compliant versus non-compliant devices, specific compliance policy violations, and trends over time. Organizations typically see compliance rates improve from a 65% baseline to 95% or higher within 12 months of implementing proper RBAC roles and Scope Tags. This improvement results from clearer ownership, faster policy deployment, and more focused administrative oversight.

Conditional Access sign-in logs in Microsoft Entra ID reveal which access attempts are granted or blocked, the reasons for access decisions, and patterns of risky sign-ins that may indicate compromised credentials or devices. For RBAC effectiveness, organizations should monitor audit logs to track which administrators are performing which actions, identify any privilege escalation attempts or suspicious administrative activity, and ensure separation of duties is maintained.

Scope tag effectiveness can be measured by confirming that administrators only see resources within their designated scope, tracking incidents where admins requested access outside their scope, and validating that regional or departmental segregation is working as intended. Organizations should establish a regular review cadence with monthly compliance and security posture reviews, quarterly RBAC and Scope Tag access reviews, bi-annual GPO migration progress assessments, and annual Zero Trust maturity assessments.

Disclaimer

All screenshots are from a non-production lab environment and can/will vary per environment. All processes and directions are of my own opinion and not of Microsoft and are from my years of experience with the Intune product in multiple customer environments

References

Role-based access control (RBAC) with Microsoft Intune - Microsoft Intune | Microsoft Learn

Use role-based access control (RBAC) and scope tags for distributed IT - Microsoft Intune | Microsoft Learn

Aligning responsibilities across teams - Cloud Adoption Framework | Microsoft Learn

How to Require Device Compliance with Conditional Access - Microsoft Entra ID | Microsoft Learn

Configuring Microsoft Intune just-in-time admin access with Azure AD PIM for Groups | Microsoft Community Hub