rss.livelink.threads-in-node

From DLP Alert Volume to Measurable Detection Assurance

Jon_Nordstrom — Tue, 15 Sep 2026 19:54:05 GMT

Introducing Data Security Workbench

Built on the newly released Microsoft Purview DLP API, Data Security Workbench is an open-source starting point for any customer who wants to turn DLP alert volume into explainable detection assurance and controlled response.

Figure 1: The workbench separates operational response from classification assurance while keeping both connected through one governed evidence plane.

The gap between alert volume and operational confidence

Microsoft Purview surfaces the activity that matters. But security teams still face the same operational challenge: connecting alerts to event evidence, understanding why a Sensitive Information Type fired, identifying the right business owner, deciding what should change, and responding without exposing the data they are trying to protect.

That work is typically split across scripts, exports, spreadsheets, portals, and one-off analyst knowledge. The result is familiar — alert volume grows faster than confidence, tuning decisions are hard to defend, and remediation becomes either too cautious to help or too broad to trust.

The goal is not to process more alerts. It is to make detection quality and response safety measurable operational controls.

Detection Assurance: a closed-loop control cycle

Detection Assurance determines whether your sensitive-data controls are behaving accurately. It explains why they fire, produces reviewable improvements, and proves whether those improvements worked — all as a repeatable, closed-loop process.

STEP 1: Observe Define the SIT boundary, tuning profile, and control language

STEP 2: Explain Analyze detections to separate signal from systemic noise

STEP 3: Improve Generate a reviewable Purview implementation plan

STEP 4: Prove Compare post-change outcomes against the original baseline

Figure 2: Classification posture reports retain the evidence period, model routing, detection totals, analysis chunks, and scoped-event count.

Full transparency into detection behavior

Each assessment produces a verbose Classification Efficiency Report documenting every detection across the scoped estate. It shows the total matches processed, how much noise was identified, the contextual patterns, underlying taxonomies, and where false positives concentrate.

If you need to understand exactly what was flagged and why, the report gives full transparency — noise detection rate, primary workload, false-positive reduction opportunity, and pattern-level detail for every SIT rule in scope.

Figure 3: Baseline and later observations make noise reduction visible by pattern and SIT rule, with comparison cautions when periods are not equivalent.

From report to reviewable Purview implementation plan

From this evidence, the system generates a Purview implementation plan. Each recommended step specifies the exact tuning change to make in your environment — the target SIT, the exact portal path, the current problem, and the precise configuration steps.

Critically, each step explains why the change is safe to implement, quantifies the expected reduction in false positives, and flags associated risks. For example, it may recommend refining a sensitive information type pattern to exclude authentication token structures generating false matches, and tells you the expected noise reduction from that single change.

Figure 4: The Purview implementation plan: prioritized actions (P0–P2), exact administrative steps, scoped workloads, deployment modes from simulation to operational control, and a copy-and-tune principle preserving rollback. This is a governed, reviewable, and quantifiable improvement to your DLP posture — not a one-time model opinion, but a repeatable control cycle with measurable outcomes.

From assurance to operational response

Each tuning round also updates a DLP response store with the AI verdict for every analyzed incident. The system triages events — identifying which are genuine exposure and which are systemic noise — and records a privacy-safe rationale alongside each verdict.

These verdicts can then be written in bulk back to the Purview incidents (as comments and tags in Microsoft Defender), or used to reach out to affected end users with guided remediation steps via email or Teams.

Figure 5: AI-triaged incidents with verdicts, security comments, and deep links back to the specific Purview DLP incidents — ready for bulk action or individual review.Figure 6: The remediation plan binds a scoped set of incidents to explicit actions: tag incidents, update status, notify affected users. All live actions require deliberate confirmation before execution.

After an explicitly approved incident update, the privacy-safe Detection Assurance rationale appears in the Microsoft Defender incident activity timeline — making outcomes easy to explain without requiring a separate incident queue.

Useful AI without an uncontrolled data boundary

Evidence is redacted by default. Classification boundaries fail closed. Microsoft Graph writes remain explicitly controlled.

The default assessment mode excludes detected values, identities, recipients, content names, senders, and subjects from the AI payload. Departments are resolved locally before identity redaction — the model receives the department, not the person used to resolve it. Sensitive-value analysis, when needed, requires separate configuration, a confirmation phrase, DPAPI protection, and an explicit per-run choice.

Live Graph actions (incident updates, email, Teams notifications) are disabled by default and require server enablement, an exact confirmation phrase, bounded targets, and an execution ledger. Dry-run is always the first gate.

Model routing

The workbench uses a luna model for high-volume event analysis and triage, and a Terra model for generating reports, implementation plans, and next-step recommendations. All AI is grounded in Purview data — no external training, no hosted data path, no opaque execution.

Get started

Turn your next DLP review into a measurable control cycle

Built on the newly released Microsoft Purview DLP API, this open-source workbench is a starting point any customer can build from. Local-first, transparent, and ready to adapt to your organization.

Explore the project →

Is it possible to search for emoji usage in Teams?

anderson2510 — Tue, 15 Sep 2026 13:23:46 GMT

I need to look into sending emojis in Teams; is it possible?

Unity Catalog and Data Map not showing in Chrome

DA_Larry1558 — Mon, 14 Sep 2026 20:24:22 GMT

I don't know if this is the right place to post this question, but I haven't been able to find an answer elsewhere. My organization is beginning to use Purview and are still trying to figure out how all of it works. I am able to log in to our Purview tenant from Microsoft Edge with no problem. When I log in I see the Unity Catalog and Data Map features and can use them. However, when I log in to Purview from Google Chrome, apparently with the same account and to the same tenant ID, I don't see either of Unity Catalog or Data Map. Could there be some obscure difference in how I am logging in through Edge and Chrome? If so, I'm not seeing it in the Account properties.

Please fix your spoofing issues with From: email address removed for privacy reasons

ProgentCT — Mon, 14 Sep 2026 19:54:05 GMT

Feel free to reach out for full headers. Your admin email address is being spoofed and this isn't the first time.

From: email address removed for privacy reasons
To: omitted
Subject: 459 USD payment received successfully.Please check your transaction
details at payinfogeek.us OR =?utf-8?b?w6fDoGxs?= 8133804297 account email
verification code

X-MXTHUNDER-RF-AuthResults: bolt105b.mxthunder.net;
dkim=pass header.d=microsoftonline.com header.s=s1024 header.b=iqnvyKM7;
dmarc=pass (policy=reject) header.from=microsoftonline.com;
spf=pass (bolt105b.mxthunder.net: domain of email address removed for privacy reasons designates 40.93.14.108 as permitted sender) smtp.mailfrom=email address removed for privacy reasons

Windows, TLS 1.3 and Post Quantum Crypto FAQ

MichaelHoward-MSFT — Mon, 14 Sep 2026 19:37:05 GMT

Q01: What is the real threat?

A: The threat is that attackers can collect encrypted network data and then break the asymmetric cryptography (RSA/ECC/DH) used to protect bulk data encryption keys (AES) once cryptographically relevant quantum computers come online. This is known as Harvest Now, Decrypt Later (HNDL).

Q02: Do I need to use TLS 1.3 for PQ support?

A: Yes. Earlier versions of TLS, including TLS 1.0, TLS 1.1, and TLS 1.2, do not and will not support post-quantum key establishment.

Q03: Does enabling TLS 1.3 give me hybrid PQ support?

A: No. By default, you will get ‘classic’ crypto algorithms. You must enable the PQ algorithms; this is explained later.

Q04: What Windows OS version must I use to get TLS 1.3 and post-quantum support?

A: TLS Hybrid Key Exchange using ML-KEM groups is available on Windows 11 starting with update KB5089573 for 24H2 and 25H2 and KB5095091 for 26H1.

For Windows Server 2025 use the patch from July 14, 2026-KB5099536 (OS Build 26100.33158)

Q05: What is hybrid crypto in TLS 1.3?

A: Hybrid crypto establishes cryptographic keys by combining elliptic-curve cryptography with post-quantum cryptography, allowing the client and server to use both algorithms during the TLS 1.3 key establishment. It’s a hedge in case the PQ cryptography is broken.

Q06: What crypto is used in hybrid?

A: Like all crypto in TLS, this is flexible; however, the most common hybrid crypto for web browser-based key establishment is X25519_MLKEM768 which combines the classic X25519 Elliptic Curve with post-quantum ML-KEM.

Q07: What is ML-KEM?

A: ML‑KEM (Module-Lattice Key Encapsulation Mechanism) is the new quantum-resistant method for securely establishing cryptographic keys between hosts. It is defined in FIPS 203.

Q08: Is hybrid TLS 1.3 enabled in Windows today?

A: No not by default; you must enable it. If you use Group Policy, you can set the policy there. If the machine does not have GP, then you can use the following from an elevated PowerShell prompt:

Enable-TlsEccCurve -Name "X25519_MLKEM768" -Position 0

Note that -Position 0 is important as it places the hybrid group X25519_MLKEM768 at the top of the preferred group list. If you do not do this, you might not negotiate to the hybrid PQC group.

IMPORTANT: Note that Group Policy will override this setting, so don’t mix-n-match! If you see your group ordering change after calling the PS cmdlet, it's probably GP coming in and overriding the setting.

Q09: In the prior answer, you used the word ‘group’ what is a group?

A: In TLS 1.3, a "group" is simply the method (or algorithm) that the client and server agree to use to securely establish keys during the connection. Examples include X25519 (the most common Elliptic Curve TLS 1.3 group) or the newer hybrid X25519_MLKEM.

As a side note, the word "group" isn't arbitrary - it comes from the underlying algebra (elliptic-curve groups, finite-field multiplicative groups). It's mathematically precise; it's just opaque to anyone who isn't thinking about group theory! However, ML-KEM isn't built on a group at all - its hardness comes, in part, from lattices.

Q10: Is a group the same as a ciphersuite in TLS 1.3?

A: No, a group is not the same as a ciphersuite in TLS 1.3. The group is how the client and server agree on secret keys. The ciphersuite is how they use secret keys to encrypt and protect the traffic. They work together in a TLS 1.3 handshake, but they are two separate parts

Q11: Are there other groups I should know about?

A: Yes. There are three common hybrid groups; you have already met X25519_MLKEM768, but there is also SecP256r1_MLKEM768 and SecP384r1_MLKEM1024.

Q12: What group should I use?

A: Follow your organization’s cryptographic policy and required assurance profile. For browser interoperability, prefer X25519_MLKEM768 where supported and place it ahead of other groups. For regulated environments, use a hybrid group and implementation permitted by the applicable policy and validated cryptographic module; this may require SecP256r1_MLKEM768 or SecP384r1_MLKEM1024 instead of X25519_MLKEM768.

Q13: If there is TLD 1.3 with hybrid crypto, is there a version that is NOT hybrid?

A: Yes, it’s called ‘pure’, and that is where rather than using ECC+PQC, you use just PQC; for example instead of X25519+MLKEM768, you use only MLKEM768 or MLKEM1024 if CNSA 2.0 compliance is in scope. Some customers may eventually require this. You can read about the MLKEM-only Windows schannel update here August 27, 2026—KB5120998 (OS Builds 26200.9278 and 26100.9278) Preview | Microsoft Support.

Q14: What’s CNSA 2.0?

A: CNSA 2.0, the Commercial National Security Algorithm Suite 2.0, is the NSA's set of quantum-resistant cryptographic algorithm requirements for U.S. National Security Systems. It updates CNSA 1.0 by introducing post-quantum algorithms intended to protect classified and other national-security-sensitive information against both classical and future quantum attacks. It is important because transitioning cryptographic infrastructure takes years, while adversaries can collect encrypted data now and attempt to decrypt it later. Although its formal scope is National Security Systems, CNSA 2.0 also provides vendors and other organizations with a concrete high-assurance target for planning, product development, and post-quantum migration.

The list of algorithms that affect TLS includes:

Key establishment: ML-KEM-1024 only (not 512, not 768)
Digital signatures: ML-DSA-87 only (not 44, not 65)
Hashing: SHA-384 or SHA-512 only
Symmetric encryption: AES-256 only

Q15: How do I test if my server supports TLS 1.3?

A: See Appendix A.

Q16: How do I test if my server supports TLS 1.3 and PQC?

A: See Appendix B.

Q17: How do I use Wireshark to determine if my server supports TLS 1.3 and PQC?

A: See Appendix C.

Q18: Do both the client and server need to support hybrid PQC TLS?

A: Yes.

Q19: What happens if one side does not support hybrid PQC TLS?

A: If one side does not support hybrid PQC TLS, the connection may still succeed using another mutually supported TLS 1.3 key establishment group, for example X25519, but it will not use hybrid PQC protection. The exact behavior depends on the client, server, and TLS configuration.

Q20: How do I know if my client, such as a browser, supports PQC TLS?

A: Point your application or browser at a tool like this https://pqc.ninja/api/browsertest/ it will output something like:

{ "negotiated_curve": "X25519MLKEM768", "offered_curves": "X25519MLKEM768:X25519:prime256v1:secp384r1", "negotiated_cipher": "TLS_AES_256_GCM_SHA384", "offered_ciphers": "TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256", "alpn_protocol": "h3", "protocol": "TLSv1.3" }

You can see that the browser and server negotiated to use the X25519_MLKEM768 hybrid group and the browser supports this along with two classic (ie; non-PQC) curves, prime256v1 and secp384r1.

Q21: Are PQC (ML-DSA) certificates required for TLS 1.3?

A: No, not for hybrid PQC key establishment. PQC certificates are a separate part of the post quantum migration and relate to authentication and digital signatures. Hybrid key establishment protects the session key agreement; PQC certificates will protect the certificate signature and authentication path.

Q22: Following the previous question, why does the server still use a classic certificate if the key negotiation is post-quantum?

A: This is by design. We need to secure data in transit first and foremost, since that represents the most immediate quantum threat. An adversary can perform a harvest-now, decrypt-later attack by storing encrypted communications today and waiting until quantum computers are available to decrypt them - any data being transmitted currently needs quantum-safe key exchange to be secure in the future. Authentication, however, does not have that same window of exposure: to perform a successful spoof via certificate misuse, an attacker would need a cryptographically meaningful quantum computer at the time of the session - they do not get to use it later. As we don't have that ability currently, by securing key exchange first we mitigate the most imminent threat while the ecosystem around it (CAs, trust anchors, relying parties, etc.) works towards supporting PQC signatures.

Q23: Is there a performance impact from hybrid PQC TLS?

A: We will provide more stats as they become available, but current details look good; X25519 vs X25519-MLKEM768 is about a 3%-6% latency delta and less than 1% CPU hit using Azure Linux, nginx + OpenSSL + SymCrypt and similar stats using https.sys on Windows Server 2025.

Q24: Should I enable this on internet-facing services first or internal services first?

A: Start with controlled pilots, then prioritize services that protect long-lived or high-value confidential data. Internet-facing services may provide broader coverage, but internal services can be easier to test and control. The right rollout order should balance risk, compatibility, visibility, and operational readiness.

Q25: What logging or telemetry should I capture during testing?

A: Capture the client and server IP addresses, the negotiated key-establishment group, the negotiated cipher suite, and the TLS protocol version for every test connection. Also record whether the handshake succeeded or failed and correlate each result with a timestamp or connection identifier. This makes it possible to confirm that TLS 1.3 and the expected hybrid PQC group were negotiated.

Below is a screen shot from a tool I have on GitHub that shows most of this passively in Windows using schannel and pktmon. The code is here x509cert/schannel-cap.

Appendix A - Testing for TLS 1.3

You can use tools like OpenSSL, PowerShell or a modern browser to test a server to determine if it supports TLS 1.3.

Let’s look at each.

OpenSSL

Use the following from a Windows or Linux command-line, obviously replacing the IP address and port number for your target service.

openssl s_client -connect 192.168.1.1:443 -tls1_3 -brief

Success is when you see:

CONNECTION ESTABLISHED Protocol version: TLSv1.3

PowerShell 7+

Save the following as Test-Tls13.ps1.

param( [Parameter(Mandatory)][string]$IpAddress, [Parameter(Mandatory)][int]$Port ) $tcp = New-Object System.Net.Sockets.TcpClient $tcp.Connect($IpAddress, $Port) $tls = New-Object System.Net.Security.SslStream($tcp.GetStream(), $false) try { $tls.AuthenticateAsClient($IpAddress, $null, [System.Security.Authentication.SslProtocols]::Tls13, $false) Write-Host "Connected: $($tls.SslProtocol), cipher $($tls.NegotiatedCipherSuite)" -ForegroundColor Green } catch { Write-Host "TLS 1.3 handshake failed: $($_.Exception.Message)" -ForegroundColor Red } finally { $tls.Dispose() $tcp.Dispose() }

You can call this using positional syntax:

.\Test-Tls13.ps1 192.168.1.1 443

Or using parameters:

.\Test-Tls13.ps1 -IpAddress "192.168.1.1" -Port 443

Success is indicated by output like this:

Connected: Tls13, cipher TLS_AES_256_GCM_SHA384

Edge and Chrome Browsers

Current versions of Edge and Chrome support hybrid TLS 1.3. After you make a connection to the server, click the ellipsis in the top right (…) -> More Tools -> Developer Tools -> Security.

If you don’t see the security option:

Then click on the + symbol and add the Security tab.

Now you will see the connection details, if you see TLS 1.3, then the server and client are connected with TLS 1.3. In the example below, the connection is also using X25519MLKEM, so the connection is not just using TLS 1.3, it’s using TLS 1.3 in PQ hybrid.

Appendix B – Testing for TLS 1.3 and PQC

The simplest and most reliable way to test a server to determine if it supports TLS 1.3 and PQC, is to use the following OpenSSL command-line:

.\openssl s_client -connect 127.0.0.1:8443 -tls1_3 -brief

You will see output like this:

Connecting to 127.0.0.1 CONNECTION ESTABLISHED Protocol version: TLSv1.3 Ciphersuite: TLS_AES_256_GCM_SHA384 Peer certificate: CN=localhost Hash used: SHA256 Negotiated TLS1.3 group: X25519MLKEM768

The group information, in this case X25519MLKEM is at the bottom, this indicates that hybrid PQC is in place for this connection.

Appendix C – Wireshark Filtering

Wireshark is commonly used to determine what data is travelling across a network. You can determine if a connection uses hybrid groups using the following steps:

Start Wireshark,
Perform some sample network connections (like make an API call or load a page in a browser),
Stop the collection
Enter the following in the filter window: tls.handshake.extensions_key_share_group
Click on the packet of interest and scroll to the Extension: key_share line.

You will see something like this:

The line in this example shows that the connection uses X25519MLKEM768 which is a hybrid PQC group.

Note, you will often see TLS 1.2 used as the protocol version, Wireshark explains why:

The TLS Version field is a deprecated field, so ignore it!

Thanks!

As usual, a big thanks to the people who helped write and edit this document:

Jessica Krynitsky - Windows Security
Andrei Popov - Windows Security
Aabha Thipsay - Windows Security
Vick Mukherjeee - Azure Security

Public Preview: Multi-account support for Microsoft Sentinel codeless connectors

MitchellGulledge — Mon, 14 Sep 2026 18:13:41 GMT

Security teams rarely have just one of anything. Most SOCs run separate production, staging, and development accounts. Large enterprises segment by region, business unit, or brand. And managed security service providers (MSSPs) watch over many customers at once. Traditionally, ISVs have used the following configuration – one connector for one product (or workspace), over as many instances of that product as are implemented. We set out to simplify and streamline that experience.

Today we're excited to announce the public preview of multi-account support for codeless connectors in Microsoft Sentinel. A single connector built on the Codeless Connector Framework (CCF) can now support multiple, independently deployable connections in the same workspace, each shown in one unified list so that one connector scales to however many accounts a customer runs.

What's new

The current CCF separates a connector's user interface from its connection configuration. That separation is what makes multiple connections possible. With the multi-account pattern, a connector provides:

A unified connections list: Every connection appears as its own row, labeled with the details that identify it such as account name, tenant ID, or environment (as seen in the screenshot above).
An Add connection experience: Users add another connection through a guided form without disturbing the connections that already exist.
Independent lifecycle per connection: Each connection is deployed, edited, and deleted on its own. Removing one leaves the others untouched.
Shared, efficient ingestion: All connections flow through the same data collection rule and land in the same table, so adding connections doesn't multiply your ingestion plumbing.

The result is a clean, predictable way to bring many sources of the same product into one Sentinel workspace.

In brief, here’s how it looks in practice: Under the hood, the connector definition that renders the UI is shared, and so are the ingestion resources — the data collection rule, the data collection endpoint, and the destination table. What's created per connection is a single lightweight data connector resource with a unique name, tagged with the metadata that labels it in the grid. That unique name is what lets connections coexist instead of overwriting one another.

Microsoft recommends all new CCF connectors support multi-account where appropriate. For a full walkthrough, annotated JSON, and an authoring checklist, see our MS Learn documentation on the topic.

Use Cases for having your Sentinel Connector utilize the Multi Account capabilities

Multiple accounts for an ISV
Different regional accounts
Developer/QA Accounts
Pre-Production Cloud Environments
MSSP
Multiple customers streaming logs to same Sentinel Instance

The pattern fits the everyday shape of security operations. Whether you are a team consolidating production and non-production accounts for one product, or an MSSP centralizing several customers' sources in a shared workspace, you now have one connector with many connections, and just one place to investigate.

Featured Early Adopter

One company that has already implemented this feature is Semperis, via their Lightning connector.

Semperis Lightning

Semperis Lightning integrates with Microsoft Sentinel to deliver deep visibility into identity‑centric risk across Active Directory and Microsoft Entra environments. The connector ingests identity security telemetry such as indicators of exposure, Tier 0 assets, and attack path insights from multiple Semperis accounts into Sentinel, enabling security teams to correlate identity risks with broader security signals. By bringing rich identity context into Sentinel analytics, hunting, and investigations, this integration helps organizations detect, prioritize, and respond to identity‑driven attacks more effectively across hybrid identity infrastructures.

And here is what Engineering Team Lead at Semperis, David Bagdasarian had to say about the new Multi-Account feature:

Get started

If you are a security professional looking to take advantage of this feature across your own environments, look for connectors that present a connections list and an Add connection action and bring all your sources into one workspace.

If you are an ISV interested in implementing multi-account functionality in your Microsoft Sentinel CCF connector, review the MS Learn documentation as a first step. If additional assistance is needed, the App Assure team is available to provide expert guidance for building and publishing your multi-account connector. Reach out to us via our intake form.

Recent Microsoft Sentinel Public Preview Announcements

Simplify Employee Identity Lifecycle with HiBob and Microsoft Entra

udimilo — Mon, 14 Sep 2026 18:17:58 GMT

Every workforce transition creates an identity moment that your IT team must get right. That’s why we’re excited to announce the general availability of HiBob’s native integration with Microsoft Entra. It helps you turn trusted workforce changes in HiBob into governed identity actions, so employees get the right access across on-premises and cloud apps as they join, change roles, or leave.

Why this matters

New hires need accounts and the right access from day one. When employees change roles, their access needs to change with them. And when someone leaves, that access needs to be removed quickly. Manual handoffs, tickets, and custom integrations slow these moments down, create more work for IT, and add unnecessary security risk. Connecting trusted workforce data in HiBob with Microsoft Entra helps you securely govern and automate the process, reducing the back-and-forth.

If your organization uses HiBob, this integration gives your HR and IT teams a more connected way to manage identity changes across hybrid environments. HR keeps workforce information current in HiBob, while IT decides how Microsoft Entra applies mappings, scoping rules, provisioning policies, and governance controls. Together, the systems turn workforce events into consistent identity actions - reducing manual handoffs, speeding up lifecycle processes, and creating a stronger foundation for identity governance.

Modernize identity without forcing a disruptive migration

Many organizations are moving applications and infrastructure to the cloud while still supporting on-premises directories. Modernizing identity does not mean replacing everything at once. The HiBob integration works with the environment you have today and helps you move toward a more cloud-managed model over time.

This integration advances a broader Microsoft Entra strategy: bring identity lifecycle control, visibility, and governance into a unified cloud service. Microsoft Entra can serve as the control plane for workforce identity changes across hybrid and cloud environments, while IT retains control over which users are in scope, how attributes are mapped, and what actions are performed.

Figure 1: HR-driven identity lifecycle flow from HiBob through Microsoft Entra.

Choose the integration that matches your identity environment

HiBob Marketplace offers two purpose-built integrations. Choose the one that fits where your organization is in its identity modernization journey.

For hybrid identities

Use the Windows Server Active Directory (Hybrid) integration if employees still need identities in an on-premises directory. Microsoft Entra cloud provisioning sends the configured changes through the Microsoft Entra provisioning agent, while Microsoft Entra keeps provisioning visibility and governance in one place.

For cloud-only identities

Use the Microsoft Entra ID integration if you manage identities directly in the cloud. This integration automatically updates Microsoft Entra user data when changes occur in HiBob.

How the integration works

The end-to-end flow is simple:

When an employee record changes, HiBob sends the relevant workforce data to Microsoft Entra.
Microsoft Entra applies provisioning attribute mappings and scoping rules configured by IT.
Microsoft Entra ID Governance can then trigger lifecycle workflows, assign birthright access through entitlement management, and initiate access reviews.

This model keeps identity changes HR-driven, IT-controlled, and cloud-managed. HR keeps employee records current in HiBob, while IT controls how Microsoft Entra processes each change. As you use Microsoft Entra source of authority capabilities to move identities toward cloud management, governance remains centralized throughout the transition.

"Workforce changes have consequences far beyond HR - from identity and access to the systems that keep the business running. Our collaboration with Microsoft connects trusted employee data in HiBob with Microsoft Entra ID and Active Directory, giving HR and IT a more coordinated way to manage those changes as organizations grow - without compromising control."

Ido Stern, Senior Vice President, Tech Platform & Engineering Excellence, HiBob

Turn workforce changes into governed lifecycle actions

When someone joins, employee and job information from HiBob can initiate identity creation in your organization’s hybrid environment. Lifecycle Workflows can automate onboarding tasks, and entitlement management can assign appropriate access through access package policies.

When someone changes roles, updates to department, manager, job title, or location flow from HiBob to Microsoft Entra. Lifecycle Workflows and other governance policies can trigger tasks and help adjust access to reflect the employee’s current role and business context.

When someone leaves, a change in employment status can initiate account deactivation and other configured Microsoft Entra lifecycle processes. Timely offboarding helps reduce lingering access to hybrid resources and cloud services.

Hear from an early customer

Novuna, a UK-based financial services company and HiBob customer, participated in the integration beta and shared its early perspective.

"During beta testing, our experience with the Microsoft Entra hybrid integration has been very positive. It shows strong potential to support our hybrid identity architecture, simplify provisioning across our existing directory environment and Microsoft Entra ID, and give us a more governed foundation for the future. The integration will streamline joiner, mover, and leaver processes… with a single flow from HiBob through Microsoft Entra and into ServiceNow, where our IT teams can complete the downstream tasks."

Chris, Automation Lead, and Alex, HR Systems Consultant, Novuna

Try the integration

Choose the HiBob integration that matches your identity environment and start by automating a high-value process, such as employee onboarding or offboarding.

Share your experience in the comments. You can also submit feedback or suggest new capabilities in the Microsoft Entra feedback forum.

Udi Milo

Partner PM, Access Management and Governance

https://www.linkedin.com/in/udimilo/

Additional resources

Learn more about Microsoft Entra

Help prevent identity attacks, support least-privilege access, unify access controls, and improve user experiences with identity and network access solutions across on-premises and cloud environments.

Locking down PAWs internet access when GSA drops

ChristianFriedel-Jain — Mon, 14 Sep 2026 08:38:19 GMT

By: Christian Friedel-Jain - Sr. Security Consultant | James Noyce - Sr. Security Solution Engineer

Introduction

Privileged Access Workstations (PAWs) are among the most sensitive endpoints in any organization. A PAW, in most of our Microsoft consulting projects, exists to do one job safely: administer cloud services from a hardened device that is only ever allowed to reach a small, tightly controlled set of internet destinations. But an endpoint’s security posture is ultimately defined by its behavior under failure conditions.

When we moved the internet access restriction for our PAW devices from a locally enforced restriction (more about that later) to a solution based on Microsoft Global Secure Access (GSA), we immediately identified a gap under failure conditions – but first a quick grounding on the moving parts.

Global Secure Access (What is Global Secure Access?) is Microsoft’s umbrella term for Microsoft Entra Internet Access and Microsoft Entra Private Access — the components of Microsoft’s Security Service Edge solution. For a PAW device we are leveraging Microsoft Entra Internet Access as an identity centric secure web gateway solution to control exactly which internet destinations the workstation can reach, by applying a fine-grained set of rules and policies enforced through Conditional Access in Microsoft Entra.

This configuration provides us better filtering capabilities, like web content filtering (Global Secure Access web content filtering) with TLS inspection (TLSi) (Global Secure Access transport layer security inspection) and additional features like Threat Intelligence (Global Secure Access threat intelligence), but it comes also with a downside. Currently by default, if the GSA client encounters an issue or cannot connect to its required GSA edge services, the GSA client will fall back to a fail-open state, rather than to a fail-close state.

Difference between those two modes:

Fail-Open: When a security or control mechanism fails, access is still allowed.
Fail-Close: When the security or control mechanism fails, access is blocked.

This blog post covers above problem and showcases a solution we built, as part of our projects, to achieve a “Fail-Close” state rather than having the current “Fail-Open” behavior.

The enforcement of the “Fail-Close” solution we developed works at two independent layers, both are deployable through Microsoft Intune:

A network layer: Windows Defender Firewall network profiles, a rule set with Windows Firewall Dynamic Keywords, and event-driven automation — restricts the device internet access in the moment GSA’s tunnels or services drop.
An identity layer: an Intune custom compliance check paired with Conditional Access — denies the device access whenever the GSA client is missing or its services are not running.

Together, they help to make sure a failure that slips past one layer is still caught by the other.

From URL Lock Proxy to Global Secure Access

Historically, we restricted internet access on PAW devices with the Windows Defender Firewall (for more details see here Microsoft Defender Firewall) and a “URL Lock Proxy” approach (and here URL lock proxy): an allow-list of permitted URLs that blocked every outbound HTTP(S) connection except the ones required for:

Approved management portals,
Authentication to Microsoft Entra ID,
Management by Microsoft Intune, and
Monitoring by Microsoft Defender for Endpoint.

Previous internet access control via URL lock proxy.

It worked, but it carried real limitations:

No auditing of what was allowed or blocked,
It did not scale and required a lot of wildcards to be used,
A limited ruleset size — the size cap on the underlying registry key meant the solution simply could not grow, and
It was not enterprise class.

Microsoft Global Secure Access with its component Entra Internet Access replaces the URL Lock Proxy configuration entirely. We are using dedicated firewall rules for the GSA client, to allow the client to reach the Entra Internet Access edge service. Through Entra Condition Access, a GSA Internet Access traffic profile (security profile) is applied which blocks all internet access except the specific FQDNs needed for approved management portals/platforms, Entra ID authentication, Intune, and Defender for Endpoint. HTTP and HTTPS traffic is evaluated and filtered within the GSA Edge service itself, and a request to a destination that is not on the allow-list is blocked with a simple “You can’t access this destination” message.

Additional features like filtering on URL level instead of FQDN, due to the use of TLSi, helped to remove most of the wildcards we had to use with the previous URL lock proxy approach.

The result is:

Access and the access results are auditable,
More granular and centrally managed rule set,
And genuinely enterprise class.

PAW internet access control via Entra Global Secure Access Internet AccessResult of blocked internet access

The catch: Global Secure Access fails open

GSA as the internet access restriction method is powerful, but it builds on the assumption that the GSA client is installed, running, and connected. When that assumption breaks, the client’s current behavior is to fail open.

As a result, the device ends up with unrestricted internet access whenever:

The GSA client is installed but cannot establish its tunnels with the GSA edge services (according to the Entra ID SLA this doesn’t happen that often – see Service Level Agreement performance for Microsoft Entra ID),
The GSA client on the PAW is installed but suspended, or
Its services are disabled, or
The GSA client component is not installed at all on the PAW device.

Current fail open behavior in case GSA internet access is not available

Left: normal operations - GSA internet access blocks access | Right: failure state - no filtering of internet access traffic

On a regular end user device, the fail-open mode is a convenience. On a PAW it is exactly the wrong default: the very moment the protection drops away, the device becomes its most exposed. Therefore, we had to develop a solution to have a fail-close behavior.

The Fail-Close approach

The core idea is deliberately simple, and it uses capability that already exists on most of the Windows devices: the Windows Defender Firewall network profiles (more details here Windows Firewall Network Profiles).

Two of the available firewall profiles are repurposed to act as separate operating modes:

Private profile: “unrestricted” HTTP(S). Internet access filtering is delegated to GSA Internet Access, so the firewall itself does not constrain destinations.
Public profile: “restricted” HTTP(S). Outbound web traffic is limited to a mandatory set of FQDNs via Defender Dynamic Keywords and selected system processes — just enough for the device to stay managed and healthy.

When the GSA client has successfully established its Internet access tunnel, the device is assigned the Private network profile. If GSA fails, the Windows Firewall profile is automatically switched to the Public network profile, restricting Internet access to essential destinations only. This profile transition implements the required fail-close behavior.

Normal state — Private profile

Normal state - Windows Firewall profile "private" doesn't perform internet access restrictions, GSA internet access performs filtering

As soon as the GSA client is running, connected to the GSA edge services and has established the Internet Access tunnel (step 1), the client writes a success event to the GSA event log (step 2) (Internet Access tunnel connected — Event ID 142)

When that event occurs, a scheduled task (step 3) runs a PowerShell script (step 4) that:

Switches the device to the Private firewall network profile,
Validates the state of all local GSA services, and
Initiates an Intune custom compliance check (to perform additional validations).

In case all validates were successfully passed, the PowerShell script enforces the Private firewall profile (step 5) and GSA Internet Access is being used to filter the internet access (step 6).

Failure state — Public profile

Failure state - Windows Firewall profile "public" enforces internet access restrictions

The moment GSA stops protecting (step 1) the device, one of several failure events is written to the GSA event log (step 2) and triggers a different scheduled task (step 3) which runs a PowerShell script (step 4) that switches the device to the Public firewall network profile (step 5) and initiates an Intune custom compliance check, too. The failure signals we watch for are:

Entra or Internet Access tunnel disconnected — Event ID 141 (logged roughly every 10 seconds while the tunnel is down),
GSA services stopped — Event IDs 106, 206, 406, and 705,
No internet connectivity — Event ID 638, and
Services start initiated — Event ID 701.

On the Public profile, the HTTP(S) outbound rule has Reusable Settings (Defender Dynamic Keywords - Windows Firewall Dynamic Keywords) (step 6) assigned, which restricts the reachable FQDNs down to a mandatory set of endpoints. Additionally, mandatory applications and services are explicitly exempt from that restriction, so the device can still be managed, patched, and monitored even while it is locked down.

Left: normal operations - GSA internet access blocks access | Right: failure state - internet access filtering by Windows Firewall

Closing the gap when GSA is absent: custom compliance

The firewall profile switch is event-driven — it reacts to the signals the GSA client writes to the event log. That works well for a device where the GSA client is present, but it leaves one blind spot: if the GSA client is not installed at all, or its services never start, there may be no events to react to.

Those are exactly the scenarios where a device would otherwise fall back to unrestricted access, the solution uses a custom device compliance policy/check that does not depend on any event firing. It directly:

Validates that the GSA client is installed on the device, and
Checks the local GSA service state — confirming that the services are running, not just present.

If either of those checks fails — GSA client is not installed, or its services are not running — Intune reports the device as non-compliant. Because a PAW’s access to cloud resources is gated by Conditional Access requiring a compliant device, a non-compliant PAW is denied access to the very cloud services it exists to manage. So even in the one case the event-driven firewall switch cannot see, access still fails closed — this time at the identity layer rather than the network layer.

In addition, as soon as the local evaluation detected a non-compliant scenario, the custom compliance check flips the firewall profile to the Public profile, too.

The profile-switching PowerShell scripts also initiate this compliance evaluation as they run in both the normal and failure states, so the device re-reports its posture promptly instead of waiting for the next routine Intune check-in. The result is defense in depth — two independent layers, neither relying on the other:

Enforcement layer	Mechanism	What it catches
Network	Defender Firewall profile switch, driven by GSA event IDs (141, 106, 206, 406, 705, 638, 701)	Tunnel drops and service stops while the GSA client is present and reporting
Identity	Intune custom compliance check + Conditional Access (require compliant device)	GSA not installed, or its services not running — no event required to trigger it

A failure that slips past one layer is caught by the other:

If GSA stops mid-session, the firewall restricts access near real-time;
If GSA is missing or disabled entirely, Conditional Access refuses the device to access Entra ID integrated resources.

Under the hood: the building blocks

The full solution is a set of several components, which all can be delivered and governed through Microsoft Intune:

Component	What it does
Firewall profile	Base firewall settings — default block all inbound and outbound connectivity across all profiles (public, private, and domain).
Firewall rules	Allow mandatory programs and services (~35 rules); restrict HTTP(S) in the Public profile using Dynamic Keywords; allow “unrestricted” HTTP(S) in the Private profile.
Defender Dynamic Keywords (Reusable Settings)	The set of FQDNs required for Entra ID, Defender for Endpoint, Intune, Windows Update, and Global Secure Access.
Platform scripts	Switch the firewall network profile to Private (unrestricted HTTP(S)); update the Defender anti-malware engine so it supports the Dynamic Keywords feature.
Win32 app package	Required app that deploys the scheduled tasks and the underlying PowerShell scripts.
Custom device compliance check	Validates that GSA is installed and checks the local GSA service state.

The firewall rules that make it work

The heart of the enforcement is a pair of “World Wide Web Services” outbound rules — one per firewall profile:

Rule	Profile	Action	Ports	Remote destinations
World Wide Web Services (HTTP & HTTPS Out)	Private	Allow	80, 443	Any address
World Wide Web Services (HTTP & HTTPS Out)	Public	Allow	80, 443	Dynamic Keywords only

The Private HTTP/HTTPS rule is deliberately open, because GSA is the gatekeeper. The Public HTTP/HTTPS rule scopes outbound web traffic down to the endpoint categories expressed as Dynamic Keywords:

GSA Edge Endpoints,
Microsoft 365 Common and Office Online,
Microsoft 365 encryption chains,
Windows 11,
Intune & Autopilot, and
Defender for Endpoint.

Because these are Defender Dynamic Keywords with AutoResolve (AutoResolve dynamic keyword addresses) deployed via Microsoft Intune reusable settings (Use reusable groups of settings policies in Microsoft Intune), rather than hard-coded IP ranges, the allow-list includes endpoints centrally instead of being frozen into a brittle registry key — directly addressing the scale and maintainability limits of the old URL Lock Proxy.

Besides the mentioned outbound HTTP/HTTPS firewall rule for the public and private network profile, additional rules are required for our scenario. With those additional firewall rules we cover:

Basic Windows operating system network communication,
Communication for Global Secure Access, and
Critical Windows processes and services.

Disclaimer: We are sharing the lists of firewall rules with you AS IS without warranty. Keep in mind that the config might require modifications to match to your scenario or environment.

Firewall rules for basic network communication

Name	Action	Network Types	Direction	Service / File / App Id	Protocols	Local Ports	Local Address Ranges	Remote Ports	Remote Address Ranges
Delivery Optimization (TCP-In)	Allow	All	Inbound	Service name: DoSvc File path: C:\windows\system32\svchost.exe	TCP	7680	Any address	Any remote port	Any address
Delivery Optimization (UDP-In)	Allow	All	Inbound	Service name: DoSvc File path: C:\windows\system32\svchost.exe	UDP	7680	Any address	Any remote port	Any address
Core Networking - DHCP (DHCP-Out)	Allow	All	Outbound	Service name: Dhcp File path: C:\windows\system32\svchost.exe	UDP	68	Any address	67	Any address
Core Networking - DHCP for IPv6 (DHCPV6-Out)	Allow	All	Outbound	Service name: Dhcp File path: C:\windows\system32\svchost.exe	UDP	546	Any address	547	Any address
Core Networking - DNS (TCP-Out)	Allow	All	Outbound	Service name: Dnscache File path: C:\windows\system32\svchost.exe	TCP	Any	Any address	53	DNS 6.6.0.0-6.6.255.255
Core Networking - DNS (UDP-Out)	Allow	All	Outbound	Service name: Dnscache File path: C:\windows\system32\svchost.exe	UDP	Any	Any address	53	DNS 6.6.0.0-6.6.255.255
Windows Time (UDP-Out)	Allow	All	Outbound	Service name: W32Time File path: C:\windows\system32\svchost.exe	UDP	Any	Any address	123	Any address
NCSI Probe (HTTP-Out)	Allow	All	Outbound	Service name: NlaSvc File path: C:\windows\system32\svchost.exe	TCP	Any	Any address	80	Any address

Firewall rules for Global Secure Access

Name	Action	Network Types	Direction	Service / File / App Id	Protocols	Local Ports	Local Address Ranges	Remote Ports	Remote Address Ranges
GSA Client - Tray App (TCP-Out)	Allow	All	Outbound	File path: %ProgramFiles%\Global Secure Access Client\TrayApp\GlobalSecureAccessClient.exe	TCP	Any	Any address	80, 443, 6543	Any address
GSA Client - Mgmt Service (TCP-Out)	Allow	All	Outbound	File path: %ProgramFiles%\Global Secure Access Client\GlobalSecureAccessClientManagerService.exe	TCP	Any	Any address	80, 443	Any address
GSA Client - Tunneling Service (TCP-Out)	Allow	All	Outbound	File path: %ProgramFiles%\global secure access client\globalsecureaccesstunnelingservice.exe	TCP	Any	Any address	80, 443	Any address
GSA Client - Advanced Diagnostics (TCP-Out)	Allow	All	Outbound	File path: %ProgramFiles%\global secure access client\advanceddiagnostics\globalsecureaccessclientadvanceddiagnostics.exe	TCP	Any	Any address	Any	Any address
GSA Client - Forwarding Profile Service (TCP-Out)	Allow	All	Outbound	File path: %ProgramFiles%\Global Secure Access Client\GlobalSecureAccessForwardingProfileService.exe	TCP	Any	Any address	80, 443	Any address
GSA Client - Engine Service (TCP-Out)	Allow	All	Outbound	File path: %ProgramFiles%\Global Secure Access Client\GlobalSecureAccessEngineService.exe	TCP	Any	Any address	80, 443	Any address

Firewall rules for critical Windows processes and services

Name	Action	Network Types	Direction	Service / File / App Id	Protocols	Local Ports	Local Address Ranges	Remote Ports	Remote Address Ranges
Microsoft Defender Antivirus Network Inspection Service (TCP-Out)	Allow	All	Outbound	Service: WdNisSvc	TCP	Any	Any	80, 443	Any
Microsoft Defender Core Service (TCP-Out)	Allow	All	Outbound	Service: MDCoreSvc	TCP	Any	Any	443	Any
Windows Defender Advanced Threat Protection Service (TCP-Out)	Allow	All	Outbound	Service: Sense	TCP	Any	Any	80, 443	Any
Microsoft Defender Antivirus Service (TCP-Out)	Allow	All	Outbound	Service: WinDefend	TCP	Any	Any	443	Any
Microsoft Intune Management Extension (TCP-Out)	Allow	All	Outbound	File path: C:\Program Files (x86)\Microsoft Intune Management Extension\Microsoft.Management.Services.IntuneWindowsAgent.exe	TCP	Any	Any	80, 443	Any
Runtimebroker (TCP-Out)	Allow	All	Outbound	File path: C:\windows\system32\runtimebroker.exe	TCP	Any	Any	443	Any
Windows Push Notifications System Service (TCP-Out)	Allow	All	Outbound	Service: WpnService File path: C:\windows\system32\svchost.exe	TCP	Any	Any	443	Any
Host Process for OMA-DM Client (TCP-Out)	Allow	All	Outbound	File path: C:\Windows\System32\omadmclient.exe	TCP	Any	Any	80, 443	Any
Microsoft Edge Update (TCP-Out)	Allow	All	Outbound	File path: C:\Program Files (x86)\Microsoft\EdgeUpdate\MicrosoftEdgeUpdate.exe	TCP	Any	Any	443	Any
Network List Service (TCP-Out)	Allow	All	Outbound	Service: netprofm File path: C:\WINDOWS\System32\svchost.exe	TCP	Any	Any	80	Any
Microsoft Health Attestation Client Agent (TCP-Out)	Allow	All	Outbound	File path: C:\Windows\System32\HealthAttestationClient\HealthAttestationClientAgent.exe	TCP	Any	Any	80, 443	Any
Windows Defender Advanced Threat Protection IMDSCollector module (TCP-Out)	Allow	All	Outbound	File path: C:\Program Files\Windows Defender Advanced Threat Protection\SenseImdsCollector.exe	TCP	Any	Any	80, 443	Any
API for MDM Enrollment (TCP-Out)	Allow	All	Outbound	File path: C:\Windows\System32\DeviceEnroller.exe	TCP	Any	Any	443	Any
Windows Defender SmartScreen (TCP-Out)	Allow	All	Outbound	File path: C:\Windows\System32\smartscreen.exe	TCP	Any	Any	443	Any
Windows Update (TCP-Out)	Allow	All	Outbound	Service: wuauserv File path: C:\WINDOWS\System32\svchost.exe	TCP	Any	Any	80, 443	Any
Device Management Enrollment Service (TCP-Out)	Allow	All	Outbound	Service: DmEnrollmentSvc File path: C:\WINDOWS\System32\svchost.exe	TCP	Any	Any	443	Any
Delivery Optimization (TCP-Out)	Allow	All	Outbound	Service: DoSvc File path: C:\WINDOWS\System32\svchost.exe	TCP	Any	Any	80, 443	Any
Company Portal (TCP-Out)	Allow	All	Outbound	App Id: Microsoft.CompanyPortal_8wekyb3d8bbwe	TCP	Any	Any	80, 443	Any
LSASS.exe (TCP-Out)	Allow	All	Outbound	File path: C:\Windows\system32\lsass.exe	TCP	Any	Any	443	Any
Windows License Manager Service	Allow	All	Outbound	Service: LicenseManager File path: C:\WINDOWS\System32\svchost.exe	TCP	Any	Any	443	Any
Background Intelligent Transfer Service (TCP-Out)	Allow	All	Outbound	Service: BITS File path: C:\WINDOWS\System32\svchost.exe	TCP	Any	Any	80	Any
Microsoft Intune ClientHealthEval (TCP-Out)	Allow	All	Outbound	File path: c:\program files (x86)\microsoft intune management extension\clienthealtheval.exe	TCP	Any	Any	443	Any
Microsoft Intune AgentExecutor (TCP-Out)	Allow	All	Outbound	File path: c:\program files (x86)\microsoft intune management extension\agentexecutor.exe	TCP	Any	Any	80, 443	Any
BitLocker Drive Encryption Service (TCP-Out)	Allow	All	Outbound	Service: BDESVC File path: C:\WINDOWS\System32\svchost.exe	TCP	Any	Any	443	Any
Microsoft Intune ClientCertCheck (TCP-Out)	Allow	All	Outbound	File path: c:\program files (x86)\microsoft intune management extension\clientcertcheck.exe	TCP	Any	Any	443	Any
Cryptographic Services (TCP-Out)	Allow	All	Outbound	Service: CryptSvc File path: C:\WINDOWS\System32\svchost.exe	TCP	Any	Any	80, 443	Any
Microsoft Malware Protection Command Line Utility (TCP-Out)	Allow	All	Outbound	File path: c:\program files\windows defender\mpcmdrun.exe	TCP	Any	Any	443	Any
Microsoft EPM Agent Service (TCP-Out)	Allow	All	Outbound	File path: C:\Program Files\Microsoft EPM Agent\EPMService\EpmService.exe	TCP	Any	Any	443	Any
Microsoft Store Install Service (TCP-Out)	Allow	All	Outbound	Service: InstallService File path: C:\WINDOWS\System32\svchost.exe	TCP	Any	Any	80, 443	Any
Update Orchestrator Service (TCP-Out)	Allow	All	Outbound	Service: UsoSvc File path: C:\WINDOWS\System32\svchost.exe	TCP	Any	Any	80, 443	Any

Note: List of mandatory programs & services is not a 100% complete list. We are still discovering additional exclusions.

Microsoft Intune Reusable Settings

As mentioned in the section before, several endpoint categories are being used as part of the Public "World Wide Web Services (HTTP & HTTPS Out)" Firewall rule. As part of this blog post, we cannot publish a one-size fits all list of FQDNs, since the actual list of FQDNs highly depends on the actual configuration, scenario or environment and are subject to change (as usual when it comes to endpoints). In our scenario it was important that PAW devices, when not connected to GSA, are able to:

Perform authentication against Microsoft Entra ID,
Remains fully managed by the MDM, in our case Microsoft Intune,
Receive updates for the operating system (Windows 11 Enterprise) and the XDR solution (Defender for Endpoint), and
Are able to connect to Microsoft Global Secure Access edge services.

Based on the requirements we leveraged several publicly available endpoint lists, which include the following, to create our Reusable Settings configuration:

GSA Edge Endpoints - FQDN and IP addresses where the Global Secure Access service receives traffic
Microsoft 365 - Microsoft 365 URLs and IP address ranges
Windows 11 - Connection endpoints for Windows 11 Enterprise
Intune & Autopilot - Network endpoints for Microsoft Intune
Defender for Endpoint - Microsoft Defender for Endpoint streamlined connectivity URLs

Create Reusable Settings objects

Attached to this blog post you will find several CSV files (GlobalSecureAccessEdgeEndpoints.csv, DefenderforEndpoint.csv, IntuneAutopilot.csv, Microsoft365Common.csv, Microsoft365encryptionchains.csv, Windows11.csv) which include the lists of FQDNs we are using as part of our deployments.

Disclaimer: We are sharing those Reusable Settings lists with you AS IS without warranty. Keep in mind that the config might require modifications to match to your scenario or environment.

The following code example can be used to create the Reusable Settings Object in Intune via Graph API. The code example doesn't include any error handling, since it should give you an idea how to perform the import, based on a CV file.

Code example for Reusable Settings import via CSV:

$csvFile = Get-Item 'C:\temp\GlobalSecureAccessEdgeEndpoints.csv' $definitionId = 'vendor_msft_firewall_mdmstore_dynamickeywords_addresses_{id}' $values = Import-Csv -LiteralPath $csvFile.FullName | ForEach-Object { $row = $_ $autoResolve = [bool]::Parse($row.AutoResolve) $autoResolveValue = $autoResolve.ToString().ToLowerInvariant() $choiceChildren = if (-not $autoResolve) { @{ '@odata.type' = '#microsoft.graph.deviceManagementConfigurationSimpleSettingCollectionInstance' settingDefinitionId = "${definitionId}_addresses" settingInstanceTemplateReference = $null simpleSettingCollectionValue = @( $row.Addresses -split ';' | Where-Object { -not [string]::IsNullOrWhiteSpace($_) } | ForEach-Object { @{ '@odata.type' = '#microsoft.graph.deviceManagementConfigurationStringSettingValue' settingValueTemplateReference = $null value = $_.Trim() } } ) } } @{ '@odata.type' = '#microsoft.graph.deviceManagementConfigurationGroupSettingValue' settingValueTemplateReference = $null children = @( @{ '@odata.type' = '#microsoft.graph.deviceManagementConfigurationSimpleSettingInstance' settingDefinitionId = "${definitionId}_id" settingInstanceTemplateReference = $null simpleSettingValue = @{ '@odata.type' = '#microsoft.graph.deviceManagementConfigurationStringSettingValue' settingValueTemplateReference = $null value = "{$([guid]::NewGuid())}" } } @{ '@odata.type' = '#microsoft.graph.deviceManagementConfigurationChoiceSettingInstance' settingDefinitionId = "${definitionId}_autoresolve" settingInstanceTemplateReference = $null choiceSettingValue = @{ '@odata.type' = '#microsoft.graph.deviceManagementConfigurationChoiceSettingValue' settingValueTemplateReference = $null value = "${definitionId}_autoresolve_$autoResolveValue" children = @($choiceChildren) } } @{ '@odata.type' = '#microsoft.graph.deviceManagementConfigurationSimpleSettingInstance' settingDefinitionId = "${definitionId}_keyword" settingInstanceTemplateReference = $null simpleSettingValue = @{ '@odata.type' = '#microsoft.graph.deviceManagementConfigurationStringSettingValue' settingValueTemplateReference = $null value = $row.Keyword } } ) } } $body = @{ '@odata.type' = '#microsoft.graph.deviceManagementReusablePolicySetting' displayName = $csvFile.BaseName description = '' settingDefinitionId = $definitionId settingInstance = @{ '@odata.type' = '#microsoft.graph.deviceManagementConfigurationGroupSettingCollectionInstance' settingDefinitionId = $definitionId settingInstanceTemplateReference = $null groupSettingCollectionValue = @($values) } } Connect-MgGraph -Scopes 'DeviceManagementConfiguration.ReadWrite.All' Invoke-MgGraphRequest ` -Method POST ` -Uri 'https://graph.microsoft.com/beta/deviceManagement/reusablePolicySettings' ` -Body ($body | ConvertTo-Json -Depth 20) ` -ContentType 'application/json'

Important: A maximum of 100 properties can be stored in a single reusable settings group object. Therefore, it might be required to split a endpoint category into multiple Reusable Settings Group objects.

Intune Win32 app package

Besides the deployment of the actual Global Secure Access client, a dedicated application package will be used to deploy the local components (Scheduled Tasks and PowerShell scripts) for the fail-close approach. To react on the two different states (normal and failure), two Scheduled Tasks need to be deployed to the PAW device. The Scheduled Task creation can be simplified by using exported XML files, which can also include the event trigger itself (examples listed in the sections Normal State and Failure State). Please note, the creation of Scheduled Tasks with event log based triggers require that the actual event log already exists on the device. So it might be worth creating a dependency between the different application packages.

Example code to register exported Scheduled Tasks via PowerShell:

Register-ScheduledTask -Xml (Get-Content "$PSScriptRoot\GSA-Connected.xml" | Out-String) -TaskName 'GSA-Connected' Register-ScheduledTask -Xml (Get-Content "$PSScriptRoot\GSA-Disconnected.xml" | Out-String) -TaskName 'GSA-Disconnected'

XML Sample Scheduled Task export GSA-Connected:

Sample XML Scheduled Task export GSA-Disconnected:

<?xml version="1.0" encoding="UTF-16"?> <Task version="1.4" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task"> <RegistrationInfo> <Date>2026-09-10T17:46:11.8914414</Date> <Author>ChristianFriedel-Jain</Author> <URI>\GSA-Disconnected</URI> </RegistrationInfo> <Triggers> <EventTrigger> <Enabled>true</Enabled> <Subscription><QueryList><Query Id="0" Path="Microsoft-Windows-Global Secure Access Client-Operational"><Select Path="Microsoft-Windows-Global Secure Access Client-Operational"> *[System[(EventID=141)]] and *[EventData[Data[@Name='Channel Name'] and (Data='Entra')]] </Select></Query></QueryList></Subscription> </EventTrigger> <EventTrigger> <Enabled>true</Enabled> <Subscription><QueryList><Query Id="0" Path="Microsoft-Windows-Global Secure Access Client-Operational"><Select Path="Microsoft-Windows-Global Secure Access Client-Operational"> *[System[(EventID=141)]] and *[EventData[Data[@Name='Channel Name'] and (Data='Internet')]] </Select></Query></QueryList></Subscription> </EventTrigger> <EventTrigger> <Enabled>true</Enabled> <Subscription><QueryList><Query Id="0" Path="Microsoft-Windows-Global Secure Access Client-Operational"><Select Path="Microsoft-Windows-Global Secure Access Client-Operational">*[System[Provider[@Name='Microsoft-Windows-Global Secure Access Client'] and EventID=106]]</Select></Query></QueryList></Subscription> </EventTrigger> <EventTrigger> <Enabled>true</Enabled> <Subscription><QueryList><Query Id="0" Path="Microsoft-Windows-Global Secure Access Client-Operational"><Select Path="Microsoft-Windows-Global Secure Access Client-Operational">*[System[Provider[@Name='Microsoft-Windows-Global Secure Access Client'] and EventID=206]]</Select></Query></QueryList></Subscription> </EventTrigger> <EventTrigger> <Enabled>true</Enabled> <Subscription><QueryList><Query Id="0" Path="Microsoft-Windows-Global Secure Access Client-Operational"><Select Path="Microsoft-Windows-Global Secure Access Client-Operational">*[System[Provider[@Name='Microsoft-Windows-Global Secure Access Client'] and EventID=406]]</Select></Query></QueryList></Subscription> </EventTrigger> <EventTrigger> <Enabled>true</Enabled> <Subscription><QueryList><Query Id="0" Path="Microsoft-Windows-Global Secure Access Client-Operational"><Select Path="Microsoft-Windows-Global Secure Access Client-Operational">*[System[Provider[@Name='Microsoft-Windows-Global Secure Access Client'] and EventID=705]]</Select></Query></QueryList></Subscription> </EventTrigger> <EventTrigger> <Enabled>true</Enabled> <Subscription><QueryList><Query Id="0" Path="Microsoft-Windows-Global Secure Access Client-Operational"><Select Path="Microsoft-Windows-Global Secure Access Client-Operational">*[System[Provider[@Name='Microsoft-Windows-Global Secure Access Client'] and EventID=638]]</Select></Query></QueryList></Subscription> </EventTrigger> <EventTrigger> <Enabled>true</Enabled> <Subscription><QueryList><Query Id="0" Path="Microsoft-Windows-Global Secure Access Client-Operational"><Select Path="Microsoft-Windows-Global Secure Access Client-Operational">*[System[Provider[@Name='Microsoft-Windows-Global Secure Access Client'] and EventID=701]]</Select></Query></QueryList></Subscription> </EventTrigger> </Triggers> <Principals> <Principal id="Author"> <UserId>S-1-5-18</UserId> <RunLevel>HighestAvailable</RunLevel> </Principal> </Principals> <Settings> <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy> <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries> <StopIfGoingOnBatteries>false</StopIfGoingOnBatteries> <AllowHardTerminate>true</AllowHardTerminate> <StartWhenAvailable>false</StartWhenAvailable> <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable> <IdleSettings> <StopOnIdleEnd>true</StopOnIdleEnd> <RestartOnIdle>false</RestartOnIdle> </IdleSettings> <AllowStartOnDemand>true</AllowStartOnDemand> <Enabled>true</Enabled> <Hidden>false</Hidden> <RunOnlyIfIdle>false</RunOnlyIfIdle> <DisallowStartOnRemoteAppSession>false</DisallowStartOnRemoteAppSession> <UseUnifiedSchedulingEngine>true</UseUnifiedSchedulingEngine> <WakeToRun>false</WakeToRun> <ExecutionTimeLimit>PT1H</ExecutionTimeLimit> <Priority>7</Priority> </Settings> <Actions Context="Author"> <Exec> <Command>"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"</Command> <Arguments>-NoProfile -ExecutionPolicy Bypass -File "C:\Progra~1\GSA-NetDetection\Set-NetworkPublic.ps1"</Arguments> </Exec> </Actions> </Task>

As soon as one of the Scheduled Tasks has been triggered, the corresponding PowerShell script (Set-NetworkPrivate.ps1 or Set-NetworkPublic.ps1) will be executed.

Example content of Set-NetworkPrivate.ps1

$NetworkName = (Get-NetConnectionProfile).Name Set-NetConnectionProfile -Name $NetworkName -NetworkCategory Private

Example content of Set-NetworkPublic.ps1

$NetworkName = (Get-NetConnectionProfile).Name Set-NetConnectionProfile -Name $NetworkName -NetworkCategory Public

Platform scripts

Install Microsoft Defender Antivirus updates during the device enrollment

To leverage the AutoResolve dynamic keyword feature, Microsoft Defender Antivirus must be turned on and running with platform version 4.18.2209.7 or later (see reference here FQDN Feature requirements). Since the required version is not natively included in Windows yet, a Platform script is being used to install the required Defender updates (Use the command line to manage Microsoft Defender Antivirus)

Example command to trigger Defender update:

$MpCmdRun = "C:\Program Files\Windows Defender\MpCmdRun.exe" & $MpCmdRun -SignatureUpdate -MMPC

Switch Defender Firewall profile to private during enrollment phase

To avoid issues during the device enrollment phase, the Defender Firewall profile is being switched from the default Public profile to the unrestricted Private profile by using another Platform Script.

Example code to switched the Firewall profile:

$NetworkName = (Get-NetConnectionProfile).Name Set-NetConnectionProfile -Name $NetworkName -NetworkCategory Private

Custom device compliance check

A custom device compliance check is being used to validate if GSA is installed and if the services are running on the device. A custom device compliance check requires an underlying script to gather the required information.

Example custom compliance script:

# GSA services to check $Services = @( "GlobalSecureAccessClientManagerService" "GlobalSecureAccessEngineService" "GlobalSecureAccessForwardingProfileService" "GlobalSecureAccessTunnelingService" ) $GSAInstalled = $false $RunningGSAServices = 0 # Validate that all Services are present (GSA installed) if ((Get-Service $Services[0] -ErrorAction SilentlyContinue) -and (Get-Service $Services[1] -ErrorAction SilentlyContinue) -and (Get-Service $Services[2] -ErrorAction SilentlyContinue) -and (Get-Service $Services[3] -ErrorAction SilentlyContinue)) { $GSAInstalled = $true } else { $GSAInstalled = $false } # Validate Service State foreach ($Service in $Services) { if ((Get-Service -Name $Service -ErrorAction SilentlyContinue).Status -eq 'Running' ) { # Service running - increase number of running services by 1 $RunningGSAServices += 1 } else { # Service not running - will not increase number of running services $RunningGSAServices += 0 } } if (($RunningGSAServices -ne 4) -or ($GSAInstalled -eq $false)) { Set-NetConnectionProfile -NetworkCategory Public } # Create a hashtable with the collected data $hash = @{ "GSAinstalled" = $GSAInstalled "GSArunning" = $RunningGSAServices } return $hash | ConvertTo-Json -Compress

The result of the custom compliance script will be evaluated against the custom compliance policy, which requires the custom compliance settings in a JSON format.

Example custom compliance settings JSON:

{ "Rules": [ { "SettingName": "GSAinstalled", "Operator": "IsEquals", "DataType": "Boolean", "Operand": "true", "MoreInfoUrl": "https://learn.microsoft.com/en-us/entra/global-secure-access/overview-what-is-global-secure-access", "RemediationStrings": [ { "Language": "en_US", "Title": "Global Secure Access not detected", "Description": "Global Secure Access service not found on the device." } ] }, { "SettingName": "GSArunning", "Operator": "IsEquals", "DataType": "Int64", "Operand": "4", "MoreInfoUrl": "https://learn.microsoft.com/en-us/entra/global-secure-access/overview-what-is-global-secure-access", "RemediationStrings": [ { "Language": "en_US", "Title": "Global Secure Access services not running", "Description": "One or more Global Secure Access service is not running on the device." } ] } ] }

Validating and monitoring

How did we work out which rules and events mattered — and how do we confirm the solution keeps working? Two sources did the heavy lifting:

The local security event log on the device, which is essential during enrollment and reset scenarios when the profile-switching lifecycle is first established; and
Microsoft Defender advanced hunting, to surface blocked connection attempts while the device is in its restricted, fail-close state.

For example, this advanced hunting query surfaces outbound connections from the PAW that were blocked while it was failing closed:

DeviceNetworkEvents | where DeviceName == "paw" | where LocalIPType == "Private" and RemoteIPType == "Public" | where ActionType == "ConnectionFailed" | sort by Timestamp desc

Reviewing these "ConnectionFailed" events tells you whether the restricted rule set is too tight (legitimate management traffic being blocked and needing an exemption) or working exactly as intended (unexpected destinations being denied while the device is locked down).

Key takeaways

Global Secure Access is the right tool for controlling PAW internet access — but its currently default fail-open behavior is unacceptable for a privileged workstation.
You don’t need a new GSA client to fix it. Windows Defender Firewall network profiles, driven by GSA’s own event log, give you a reliable fail-close backstop.
Defender Dynamic Keywords keep the locked-down state both minimal and maintainable, replacing brittle, unscalable allow-lists.
Enforcement runs at two independent layers — network (Defender Firewall profiles) and identity (Intune custom compliance plus Conditional Access) — so a failure that evades one is still caught by the other. The compliance check specifically covers the case the firewall cannot see: GSA not installed or its services not running.
The whole solution deploys through Intune — Win32 app, firewall profile and rules, and a custom compliance check — and is observable through the event log and Defender advanced hunting.

The Fail-Close solution turns a gap into a safe default: the instant Global Secure Access stops protecting the workstation, the privileged access workstation stops trusting the internet.

We hope this article gives you a practical pattern to harden your own privileged endpoints — and if you’d like to hear more about how we design and implement our Secure Privileged Access (SPA) strategy (for instance leveraging Global Secure Access to secure on-Premises management, secure access and management of Azure private resources, what Entra ID identity controls we are using to protect privileged access, or how we leverage Identity Governance to simplify governance for privileged users), feel free to reach out to us and stay tuned for more articles.

I'd like to thank DagmarHeidecker for her review and help in getting my first blog post created. As well as, JamesNoyce who came up with the initial base concept which I built upon.

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.

Microsoft defender is not catching threats before they are put into download folder.

brad03 — Sun, 13 Sep 2026 11:12:38 GMT

Before I post this, please note that I’m a security researcher trained to investigate malware and other application bugs. my complaint is the following and it's a serious one that should be fixed by Microsoft as soon as possible.

When I downloaded several malicious EXE files, Microsoft Defender didn't block or quarantine them during the download. Instead, Defender only detected them after I actually ran or executed the files. I also noticed that online platforms showed Microsoft Defender detecting the threats, so the files were clearly being recognized as malicious by Defender's engine. Has Microsoft changed the way Defender detects malware? Does it now require a malicious file to be executed before it detects it, similar to how some behavioral detection works in Malwarebytes? Or should Defender still be detecting and blocking known malicious EXE files before they are executed/downloaded because it's not at this current time and this is a clean installed system.

My system is clean, and I even performed a clean installation of Windows. I also used ConfigureDefender with the settings configured to High, and all of the relevant protection settings appeared to be enabled.I'm trying to understand whether this is normal behavior with the current version of Microsoft Defender or if something might be misconfigured on my system. Before, Microsoft Defender would detect and block malicious files while they were being downloaded, before I had a chance to run or execute them. Now, however, it seems like Defender is allowing the files to finish downloading and only detects them after I execute them.

Windows Defender isn't detecting EICAR test files? Mine doesn’t seem to detect them automatically, as shown in my proof. It only detects the file when I right-click it and select “Scan with Microsoft Defender.” Is this normal? It seems pretty crazy that it doesn’t detect the file immediately. it allowed them all to download. It's not even blocking Eicar test files when i bypass edges warning to download it just allows it to download no problem. edge detects it but Microsoft security does not.

Please have Microsoft’s threat team investigate why Windows Defender isn’t detecting malicious files when downloaded through Microsoft Edge. When Edge warns about a malicious or suspicious download and those warnings are bypassed, the files aren’t caught or blocked by Defender and end up being saved to the system. This is extremely dangerous and needs to be replicated to confirm the issue.

Trojan;Win32 Threat Found- how to get rid of

cdarling52 — Thu, 10 Sep 2026 23:48:02 GMT

I've noticed that I've been getting this same threat consistently since yesterday and even when I "remove" the threat, it just comes back. Can someone tell me what this means and what it might be from so I can remove he problem. I already did a full scan and it didn't find any other threats

Age Signals administrative control

JDBaggs — Thu, 10 Sep 2026 18:22:19 GMT

Hi.

There has been discussion that starting January 2027 discussion age signal responses will be required during the Windows 11 Out of Box Experience and when a Microsoft account is created; personal accounts I am assuming. But what about Enterprise Entra ID accounts and the OOBE experience using Intune and Autopilot? In the Microsof article, it states that Administrative Control will be an option. When will these fields be available in Entra ID accounts and be controlled via Intune policies to send a default value for all users if requested?

Link to the full document is below.

Age signals overview for Windows developers - Windows apps | Microsoft Learn

The Hidden Reason Your Sentinel Playbook Won't Show Up in Automation Rules (It's Not RBAC)

Blackfoundry — Thu, 10 Sep 2026 17:14:52 GMT

If a Logic App using the native Microsoft Sentinel incident trigger doesn't show up in the "Run playbook" picker of an Automation Rule — even though permissions, region, and connection are all correct — check the internal action name of the trigger in the JSON code view. If the Logic App was created while the Azure portal was set to a non-English language, the designer may generate a localized action name instead of the expected Microsoft_Sentinel_incident, and the playbook won't be picked up.

Environment

Microsoft Sentinel (Log Analytics workspace)
Logic Apps (Consumption plan)
Trigger: native Microsoft Sentinel connector, "Incident" trigger (/incident-creation path)
Authentication: system-assigned Managed Identity
Same subscription, resource group, and region as the Sentinel workspace

Problem

Two Logic Apps, both triggered by the native Microsoft Sentinel incident trigger, both using a system-assigned managed identity with the Microsoft Sentinel Responder role granted on the workspace. Same subscription, same resource group, same region.

Only one of the two appeared in the "Run playbook" dropdown when configuring an Automation Rule in Sentinel. The other was simply absent — no error message, no warning, nothing in the run history to explain it.

Investigation

The usual suspects were checked and ruled out one by one:

API connection health — one azuresentinel connection was indeed in an "Error" state, but it turned out not to be the one referenced by the affected trigger.
Managed identity RBAC — the Microsoft Sentinel Responder role was correctly assigned to the Logic App's managed identity on the Sentinel workspace.
User's own RBAC/PIM role — the Logic App Contributor role (required for the account configuring the Automation Rule to even see the resource) was active via PIM at the time of testing.
Region/subscription/resource group — identical for both Logic Apps.
Trigger type — both used the native "Incident in Microsoft Sentinel" trigger added through the visual designer, not a generic HTTP trigger or a deprecated connector.

Every documented requirement was met. The playbook was still invisible.

Root Cause

Comparing the raw JSON (Logic app > Development tools > Code view) revealed the actual difference.

Working Logic App (visible in the picker):

"triggers": {
  "Microsoft_Sentinel_incident": {
    "type": "ApiConnectionWebhook",
    "inputs": {
      "body": { "callback_url": "@{listCallbackUrl()}" },
      "path": "/incident-creation"
    }
  }
}

Broken Logic App (invisible in the picker):

"triggers": {
  "Incident_dans_Microsoft_Sentinel": {
    "type": "ApiConnectionWebhook",
    "inputs": {
      "body": { "callback_url": "@listCallbackUrl()" },
      "path": "/incident-creation"
    }
  }
}

The connector type and the path (/incident-creation) are identical. The one meaningful structural difference is the trigger's action name: Microsoft_Sentinel_incident versus Incident_dans_Microsoft_Sentinel.

The second Logic App's trigger had been added while the Azure portal was set to French. The designer generated a localized action name instead of the canonical English one.

Everything points to Sentinel's playbook discovery mechanism scanning Logic App definitions for that exact canonical action name (Microsoft_Sentinel_incident) to identify a resource as a valid Sentinel playbook — rather than relying solely on the connector type or the webhook path, as one would reasonably expect.

Fix

Renaming the trigger's action key in the JSON to the canonical name was enough:

"triggers": {
  "Microsoft_Sentinel_incident": {
    ...
  }
}

No permission, connection, or region change was required — only this rename.

Takeaways

The Sentinel Automation Rule playbook picker appears to depend on the exact trigger action name, not just its type or functional behavior — a dependency that isn't documented anywhere in the official Microsoft docs as of this writing.
The Azure portal's display language at the time a trigger is added has a direct impact on that Logic App's compatibility with Sentinel Automation Rules.
A playbook can be fully functional (running without errors when triggered manually or through an older automation mechanism) while still being invisible in the newer Automation Rule selector — which makes this particular issue easy to miss, since nothing explicitly flags it.

Recommendations

Temporarily switch the Azure portal to English (Portal settings > Language and region) before adding a Sentinel trigger to a Logic App, if your team usually works in another language.
If an existing Logic App won't show up despite an otherwise correct configuration, check the trigger's action name in the JSON code view first — it's a 30-second check that can save hours of RBAC/connection troubleshooting.
Document this in your internal runbooks if your team works in a localized portal — this kind of detail is easy to lose and can cost significant troubleshooting time down the line.

Has anyone else run into similar localization-related quirks in Sentinel or Logic Apps? Would be curious to hear about other cases in the comments.

The Hidden Reason Your Sentinel Playbook Won't Show Up in Automation Rules (It's Not RBAC)

Blackfoundry — Thu, 10 Sep 2026 16:18:38 GMT

If a Logic App using the native Microsoft Sentinel incident trigger doesn't show up in the "Run playbook" picker of an Automation Rule — even though permissions, region, and connection are all correct — check the internal action name of the trigger in the JSON code view. If the Logic App was created while the Azure portal was set to a non-English language, the designer may generate a localized action name instead of the expected Microsoft_Sentinel_incident, and the playbook won't be picked up.

Environment

Microsoft Sentinel (Log Analytics workspace)
Logic Apps (Consumption plan)
Trigger: native Microsoft Sentinel connector, "Incident" trigger (/incident-creation path)
Authentication: system-assigned Managed Identity
Same subscription, resource group, and region as the Sentinel workspace

Problem

Investigation

The usual suspects were checked and ruled out one by one:

API connection health — one azuresentinel connection was indeed in an "Error" state, but it turned out not to be the one referenced by the affected trigger.
Managed identity RBAC — the Microsoft Sentinel Responder role was correctly assigned to the Logic App's managed identity on the Sentinel workspace.
User's own RBAC/PIM role — the Logic App Contributor role (required for the account configuring the Automation Rule to even see the resource) was active via PIM at the time of testing.
Region/subscription/resource group — identical for both Logic Apps.
Trigger type — both used the native "Incident in Microsoft Sentinel" trigger added through the visual designer, not a generic HTTP trigger or a deprecated connector.

Every documented requirement was met. The playbook was still invisible.

Root Cause

Comparing the raw JSON (Logic app > Development tools > Code view) revealed the actual difference.

Working Logic App (visible in the picker):

"triggers": {
  "Microsoft_Sentinel_incident": {
    "type": "ApiConnectionWebhook",
    "inputs": {
      "body": { "callback_url": "@{listCallbackUrl()}" },
      "path": "/incident-creation"
    }
  }
}

Broken Logic App (invisible in the picker):

"triggers": {
  "Incident_dans_Microsoft_Sentinel": {
    "type": "ApiConnectionWebhook",
    "inputs": {
      "body": { "callback_url": "@listCallbackUrl()" },
      "path": "/incident-creation"
    }
  }
}

The connector type and the path (/incident-creation) are

MDE endpoint to Purview onboarding

vipinjain — Tue, 08 Sep 2026 10:33:49 GMT

Hi All,

I have Microsoft defender endpoint plan 2 onboarded endpoints in my organisation, as a new dlp functionality i need to test purview DLP functionality for few of my endpoints but i see that it needs to be enabled the device onboarding in microsoft purview under settings, and it also says that all MDE endpoints will populate automatically here and onboarded since they alreay have MDE, now my worry is, if i enable this and all endpoints start onboarding under purview automatically and if we start facing any difficulty with enspoints how to stop or rollback that since no. of endpoints are more than 500. although i have checked there are no DLP settings or policies configured in the purview. is there any way to include only few endpoints to purview and test before enabling the tenant level button?

is there a way we can disable the button if we enable it and we start encountring any issues with endpoints?

Appreciate help on this.

Thanks

Vipin

Securing Your Certification Authorities (Practical PKI Part 4)

RonArestia — Mon, 07 Sep 2026 10:57:56 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 blog post, we work to enhance the security position of PKI by focusing on the most vital component first: your Certification Authorities (CAs). This is part 4 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)

Purpose For Your PKI (Practical PKI Part 3)

Before you start down this path, review SpecterOps Exploitation of Certificate Services framework. This is the de facto standard against which you should secure your PKI. If you cannot protect against misconfigurations, threat actors are going to leverage them against you.

Please note: I will not be demonstrating any red team/hacking tools in this blog out of an abundance of caution. There are myriad guides on how to leverage these tools against an ADCS PKI. My goal with this series is to provide best practice guidance and learn to think like a defensive security professional specific to PKI.

Throughout this and future blog posts, I am going to reference the Exploitation of Certificate Services framework as ESC and reference specific ESC exploits. Take a moment to cross-reference what is written here with the finding to understand how misconfigurations can be abused.

Root CA Security

I would advise anyone jumping into this blog series at this point to go back and review previous posts about root CA security and best practices. So much has already been written about this, so I will be brief in this section to focus on downstream security concepts.

If a root CA is truly offline and protected by an HSM, the risk of compromise is exceptionally low albeit not zero. While I do not know of any specific anecdotal evidence of an offline root CA compromise, I am sure Hollywood could produce some Mission Impossible-level script. In reality, most threat actors are maneuvering around an enterprise via the identity plane, and the PKI infrastructure is the icing on a very scrumptious cake once they have achieved domain dominance. The idea of air-gapping your root CA does not mean your enterprise is insulated from a PKI attack, but the root of trust for your organization is sufficiently protected that rebuilding the subordinate infrastructure is much quicker than having to perform a greenfield deployment of your PKI.

Recall that your root CA, as with all root CAs, leverages a self-signed certificate. That certificate is not by itself very remarkable except that it signs all of the subordinate/issuing/registration authorities AND all of the certificate revocation lists (CRLs). If a threat actor cannot compromise the root CA, in the case of a cybersecurity incident involving the subordinate infrastructure, the impacted organization can simply revoke all of the subordinate infrastructure certificates which will then be added to the CRL. That will subsequently invalidate any and all certificates issued by those subordinate CAs, but securely rebuilding the subordinate infrastructure means that an organization only needs to hydrate their issuance/registration infrastructure while the root remains trusted by the entire organization. This reduces the recovery time significantly since the root infrastructure is still trusted across the enterprise.

If your root CA is NOT offline, it needs to be. There is no way to adequately mitigate risk against your PKI if the root CA is enterprise-joined. If your root CA is also your primary issuer, you should migrate to a two-tier PKI hierarchy after assessing need and impact. Threat actors are attracted to the highest branch in your organization’s technical hierarchy. If the root CA is online, they will find it, and chances are good that they will figure out how to exploit it.

Enterprise CA Security

One piece of advice throughout this entire process: take your time. There is no reason for you to rush this process or otherwise expedite your PKI into production. “Haste makes waste,” as goes the old proverb. While it is absolutely possible to stand up a servicing infrastructure in a brief period of time, you will miss critical security controls that will put your organization at risk. Take pains to document exhaustively your desired PKI configuration: CA names, supported encryption types, minimum key sizes, certificate and CRL validity periods, template types and purposes, and groups and users used across the PKI for management of the CA, templates, and issuance. Documentation of your PKI should be the overwhelming majority of the time spent building it. Every other component falls into place with a proper framework established in advance.

Your issuers are going to be front and center to most of your PKI operations. Do not co-locate services on your issuing CAs. Your issuing CAs have a single purpose: as an enterprise issuing certificate authority. The only service installed on these systems should be the ADCS Certification Authority role. Do not install the CA role on a domain controller. (I cannot stress this enough!) Do not install any other Windows role or feature, even those under the ADCS role. Every additional role you install on your issuing CA increases its risk footprint and your administrative burden. Keep third party tools, agents, services, APIs, etc. to the bare minimum. If this is installed in Tier 0 of a properly tiered security environment, the risk should be much lower. PKI is a Tier 0 system! It should be treated with the same level of security as your domain controllers.

For both (Offline) Root and Issuing CAs, the theft of a private key is considered a domain persistence technique, and the CA should be considered compromised even if there is no evidence of exfiltration.

Proper CA Rights Management

Before you get started with your PKI implementation, you should create a handful of new security groups in Active Directory to directly manage your CAs, templates, and issuance. By default, ADCS assumes Domain Admins and Enterprise Admins are administering your PKI. Do not leave this configuration in place. This does not comply with any least privilege guidance, and it leaves your PKI in a position where it can be compromised either directly or indirectly through lateral account movement once either of those groups is compromised by a threat actor.

To manage your issuing CA, create a security group named “CA Admins” or something similar that meets your organizational naming standards or needs. CA Admins have the sole responsibility of managing the CAs themselves. These are the admins who will open the Certification Authority management console (MMC), modify the CA configuration, when necessary, perform signing operations (e.g., manual CRL issuance), revoke certificates, perform backups, and maintain the overall health of the PKI. (Figure 1)

Figure 1

To manage certificate issuance for your enterprise, create a security group named “Certificate Managers” or something similar. Certificate Managers have the responsibility of scrutinizing certificates pending issuance. This should be a small group of trusted admins who are trained to review certificate requests and perform issuance based on security and risk standards established for your enterprise. (Figure 2)

Figure 2

Each of these groups will be configured in the ADCS certification authority MMC with their respective rights. Each one of these groups is single-purpose. None of them should have the ability to request certificates, and ideally, the membership of these groups should never overlap. The purpose here is to provide role separation. No one should be able to request a certificate and approve their own request, for example.

To manage certificate templates for your enterprise, create a security group named “Certificate Template Managers” or something similar. Certificate Template Managers are responsible for creation, management, and maintenance of all certificate templates in the enterprise. These individuals should have a comprehensive understanding of certificate template creation, purposeful provisioning of new templates, and management of access control lists (ACLs) on templates. These individuals are your first line of defense against misconfiguration of certificate templates that lead to compromise through many of the Exploitation of Certificate Services (ESC) methods. Note: this requires manipulation of a container in the Active Directory Configuration partition and may not be explicitly necessary if Certificate Managers is properly constrained. (Figure 3)

Figure 3

These configurations made during inception of the PKI should cover you against exploitation of ESC7 specifically and require a very narrowly-scoped attack path for a threat actor to leverage it. I want to caution that this is not foolproof and does not account for exploitation of the administrative accounts themselves. If a threat actor gains control of one of the administrative accounts, they will have exploitation capability of whatever administrative function(s) is/are in scope for that user. This is why role separation is such an important concept for PKI management. In a true cybersecurity incident, the threat actor would have to gain access to multiple accounts to take full advantage of the enterprise PKI.

Configure Role Separation at the CA

In addition to proper assignment of roles, you can enforce strict role separation by implementing the role separation registry setting for ADCS (Figure 4):

Certutil -setreg CA\RoleSeparationEnabled 1

Figure 4

Before you do this, one caution: this will force ADCS to only allow one role per account. If, for example, you have a user who is both a CA Admin and a Certificate Manager, with role separation enabled, they will not be able to perform either action. ADCS role separation role sets and only permits them to hold one. While this configuration is exceptionally strong at preventing misuse of the PKI, it can lock out your admins from administering the PKI at all! As such, you should have high confidence that your roles are properly assigned prior to changing this configuration setting. This setting is global meaning that it applies to any and all roles assigned to the PKI, not just the privileged roles.

Good news, however, is that if this happens during your testing, you can log into the CA directly and remove the role separation registry configuration. This will allow you to go back to proper configuration to resolve the overlapping identities or avoid this setting going forward but be aware of service interruption as a result.

It is possible to manage a secure PKI without this setting, however. It is one of many tools at your disposal.

Disable Request Attribute SAN (EDITF_ATTRIBUTESUBJECTALTNAME2)

Microsoft introduced strong certificate mapping limitations as part of KB5014754 in response to a number of CVEs that surfaced back in 2022 (CVE-2022-34691,CVE-2022-26931 and CVE-2022-26923). This protection makes exploitation of ESC6 difficult but not impossible. In concert with ESC9 or ESC16, this could still be exploited even with properly-patched domain controllers.

This misconfiguration (Figure 5) allows a requester to submit any subject alternative name (SAN) they want against a certificate template, even if the template does not allow it. To harden your CAs against this attack, you can make a registry change to disallow this behavior:

Certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2

Figure 5

It is important to note that if any other CA administrative escalation vulnerabilities exist, a threat actor can remove this attribute without difficulty. It does require a restart of the service, so monitoring your ADCS service health can help to identify unwanted changes.

Protect the ICertPassage RPC Interface

ESC11 is a more recent exploitation that allows relaying of NTLM authentication to RPC on a vulnerable CA. This could allow an attacker to request certificates on behalf of other domain principals. (Figure 6)

To harden your CAs against this attack, you can make a registry change to disallow this behavior:

Certutil -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST

Figure 6

Note that this will force the CA to accept only RPC connections that are both signed and encrypted.

Check the CA Policy Module for Disabled Extensions

ESC16 covers another CA misconfiguration where a specific OID (1.3.6.1.4.1.311.25.2) is disabled in the CA Policy Module. This extension (szOID_NTDS_CA_SECURITY_EXT) will force the CA to omit a SID security extension in issued certificates which allows for exploitation of ESC6 and/or ESC7. This is functionally similar to ESC9, but this is a global setting whereas ESC9 is template-specific. (Figure 7)

To harden your CAs against this attack, review the disabled extension list on your CA:

Certutil -getreg policy\DisableExtensionList

Figure 7

If this specific OID (1.3.6.1.4.1.311.25.2) is in the disabled extension list (Figure 8), remove it:

Certutil -setreg policy\DisableExtensionList -1.3.6.1.4.1.311.25.2

Figure 8

Figure 9

Wrapping Up

As I said at the beginning of this post, take your time setting up your CAs. If you configure them with proper protections from the word “go,” you will harden your PKI sufficiently to confound even the most determined adversaries.

Of the sixteen published ESC vulnerabilities, five of them are directly attributed to CA security misconfigurations (ESC 6, 7, 8, 11, & 16). In this blog post, we provided guidance for all of these except ESC8 which deals with Certification Authority Web Enrollment (CAWE), Certificate Enrollment Service (CES), Certificate Enrollment Policy (CEP), and Network Device Enrollment Service (NDES). In my introduction, I reinforced that your Certification Authority should be single-purpose. Do NOT install other ADCS roles on your CA. You introduce risks to which the CA itself should not be exposed. If you follow this guidance, ESC8 will not present a problem, but we will cover it in more detail in a future blog post.

In Part 5, we will dive deep into the configuration of your certificate templates to address a multitude of vulnerabilities that are present from oftentimes simple misconfigurations that can lead to big headaches.

How can I unlock my account?

PadreShrek — Sun, 06 Sep 2026 19:40:56 GMT

I've tried contacting support several times, both through the form and live chat, but neither resolved anything. On the form, they either stopped responding or started giving lame excuses, and on the live chat they even told me to create another account and buy what I had on the lost account. Is there another way to contact a human at Microsoft, or am I just going to waste my time talking to bots and receiving excuses?

Monitoring work from home

lfk73 — Sun, 06 Sep 2026 03:34:27 GMT

My boss has asked me if there is a way to see just how "busy" people who are working from home are. I have this data in Sentinel:

Entra sign-in logs

Defender for Endpoint logs

Office 365 logs

Most, if not all, on premise AD login events

Netskope (current ZTNA solution) logs

I have my known office location IPs so i could just exclude those and look for activity from other IPs however many times people will work in the morning or on the way to work appearing from a non corporate IP, come into the office appearing to come from a corporate IP, and then from home again in the evening.

I need a way to query Sentinel looking for people who appear to be working but not coming from Corp IP. If they came from different IPs on the same day including Corp check to see if those non Corp are before and after business hours and exclude those.

Anyone know of a good query to achieve this? Or maybe a tool that can extract and generate a report?

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

TysonPaul — Fri, 04 Sep 2026 20:18:34 GMT

Member: TysonPaul | Microsoft Community Hub

Retirement of Microsoft HPC Pack

Team Blog: Azure High Performance Computing (HPC)

Author: XinXin

Published: 08/25/2026

Summary: Microsoft HPC Pack, a Windows-based HPC scheduler, will be retired, with support ending August 27, 2027. No new updates, features, or enhancements will be provided after this date, and only limited security support is available during the retirement period. Customers are advised to migrate to Azure Batch or other Azure services for HPC workloads. Existing deployments will not be forcibly disabled but will be unsupported after the retirement date. Microsoft encourages early migration planning and feedback to facilitate a smooth transition and address customer concerns.

Azure DNS + Traffic Manager linked records

Team Blog: Azure Networking

Author: atiy

Published: 08/26/2026

Summary: Azure DNS Traffic Manager linked records allow direct, managed integration between Azure DNS and Traffic Manager profiles, enabling endpoint IP addresses to be returned without an intermediate CNAME. This improves DNS responses, supports zone-apex routing, and enhances DNSSEC compatibility while preserving Traffic Manager’s routing intelligence, health monitoring, and failover. The article provides a practical guide for configuring, validating, and testing this feature, currently in public preview, using a multi-region Contoso scenario. The feature simplifies DNS architecture and client experience, making global routing more seamless and secure, especially for root domains.

Azure Virtual Network routing appliance is now generally available

Team Blog: Azure Networking

Author: Anshu_Verma

Published: 08/04/2026

Summary: Azure Virtual Network routing appliance is now generally available, offering a managed, platform-native routing service for high-performance connectivity across Azure virtual networks. Designed for modern cloud demands—including AI, private connectivity, IPv6 adoption, and multi-region architectures—it enables scalable hub-and-spoke and private network models, simplifies operations, and supports both IPv4 and IPv6. With built-in resiliency, Azure-native management, configurable bandwidth, and integrated monitoring, it helps organizations build large-scale, efficient, and innovative network infrastructures, accelerating cloud and AI initiatives while reducing operational complexity.

Introducing the new Microsoft 365 Setup experience: A personalized dashboard for admins

Team Blog: FastTrack

Author: johnvincent

Published: 08/31/2026

Summary: Microsoft is launching a redesigned Microsoft 365 Setup experience for admins, featuring a personalized dashboard that centralizes deployment progress, onboarding, licensing, and readiness insights. The new setup offers tailored recommendations, direct product configuration, and easy access to guides and support, streamlining the deployment process. Admins can now spend less time searching and more time taking action, with integrated training, migration resources, and FastTrack support. This update aims to simplify Microsoft 365 deployments, making them more intuitive and efficient, with future enhancements planned based on admin feedback, including AI-powered insights and assistance.

Building a Fully Automated Azure Landing Zone Deployment Using Azure DevOps and Terraform

Team Blog: Azure Tools

Author: Rajasekharvemula

Published: 08/18/2026

Summary: The article explains how to build a fully automated Azure Landing Zone using Azure DevOps and Terraform. It outlines best practices for deploying standardized cloud environments, including structured Git workflows, automated CI pipelines, environment promotion strategies, governance integration, identity and access management, and monitoring. Storing Terraform state in Azure Storage ensures collaboration and recovery. Automation from the start enables consistent, secure, and auditable cloud foundations, reducing operational effort and improving compliance. Combining Azure DevOps and Terraform transforms cloud deployment into a scalable, governed, and enterprise-ready platform engineering practice.

Cost Management with Azure Resource Manager MCP

Team Blog: FinOps

Author: demiajayi

Published: 08/25/2026

Summary: Microsoft has announced new Cost Management features in Azure Resource Manager MCP, providing default tools for AI agents to integrate cost insights into Azure workflows. These tools help with cost estimation, budget tracking, and identifying savings opportunities, while optional advanced tools enable deeper analysis, forecasting, and optimization. AI agents can query costs, analyze AKS workloads, and recommend savings, streamlining financial decision-making in cloud operations. Installation and configuration details are provided for VS Code and GitHub Copilot. Microsoft plans to expand agentic cost capabilities and invites user feedback on the new tools.

Who Ordered All These Tokens? Giving AI Spend a Name in FOCUS

Team Blog: FinOps

Author: Dirk_Brinkmann

Published: 08/19/2026

Summary: The article discusses the challenge of accurately attributing AI-related costs, such as Copilot and agent spend, within enterprise billing systems. Existing cost reports scatter AI expenses across ambiguous categories, making analysis difficult. The proposed solution is to create a custom “meter map” that classifies each billing meter into meaningful attributes (like token type, provider, Copilot, or agent). This enables clear reporting and chargeback, aligning spend with business questions. The approach is flexible, ongoing, and requires ownership, but solves the gap until vendor-neutral standards evolve further.

Zonal Resiliency in Azure: Application-Centric Goals, Recovery Plans, and Drills

Team Blog: ITOps Talk

Author: Pierre_Roman

Published: 08/06/2026

Summary: The article introduces “Resiliency in Azure” (formerly Azure Business Continuity Center), a unified platform for managing and validating zonal resiliency at the application level across IaaS, PaaS, and shared services. Key features include application-centric recovery plans, tailored Azure Advisor recommendations, Copilot-guided remediation, and automated zone-down drills via Azure Chaos Studio. This approach streamlines resiliency management, supports compliance, and enables realistic failover testing, reducing manual effort and uncertainty. While not all services are supported and costs may vary, it offers a significant improvement in visibility, confidence, and operational readiness for Azure applications.

Operating Azure Backup at Scale: Day-2 Excellence for IaaS, PaaS, and Storage Workloads

Team Blog: ITOps Talk

Author: Pierre_Roman

Published: 08/11/2026

Summary: The article summarizes advancements in Azure Backup, highlighting its unified, application-centric approach for protecting IaaS, PaaS, AKS, PostgreSQL, and storage workloads. Key features include a single vault model, built-in cyber resiliency with immutability and multi-user authorization, threat detection, agentless backups, and conversational configuration via VS Code. Azure Backup offers granular restores, compliance-friendly retention tiers, and robust protection against ransomware. Real-world scenarios and actionable steps demonstrate improved operational efficiency, security, and reliability for IT professionals managing large-scale Azure environments.

Expanding the Azure Local Security Ecosystem with IBM QRadar and Splunk

Team Blog: Azure Arc

Author: Ariel Netz

Published: 08/07/2026

Summary: Microsoft has announced new integrations for Azure Local with IBM QRadar and Splunk, enabling organizations in regulated and sovereign environments to incorporate Azure Local security signals into their existing security operations platforms. This enhances monitoring, investigation, and compliance while preserving established tools and processes. Azure Local’s built-in security controls and audit logs now work seamlessly with these partner solutions, supporting flexible and resilient security operations. Microsoft is also working to expand its security ecosystem with additional partners in areas like endpoint detection, vulnerability management, and container security for Azure Local and Sovereign Private Cloud deployments.

Episode 1: Onboarding Azure Arc at Scale | The Azure Arc Check-In

Team Blog: Azure Arc

Author: Mason_Torres

Published: 08/18/2026

Summary: Episode 1 of The Azure Arc Check-In discusses strategies for onboarding large fleets of Windows and Linux servers to Azure Arc at scale. It emphasizes automation and non-interactive authentication to minimize manual effort and errors. For Linux servers, Ansible with managed identity streamlines agent deployment, while Windows servers can be onboarded using Active Directory Group Policy. The episode provides step-by-step guidance for both approaches, highlighting the importance of aligning onboarding methods with existing management tools and enabling consistent configuration and governance from day one.

Announcing General Availability of Disable Multithreading and Configurable Constrained Cores

Team Blog: Azure Compute

Author: misha-bansal

Published: 08/19/2026

Summary: Microsoft Azure has launched two new features: Disable Simultaneous Multithreading/Hyper-Threading (SMT/HT Off) and Configurable Constrained Cores. These allow customers to optimize VM performance and reduce software licensing costs by customizing vCPU configurations and disabling SMT/HT for improved performance and latency. Users can select specific vCPU counts without altering memory or storage, aiding compliance and cost efficiency. The features are available in all Azure regions, with no changes to VM pricing, and help customers tailor compute resources to their workloads, maintaining performance while controlling costs.

The OpenVMM Project

Team Blog: Windows OS Platform

Author: Caroline_Perezvargas

Published: 08/17/2026

Summary: OpenVMM is an open-source, cross-platform Virtual Machine Manager (VMM) written in Rust and released under the MIT license. It offers broad support for multiple architectures, host operating systems, and virtualization backends, and features a modular, flexible design. Since becoming open source in 2024, OpenVMM has grown with contributions from major industry partners, expanding device emulation, testing infrastructure, and confidential computing capabilities. Its modern security architecture leverages Rust, process sandboxing, and user-mode virtualization. OpenVMM is used in various environments, including Azure, and aims to provide secure, high-performance virtualization for diverse workloads.

Azure Managed Redis Deployment Automation

Team Blog: Azure PaaS

Author: LuisFilipe

Published: 08/21/2026

Summary: The article introduces a PowerShell script for automating Azure Managed Redis (AMR) deployments, especially when facing regional capacity restrictions. The script retries cache creation at random intervals, cycling through specified SKUs and configurations, and cleans up failed resources before each attempt. It supports geo-replication, clustering, high availability, and custom eviction policies. Authentication, logging, and parameter validation are included. The script is provided as-is, without support or guarantees, and users are advised to test before production use due to potential costs and risks.

Tracking Batch node state and duration in Log Analytics

Team Blog: Azure PaaS

Author: Ahmed_Khaled

Published: 08/25/2026

Summary: The article addresses gaps in Azure Batch node monitoring, such as identifying nodes stuck in certain states and automating alerts. Since Azure Monitor lacks per-node granularity, the proposed solution uses a Python script to poll Batch REST API and ingest node-level data into Log Analytics. Custom KQL queries and alerts enable precise tracking of node state, duration, and errors. The solution supports dashboards, automated remediation, and actionable alerts, and can be deployed via Azure Functions, Container Apps, or VMs. It enhances monitoring without replacing built-in metrics, providing detailed, per-node visibility for customers.

Beyond Deployment: What It Really Takes to Run GitHub Actions Runners on AKS

Team Blog: Azure Infrastructure

Author: aparnabadireddigari

Published: 08/17/2026

Summary: Deploying GitHub Actions runners on Azure Kubernetes Service (AKS) with Actions Runner Controller (ARC) is straightforward, but running it as a production platform requires much more. Key challenges involve managing authentication, network dependencies, workload isolation, image lifecycle, and observability. Production readiness demands clear ownership, validated connectivity, strong operational practices, and reliable monitoring. Naming conventions and image management become platform contracts. Ultimately, success depends on operational excellence, governance, and ownership—moving beyond a working deployment to a mature, dependable platform that reliably supports multiple teams and business-critical workflows.

Azure Copilot Introduces Direct Access to Agents

Team Blog: Azure Infrastructure

Author: artigulwadi

Published: 08/18/2026

Summary: Azure Copilot now offers direct access to specialized agents for troubleshooting, deployment, optimization, and resiliency, allowing cloud operations teams to quickly engage relevant expertise. This update streamlines workflows by matching tasks with purpose-built agents, enhancing efficiency and tailored guidance. Administrators can manage agent availability flexibly, enabling incremental adoption and better governance. Pricing remains unchanged, with most agents available at no extra cost. This evolution supports agentic cloud operations, empowering teams to operate more effectively across application and infrastructure lifecycles, with future enhancements and administrative controls expected.

Accelerate Inference on AKS with Azure Blob Storage and NVIDIA Dynamo

Team Blog: Azure Storage

Author: Vishnu Charan TJ

Published: 08/11/2026

Summary: The article details how integrating Azure Blob Storage with NVIDIA’s Dynamo stack accelerates AI inference on Azure Kubernetes Service (AKS). By using Dynamo ModelExpress and Run:ai Model Streamer, model weights are loaded up to 7.3x faster, reducing cold start latency by up to 4.6x. Offloading KV cache via NIXL to Blob Storage further lowers time-to-first-token latency by 2.8x and optimizes GPU memory use. These enhancements enable faster scaling, operational simplicity, and improved reliability for large AI models, streamlining inference workflows on AKS.

Unified AI Defense: Security Copilot, Project Perception, and MDASH

Team Blog: Core Infrastructure and Security

Author: edgarus71

Published: 08/24/2026

Summary: The article outlines Microsoft’s unified AI security platform, comprising Security Copilot, Project Perception, and MDASH. Security Copilot assists security analysts via AI-driven workflows and investigations. Project Perception orchestrates multi-agent defense, coordinating Red, Blue, and Green agents to proactively identify, validate, and remediate threats. MDASH specializes in code vulnerability discovery, validation, and remediation guidance, feeding findings into broader defense workflows. Each tool serves distinct roles—analyst assistance, coordinated defense, and deep application security—but together provide a comprehensive, layered AI security solution with human oversight and governance.

AI Skills Navigator is now available in Microsoft Copilot

Team Blog: Microsoft Learn

Author: MattErni

Published: 08/27/2026

Summary: Microsoft has integrated AI Skills Navigator into Copilot's Learning Agent, enabling users to ask questions and receive personalized AI skill recommendations directly in their workflow. This new feature tailors training, learning paths, and credentials to individual roles and goals, streamlining skill development for both individuals and organizations. Progress is tracked automatically, and learning resources from various platforms are accessible within Copilot. This integration helps connect real work tasks to relevant learning opportunities, making AI upskilling more efficient and accessible across organizations.

From GPO to Microsoft Intune: A practical guide to cloud-first policy management

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 08/31/2026

Summary: The article offers a practical guide for organizations transitioning from Group Policy Objects (GPOs) to Microsoft Intune for cloud-first policy management. It outlines three migration paths—starting fresh for cloud-native devices, selectively transitioning necessary settings, or coordinating GPO and Intune for hybrid environments. Key recommendations include assessing and rationalizing existing policies, avoiding direct lift-and-shift, leveraging security baselines, piloting changes, and coordinating targeting to prevent conflicts. The guide stresses the importance of tailoring management strategies to device populations and business needs, ensuring a streamlined, secure, and efficient move to modern policy management.

Introducing device association for Windows Autopilot device preparation

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 08/27/2026

Summary: Device association for Windows Autopilot device preparation enables organizations to securely bind Windows 11 devices to their tenant before enrollment, using hardware-backed attestation. This ensures devices are recognized as corporate-owned, allowing IT admins to apply targeted policies and configurations early, streamlining the out-of-box experience for users. The association persists through resets and reinstallation, supporting consistent lifecycle management. Device association integrates with existing Autopilot strategies, offering improved security, predictability, and a device-centric onboarding process, while simplifying setup for employees and enhancing control for IT teams.

From Features to Flow: How Real-World Adoption Reshaped the Azure Architecture Diagram Builder

Team Blog: Azure Architecture

Author: arturoqu

Published: 08/13/2026

Summary: The article discusses how real-world adoption of the open-source Azure Architecture Diagram Builder led to a shift from feature-focused development to a guided, four-stage workflow: Create, Refine, Validate & Improve, and Share or Build. User feedback revealed the importance of preserving human edits, improving diagram integrity, and ensuring validation continuity. Adoption data showed users required more than simple diagram generation—they needed iterative refinement, validation, and artifact export. The product now emphasizes workflow coherence, human judgment, and clear boundaries between logical and physical architecture, while maintaining privacy-safe feedback and ongoing open-source development.

Choosing the Right Agent in Microsoft Foundry

Team Blog: Azure Architecture

Author: supriyas

Published: 08/19/2026

Summary: The article discusses how to choose between Prompt Agents and Hosted Agents in Microsoft Foundry Agent Service. Prompt Agents are simpler, managed by Foundry, and suitable for straightforward tasks with clear instructions. Hosted Agents offer greater control, supporting complex workflows, custom code, and orchestration logic, but require more engineering responsibility. The key decision factor is runtime control—teams should start with Prompt Agents and switch to Hosted Agents only when customization or advanced orchestration is needed. Identifying runtime requirements clarifies which agent type is appropriate, minimizing risk and operational overhead.

[Now Generally Available] What-If for Azure Deployment Stacks

Team Blog: Azure Governance and Management

Author: torreyt

Published: 08/18/2026

Summary: Azure’s Stacks What-if feature is now generally available, providing detailed previews of changes before deploying Azure Deployment Stacks. It shows resource-level actions (create, modify, delete, detach), filters out false positives, and stores results as retrievable resources for use in CI pipelines. This enables safer updates by clarifying impacts, especially deletions or detachments, and supports review and approval workflows. Available across all regions and scopes via CLI, PowerShell, and SDKs, Stacks What-if addresses a top user request by enhancing deployment stack transparency and reliability.

Help Shape the Microsoft Security Practitioner Community

BrookeLynnWeenig — Fri, 04 Sep 2026 17:05:32 GMT

We want to hear from the people who configure, operate, and defend with Microsoft Security every day. Share your priorities, challenges, and where you go to learn and connect.

Your feedback will help shape future technical content, hands-on experiences, events, and community programs. The survey takes just a few minutes.

Please fill out the survey here: Microsoft Security Tech Community Practitioner Survey – Fill out form

Thank you!

Microsoft Purview - Insider Risk Management

SubhajitBhuiya — Fri, 04 Sep 2026 11:30:02 GMT

What are the Problems statements you faced while Implementing Insider Risk Management for different clients ? Any Common Problems and Challanges which is similar to Financial Services Organization and You have used similar approach or build a Unique Solution to solve this ?

Regards,

Subhajit Bhuiya