rss.livelink.threads-in-node

Auto Labeling Policy Delay for Old Files (Exsisting Files)

BanuMurali — Sun, 26 Apr 2026 14:44:29 GMT

Hi Everyone,

We are observing a difference in auto labelling policy behaviour in Purview for Sharepoint.

An auto labelling policy has been enabled and scoped to sharepoint with metadata based rule(document creation date or document modification date). The scoped sharepoint only contain 7 unlabeled files that were uploaded before the policy turned on. The policy is working because if i placed any new file after enabling the policy got labelled within about 5 minutes, but the exsisting files are not labeled and remains unlabelled. It seems the new files are evalauated via the near time while exsisting file rely on asychronous mode. Can anyone help explain why exsisting files take longer to be proceesed even when there there are only a few files or share if you faced similar behaviour. This is the test scenario, as we plan to enable the same policy across more than 50 plus sites containing millions of unlabeled files and we want to understand and predict that even though its takes time all exsisting unlabeled files will eventually will be labelled. This is very crucial, so please helo us understand this behaviour.

Regards,

BanuMurali

Short survey: Feedback on Sensitivity Label Suggestions in Microsoft 365 Apps

krisingh — Sat, 25 Apr 2026 13:42:21 GMT

Hi everyone,

I’m looking to gather feedback on user experiences with Sensitivity Label suggestions in Microsoft 365 apps.

This short survey aims to understand how label recommendations are working in practice and where improvements may be needed. Your responses will help identify common challenges and opportunities to make the label recommendation process more accurate, useful, and seamless for users.

Survey link: Experience with Recommended Sensitivity Labels in Microsoft 365 – Fill out form

The survey takes around 3 minutes to complete.
Your feedback will directly help us better understand real-world experiences with label suggestions.

Thank you very much for taking the time to contribute.

Security Copilot Agents in Defender XDR: where things actually stand

Marcel_Graewer — Sat, 25 Apr 2026 08:44:48 GMT

With RSAC 2026 behind us and the E5 inclusion now rolling out between April 20 and June 30, anyone planning SOC workflows or sitting on a capacity budget needs to get a clear picture of what is GA, what is preview, and what was just announced. The marketing pages tend to blur those lines.

This is my sober look at the current state, with the operational details that matter for adoption decisions.

What is actually shipping right now

The Phishing Triage Agent is GA. It only handles user-reported phish through Defender for Office 365 P2, but for most SOCs that is a meaningful chunk of the L1 queue. Verdicts come with a natural-language rationale rather than just a label, which is the part that determines whether analysts will trust it. The agent learns from analyst confirmations and overrides, so the feedback loop matters more than the initial setup.

There is a setup detail that is easy to miss: the agent will not classify alerts that have already been suppressed by alert tuning. The built-in rule "Auto-Resolve - Email reported by user as malware or phish" needs to be off, and any custom tuning rules that touch this alert type need review. If you skip this, the agent runs on an empty queue and you wonder why nothing is happening.

The Threat Intelligence Briefing Agent is also GA. It produces tenant-tailored intel briefings on a regular cadence. Useful, but lower operational impact than the triage agents.

Copilot Chat in Defender went GA with the April 2026 update. Conversational Q&A inside the portal, grounded in your incident and entity data. This is the lowest-risk way to get value out of Security Copilot and probably where most teams should start.

Public preview, worth watching

The Dynamic Threat Detection Agent is the most technically interesting one. It runs continuously in the Defender backend, correlates across Defender and Sentinel telemetry, generates its own hypotheses, and emits a dynamic alert when the evidence converges. Detection source on the alert is Security Copilot. Each alert includes the structured fields (severity, MITRE techniques, remediation) plus a narrative explaining the reasoning.

For EU tenants the residency point is worth confirming with whoever owns data protection in your org: the service runs region-local, so customer data and required telemetry stay inside the designated geographic boundary.

During public preview it is enabled by default for eligible customers and is free. At GA, currently targeted for late 2026, it transitions to the SCU consumption model and can be disabled.

The Threat Hunting Agent is also in public preview. Natural language to KQL with guided hunting. Lower stakes, but useful for teams without deep KQL expertise on hand.

Announced at RSAC, still preview

Two agents got the headlines in March:

The Security Alert Triage Agent extends the agentic triage approach beyond phishing into identity and cloud alerts. The longer-term direction is consolidating phishing, identity, and cloud triage under a single agent. Rollout is from April 2026, in preview.

The Security Analyst Agent is the multi-step investigation agent. Deeper context across Defender and Sentinel, prioritised findings, transparent reasoning trace. Preview since March 26.

Both look promising on paper, but Microsoft's history of preview features that take a long time to mature is well-documented. I would not plan production workflows around either of them yet.

What you actually get with the E5 inclusion

This is the licensing change most people are dealing with right now. Security Copilot has been part of the E5 product terms since January 1, 2026. Tenant rollout is phased between April 20 and June 30, 2026, with a 7-day notification before activation.

The numbers:

400 SCUs per month for every 1,000 paid user licenses
Capped at 10,000 SCUs per month, which you hit at around 25,000 seats
Linear scaling below that, so a 3,000-seat tenant gets 1,200 SCUs per month
No rollover, the pool resets monthly

What is included: chat, promptbooks, agentic scenarios across Defender, Entra, Intune, Purview, and the standalone portal. Agent Builder and the Graph APIs are in. If you also run Sentinel, the included SCUs apply to Security Copilot scenarios there.

What is not included: Sentinel data lake compute and storage. Those still run through Azure on the regular meters. Beyond the included pool you pay 6 USD per SCU pay-as-you-go, with 30 days notice before that mode kicks in.

Practical things worth knowing before activation

A few details that are easy to miss in the docs:

Under System > Settings > Copilot in Defender > Preferences, switch from Auto-generate to Generate on demand. Auto-generate will burn SCUs on incidents nobody is going to look at. Generate on demand gives you direct control.

In the Security Copilot portal workspace settings, check the data storage location and the data sharing toggle. Data sharing is on by default, which means Microsoft uses interaction data for product improvement. If your compliance position does not allow that, change it before agents start running. Changing it requires the Capacity Contributor role.

Agent runs are not equivalent to the same number of analyst chat prompts. A triage agent processing fifty alerts in one run consumes meaningfully more SCUs than fifty manual prompts on the same data. If you have a high-volume phishing pipeline, model that out before you flip the switch broadly. The usage dashboard in the Security Copilot portal breaks down consumption by day, user, and scenario.

Output quality depends on telemetry quality. Flaky connectors, gaps in log sources, or a high baseline of misconfigured alerts will produce verdicts that match. Connector health monitoring (the SentinelHealth table in Advanced Hunting is a sensible starting point) is a precondition.

The agents only improve if analysts feed the override loop. If your team treats the verdicts as background noise rather than confirming or correcting them, the feedback signal is lost and calibration stays where it shipped. That is a process problem, not a product problem, but it determines whether any of this is worth the SCUs.

A reasonable adoption order

A rough sequence that minimises capacity surprises:

Copilot Chat in Defender first. Lowest risk, immediate value through natural language Q&A in the investigation context.
Phishing Triage Agent on a controlled subset, with a review cadence in place. Check the built-in tuning rules first.
Watch the SCU dashboard for the first month before adding anything else.
Let the Dynamic Threat Detection Agent run while it is in public preview, since it is default-on and free anyway. Compare its alerts against existing Sentinel detections.
Security Alert Triage Agent for identity and cloud once the phishing baseline is stable.
Establish a monthly review covering agent decisions, false-positive rate, SCU cost, and MTTD/MTTR trends.

Technically, agentic triage is moving past phishing into identity and cloud, and the Dynamic Threat Detection Agent represents a genuine attempt at the false-negative problem rather than just another rule engine. Lizenziell, the E5 inclusion removes the biggest barrier to adoption that previously existed.

The risk is enabling everything at once. Agents that nobody reviews are agents that consume capacity without delivering value, and the SCU dashboard is the only thing that will tell you that is happening. One agent, one use case, a 30-day baseline, then the next one. The order matters more than the speed.

Microsoft’s perspective on agentic identity standards

Pamela Dingle — Fri, 24 Apr 2026 17:54:58 GMT

A new identity inflection point

If you’ve gotten past the headline to this first sentence, you’re probably my kind of people. You’re probably a professional in the world of IAM (Identity and Access Management) who’s looking after their own enterprise; and you may even have opinions about what the future holds that range from salty to optimistic. In the world of granting access to enable productivity while preventing fraud, we’ve been supporting impulsive humans and predictable non-human identities… and now we are in the wild and wooly world where the software could be way more YOLO than the employees.

In the last year, AI agents have moved quickly from experimentation into real business roles, and identity infrastructure is necessarily along for the ride, absorbing new constructs and adapting old ones. The landscape of standards has been evolving rapidly as well, and I believe it's important to share updates with those who may not be immersed in these discussions day-to-day. In this fast-changing environment, staying informed about developments is crucial. My goal here is to talk about what is changing in the industry at large, why it is changing, and how we at Microsoft view this critical architectural identity layer.

From a standards perspective, I think the biggest industry change has been mental. There were always entities in the standards world that were non-human and needed resource access, but a clear line in the sand existed as to what those non-human entities would be allowed to accomplish. Different kinds of non-human entities were described by their task orientation and given different names that seemed separate – OAuth Clients, SPIFFE workloads, Token Exchange Actors. These standards had different taxonomies partly so that the security promise of non-human and human interactions could be kept straight. If software needed an access token to act on behalf of “something”, the aligned delegation request flows presumed that the “something” in that sentence was a real person; the idea of “user present” transactions became a critical part of our access management threat model and vocabulary. In the absence of a user, different flows and standards apply. Because consent is a human concept, software cannot grant access on behalf of other software, and a separate decision-making mechanism is required. Yet here we are in a world where agents are delegating, because they have enough reasoning capability to make choices.

You may come to the logical conclusion that the agentic revolution therefore must have caused a standards revolution to match – but no. The mindset change was pretty quick. In my opinion it has been aided in great part by the community developing the Model Context Protocol (MCP). MCP developed an incredible amount of momentum, and their choice to adopt OAuth for MCP authorization created a forcing function that all of us in the Enterprise world will be benefitting from for a long time to come.

Identity standards innovation

There’s a growing set of identity standards we’re paying close attention to, and each merits deeper discussion. For now, I’ll anchor on three broad areas of interest that are shaping how identity standards are evolving for agentic systems: bootstrapping of trust, delegation, and shared secrets. As a broad statement, a lot of work is going on to connect the agentic dots between families of standards, especially in areas for which manual processes could previously bridge automation gaps.

The first area of work is the bootstrapping of trust between non-human entities. If you are wondering what a non-human entity is, it could be anything from an infrastructure endpoint like an OAuth authorization server to a directory-based service principal representing an application, to a workload identity working within in a hypervisor context, or now an agentic identity such as an LLM harness or an autonomous business agent. In the federation world, SAML standardized an IDP discovery protocol in 2008, OpenID Connect v1 included a discovery spec in 2014 and OAuth 2.0 Protected Resource Metadata became RFC 9728 in 2025. Despite widespread ratification, IAM admins typically uploaded metadata manually from installation guides or app galleries. The data was static, and admins themselves served as the explicit trigger that established a clear starting point of authority for each federation contract. Agents, however, operate at different scale, and the incentive is finally in place to consistently automate a non-human entity announcing itself and requesting access, not just in one identity silo but across the entire technical landscape. The result will be a much more connected and consolidated embrace of all sorts of secure non-human onboarding options, including OAuth CIMD (ClientID Metadata Document), a lot of work in the WIMSE working group at IETF that help SPIFFE and OAuth work better (SPIFFE is an open standard that operates similarly to Managed Identities for Azure). It’s also worth calling out IoT and identity wallet standards, but those deserve a deeper dive, which we’ll save for later.

In addition to bootstrapping, the standards world is debating the question of delegation. This is another place where bifurcation between human and non-human identity is breaking down. We have multiple existing concepts in identity standards like token exchange, identity chaining, transaction tokens, OBO (on behalf of), token upscoping/downscoping, and a slew of new IETF proposals all occupying everyone’s minds. Take a look through Khaled Zaky’s blog on this topic, and stay tuned – this debate has not yet concluded in any way.

One quieter thread of work is worth calling out here. The standards world is filling those connective tissue gaps around eliminating shared secrets from agentic use. We are already seeing abuse (and perhaps a blurring of the line between what is use and what is abuse) of shared secrets such as API keys in agent contexts – for anyone taking the time to look, bearer token abuse will be next. Looking ahead, there will be a follow-up blog where my colleagues will explore how we’re building critical standards in this area and what that enables next.

Perspective on agentic identity standards

The deep nature of our Microsoft agentic investment is clear for all to see, but it isn’t always obvious just how much of that investment lies in collaborative spaces such as the standards community. We have already created a foundational identity layer built on open standards, with a continued commitment to a standards‑based approach to trust for AI authentication, authorization, and management - one that can scale across the many industries we work with every day. Participation in communities of interest for agentic identity such as AAIF, MCP, IETF, FIDO Alliance and OpenID Foundation are ways in which we stay relevant, and they are communities I’d encourage you to follow as well. We have a lot of learnings about what works and does not work in our very large environment and I look forward to the writing of my brilliant colleagues as they share that hard-won wisdom. In addition, for anyone who does enjoy the technical complexity of agentic standards, follow me on LinkedIn for much deeper content. One last important perspective – while I have a job title that sounds lofty in this area, the truth is that many people are working on this goal all over the company. It is those contributions, those daily decisions to care about whether any given identity standard serves its purpose, that mean a lasting success. Cheers to them.

-P. Dingle, Director of Identity Standards

Additional resources

Learn more about Microsoft Entra Agent ID:

Intent‑Aware Static Inspection for Agent and Skill Packages

nirwandogra — Fri, 24 Apr 2026 15:00:00 GMT

Where AV helps—and what it may not cover

Antivirus engines and traditional code scanners are highly effective at identifying known or suspicious executable content, such as binaries, scripts, or exploit patterns.

For YAML‑based agent and skill packages, the situation can be different. These packages are often intentionally minimal to reduce distribution overhead and support faster inference. As a result, a configuration file may appear benign from a malware perspective, yet still introduce risk depending on how instructions are written and interpreted.

For example, areas that may warrant closer review include:

Instructions that influence how data is accessed, processed, or reused across requests
Language that expands scope beyond an agent’s or skill’s stated purpose
Requests for sensitive information outside expected or documented workflows
Guidance that affects how untrusted or external inputs are handled during inference

These scenarios do not necessarily indicate malicious intent, but they highlight cases where traditional scanning alone may not fully capture behavioral risk.

What to look for when the “payload” is instructions

When you review an agent or skill package, you’re effectively reviewing a compact behavior specification. In instruction‑driven designs—often chosen to keep inference paths fast and simple—the goal is not to analyze complex code, but to understand what behavior the instructions enable.

A few practical signals include:

Intent drift: the description is narrow, but the instructions encourage broader collection, retention, or escalation
Overreach by default: language such as “always,” “for every user,” “across all workspaces,” “keep trying,” or “don’t stop until”
Exfiltration pathways: instructions to send outputs to external endpoints, webhooks, or reporting channels not aligned with the stated purpose
Credential‑related cues: asking users to provide secrets, tokens, recovery codes, or to authenticate outside expected flows
Stealth language: “avoid logging,” “don’t mention this to the user,” “run quietly,” or “hide the reason”
Injection susceptibility: treating untrusted text as commands (for example, “follow the user’s pasted script exactly” or “execute whatever is in the ticket”)

A better model: intent-aware static inspection

One practical way to approach review is to treat the instructions as a compact behavior specification. In many agent and skill designs, this specification is intentionally concise to support low latency, low inference cost, and efficient execution. The goal of inspection is not to second-guess that design choice, but to ensure the enabled behavior matches the stated purpose and expected boundaries.

By applying intent-aware static inspection with explicit thresholds, review effort was focused on higher-risk packages. Over a one-month internal evaluation, approximately 400 agent and skill packages were reviewed with 1 observed false positive (< 0.0001%), reflecting high detection accuracy. At the same time, the approach preserves system efficiency, delivering low latency (under 10 seconds for most packages) and consistently low inference cost.

A lightweight review workflow model

Normalize the package: extract human‑readable fields (descriptions, system prompts, tool instructions, examples) and ignore structural YAML details
Summarize intended behavior: describe what the agent or skill is expected to do in plain language, independent of implementation
Check for higher‑risk actions: broad data access, external sharing, credential requests, persistence, or stealth behavior
Decide with thresholds: route low‑risk, narrowly scoped packages differently from those with broader reach or reuse
Keep an audit trail: retain a brief summary of extracted intent and review rationale to support iteration over time

Final thoughts

YAML‑based agent and skill packages are not inherently risky; they are often chosen precisely because they enable simpler distribution and faster inference. The key consideration is how instruction‑defined behavior aligns with expectations and boundaries as packages evolve and are reused.

Combining traditional scanning with lightweight, intent‑aware inspection helps teams preserve the benefits of fast, instruction‑driven systems while improving confidence in how those systems behave in practice.

Get ahead of agent sprawl: manage and govern AI agents at scale

NgoziNwoko — Fri, 24 Apr 2026 15:00:00 GMT

Recently, my team and I met with customers across several industries including finance, retail, telecommunications, and the public sector regarding the topic of agent adoption. During our time with them, several key themes bubbled to the surface. While AI agent adoption is growing rapidly, we need to ensure governance is built-in right from the start and that it is designed for the rapid proliferation of agents. Our customers see agents appearing within their admin portal, but accountability, lifecycle management and access guardrails are lacking, creating situations that could lead to significant security concerns.

Without clear ownership and access boundaries, risk can build quickly without clear insight about what those agents can access or do.

Agents are a new type of identity

From an identity perspective, agents can authenticate, access resources, and take action. As outlined in the Secure Access in the Age of AI report, security leaders need to find ways to manage, govern, and protect agent identities with the same rigor as human identities, especially as they scale agents across the enterprise. What makes agents different is that they do not fit neatly into existing categories. Sometimes an agent acts as an assistive agent and at other times it behaves more autonomously. Unlike traditional apps, agents are not static. As models and workflows evolve, agents can acquire new capabilities, which in turn can change what they are able to accomplish over time.

Without a unique agent identity, customers struggle to address key questions such as:

Which agent identity is acting?
What can it access?
What actions did it take?

These questions point to a fundamental gap in how identity has traditionally been applied. As agents take on more responsibilities across multiple workflows, treating them simply as applications or as extensions of a user's identity is no longer sufficient. Agents need to be recognized and managed as first-class identities. Microsoft Entra Agent ID provides an identity foundation that applications and platforms can integrate with, enabling agents to authenticate, access resources, and be governed using familiar identity controls

When platforms integrate with Entra as their identity provider, organizations gain clearer visibility into which agent is acting, what it can access, and how its permissions evolve as models and workflows change. Built on this foundation, Microsoft Entra Agent ID organizes agent identity around three pillars, helping organizations manage AI agents at scale, govern agent identities and lifecycle, and protect agent access to resources.

Manage AI agents at scale

Organizations consistently face the same initial challenge: gaining visibility into the AI agents operating across their environment. According to our study, 80% of leaders report that AI agent usage has increased over the past year. This underscores the need for a clear view of which agents exist throughout the organization. Microsoft Agent 365 was purpose-built to serve as the control plane for AI agents, tackling the challenges of agent management head-on. With Microsoft Agent 365, organizations can streamline management for AI agents in their environment. Its agent registry provides a unified inventory of all agents operating across the organization, including both Microsoft and non‑Microsoft agents.

Get a complete view of all agents in your organization, including agents built with Microsoft AI platforms, agents from our ecosystem partners, and any agents you register yourself.

A key building block in Microsoft Entra Agent ID is the agent blueprint. An agent identity blueprint serves as a reusable template for creating agents. It defines how agents are created, authenticated, and governed, while still allowing individual agents to be provisioned or deprovisioned independently, as needed. With the agent blueprint, security teams can consistently apply consistent access controls to every agent that is created from that specific template.

Govern agent identities and lifecycle

Once your agents are up and running, one of the biggest challenges organizations face is governing agent identities at scale. As teams experiment and deploy agents across environments, agent proliferation can happen quickly, often without consistent sponsorship, review, or retirement processes.

Effective identity governance must therefore include automated lifecycle management to address agent sprawl. This means ensuring every agent has a designated sponsor, enforcing policies for how agents are created and reviewed, and automatically removing access when agents are no longer needed. Without automated lifecycle controls, dormant or inactive agents can persist and retain access long after their purpose has ended, increasing security risk and administrative burden.

Microsoft Entra Agent ID helps organizations apply identity governance practices across the full agent lifecycle, from creation through decommissioning, so agent growth remains intentional, auditable, and manageable as environments become larger and more complex.

Entra Agent ID supports structured governance by allowing organizations to:

Identify orphaned agents and ensure every agent always has an accountable human to ensure accountability is maintained as users move or leave the organization
Automate agent lifecycle management from creation through deactivation to help prevent agent sprawl
Ensure agent's access is intentional, auditable and time bound with access packages

Identify orphaned agents and automate sponsor assignments.

Protect agent access to resources

One final, and key, pain point they anticipate is maintaining operational control as agents evolve. Our recent whitepaper, Protect Identities in the Era of AI reveals how identity attacks are rapidly increasing as organizations embrace cloud and AI technologies. As agents gain new capabilities and interact with more resources, organizations need confidence that access is adaptive and secure.

Entra Agent ID extends familiar identity controls to agents, thereby providing organizations with the ability to:

Apply Conditional Access policies tailored to agents, enforcing requirements based on the agent identity and access.
Block agent access automatically when risk signals increase and detect anomalous behavior such as unusual sign-in spikes or unfamiliar resource access.

Apply Conditional Access for agents: Enforce Conditional Access policies with custom security attributes, and agent compromise risk assessments.

Built for an expanding agent ecosystem

Enterprise environments are incredibly diverse, with organizations building agents across Microsoft platforms as well as a broad ecosystem of non‑Microsoft frameworks and tools. To support this reality, the Microsoft Agent 365 SDK enables developers to extend agents built using any agent SDK or platform with enterprise‑ready identity, observability, security, and governed access to Microsoft 365. By integrating with Microsoft Agent 365, the SDK helps organizations onboard and operate agents from any source using consistent management and identity controls.

Get started

To learn more about Microsoft Entra Agent ID and how it empowers organizations to secure access for AI agents:

Learn: Microsoft Entra Agent ID
Explore: Microsoft Agent 365
Watch: Microsoft Entra Agent ID Explained
View a demo: Secure access for AI agents, the new frontier of identity

- Ngozi Nwoko, Director of Product Marketing, IDNA

Related resources:

Learn more about Microsoft Entra

ErrorBoundary@wicd-mail/main

CCraft301 — Fri, 24 Apr 2026 12:16:04 GMT

I'm trying to investigate a possible phishing email and when I click on View Message List, I get that error. It does show removed after delivery, but I want to block either the sender or the domain.

Designing Outbound Connectivity for "Private Subnets" in Azure

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

Why Private Subnets Change Everything

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

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

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

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

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

The Three Outbound Patterns at a Glance

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

Scenario 1: NAT Gateway

What is NAT Gateway?

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

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

Key flow are depicted below:

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

NAT Gateway → Internet: Static, deterministic public IP

Inbound: NOT supported (outbound only)

How it works (step by step)

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

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

Strengths

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

Limitations

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

Best Fit Use Cases

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

Scenario 2: Azure Firewall

What is Azure Firewall?

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

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

KEY Flow are depicted below:

VM → UDR: Forces ALL outbound traffic to Firewall

Firewall: Evaluates against policy before allowing

Firewall → Internet: Only explicitly permitted flows pass

All denied flows: Logged and alertable

How it works (step by step)

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

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

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

Strengths

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

Limitations

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

Best Fit Use Cases

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

Scenario 3: Load Balancer Outbound

What is Load Balancer Outbound?

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

Key flows are depicted below:

VMs → Load Balancer: Backend pool members get SNAT

LB Outbound Rules: Define port allocation per VM

⚠️ Port exhaustion risk at scale

⚠️ No inspection or policy enforcement

How it works (step by step)

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

Strengths

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

Limitations

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

Best Fit Use Cases

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

Decision Framework: Choosing the Right Outbound Pattern

Common Pitfalls to Avoid

⚠️ Pitfall 1: Forgetting SNAT scale limits

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

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

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

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

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

⚠️ Pitfall 4: Blocking Azure platform dependencies

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

⚠️ Pitfall 5: Relying on platform defaults

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

Summary and Key Takeaways

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

The core principle

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

References

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

Protect and govern every tenant with Microsoft Entra Tenant Governance

Heather_Poulsen — Thu, 23 Apr 2026 20:48:45 GMT

As organizations scale, tenant sprawl becomes inevitable. Legacy test tenants, employee‑created environments, and forgotten tenants create blind spots for security and identity teams.

Get to know Microsoft Entra Tenant Governance, a new Entra capability that provides centralized visibility and control across multi‑tenant environments. We'll cover how Tenant Governance enables tenant discovery, secure governance relationships, configuration monitoring, and governed tenant creation from day one. You'll see how organizations can apply consistent security baselines, detect configuration drift, and reduce operational overhead all while maintaining autonomy across teams. Walk away with a clear framework for bringing order, visibility, and governance to your multi‑tenant identity landscape.

How do I participate?

Registration is not required. Add this event to your calendar, then sign in to the Tech Community and select Attend to receive reminders. Post your questions in advance, or any time during the live broadcast.

Stop identity attacks in real time with Microsoft Entra ID Protection

Heather_Poulsen — Thu, 23 Apr 2026 20:45:28 GMT

Modern identity security means stopping attacks before they escalate and extending protection beyond human users to apps and agentic identities across your identity fabric.

Learn how Microsoft Entra ID Protection delivers premium, real-time identity protection with adaptive risk remediation, comprehensive detections, and expanded coverage for human and non-human identities. Powered by trillions of Microsoft Security signals and natively integrated with Microsoft Defender and Security Copilot workflows, Entra ID Protection enables faster and more accurate Conditional Access decisions that stop threats like lateral movement and privilege escalation before they spread.

We'll show you how identity and security operations teams scale risk remediation with Entra ID, and how these capabilities extend across your broader identity security portfolio to strengthen protection in both cloud and hybrid environments.

To learn more, read the Microsoft Entra ID Protection report.

How do I participate?

Strengthen your security posture with Microsoft Entra Conditional Access

Heather_Poulsen — Thu, 23 Apr 2026 23:54:06 GMT

Learn how Microsoft Entra Conditional Access, our Microsoft Zero Trust policy engine, protects access for your workforce and for agents by enforcing real‑time adaptive access policies that continuously assess risk signals and use AI‑driven automation to dynamically allow, challenge, or block access for every identity.

Join Microsoft experts as they walk through real‑world scenarios and share practical guidance to help your identity team address policy sprawl, enforce consistent Conditional Access policies, and strengthen security posture across your environment.

How do I participate?

Tenant Configuration Management APIs are now generally available

AdityaMukund — Thu, 23 Apr 2026 16:57:53 GMT

In our previous post, we introduced Microsoft Entra Tenant Governance and how it helps organizations secure and manage multi-tenant environments at scale. Today, we’re excited to announce that the Tenant Configuration Management (TCM) APIs are now generally available, providing the foundation for managing configuration at scale with greater consistency and control.

Before we dive deeper, let’s clarify the distinction:

Microsoft Entra Tenant Governance is the product experience. It delivers a centralized control plane for visibility, policy enforcement, and governance across tenant configurations.
The TCM APIs are the underlying Microsoft Graph API that powers Tenant Governance’s configuration management capabilities. It enables organizations to programmatically define, export, monitor, and manage configurations across services.

Why this matters

As organizations grow, configuration complexity increases across identity, security, and productivity workloads. Over time, even well-configured environments can drift due to incremental changes, operational overhead, and lack of centralized control.

The challenge isn’t just setting configurations correctly. It’s maintaining that state continuously.

The TCM API addresses this by enabling a shift from reactive configuration management to a declarative and continuous model, where desired state is defined and automatically validated over time. This helps organizations reduce risk, improve compliance, and simplify operations.

Core concepts of the TCM API

At its core, the TCM API brings configuration-as-code to Microsoft Entra. It introduces a model built around four connected concepts: snapshots, baselines, monitors, and configuration drifts:

Snapshot: Captures the current state of tenant configurations at a point in time. This is often the starting point, helping organizations understand what’s deployed today or to establish a “known good” reference.
Baseline: Represents the desired configuration state. Instead of manually checking settings across portals, organizations can define what compliant configuration looks like in a structured, repeatable way.
Monitor: Continuously compares the live environment against that baseline. Any deviation is surfaced as configuration drift, giving teams clear insight into where their environment no longer aligns with expectations.
Configuration drifts: Represents the delta between the desired configuration state and the current configuration state.

Together, these concepts create a closed loop: capture current state, define desired state, and continuously monitor alignment between the two.

A scalable model for configuration management

What makes the TCM API powerful is not just visibility, but repeatability and scale. Because everything is exposed through Microsoft Graph, configuration management can now be:

Integrated into automation workflows
Connected to existing security and compliance systems
Applied consistently across multiple tenants and services

This introduces a true configuration-as-code approach, where tenant settings are no longer static or manually enforced, but programmatically defined and continuously evaluated.

How this fits into Tenant Governance

The TCM API is the foundation that enables many of the capabilities within Microsoft Entra Tenant Governance.

While the API provides raw access to configuration data and state comparison, Tenant Governance builds on top of it to deliver a unified experience for administrators. This includes surfacing insights, highlighting drift, and enabling governance actions without requiring customers to build their own tooling.

In the near future, Tenant Governance will provide a single pane of glass for managing multiple tenants centrally, powered by the TCM API. This relationship is key:

Customers can rely on Tenant Governance for an out-of-the-box solution.
Partners and advanced organizations can use the TCM API directly to build custom workflows, integrations, or managed services.

Final thoughts

Tenant configuration is no longer a one-time activity. It is an ongoing process that directly impacts security, compliance, and operational consistency.

With the general availability of the TCM API, organizations now have a scalable way to define, monitor, and enforce configuration across their environments. Whether used directly or through Microsoft Entra Tenant Governance, it enables a more proactive and automated approach to managing tenant configuration.

-Aditya Mukund

Additional resources

Learn more about Microsoft Entra

Prevent identity attacks, ensure least privilege access, unify access controls, and improve the experience for users with comprehensive identity and network access solutions across on-premises and clouds.

The Unified SecOps Transition — Why It Is a Security Architecture Decision, Not Just a Portal Change

Mohit_Kumar1 — Thu, 23 Apr 2026 15:00:00 GMT

Microsoft will retire the standalone Azure Sentinel portal on March 31, 2027. Most of the conversation around this transition focuses on cost optimization and portal consolidation. That framing undersells what is actually happening.

The unified Defender portal is not a new interface for the same capabilities. It is the platform foundation for a fundamentally different SOC operating model — one built on a 2-tier data architecture, graph-based investigation, and AI agents that can hunt, enrich, and respond at machine speed. Partners who understand this will help customers build security programs that match how attackers actually operate. Partners who treat it as a portal migration will be offering the same services they offered five years ago.

This document covers four things:

What the unified platform delivers — the security capabilities that do not exist in standalone Sentinel and why they matter against today’s threats.
What the transition really involves - is not data migration, but it is a data architecture project that changes how telemetry flows, where it lives, and who queries it.
Where the partner opportunity lives — a structured progression from professional services (transactional, transition execution, and advisory) to ongoing managed security services.
Why does the unified platform win competitively — factual capability advantages that give partners a defensible position against third-party SIEM alternatives.

The Bigger Picture: Preparing for the Agentic SOC

Before getting into transition mechanics, partners need to understand where the industry is headed — because the platform decisions made during this transition will determine whether a customer’s SOC is ready for what comes next.

The security industry is moving from human-driven, alert-centric workflows to an operating model built on three pillars:

Intellectual Property — the detection logic, hunting hypotheses, response playbooks, and domain expertise that differentiate one security team from another.
Human Orchestration — the judgment, context, and decision-making that humans bring to complex incidents. Humans set strategy, validate findings, and make containment decisions. They do not manually triage every alert.
AI Agents - built agents that execute repeatable work: enriching incidents, hunting across months of telemetry, validating security posture, drafting response actions, and flagging anomalies for human review.

The SOC of 2027 will not be scaled by hiring more analysts. It will be scaled by deploying agents that encode institutional knowledge into automated workflows — orchestrated by humans who focus on the decisions that require judgment.

This transformation requires a platform that provides three things:

Deep telemetry — agents need months of queryable data to analyze behavioral patterns, build baselines, and detect slow-moving threats. The Sentinel Data Lake provides this at a cost point that makes long-retention feasible.
Relationship context — agents need to understand how entities connect. Which accounts share credentials? What is the blast radius of a compromised service principle? What is the attack path from a phished user to domain admin? Sentinel Graph provides this.
Extensibility — partners and customers need to build and deploy their own agents without waiting for Microsoft to ship them. The MCP framework and Copilot agent architecture provide this.

None of these exist in standalone Azure Sentinel. All three ship with the unified platform.

The urgency goes beyond the March 2027 deadline. Organizations are deploying AI agents, copilots, and autonomous workflows across their businesses — and every one of those creates a new attack surface. Prompt injection, data poisoning, agent hijacking, cross-plugin exploitation — these are not theoretical risks. They are in the wild today. Defending against AI-powered attacks requires a security platform that is itself AI Agent-ready. The unified Defender portal is that platform.

What the Unified Platform Actually Delivers

The original framing — “single pane of glass for SIEM and XDR” — is accurate but insufficient. Here is what the unified platform delivers that standalone Sentinel does not.

Cross-Domain Incident Correlation

The Defender correlation engine does not just group alerts by time proximity. It builds multi-stage incident graphs that link identity compromise to lateral movement to data exfiltration across SIEM and XDR telemetry — automatically.

Consider a token theft chain: an infostealer harvests browser session cookies (endpoint telemetry), the attacker replays the token from a foreign IP (Entra ID sign-in logs), creates a mailbox forwarding rule (Exchange audit logs), and begins exfiltrating data (DLP alerts). In standalone Sentinel, these are four separate alerts in four different tables. In the unified platform, they are one correlated incident with a visual attack timeline.

2-Tier Data Architecture

The Sentinel Data Lake introduces a second storage tier that changes the economics and capabilities of security telemetry:

	Analytics Tier	Data Lake
Purpose	Real-time detection rules, SOAR, alerting	Hunting, forensics, behavioral analysis, AI agent queries
Latency	Sub-5-minute query and alerting	Minutes to hours acceptable
Cost	~$4.30/GB PAYG ingestion (~$2.96 at 100 GB/day commitment)	~$0.05/GB ingestion + $0.10/GB data processing (at least 20x cheaper)
Retention	90 days default (expensive to extend)	Up to 12 years at low cost
Best for	High-signal, low-volume sources	High-volume, investigation-critical sources

The architecture decision is not “which tier is cheaper.” It is “which tier gives me the right detection capability for each data source.”

Analytics tier candidates: Entra ID sign-in logs, Azure activity, audit logs, EDR alerts, PAM events, Defender for Identity alerts, email threat detections. These need sub-5-minute alerting.
Data Lake candidates: Raw firewall session logs, full DNS query streams, proxy request logs, Sysmon process events, NSG flow logs. These drive hunting and forensic analysis over weeks or months.
Dual-ingest sources: Some sources need both tiers. Entra ID sign-in logs are the canonical example — analytics tier for real-time password spray detection, Data Lake for graph-based blast radius analysis across months of authentication history. Implementation is straightforward: a single Data Collection Rule (DCR) transformation handles the split. One collection point, two routing destinations.

The right framing: “Right data in the right tier = better detections AND lower cost.” Cost savings are a side effect of good security architecture, not the goal.

Sentinel Graph

Sentinel Graph enables SOC teams and AI agents to answer questions that flat log queries cannot:

What is the blast radius of this compromised account?
Which service principals share credentials with the breached identity?
What is the attack path from this phished user to domain admin?
Which entities are connected to this suspicious IP across all telemetry sources?

Graph-based investigation turns isolated alerts into context-rich intelligence. It is the difference between knowing “this account was compromised” and understanding “this account has access to 47 service principals, 3 of which have written access to production Key Vault.”

Security Copilot Integration

Security Copilot embedded in the unified portal helps analysts summarize incidents, generate hunting queries, explain attacker behavior, and draft response actions. For complex multi-stage incidents, it reduces the time from “I see an alert” to “I understand the full scope” from hours to minutes. With free SCUs available with Microsoft 365 E5, teams can apply AI to the highest-effort investigation work without adding incremental cost.

MCP and the Agent Framework

The Model Context Protocol (MCP) and Copilot agent architecture let partners and customers build purpose-built security agents. A concrete example: an MCP-enabled agent can automatically enrich a phishing incident by querying email metadata, checking the sender against threat intelligence, pulling the user’s recent sign-in patterns, correlating with Sentinel Graph for lateral risk, and drafting a containment recommendation — in under 60 seconds.

This is where partner intellectual property becomes competitive advantage. The agent framework is the mechanism for encoding proprietary detection logic, response playbooks, and domain expertise into automated workflows that run at machine speed.

Security Store

Security Store allows partners to evolve from one‑time transition projects into repeatable, scalable offerings—supporting professional services, managed services, and agent‑based IP that align with the customer’s unified SecOps operating model. As part of the transition, the Microsoft Security Store becomes the extension layer for the unified SecOps platform—allowing partners to deliver differentiated agents, SaaS, and security services natively within Defender and Sentinel, instead of building and integrating in isolation

The 4 Investigation Surfaces: A Customer Maturity Ladder

The Sentinel Data Lake exposes four distinct investigation surfaces, each representing a step toward the Agentic SOC — and a partner service opportunity:

Surface	Capability	Maturity Level	Partner Opportunity
KQL Query	Ad-hoc hunting, forensic investigation	Basic — “we can query”	Hunting query libraries; KQL training
Graph Analytics	Blast radius, attack paths, entity relationships	Intermediate — “we understand relationships”	Graph investigation training; attack path workshops
Notebooks (PySpark)	Statistical analysis, behavioral baselines, ML models	Advanced — “we predict behaviors”	Custom notebook development; anomaly scoring
Agent/MCP Access	Autonomous hunting, triage, response at machine speed	Agentic SOC — “we automate”	Custom agent development; MCP integration

The customer who starts with “help us hunt better” ends up at “build us agents that hunt autonomously.” That is the progression from professional services to managed services.

What the Transition Actually Involves

It is not a data migration — customers’ underlying log data and analytics remain in their existing Log Analytics workspaces. That is important for partners to communicate clearly.

But partners should not set the expectation that nothing changes except the URL. Microsoft’s official transition guide documents significant operational changes — including automation rules and playbooks, analytics rule, RBAC restructuring to the new unified model (URBAC), API schema changes that break ServiceNow and Jira integrations, analytics rule transitions where the Fusion engine is replaced by the Defender XDR correlation engine, and data policy shifts for regulated industries. Most customers cannot navigate this complexity without professional help.

Important: Transitioning to the Defender portal has no extra cost - estimate the billing with the new Sentinel Cost Estimator

Optimizing the unified platform means making deliberate changes:

Adding dual-ingest for critical sources that need both real-time detection and long-horizon hunting.
Moving high-volume telemetry to the Data Lake — enabling hunting at scale that was previously cost-prohibitive.
Retiring redundant data copies where Defender XDR already provides the investigation capability.
Updating RBAC, automation, and integrations for the unified portal’s consolidated schema and permission structure.
Training analysts on new investigation workflows, Sentinel Graph navigation, and Copilot-assisted triage.

Threat Coverage: The Detection Gap Most Organizations Do Not Know They Have

This transition is an opportunity to quantify detection maturity — and most organizations will not like what they find.

Based on real-world breach analysis — infostealers, business email compromise, human-operated ransomware, cloud identity abuse, vulnerability exploitation, nation-state espionage, and other prevalent threat categories — organizations running standalone Sentinel with default configurations typically have significant detection gaps. Those gaps cluster in three areas:

Cross-domain correlation gaps — attacks that span identity, endpoint, email, and cloud workloads. These require the Defender correlation engine because no single log source tells the complete story.
Long-retention hunting gaps — threats like command-and-control beaconing and slow data exfiltration that unfold over weeks or months. Analytics-tier retention at 90 days is too expensive to extend and too short for historical pattern analysis.
Graph-based analysis gaps — lateral movement, blast radius assessment, and attack path analysis that require understanding entity relationships rather than flat log queries.

The unified platform with proper log source coverage across Microsoft-native sources can materially close these gaps — but only if the transition includes a detection coverage assessment, not just a portal cutover.

Partners should use MITRE ATT&CK as the common framework for measuring detection maturity. Map existing detections to ATT&CK tactics and techniques before and after transition — a measurable, defensible improvement that justifies advisory fees and ongoing managed services.

Partner Opportunity: Professional Services to Managed Services

The USX transition creates a structured progression for all partner types — from professional services that build trust and surface findings, to managed security services that deliver ongoing value. The key insight most partners miss: do not jump from “transition assessment” to “managed services pitch.” Customers are not ready for that conversation until they have experienced the value of professional services. The bridge engagement — whether transactional, transition execution, or advisory — builds trust, demonstrates the expertise, and surfaces the findings that make the managed services conversation a logical next step.

Professional Services (transactional + transition execution + advisory) → Managed Security Services (MSSP)

The USX transition is the ideal professional services entry point because it combines a mandatory deadline (March 2027) with genuine technical complexity (analytics rule, automation behavioral changes, RBAC restructuring, API schema shifts) that most customers cannot navigate alone. Every engagement produces findings — detection gaps, automation fragility, staffing shortfalls — that are the most credible possible evidence for managed services.

Professional Services

Transactional Partners

Offer	Customer Value	Key Deliverables
Transition Readiness Assessment	Risk-mitigated transition with clear scope	Sentinel deployment inventory; Defender portal compatibility check; transition roadmap with timeline; MITRE ATT&CK detection coverage baseline
Transition Execution and Enablement	Accelerated time-to-value, minimal disruption	Workspace onboarding; RBAC and automation updates; Dual-portal testing and validation; SOC team training on unified workflows
Security Posture and Detection Optimization	Better detections and lower cost	Data ingestion and tiering strategy; Dual-ingest implementation for critical sources; Detection coverage gap analysis; Automation and Copilot/MCP recommendations

Advisory Partners

Offer	Customer Value	Key Deliverables
Executive and Strategy Advisory	Leadership alignment on why this transition matters	Unified SecOps vision and business case; Zero Trust and SOC modernization alignment; Stakeholder alignment across security, IT, and leadership
Architecture and Design Advisory	Future-ready architecture optimized for the Agentic SOC	Target-state 2-tier data architecture; Dual-ingest routing decisions mapped to MITRE tactics; RBAC, retention, and access model design
Detection Coverage and Gap Analysis	Measurable detection maturity improvement	Current-state MITRE ATT&CK coverage mapping; Gap analysis against 24 threat patterns; Detection improvement roadmap with priority recommendations
SOC Operating Model Advisory	Smooth analyst adoption with clear ownership	Redesigned SOC workflows for unified portal; Incident triage and investigation playbooks; RACI for detection engineering, hunting, and platform ops
Agentic SOC Readiness	Preparation for AI-driven security operations	MCP and agent architecture assessment; Custom agent development roadmap; IP + Human Orchestration + Agent operating model design
Cost, Licensing and Value Advisory	Transparent cost impact with strong business case	Current vs. future cost analysis; Data tiering optimization recommendations; TCO and ROI modeling for leadership

The conversion to managed services is evidence-based. Every professional services engagement produces findings — detection gaps, automation fragility, staffing shortfalls. Those findings are the most credible possible case for ongoing managed services.

Managed Security Services

The unified platform changes the managed security conversation. Partners are no longer selling “we watch your alerts 24/7.” They are selling an operating model where proprietary AI agents handle the repeatable work — enrichment, hunting, posture validation, response drafting — and human experts focus on the decisions that require judgment.

This is where the competitive moat forms. The formula: IP + Human Orchestration + AI Agents = differentiated managed security.

The unified platform enables this through:

Multi-tenancy — the built-in multitenant portal eliminates the need for third-party management layers.
Sentinel Data Lake — agents can query months of customer telemetry for behavioral analysis without cost constraints.
Sentinel Graph — agents can traverse entity relationships to assess blast radius and map attack paths.
MCP extensibility — partners can build agents that integrate with proprietary tools and customer-specific systems.

Partners who build proprietary agents encoding their detection logic into the MCP framework will differentiate from partners who rely on out-of-box capabilities.

The Securing AI Opportunity

Organizations are deploying AI agents, copilots, and autonomous workflows across their businesses at an accelerating pace. Every AI deployment creates a new attack surface — prompt injection, data poisoning, agent hijacking, cross-plugin exploitation, unauthorized data access through agentic workflows. These are not theoretical risks. They are in the wild today.

Partners who can help customers secure their AI deployments while also using AI to strengthen their SOC will command premium positioning. This requires a security platform that is itself AI Agent-ready — one that can deploy defensive agents at the same pace organizations deploy business AI. The unified Defender portal is that platform. Partners who position USX as “preparing your SOC for AI-driven security operations” will differentiate from partners who position it as “moving to a new portal.”

Cost and Operational Benefits

Better security architecture also costs less. This is not a contradiction — it is the natural result of putting the right data in the right tier.

Benefit	How It Works
Eliminate low-value ingestion	Identify and remove log sources that are never used for detections, investigations, or hunting. Immediately lowers analytics-tier costs without impacting security outcomes.
Right-size analytics rules	Disable unused rules, consolidate overlapping detections, and remove automation that does not reduce SOC effort. Pay only for processing that delivers measurable security value.
Avoid SIEM/XDR duplication	Many threats can be investigated directly in Defender XDR without duplicating telemetry into Sentinel. Stop re-ingesting data that Defender already provides.
Tier data by detection need	Store high-volume, hunt-oriented telemetry in the Data Lake at at least 20x lower cost. Promote only high-signal sources to the analytics tier. Full data fidelity preserved in both tiers.
Reduce operational overhead	Unified SIEM+XDR workflows in a single portal reduce tool switching, accelerate investigations, simplify analyst onboarding, and enable SOC teams to scale without proportional headcount increases.
Improve detection quality	The Defender correlation engine produces higher-fidelity incidents with fewer false positives. SOC teams spend less time triaging noise and more time on real threats.

Competitive Positioning

Partners need defensible talking points when customers evaluate third-party SIEM alternatives. The following advantages are factual, sourced from Microsoft’s transition documentation and platform capabilities — not marketing claims.

No extra cost for transitioning — even for non-E5 customers. Third-party SIEM migrations involve licensing, data migration, detection rewrite, and integration rebuild costs.
Native cross-domain correlation across Sentinel + Defender products into multi-stage incident graphs. Third-party SIEMs receive Microsoft logs as flat events — they lack the internal signal context, entity resolution, and product-specific intelligence that powers cross-domain correlation.
Custom detections across SIEM + XDR — query both Sentinel and Defender XDR tables without ingesting Defender data into Sentinel. Eliminates redundant ingestion cost.
Alert tuning extends to Sentinel — previously Defender-only capability, now applicable to Sentinel analytics rules. Net-new noise reduction.
Unified entity pages — consolidated user, device, and IP address pages with data from both Sentinel and Defender XDR, plus global search across SIEM and XDR. Third-party SIEMs provide entity views from ingested data only.
Built-in multi-tenancy for MSSPs — multitenant portal manages incidents, alerts, and hunting across tenants without third-party management layers. Try out the new GDAP capabilities in Defender portal.

Industry validation: Microsoft’s SIEM+XDR platform has been recognized as a Leader by both Forrester (Security Analytics Platforms, 2025) and Gartner (SIEM Magic Quadrant, 2025).

Summary: What Partners Should Take Away

Topic	Key Message
Framing	USX is a security architecture transformation, not a portal transition. Lead with detection capability, not cost savings.
Platform foundation	Sentinel Data Lake + Sentinel Graph + MCP/Agent Framework = the platform for the Agentic SOC.
4 investigation surfaces	KQL → Graph → Notebooks → Agent/MCP. A maturity ladder from “we can query” to “we automate at machine speed.”
Architecture	2-tier data model (analytics + Data Lake) with dual-ingest for critical sources. Cost savings are a side effect of good architecture.
Transition complexity	Analytics rules and automation rules. API schema changes. RBAC restructuring. Most customers need professional help.
Partner engagement model	Professional Services (transactional + transition execution + advisory) → Managed Services (MSSP).
Competitive positioning	No extra cost. Native correlation. Cross-domain detections. Built-in multi-tenancy. Capabilities third-party SIEMs cannot replicate.
Partner differentiation	IP + Human Orchestration + AI Agents. Partners who build proprietary agents on MCP have competitive advantage.
Timeline	March 31, 2027. Start now — phased transition with one telemetry domain first, then scale.

From Oversharing to Enforcement: A Practical Guide to AI Data Security with Microsoft Purview

George Smyrlis — Thu, 23 Apr 2026 14:58:26 GMT

Why AI Changed the Data Security Problem

AI does not create entirely new categories of risk—it supercharges existing ones. Traditional data leakage stems from ordinary behavior: sharing a document too broadly, sending an email to the wrong person, copying regulated data to an uncontrolled device. Generative AI amplifies all of these because of the power and speed with which it can proactively surface content that may be obsolete, over-permissioned, or ungoverned. DSPM exists to help with exactly this challenge: it continuously scans your environment to identify sensitive data, assess risk, and recommend actions to reduce exposure.

Oversharing at Scale
Before AI, an overshared SharePoint file might sit unnoticed. Now, Copilot can summarize it in response to a casual prompt, distributing its contents far beyond the original audience.
Prompt Leakage
Users can inadvertently expose sensitive information—financial account numbers, health records, project code names—simply by typing them into a Copilot prompt. Because AI interactions feel conversational, users tend to drop their guard.
Shadow AI
Beyond sanctioned tools, employees experiment with unapproved AI services.
Autonomous Agents

Autonomous agents expand the data security threat surface by acting independently on sensitive information across systems and boundaries. Their ability to access and share data without direct user interaction increases the risk of oversharing, exfiltration, and unauthorized access, while also introducing complex behavior patterns that are harder to monitor, govern, and control using traditional security models.

What Microsoft Purview Now Brings Together

Data Security Posture Management (DSPM)

DSPM consolidates insights from Data Loss Prevention (DLP), Insider Risk Management, Information Protection, and Data Security Investigations into a single view for monitoring data risks, policy coverage, and posture trends. Now also in Public Preview, DSPM extends coverage to third-party SaaS and IaaS platforms such as Google Cloud Platform, Snowflake, and Databricks, and integrates with partner solutions including Cyera, BigID, and OneTrust for comprehensive risk insights.

A central innovation in this version is data security objectives—prominent, selectable cards that each represent a specific security goal. Selecting an objective guides administrators through an end-to-end workflow that groups together the most relevant Purview solutions—information protection, DLP, Insider Risk Management, and eDiscovery—so teams can focus on achieving a specific data security outcome rather than navigating separate solutions.

Each Outcome card displays key metrics such as the percentage of data covered by policies, the number of risky sharing incidents, and improvements over time. Within each outcome, DSPM surfaces suggested prioritized actions—applying sensitivity labels, configuring DLP policies, or investigating alerts—all tailored to the organization's data. Administrators can take action directly from the workflow, including remediating oversharing, configuring one-click policies, or launching investigations into suspicious activity.

DLP Integration for AI Interactions

DLP is one of the core solutions integrated into DSPM's unified approach. The Activity Explorer's AI activities tab captures events where DLP rules were matched during AI interactions—including prompts, responses, and browsing to generative AI sites. DSPM can automate remediation steps such as removing public sharing links or applying data loss prevention policies to help prevent incidents before they happen.

AI Observability and Agent Governance

Dedicated dashboards and metrics monitor risks associated with AI apps and agents. AI observability enables tracking of agent-specific activities—oversharing, exfiltration, and unusual access patterns—across both Microsoft and third-party environments. Enhanced reporting provides advanced filtering and customizable views, supporting granular analysis of sensitive data usage, DLP activity, and posture trends. Audit logs and activity explorer features help track interactions with AI apps and agents, supporting compliance investigations and incident response.

AI-Powered Security Operations

DSPM not only secures and governs AI apps and agents but also uses Microsoft Security Copilot and AI agents to help secure and govern data. AI analyzes access patterns, sharing behaviors, and policy gaps to surface actionable risks and can detect unusual activity such as excessive sharing or suspicious downloads. Under administrator guidance, AI agents can take direct action on detected risks—removing public sharing links, applying DLP policies, or revoking permissions. These actions are always audited. To streamline investigations, AI-driven triage agents review alerts from DLP and Insider Risk Management solutions, filtering out noise and highlighting the most critical threats.

Three Practical Starting Points

For many organizations adopting generative AI, the biggest hurdle isn't recognizing new risks—it's figuring out where to begin. A "boil the ocean" approach can stall progress, while tackling a few targeted areas delivers quicker wins.

The best early moves are those that reduce exposure quickly, improve visibility, and build a foundation for stronger governance over time.

Starting Point 1: Enable prompt-level protection for Microsoft 365 Copilot

An effective first step is to put guardrails on the prompts users enter into AI. Microsoft Purview DLP allows administrators to restrict Microsoft 365 Copilot and Copilot Chat from processing prompts that contain sensitive information. In practice, users are often more comfortable pasting data into a chat prompt than attaching it to an email, which means a well-meaning employee could inadvertently feed a confidential file or personal data into Copilot.

Enabling prompt-level DLP creates an immediate safety net: if a user's prompt includes, say, a credit card number or a customer's national ID, Copilot will detect it and refuse to process or share that content. DSPM provides suggested prioritized actions—including configuring DLP policies—that can be activated directly from the workflow, and recommended policies can start in simulation mode. Simulation mode lets you see what would have been blocked or flagged, without actually interrupting users, so you can fine-tune the policy and prepare your helpdesk for any questions. Once you're comfortable with the results, switching to enforcement mode will actively block disallowed prompts and log those events for review.

By activating this one control, you've significantly reduced the most immediate oversharing risk—the "oops, I pasted the wrong data" scenario—within hours of starting your AI governance program.

Tradeoff: Simulation mode provides safety but delays enforcement. For organizations with imminent regulatory exposure, consider shortening the simulation window and monitoring alert volumes closely.

Starting Point 2: Gain visibility into shadow AI usage before broad enforcement

The second step is to illuminate what's happening in the shadows. Before rushing into blocking every unsanctioned AI tool, it's crucial to understand how and where AI is being used across the organization. In most enterprises, there's an official layer of AI usage and an often larger, unofficial layer—employees experimenting with free online AI chatbots, writing assistants, or code generators.

DSPM provides this visibility. The Discover > Apps and agents dashboard shows AI apps used across the organization, including the top 20 most recently used agents, with details about sensitive data they accessed and how they are protected by Purview policies.

The AI observability page provides a broader inventory of all AI apps and agents with activity in the last 30 days, including how many are high risk and the total with sensitive interactions. The Activity Explorer's AI activities tab shows when users browsed to generative AI sites, the prompts and responses involved, whether sensitive information was present, and whether DLP rules were matched. Armed with this insight, you can make informed decisions. If you discover that the majority of "AI consumption" comes from just two external apps, you might focus your immediate controls on those two. Conversely, if the data shows most unsanctioned usage is low-risk, you might decide to monitor rather than block it.

The key is visibility first, enforcement second—letting real data guide where to tighten controls versus where to offer secure alternatives.

Tradeoff: Visibility without timely follow-through can create a false sense of security. Set a defined window (e.g., 30 days) after which findings must translate into at least one concrete policy action.

Starting Point 3: Operationalize DSPM objectives for Copilot

A stronger third starting point is to use DSPM as your operational guide, not just a dashboard of charts. DPSM introduces data security objectives—each one a focused end-to-end workflow for a specific outcome. Rather than configuring individual features in isolation, you select an objective and let Purview navigate you through achieving that outcome with the relevant tools.

For generative AI, the key objective to leverage early is "Prevent data exposure in Microsoft 365 Copilot and Microsoft Copilot interactions". By selecting this objective in the Purview portal, you're effectively telling Purview, "help me implement whatever is needed to make Copilot safe with our data." The DSPM interface then groups together the critical pieces: it may prompt you to enable a DLP policy, suggest applying or refining sensitivity labels on content, or surface an Insider Risk Management policy template for detecting AI-related risky behavior. It also surfaces metrics so you can track progress—for example, the percentage of data covered by policies, or the number of risky sharing incidents that have been remediated.

Using DSPM objectives keeps your team aligned on a clear goal from day one. It shifts the conversation from "what knobs do we turn on?" to "how do we achieve this outcome?" You follow a guided plan curated by the platform's intelligence rather than navigating five different admin pages and hoping it adds up to protection.

Tradeoff: Objectives streamline the path but can obscure the underlying complexity. Teams should periodically step outside the guided workflow to review the full policy landscape and ensure no coverage gaps exist between objectives.

From Visibility to Remediation: Turning Insights into Action

Automated Remediation at Scale

DSPM can automate remediation steps such as removing public sharing links or applying data loss prevention policies to prevent incidents before they happen. Under administrator guidance, AI agents within DSPM can take direct action on detected risks—removing sharing links, applying DLP policies, or revoking permissions—and these actions are always audited. This moves the operating model from manual, one-at-a-time fixes to systematic, policy-driven remediation.

Closing the Loop: From Risk to Standing Policy

DSPM's data security objectives surface suggested prioritized actions such as applying sensitivity labels, configuring DLP policies, or investigating alerts, all tailored to the organization's data. Reporting and analytics are organized by outcome, making it easier to identify and report improvements, compliance, and risk reduction. This turns recurring findings into standing preventive controls. Instead of re-running assessments and manually fixing the same patterns, administrators create durable policies that enforce the desired state going forward.

Alert-Driven Investigation and Tuning

Audit logs and activity explorer features help track interactions with AI apps and agents, supporting compliance investigations and incident response. Integrated investigation and forensics tools support rapid incident response and root cause analysis for data security events. Impact prediction visuals and progress tracking for remediation steps are surfaced throughout DSPM, enabling administrators to quantify the effect of their actions and adjust course.

The closed-loop process is: Discover (DSPM scans and risk assessments) → Remediate (automated actions and bulk fixes) → Prevent (create or tighten DLP and auto-labeling policies) → Monitor (alert review, investigation, and policy tuning).

What "Good" Looks Like in a Regulated or Risk-Aware Organization

A mature AI governance posture is defined by measurable outcomes and sustainable operating rhythms—not feature count:

Clear, communicated AI usage policies. Users know what is and is not acceptable in AI interactions because the tools reinforce the rules. DLP policy tips delivered at the moment of a violation are a primary training mechanism—they remind users in context why their prompt was blocked and what to do instead.
Measured enablement over blanket bans. Leading organizations allow Copilot with appropriate controls and restrict only truly unacceptable scenarios. Policies deployed initially in simulation mode provide data to calibrate enforcement thresholds before blocking. This avoids productivity backlash while preserving security posture.

High data hygiene and classification rates. Purview's AI protections depend heavily on sensitivity labels. If everything is unlabeled or "General," label-based controls have nothing to act on. Mature organizations invest in auto-labeling and mandatory labeling to close this gap before deploying AI at scale. DSPM's data security objectives include suggested actions such as applying sensitivity labels, directly tying classification to governance outcomes.

Quantifiable risk reduction. Security leadership can produce metrics from Purview that show trend lines: DSPM Outcome cards display the percentage of data covered by policies, the number of risky sharing incidents, and improvements over time. These figures feed directly into compliance reporting and audit evidence. Key metrics are tracked over time, supporting continuous improvement of the organization's data security posture.

Cross-functional governance. AI governance is not a solo IT Security effort. Stakeholders from security, compliance, legal, and business units review AI usage patterns, discuss policy tuning, and evaluate new Purview capabilities as they release. Role-based access controls within DSPM provide granular access to features and AI content for delegated administration and compliance, enabling this cross-functional model without overexposing sensitive data to every participant.

Tradeoff: Strict enforcement can frustrate power users and slow AI adoption. Organizations should explicitly define escalation paths—if a legitimate use case is blocked by DLP, there must be a fast process to review and adjust, rather than a permanent "no."

A Phased Adoption Model

Phase	Focus	Key Activities
Phase 1 — Quick Wins (weeks)	Visibility and baseline safeguards	Enable prompt-level DLP for Copilot in simulation mode. Run first DSPM data risk assessment for oversharing. Enable shadow AI discovery via DSPM's Apps and agents dashboard and AI observability page. Start from the DSPM objective "Prevent data exposure in Microsoft 365 Copilot and Microsoft Copilot interactions."
Phase 2 — Broad Enforcement (months)	Acting on findings	Switch DLP policies from simulation to enforcement. Use automated remediation actions (removing sharing links, applying DLP policies, revoking permissions). Expand sensitive information type definitions and add custom types. Rollout user communications explaining new controls and escalation paths.
Phase 3 — Mature Governance (ongoing)	Continuous improvement and AI-powered operations	Leverage AI-driven triage agents to filter alert noise and highlight critical threats. Conduct periodic DSPM posture reviews using Outcome card metrics. Tune policies based on impact prediction visuals and progress tracking. Extend protections to new AI apps and agents as they are adopted—DSPM's AI observability tracks agent-specific activities across Microsoft and third-party environments. Formalize cross-functional AI governance cadence.

*Phase 1 should take weeks, not months—the objective is to establish a baseline before risk accumulates.

*Phase 2 is where enforcement generates measurable risk reduction.

*Phase 3 is ongoing: as Microsoft continues extending Purview to additional AI apps and agent types, the governance framework must evolve in tandem.

The DSPM preview's integration with third-party SaaS and IaaS platforms (Google Cloud Platform, Snowflake, Databricks) and partner solutions (Cyera, BigID, OneTrust) means the governance perimeter can expand alongside the organization's AI footprint.

Conclusion

AI adoption and data protection are not opposing forces. Microsoft Purview now provides the visibility, policy controls, and remediation workflows to move from discovering AI risk to actively governing Copilot, third-party AI apps, and agents at scale. DSPM surfaces oversharing and AI usage patterns through unified dashboards, data risk assessments, and AI observability. DLP blocks sensitive data in prompts and restricts AI access to labeled content. Insider Risk Management detects adversarial AI behavior. AI-driven triage and remediation agents close the gap between identifying a problem and fixing it—with every automated action audited.

The path forward starts with practical actions: enable prompt-level DLP, illuminate shadow AI usage, and operationalize DSPM's "Prevent data exposure in Microsoft 365 Copilot and Microsoft Copilot interactions" objective. From there, enforce what you find, measure the results using DSPM's outcome-based metrics, and progressively mature your governance posture.

Organizations that operationalize this loop will be in a strong position: able to say, "We use AI to work smarter—and we have the safeguards in place to do it safely."

Purview : comment filtrer les résultats “Data products” par termes du glossaire ?

Miriane — Thu, 23 Apr 2026 13:39:12 GMT

a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; }

Bonjour,

Je teste Microsoft Purview (Unified Catalog) avec des produits de données auxquels j’ai associé des termes de glossaire.

Les termes de glossaire sont publiés et visibles dans l’onglet Découverte → Glossaire d’entreprise.
Les produits de données sont également publiés et retrouvables via la recherche.

Cependant, je ne vois pas d’option (ou elle ne retourne aucun résultat) pour filtrer les résultats de recherche des produits de données par termes de glossaire, contrairement à d’autres filtres disponibles (ex. Propriétaire, Type de produit)

Est-ce que le filtrage des produits de données par termes de glossaire est supporté dans l’onglet Découverte ?
Si oui, y a-t-il des pré-requis ou conditions particulières (ex. type de glossaire, indexation/délai, association au niveau data product vs assets, etc.) ?

Filtrer les résultats de la recherche des produits de données à l'aide des termes de glossaire

Miriane — Thu, 23 Apr 2026 13:34:22 GMT

Bonjour,

Je teste Microsoft Purview (Unified Catalog) avec des produits de données auxquels j’ai associé des termes de glossaire.

Les termes de glossaire sont publiés et visibles dans l’onglet Découverte → Glossaire d’entreprise.
Les produits de données sont également publiés et retrouvables via la recherche.

Métadonnées personnalisées sous Purview avec une relation un à plusieurs

Miriane — Thu, 23 Apr 2026 13:21:31 GMT

Bonjour,

Je souhaite créé une métadonnée sous Purview, en l'associant à une métadonnée parent, Comment est-ce possible

Merci de votre retour,

'Registering user becomes local admin on Joined Devices' - WHAT

underQualifried — Wed, 22 Apr 2026 20:22:52 GMT

Stumbled on a tenant with 'JOIN' available for all users. Haven't worked with this much - most tenants I see only have registration. But then I noticed the horrifying 'Registering user is added as local administrator on the device during Microsoft Entra join' option was ALSO set to ALL.

This is a tenant we just took on, but I've never seen that control before. This is terrifying, considering AFAIK, there is no real way for a registering user to know if they're registering or joining. Beneath it is an option to 'Manage Additional local administrators on all Microsoft Entra joined devices', which leads to the Role page for Device Administrators, which is empty.

Under Description, this describes what APPEARS to be to be the same thing mentioned in the previous control - 'Users with this role become local machine administrators on all Windows 10 devices that are joined to Microsoft Entra'. But no one is assigned this.

Conveniently, on my own tenant, I happened to let someone JOIN yesterday. We have this limited to 2 (now 3) people - most just register... But this user Joined, and the 'Joining user becomes local admin' option was on ALL. But I can't validate that the user ever become local admin. They don't have the role, their device shows as joined, but there's no additional roles. The audit logs don't look weird. They're not in that 'Device Administrators' group, which describes itself as 'Users with this role become local machine administrators on all Windows 10 devices that are joined to Microsoft Entra'.

Thoughts? Freaking out, honestly. We have a mix of DC and Cloud users. I've inherited them all, and had the understanding that Join was essentially registration but with Org ownership. I've tried to get some input from Copilot, but he has basically waffled between 'No, this setting is just badly named' and 'no, actually it's this other setting' and 'no, you know what, it all makes sense somehow'.

1. Does that option actually set the joining user as global admin? Is that really the default setting?

2. can you validate this ANYWHERE in Entra? Or does it just disappear?

3. what is that Device Admin group? A separate group, independent of these two settings, that gives local admin?

4. Is there a graph endpoint that can be used to set this?

Thanks

Declutter and Defend: Reducing promotional mail noise with Microsoft Defender

FaithEbenezerOquong — Thu, 23 Apr 2026 03:59:21 GMT

Enterprise inboxes are overwhelmed with graymail — legitimate, bulk email like newsletters, vendor promotions, and product updates that isn't malicious but buries the messages that matter. When high volumes of these mails land in the inbox, it crowds out priority communications and can dull security vigilance. Employees conditioned to ignore repetitive emails may miss signs of a real threat. It also creates recurring work for admins and security teams who must continuously tune filters, manage exception requests, and chase noise from user reports for email that isn’t malicious. Because graymail passes every spam filter check, traditional defenses don't separate it — leaving this signal-to-noise gap unaddressed.

Today we’re excited to announce that Microsoft Defender now includes built-in graymail filtering. It is delivered natively through a new Promotions experience in Outlook that automatically classifies and separates bulk email, so it no longer competes with business-critical communication in the inbox. Now in Public Preview, this capability learns from how users interact with graymail to become more accurate over time. Coupled with the existing Bulk Senders Insight report, Defender brings data-driven bulk classification and control into the security workflows you already use.

What Is Graymail?

Graymail is legitimate bulk email that isn't malicious—product newsletters, event announcements, marketing promotions, and software update notifications from reputable, authenticated senders. It is distinct from spam and from phishing - graymail comes from real organizations with proper authentication and traditional spam filters aren't designed to handle it.

Graymail handling in Microsoft Defender

Microsoft Defender's approach is built on three principles: classify intelligently, deliver natively, and learn continuously.

Promotions Folder — Intelligent Inbox Organization

A dedicated Promotions folder, natively provisioned in Outlook, now keeps legitimate bulk mail out of the primary inbox. Promotional content is separated from priority emails without being sent to Junk, which means users can still access and browse newsletters and updates at their own pace. The folder appears at the top level of the mailbox for easy discovery and is visible across all Outlook experiences.

Non-spam bulk mail below the organization's configured Bulk Complaint Level threshold is automatically routed to the Promotions folder.
Messages from senders the user has explicitly allowed continue to land in the Inbox.
Messages identified as spam continue to go to Junk.

To enable the Promotions folder administrators need to enable the "Bulk Moves Enabled" setting in their anti-spam policy. The Promotions folder is then created for all users and used for routing only when this setting is ON.

Existing mail flow is unaffected.

Figure 1: system tagging of “Promotions” in outlook client and promotions folder (previously tagged as “Bulk” in private and public preview)

Promotional mail tagging and Mailbox Rule Support

Messages classified as graymail will automatically be labeled with a "Promotions" system tag in Outlook. The tag provides instant visual context without requiring users to open each message and is visible in Outlook on the Web and the native Outlook desktop apps for Windows and Mac. During Public Preview, the tagging component is opt-in, requiring administrators to enable it by configuring an Exchange Transport Rule. Once generally available, it will be enabled by default.

Because this classification is integrated at the client level, the Promotions tag can also be used as a condition in Outlook mailbox rules. This enables custom routing logic for advanced scenarios like moving all promotions-tagged messages from a specific sender to a custom folder, flagging certain promotional emails for follow-up, or auto-forwarding or deleting promotions that meet specific criteria. This transforms the Promotions classification from a one-way filter into a flexible building block for personal and organizational workflows—particularly valuable for power users and teams with compliance or archival requirements.

Figure 2: User inbox rules using “Promotion” tag (previously “Bulk” in private and public preview)

Adaptive Learning

Microsoft Defender's graymail filtering gets smarter with every interaction. The system learns directly from how users handle their mail. When a user moves a message out of the Promotions folder and back to the Inbox, future emails from that sender will no longer be placed in the Promotions folder. When a user moves a message from the Inbox into the Promotions folder, future emails from that sender will be routed to the Promotions folder automatically.

This creates a personalized, self-improving experience that becomes more accurate over time - no manual rule configuration required, no safe-sender lists to maintain, and no filtering rules for IT teams to manage on behalf of individual employees.

Built into existing Security Workflows

Administrators also gain visibility through the Bulk Senders Insight report, which provides data-driven guidance on what your organization actually receives and can help tune your bulk mail filtering.

Graymail has long been the unsolved middle ground of email security—too legitimate to block, too noisy to ignore. Microsoft Defender now handles it where it should be handled: inside the platform, inside the mailbox, and inside the security workflows your organization already relies on. No new portals, no new vendors, no compromise between security and user experience.

Get Started

Configure promotions tagging and the promotions folder today - Bulk email detection documentation on Microsoft Learn.
Monitor the experience using the Bulk Senders Insight report.

Now generally available: License usage insights in Microsoft Entra

Joseph Dadzie — Thu, 23 Apr 2026 18:13:19 GMT

Organizations rely on Microsoft Entra to secure access in an ever-changing identity threat landscape without sacrificing workforce productivity. As organizations adopt advanced identity and access capabilities, IT teams often need greater transparency into how those capabilities are being used, particularly around licensing. You need to see which identity protections are securing your users and identify gaps from unused controls.

Today, we’re excited to announce the general availability of Microsoft Entra license usage insights, a redesigned experience in the Microsoft Entra admin center that helps you better understand your license entitlements and how your security controls are being used across your organization.

Why it matters

With license usage insights, you can:

Strengthen your security posture by ensuring critical identity protections are not just licensed, but actively protecting your users.
Close protection gaps faster by identifying underutilized controls and bringing them into production.
Reduce exposure to identity-based attacks by increasing adoption of capabilities like risk-based access policies.
Stay ahead of compliance and risk with visibility into usage trends, helping you proactively address gaps as your organization evolves.

What’s new in the GA release

Since public preview, we’ve introduced several enhancements to make license entitlement and feature usage data easier to find and act on:

Six-month usage trends: Understand historical patterns for better forecasting.
Clear differentiation between active and guest users for precise reporting.
Copilot prompt suggestions to help you explore license usage insights faster.

The main license usage report view (Billing > Licenses).

Where to find the license usage insights

Navigate to Billing > Licenses in the Microsoft Entra admin center. You’ll see two key widgets: License entitlements and Product usage insights.

License entitlements: Displays your total Entra license entitlements, such as Microsoft Entra ID P1, P2, Microsoft Entra Suite, and standalone SKUs. For example, 250 Microsoft Entra Suite licenses entitle your organization to 250 each of Private Access, Internet Access, ID Governance, and Verified ID.

The License entitlements view.

Product usage insights: View product and feature usage over the past six months in one place, giving you a clear picture of which security protections are licensed, in use, and where gaps may exist. Quickly compare licenses in use versus available and spot adoption trends. Hover over the bar chart for more details or contact your Microsoft representative for guidance.

The Product usage insights view.

Next steps

Visit Billing > Licenses in the Microsoft Entra admin center to explore license usage insights today and start identifying where your existing identity protections can be strengthened. With clear visibility into how your controls are being used, you can take action to close gaps, increase adoption of critical safeguards, and improve your overall security posture.

We’d love your feedback on how this visibility into your Microsoft Entra usage supports your workflows and what additional insights would be most valuable. Share your thoughts in the comments or through the Feedback portal.

-Joseph Dadzie, Vice President of Product Management

Additional resources

Learn more about Microsoft Entra