rss.livelink.threads-in-node

EDR coexistence by design: A practical starting point to Defender

Raae_ — Thu, 30 Apr 2026 17:27:14 GMT

Co-authors: Kayla Rohde & Kenneth Johnson

Having multiple cybersecurity technologies, controls, systems, and stakeholders operating together without conflict is not a temporary inconvenience. It is how real environments operate and a practical way to make progress without disruption.

Complexity exists because businesses are complex. Endpoint platforms already deployed, are relied upon 24/7. Moreover, contracts and operational dependencies make them challenging to change. On the other hand, many organizations already own Microsoft licensing that entitles them to Defender endpoint capabilities, including the ability to run Microsoft Defender for Endpoint in passive mode with EDR capabilities enabled.

Increasingly, organizations are finding that coexistence can deliver meaningful security outcomes. In addition, when designed with purpose, coexistence allows teams to being realizing the value of their existing Microsoft licensing, strengthen detection and response, and build confidence in Defender under real-world operating conditions.

In practice, once teams see the depth of signal, investigation quality, and platform integration that Defender provides, most will migrate over and use it as their primary endpoint security platform once the technical, operational, and economic timing makes sense.

Side-by-side is not standing still

A common assumption is that side by side deployment exists only as a short bridge to replacement. That assumption does not hold up in real environments.

Experienced teams use coexistence as a controlled transition model that produces immediate security outcomes while preserving operational stability.

Running Defender alongside an existing prevention platform allows organizations to:

Activate endpoint telemetry and behavioral detections already included in licensing
Expand investigative depth without disrupting the current prevention layer
Validate detection coverage before making enforcement changes
Build operational familiarity with Defender workflows under real conditions
Maintain visibility during periods of architectural change

Coexistence is not about running two tools. It is about sequencing risk reduction with intent.

What Passive Mode actually means for your SOC

One of the most persistent points of confusion is what “passive mode” actually entails.

When Defender operates in passive mode:

It is not the real‑time blocking engine
Another platform remains the primary prevention control
EDR capabilities continue to collect telemetry, generate detections, and support investigation

For seasoned practitioners, this distinction matters. Many of the most consequential security decisions happen after execution, when responders need clarity, context, and speed. Defender endpoint capabilities contribute directly in that phase, regardless of which tool owns real‑time blocking. This is why coexistence works. It preserves prevention continuity while materially improving detection and response.

Turning licensed capability into operational advantage

The real value of Defender for Endpoint in a coexistence model is not just what it observes on the endpoint. It is how that signal connects across the Microsoft security platform to produce a more complete picture of attacker behavior.

Even in passive mode, MDE is not a standalone sensor. Endpoint telemetry feeds into a system that correlates identity, email, cloud, and data signals into a unified investigation experience. That is where the advantage compounds.

As organizations begin to operationalize MDE in coexistence scenarios, endpoint telemetry does more than generate alerts. It enriches incidents with process level and device context, then ties that activity to identity signals such as risky sign ins, anomalous sessions, and lateral movement patterns. Email events and user interaction history align with execution timelines. Data access and sensitivity context introduce impact.

The result is not more “noise”. It is better context. What changes is not just visibility. It is decision quality. Process execution is no longer evaluated in isolation. It is tied to a user, a session, an originating communication, and the data that may have been accessed or exposed. Investigations become faster, more confident, and more defensible.

This is especially relevant for organizations already licensed for Microsoft 365 E5 or equivalent that have not enabled Defender for Endpoint. In those environments, coexistence is not introducing another tool. It is activating an intelligence layer that already exists and is not yet contributing signal.

Once that signal is connected, a suspicious process execution becomes materially richer. It can be correlated to a user’s sign in risk posture, traced back to an originating email or phishing thread, enriched with device exposure and vulnerability context, and evaluated against sensitive data access.

That is a fundamentally different investigation than what a siloed endpoint alert produces. Passive mode does not diminish this value. It enables it. Organizations can establish a unified detection and investigation layer while preserving their existing prevention controls. Isolated telemetry becomes an operational signal. Signal becomes a coordinated response.

For teams that have not yet enabled MDE, the gap is not capability. It is visibility that is already licensed, already available, and not yet being used.

From entitlement to enforcement: A resilience arc

Cyber resilience is not about assuming controls never fail. It’s about maintaining visibility, decision quality, and response speed when they do.

Using Defender Endpoint capabilities in a side‑by‑side model:

Improves resilience during periods of change
Reduces dependency on a single control plane
Allows teams to mature detection and response before altering enforcement ownership

Over time, many organizations choose to simplify. Layering builds resilience while teams learn. Platform consolidation sustains it once confidence is earned.

We focused on coexistence because it reflects where many organizations begin, not because it is where they should end. Many teams already have endpoint protection in place and licensing that entitles them to Defender Endpoint Capabilities. Coexistence allows those capabilities to be turned on, understood, and used effectively without forcing premature decisions or unnecessary disruption. It creates a practical on‑ramp that lets teams build confidence, improve detection and response, and establish operational muscle before making broader platform choices.

Learn more: MDE side-by-side guidance: https://learn.microsoft.com/en-us/defender-endpoint/mde-side-by-side

Ask Microsoft Anything: Purview Data Security Investigations Part 3

Trevor_Rusher — Mon, 27 Apr 2026 20:19:51 GMT

AMA: What’s New in Microsoft Purview Data Security Investigations

Join us to learn about the latest updates to Microsoft Purview Data Security Investigations (DSI)—including new capabilities like the agentic credential scan in the Data Security Posture Agent.

DSI helps security teams quickly uncover, investigate, and mitigate sensitive data risks hidden across their environment using AI‑powered deep content analysis. Whether responding to an active data security incident or proactively assessing data exposure, DSI enables teams to identify investigation‑relevant data, analyze it at scale with AI, and mitigate risk—all within a single, unified solution.

By streamlining complex and time‑consuming investigative workflows, DSI helps organizations move from signal to insight in hours instead of weeks, giving security teams the speed, clarity, and confidence needed to address today’s evolving threat landscape.

Join this AMA with the product team behind Microsoft Purview Data Security Investigations to hear about what’s new, see what’s coming next, and get your questions answered live.

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.

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.

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?

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.

Introducing the New Microsoft Security Community Home!

emilyfalla — Tue, 21 Apr 2026 18:22:33 GMT

We are excited to introduce the new home of the Microsoft Security Community!

At aka.ms/securitycommunity, you can explore upcoming events, access technical content, and find new ways to connect with Microsoft experts and peers across the security ecosystem.

The Microsoft Security Community Home is designed to help you:

Discover live and on-demand community events
Access technical resources and learning opportunities
Connect with peers and Microsoft product teams
Stay up to date on Microsoft Security announcements
Get involved through our community programs, including opportunities to share feedback that helps shape Microsoft Security products and features

Whether you are looking to build your expertise, join discussions, or influence the future direction of Microsoft Security solutions, this is your starting point.

👉 Visit the Microsoft Security Community Home: aka.ms/securitycommunity

Safeguarding Sensitive Data in Microsoft 365 Copilot Interactions: DLP for Microsoft 365 Copilot

Aaron_Thorp — Tue, 21 Apr 2026 18:13:10 GMT

Microsoft 365 Copilot is redefining how organizations work, bringing the power of generative AI directly into our secure productivity tools. As Copilot adoption accelerates, we’ve heard that you want more control over how your sensitive data can be used in interactions with Copilot. At Ignite 2025, Microsoft announced a major enhancement: Microsoft Purview Data Loss Prevention for Microsoft 365 Copilot to safeguard Microsoft 365 Copilot and Copilot Chat prompts, now entering General Availability. Even better, this capability is included for all users of Microsoft 365 Copilot and Copilot Chat.

Why DLP for Copilot Prompts Is a Game-Changer

As organizations adopt Copilot, their ways of sharing, creating, and interacting with data expand. With just a prompt, users can have Copilot summarize documents, analyze spreadsheets, or help brainstorm presentations. However, it raises an important question: what if the prompt includes sensitive information, like project code names, financial account numbers, health records, or other sensitive data?

Over the last 2 years, Microsoft has been building a set of Data Loss Prevention (DLP) controls specifically designed for Copilot. Below is a quick overview of these related capabilities — ranging from already available to newly in preview — before we dive deep into today's GA announcement:

Prevent Copilot processing of files & emails based on sensitivity labels

In November 2024, Microsoft introduced the ability to create a DLP policy to restrict Microsoft 365 Copilot and Copilot Chat from processing sensitive files and emails using Sensitivity Labels for grounding data. This capability gives you control over whether content with the sensitivity labels you specify is restricted from being used in Microsoft 365 Copilot and Copilot Chat to generate summaries and responses.

Prevent web searches for prompts containing Sensitive Information Types (SITs)

The latest feature entering Public Preview is DLP for Microsoft 365 Copilot and Copilot Chat to prevent web searches for prompts containing sensitive data. This real-time control helps organizations mitigate data leakage and oversharing risks by preventing Microsoft 365 Copilot and agents from using sensitive data for external web searches. If a sensitive information type (SIT) is detected in a user prompt, Copilot can still leverage your enterprise data to form a response without sending the sensitive data to external search engines for web grounding. This capability extends to Microsoft 365 Copilot and agents built in Copilot Studio that are published to Microsoft 365 Copilot.

DLP to Safeguard Copilot Prompts with Sensitive Information Types (SITs)

The rest of this blog focuses on a key addition to this capability set: DLP for Microsoft 365 Copilot + Copilot Chat prompts to prevent processing of prompts containing sensitive information, now entering General Availability. Unlike the web search capability above, which prevents sensitive data from being sent externally during a web query, this capability evaluates the user’s text input directly, before processing occurs, to determine whether both enterprise data and web grounding can proceed.

This feature uses Sensitive Information Types (SITs) as a condition within a Purview DLP policy to assess whether a user prompt sent to Copilot contains sensitive data, even if the data is unlabeled. With DLP for Copilot prompts, a user’s text input is scanned in real time for SITs, whether built-in (like Social Security Numbers, credit card numbers, etc.) or custom-defined by your organization (such as confidential terms or project names). If a text prompt contains one of the SITs you specify, Copilot restricts processing, halts any Graph or web grounding, and displays a clear message to the end user that the request cannot be completed.

A user enters a prompt in Microsoft 365 Copilot Chat containing sensitive information.

Microsoft 365 Copilot Chat detects a SIT within the user prompt and restricts a response.

How DLP for Copilot Protects Prompts: Real-Time, Intelligent Protection

The new DLP capability integrates seamlessly with Microsoft Purview, leveraging its powerful data classification & detection engine for sensitive information types. Here’s how it works:

Input: When a user submits a prompt, Copilot checks the prompt for sensitive information using built-in or organization-defined sensitive information types (SITs).
Immediate Action: If a SIT is detected, Copilot restricts the prompt from being processed. No AI response is generated, and no data is sent for Graph or web grounding.
Output: Users receive a clear notification that their request cannot be completed due to company policies.

This real-time protection ensures that sensitive data is not leaked or overshared, even as users explore new ways to work with AI.

Overview of how the feature works.

Setting Up DLP for Copilot Prompts: Data Security Admin Experience

The easiest way to get started is through the new Microsoft Purview Data Security Posture Management (DSPM) portal, which provides a guided, one-click setup experience:

1. In Purview, go to Solutions > DSPM (preview)

2. Select the "Prevent data exposure in Microsoft 365 Copilot and Microsoft Copilot interactions" objective.

3. Follow the guided workflow and apply the recommended one-click DLP policy. The policy starts in simulation mode so you can review activity before enforcing it.

Alternatively, you can configure and customize this policy directly from the Purview DLP portal Policies page or enable it from the Microsoft 365 Admin Center.

Navigate to the Data Security Posture Management (Preview) portal Objectives tab. View the objective, “Prevent data exposure in Microsoft 365 Copilot and Microsoft Copilot interactions” and click the button, view the remediation plan.

View the remediation plan details and estimated impact on risk pattern.

Click the button, view policy details and review. Then click the button, create a custom policy in DLP simulation mode to protect sensitive data referenced in Microsoft 365 Copilot and Microsoft Copilot.

IT and AI admins can enable DLP protection for Copilot prompts directly from the Security section of the Microsoft 365 Admin Center using a simplified setup experience.

To configure polices in DLP, navigate to the Purview DLP portal. Then select the Policies tab to create a new policy.

Create a DLP Custom policy.

Choose where to apply the policy (Microsoft 365 Copilot and Copilot Chat).

Create a rule with a name and optional description.

Add Sensitive Information Types as part of the conditions.

Select the desired Sensitive Information Types (built-in or custom).

Identify the confidence level and instance count.

Add the action to restrict Copilot from processing content and complete the policy configuration.Confirm the rule was set up correctly by testing it out.

Practical Scenarios: Protecting What Matters Most

Protect PII, financial data, and intellectual property: Financial institutions can block prompts containing deal terms, account numbers, or other sensitive data, preventing leaks through AI interactions. Similarly, healthcare organizations can safeguard patient information, and manufacturers can secure intellectual property and trade secrets from exposure, along with many other practical use cases. Once the prompt is detected and blocked, Microsoft Graph grounding and Bing web grounding is restricted.

Safeguard sensitive non-public information: Imagine an organization involved in a confidential merger. By using DLP for Copilot prompts, administrators can set up a custom SIT that includes the project’s code name. If a user asks Copilot about the merger using the project’s code name, their request will be blocked, keeping sensitive information secure and protected.

Visibility into DLP for M365 Copilot Prompts

When a user’s prompt triggers a DLP policy, notifications and alerts are surfaced directly in the Microsoft Purview and Defender portals for security administrators. These alerts provide detailed information about which policy was activated, the type of sensitive information detected, and the context of the attempted Copilot interaction.

Using these alert queues in Purview and Defender XDR, administrators can efficiently track policy activity, investigate potential incidents, and refine DLP rules to better align with organizational needs. The ability to review historical alerts and track ongoing enforcement empowers admins to maintain strong data security and proactively safeguard sensitive information.

DLP policy alert within the Alerts page.

Defender XDR portal investigation of prompt DLP based incident.

Takeaways

The introduction of this latest enhancement to DLP for Copilot represents a key advancement in secure Copilot deployment and adoption. By empowering organizations to block sensitive data at the prompt level, Microsoft is helping customers unlock the full potential of Copilot, without compromising security or compliance.

This innovation reflects Microsoft’s commitment to responsible AI, continuous improvement, and customer-driven development. As Copilot evolves, so will the tools to protect your data, ensuring that productivity and security go hand in hand.

For more details, stay tuned for updates to the Product Roadmap and Learn documentation.

Detecting Plain‑Text Password Exposure Using Custom Regex in Microsoft Purview

samsul_ahamed — Mon, 20 Apr 2026 16:55:05 GMT

Strong authentication controls like MFA significantly reduce account compromise — but they don’t eliminate the risk of password exposure.
In many organizations, users still interact with legacy systems, third‑party tools, or service accounts that rely on password‑only authentication. When those credentials are shared or stored in plain text — whether accidentally or out of convenience — they introduce a serious security risk.

Microsoft Purview helps organizations identify and protect sensitive information using Sensitive Information Types (SITs). While built‑in detections provide a solid foundation, certain scenarios benefit from organization‑specific context and policy‑driven patterns.

This post walks through how to extend password detection using a custom regex pattern — allowing you to identify strong passwords stored in plain text and respond before exposure turns into an incident.

The Challenge: Passwords Still Appear in Everyday Content

Despite user awareness training and improved security posture, passwords still surface in places like:

Emails shared for “quick access”
Documents stored in collaboration sites
Notes created during troubleshooting
Spreadsheets used for credential tracking

Even a single exposed password — especially for non‑MFA‑protected systems — can lead to unauthorized access or data leakage.

Extending Password Detection to Align with Organizational Policies

Microsoft Purview includes built‑in patterns to detect generic password formats. These offer a strong baseline and are effective for broad protection scenarios.

However, many organizations define specific password standards and want detection logic that reflects how passwords are referenced according to their organization policy. For example:

Enforcing minimum and maximum password length
Requiring complexity (letters, digits, special characters)
Detecting passwords only when explicitly referenced, such as near the word password
Reducing false positives from random strong strings (API keys, hashes, tokens)

In these cases, custom regex‑based Sensitive Information Types allow organizations to build on existing protection and apply targeted, high‑confidence detection.

Detection Requirements for This Scenario

In this example, we want to identify passwords that meet all of the following criteria:

✔ Minimum length: 10 characters
✔ Maximum length: 20 characters
✔ Must contain:

At least one alphabet character
At least one digit
At least one special character
✔ Must appear in close proximity (within 2 characters) to a keyword such as:
password
pwd
passcode

This ensures we’re detecting intentional password disclosures, not unrelated strong strings.

In this scenario, the detection logic is intentionally split across three components:

Primary element – Detects password length and structure
First supporting element – Validates password complexity rules
Second supporting element (keywords) – Adds human context using proximity

This structured design ensures that detection aligns closely with real‑world password disclosure patterns.

Detection Architecture Overview

Component	Purpose
Primary Element	Identifies candidate password strings
Supporting Element (Complexity)	Confirms password strength
Supporting Element (Keywords)	Confirms contextual intent

Primary Element: Password Length Identification

The primary element focuses purely on identifying potential password strings based on length.

Regex Pattern

\S{10,20}

What this enforces

No whitespace characters
Minimum length: 10 characters
Maximum length: 20 characters

Proximity Configuration

Distance between Primary and Supporting Element: 1 character

This ensures that the supporting complexity patterns evaluate directly against the same string, rather than unrelated values nearby.

First Supporting Element: Password Complexity Validation

The first supporting element ensures that the detected string meets organizational password complexity requirements.

All the following patterns are grouped within the same supporting element, and no internal proximity is configured (as they evaluate the same primary value).

Complexity Patterns Included

Requirement	Regex Pattern
At least one uppercase letter	[A-Z]
At least one lowercase letter	[a-z]
At least one digit	[0-9]
Allowed character set	[A-Za-z0-9!@#$%^&*()_+\-=]{10,}
At least one special character	[!@#$%&*+=]

This approach avoids relying on a single large regex, making the detection more readable, maintainable, and auditable.

Second Supporting Element: Keyword Context (Human Intent)

To further improve accuracy, a second supporting element is used to ensure the password appears in a meaningful, human context.

Keyword List (Case‑Insensitive)

credential

password

pwd

pswd

Keywords are configured in case‑insensitive mode to match variations such as Password, PWD, or Pswd.

(You can change the keyword and Proximity Character as per the need)

Proximity Configuration

Proximity value: 30 characters

Why 30 Characters?

This value accounts for:

Maximum keyword length: 10 characters
Maximum password length: 20 characters

This ensures the keyword and password must appear within the same meaningful sentence or fragment, for example:

Password: P@ssW0rd123!

credential=Adm1n#Secure

pwd -> Qwerty@2024!

It avoids triggering on:

RandomStrongString123!

API_KEY = A9$kLmZpQw

How This Comes Together in Microsoft Purview

When implemented as a custom Sensitive Information Type:

The primary element detects candidate passwords
The first supporting element confirms password strength
The second supporting element confirms user intent via keywords
Proximity rules ensure all components relate to the same disclosure

This SIT can then be used across:

Data Loss Prevention (DLP)
Endpoint DLP
Auto‑labelling
Email and collaboration workload protection

Why This Design Is Effective

This structured approach allows organizations to:

Detect real password disclosures with high confidence
Align detection with internal password policy
Reduce false positives from random strong strings
Apply protection consistently across Microsoft 365 workloads
Maintain a clean, auditable detection design

Most importantly, it extends Microsoft Purview’s native capabilities without changing the underlying security model.

Final Takeaway

Even in environments with strong authentication controls, password exposure remains a real risk — especially for legacy and third‑party systems.

By combining length validation, complexity enforcement, and contextual keyword proximity, Microsoft Purview enables precise and scalable password detection, helping organizations identify and protect sensitive credentials before they are misused.

When the shield becomes the sword: How misconfigured PAM bridges the tiering model

UgurTGudekli — Wed, 15 Apr 2026 18:34:46 GMT

In the world of identity security, few tools promise as much peace of mind as Privileged Access Management (PAM). It is often referred to as the "vault" that locks away your kingdom's keys. However, in Microsoft Incident Response – the Detection and Response Team (DART) engagements, we frequently encounter a paradox: the tool used to secure Tier 0 often becomes a quick path for threat actors to compromise it.

In a recent DART engagement, a threat actor moved from a compromised helpdesk workstation to full domain compromise in under four hours. They didn't use a zero-day. They used the organization's PAM server.

We have seen this story play out in real-time. An organization invests heavily in Active Directory (AD) Tiering and a premium PAM solution. They feel secure. Yet, during an incident, we trace the threat actor’s path and find they didn't burn a zero-day or crack a complex algorithm. They simply walked across a bridge the organization built themselves: a PAM server positioned in Tier 1 that held the keys to Tier 0.

This isn't a failure of the product; it's a failure of positioning. This post shares what DART sees on the front lines, why "intermediaries" are the most critical link in your chain, and how to deploy PAM without rolling out a red carpet for threat actors.

The foundation: A quick refresher on tiering model and PAM, PIM, and PAW concepts

Before we dive into the threat actor’s tactics and techniques, let’s revisit the ground rules and define a few key concepts. The Active Directory Tiering Model is built on a simple premise: prevent credential theft propagation; ensuring that credentials with administrative access to higher-tier systems are never exposed on lower-tier systems where a threat actor may already have a foothold.

Tier 0 is your control plane: Domain Controllers, PKI, and the identities that manage your authentication plane.

Tier 1 houses your application servers and data.

Tier 2 is the high-risk environment: user workstations and devices exposed to the internet.

The golden rule of tiering is strictly one-way: higher tier admins must never expose their credentials to lower tier systems, and lower tiers must never have management access to higher tiers. The core purpose of this separation is to ensure that a compromised workstation cannot yield Domain Admin credentials. However, operational tools that bridge these tiers often inadvertently break this definitional boundary.

PAM (Privileged Access Management): Solutions designed to securely vault credentials and broker administrative sessions, ensuring access to critical systems is monitored and controlled.

PIM (Privileged Identity Management): Tools that manage the lifecycle of elevated roles, typically by enforcing time-bound, Just-In-Time (JIT) access to eliminate standing privileges.

PAW (Privileged Access Workstation): Highly hardened, dedicated devices used exclusively for sensitive administrative tasks, physically or logically isolating tier admins from high-risk activities like email and web browsing.

Figure 1: Administration with dedicated tiered accounts

The front-line reality: the shared intermediary trap

Imagine this scenario: A threat actor compromises a standard workstation (Tier 2) through a phishing email. Their goal is the Domain Controller (Tier 0). In a properly tiered environment, this path is blocked; there are no credentials on the workstation to steal, and no direct privilege escalation route to the Domain Controller.

But then the threat actor finds an intermediary system.

In many environments, we see a single PAM session host used by everyone. The Tier 1 admins use it to manage application servers, and the Tier 0 admins use it to manage Domain Controllers. This convergence creates a "Shared" or "Dirty" Intermediary.

The attack path

The foothold: The threat actor compromises a standard Tier 2 workstation.
The escalation: The threat actor moves laterally and escalates privileges by exploiting common lower-tier misconfigurations (such as Helpdesk scenarios or exposed privileged service accounts) to compromise a Tier 1 administrator account who has full control over the Tier 1 PAM Host.
The pivot: Because the PAM Session Host resides in Tier 1, the threat actor uses those compromised Tier 1 admin rights to seamlessly gain full control of the underlying operating system of the PAM host itself.
The compromise: The threat actor simply waits for a Tier 0 admin to initiate a session. Because the threat actor already has full administrative control over the underlying server, it is a given that they can extract the Tier 0 credentials the moment that session begins.
Note: A threat actor at this stage does not need to exploit any weakness in the PAM software itself. Because the session host logically resides within the Tier 1 boundary, any identity or system with administrative rights over that tier holds ultimate authority over the host. This administrative control provides the means to modify the host's configuration, bypass security agents, and disable runtime protections before a privileged session ever begins. Once this foundational control is established, credential material processed by the operating system for outbound privileged sessions becomes accessible. This is not a PAM product failure; it is an architectural placement failure
Game over: The threat actor replays those credentials to take over the Domain Controller.

Here is how that compromise looks architecturally:

Figure 2: Single PAM host architecture

The core concept: PAM is an intermediary

To understand why the scenario above happens, we have to look at how Microsoft defines Privileged Access Intermediaries.

As detailed in our Privileged access intermediaries guidance, an intermediary is any system that stands between a user and a target resource. This includes VPNs, Jump Servers, and PAM solutions.

The Golden Rule of intermediaries

The security assurance of the target is only as good as the security assurance of the intermediary.

If you manage a Tier 0 asset (like a Domain Controller) through a PAM server, that PAM server becomes a Tier 0 asset. If that PAM server allows logins from Tier 1 users or is reachable from Tier 2 workstations, you have effectively downgraded your Domain Controllers to the security level of a workstation.

You cannot have a "Tier 1" server managing "Tier 0" assets. The math simply doesn't work. Each type of intermediary serves a different role, so the security controls won’t be identical. However, some basics apply to all of them, like quickly patching appliances, firmware, operating systems, and applications.

Figure 3: Security impact of different PAM approaches

Third-party PIM/PAM solutions are often deployed on-premises or as a Virtual Machine (VM) in an Infrastructure as a Service (IaaS) environment and are usually reachable only from internal (intranet) systems. Even if they aren’t exposed to the internet, one stolen credential could let a threat actor reach them through VPN or other remote access methods.

The hidden risk: the "master key" service account

The attack path above assumes a threat actor waits for a human administrator to arrive. But there is a second, more direct risk and it doesn’t require patience at all. It’s not just about where users log in; it’s about the power the software holds.

Consider the Password Reset scenario. A key feature of PAM is automatically rotating Domain Admin passwords, so human admins never need to know them; credentials are simply injected into the session. However, to perform this action, the PAM Service Account itself requires massive privileges (typically Domain Admin or equivalent) to reset those target passwords.

Here is the trap: If your PAM Core or Vault resides in Tier 1 (or is treated as such) but manages Tier 0 credentials, you have effectively granted Domain Admin rights to a Tier 1 asset.

A threat actor doesn't even need to wait for a human administrator to log in. If they compromise the underlying server where the PAM service runs, they can extract the Service Account’s credentials. Since this account has the power to reset Domain Admin passwords, the threat actor instantly elevates to Tier 0; no session required, no waiting, no noise.

This reinforces the golden rule: If a Service Account manages Tier 0, the system it runs on is Tier 0. The two attack vectors: hijacking a session and stealing the service account. Both stem from the same root cause: architectural misplacement. Fix the placement, and you eliminate both.

Practical checklist: are you exposed?

In DART engagements, we use this checklist to rapidly assess if a PAM deployment is a security asset or a liability. Use this to validate your own environment:

The intermediary check: Does any server used to manage Domain Controllers allow inbound RDP, SMB or other management connections from standard workstations or Tier 1 servers? (If yes, you are bridged).
The identity check: Do you use the same "Admin" account to log into the PAM portal for both Tier 0 and Tier 1 tasks? (If yes, you are exposing credentials).
The reachability check: Can your PAM Vault/Core be reached from the general user network? (It should only be reachable from management zones).
The isolation check: Are your Tier 0 Session Hosts logically and technically treated as Tier 0 assets?

What good looks like: The tiered PAM architecture

How do we fix this? We don't throw away PAM; we align it with the Enterprise Access Model.

In DART, we advocate for a tiered PAM deployment. This doesn't necessarily mean buying three different PAM vaults. It means strictly segregating the session hosts and the control plane.

The architecture of isolation

Tier 0 Control Plane: The core of your PAM (the Vault, the Policy Manager) holds the keys to the kingdom. Therefore, it must be treated as Tier 0. It should only be manageable by Tier 0 admins from Tier 0 workstations.
Segregated Session Hosts: You must have separate session host infrastructure for each tier.

- Tier 1 Session Host: Accessible from Tier 1, manages Tier 1. Blocked from talking to Domain Controllers.
- Tier 0 Session Host: Accessible only from Tier 0 PAWs, manages Tier 0. Totally isolated from the rest of the network.

This diagram illustrates a PAM deployment that respects the tiering model:

Figure 4: Separate PAM host architecture

For a deeper dive into reconciling these paradigms, review Intermediaries in Securing Privileged Administration and Microsoft's guide on Partitioning Administrative Privileges.

FAQ: Clearing the confusion

Q: Does PAM always belong in Tier 0?

A: If the PAM system manages Tier 0 credentials or provides access to Tier 0 assets, yes. The components that touch Tier 0 (Vault, Brokers, Session Hosts) must be secured at Tier 0 standards.

Q: Can we use a single "hardened" session host for all tiers to save costs?

A: In DART's experience, no. "Hardening" is often a configuration state that drifts or is bypassed by zero-days. Architecture beats configuration. If you bridge the network tiers, a compromised Tier 1 admin account is all a threat actor needs to gain OS-level control of that host and from there, access to Tier 0 sessions is a matter of patience, not sophistication.

Q: If we have PAM, do we still need the Tiering Model?

A: Absolutely. PAM doesn’t replace Tiering; when implemented correctly, it adds another layer of security and/or governance. Tiering keeps credentials and admin access separated, so threat actors can’t easily move sideways or reuse stolen hashes. PAM provides workflow, rotation, and audit trails.

Q: What is the most common mistake you see?

A: We frequently see organizations approach PAM as a "magic stick", believing it secures everything about credential hygiene. Yet, because they assume the tool secures itself, they treat this critical infrastructure as just another Tier-1 asset. It gets patched like a standard file server and monitored like a print server, rather than being hardened and isolated as a Tier-0 component. This mindset doesn't secure the environment; it creates a fragile bridge that threat actors can easily cross.

Q: Our PAM vendor says their session host is hardened out of the box. Why is this still a risk?

A: PAM vendors are right that a well-configured session host with Credential Guard enabled, application control enforced, and remote management restricted is considerably harder to exploit than a stock Windows Server. Some vendors use Kerberos constrained delegation with S4U2Proxy, meaning the machine account rather than the Domain Admin’s actual credentials authenticates to the target, which limits direct credential exposure. These are meaningful controls and we don’t dismiss them. However, application-layer hardening is defeated by OS-layer control. If the PAM host is domain-joined and sits in a Tier 1 OU, a Tier 1 Domain Admin has Group Policy, software deployment rights, and Active Directory machine account control over that host. They can push a GPO to disable Credential Guard, deploy a driver via software distribution, or alter the machine’s configuration before the next reboot, all using entirely legitimate AD administration tools. The vendor’s hardening is irrelevant once the threat actor controls the tier the machine lives in. This is precisely why tier placement is not a PAM configuration decision; it is an Active Directory architecture decision.

Q: We’re cloud-first and use Entra ID. Does AD Tiering still apply to us?

A: The specific tier labels change, but the principle does not. Microsoft’s Enterprise Access Model is the cloud-era evolution of AD Tiering, built around the same core concept: Control Plane (equivalent to Tier 0), Management Plane (Tier 1), and User Access / Data Plane (Tier 2). In an Entra ID environment, your Control Plane includes Global Administrators, Privileged Role Administrators, and the Conditional Access policies that govern them. A PAM or PIM solution managing those identities must be treated with the same isolation discipline. Hybrid environments, where on-premises AD and Entra ID are synchronized, carry the additional risk that a compromise of either plane can propagate to the other through synchronization. If anything, hybrid environments make strict intermediary placement more critical, not less.

Conclusion

PAM is a powerful tool in the defender’s arsenal; but like any powerful tool, its effectiveness depends entirely on how it is positioned. The threat actors we encounter in DART engagements don’t look for the most sophisticated path to Domain Admin. They look for the most trusted one. A PAM server in the wrong tier isn’t a hardened barrier; it’s a trusted bridge with a gold-plated sign.

By aligning your PAM deployment with the principles of Privileged Access Administration, treating session hosts and service accounts as the tier of the assets they manage, not the zone they physically sit in, you close the bridge before a threat actor finds it.

Build your architecture like a threat actor will find it. Because they will.

Stay secure, stay tiered.

Security Community Spotlight: Fabrício Assumpção

RenWoods — Wed, 15 Apr 2026 17:13:44 GMT

Meet Fabrício Assumpção, a Technical Specialist Architect for a Microsoft Security and Compliance Certified Partner, based in Brazil. Fabrício considers his involvement with the Microsoft Security Community defined by a dual approach: architectural innovation and technical enablement. As a Microsoft Certified Trainer (MCT) since 2021, he has been dedicated to bridging the gap between theory and real-world implementation for security professionals globally.

What do you find most rewarding about being a member of the Microsoft Security Community?

The most rewarding part of being a member of the Microsoft Security Community is the direct access to the pulse of cybersecurity innovation. As a Microsoft Certified Trainer (MCT) and a developer/engineer/architect focused on Cloud Security/M365 Security and SIEM, being in this ecosystem allows me to bridge the gap between complex architectural challenges and AI-driven solutions. Developing security agents for Microsoft Security Copilot is particularly fulfilling because I can see how the community’s collective knowledge shapes the future of automated defense. For me, it’s not just about the tools, but about being part of a global movement that empowers defenders to stay ahead of sophisticated threats through intelligence and automation.

How would you describe your Microsoft Community involvement?

In my role as a Security Architect and Engineer at adaQuest, I advocate for Microsoft’s vision by designing and deploying complex security infrastructures. My work spans the entire Microsoft Security stack, from high-level XDR (Microsoft Defender) strategies and SIEM (Microsoft Sentinel) deployments to the cutting edge of AI-driven defense. Currently, alongside my other activities, I'm focused on developing custom security agents for Microsoft Security Copilot, a task that allows me to push the boundaries of how automation and AI can empower modern SOCs.

While my primary involvement has been focused on technical architecture and developing security Copilot agents, my ideal community experience would be centered on deep-tier technical co-creation. I envision a community space that facilitates direct architectural dialogues between Microsoft product teams and the engineers who are building on top of those platforms. For me, the most valuable community experience is one that prioritizes 'early-access' feedback loops and specialized hackathons where we can stress-test new features—like advanced XDR integrations or AI agent capabilities—before they hit the mainstream. My ideal is a community that functions as a high-octane R&D hub, where the collective expertise of architects and developers directly influences the roadmap of the security tools we use every day

Editor’s note: The scenario Fabrício describes above is much like the Security Advisors program, which gives you early access to products, features, and private previews. Your feedback to engineering has the power to directly influence Microsoft Security products. If this interests you, consider joining!

How long have you been working with Microsoft Security products?

My Microsoft security journey is a story of evolution—from a cloud support engineer resolving complex L3/L4 infrastructure issues to a Security Architect leading global SOC operations. I have spent the last decade mastering the transition to the cloud, starting with identity and endpoint management (Entra ID and Intune) and progressing to end-to-end administration of the Microsoft 365 and Azure security stack. A turning point was joining adaQuest, where I took the lead on SOCaaS and began bridging the gap between governance and hands-on engineering and Sentinel. Today, my journey has reached its most exciting phase: pioneering the use of Generative AI in security to build scalable, automated solutions that protect clients worldwide.

What features or products have provided the most impact? Please describe how it has helped you or your customers.

The most impactful solution has been the integration of Microsoft Sentinel with Security Copilot through custom-developed security agents. This combination has revolutionized how our customers manage their security posture, allowing them to orchestrate and query the entire Defender XDR, Entra ID, and Purview stack through natural language automation. The most direct benefit for our clients has been a drastic reduction in Mean Time to Respond (MTTR) and a significant increase in operational efficiency, transforming complex security data into proactive defense. This unified approach ensures that our customers maximize their investment in the Microsoft ecosystem while maintaining high-speed resilience against sophisticated threats.

You’ve indeed been instrumental in building with Microsoft Security. What can you share with us, and can you tell us about your journey?

I am incredibly proud of being a pioneer in the Microsoft Security Copilot ecosystem. In early 2025, before official documentation was fully available or the feature had reached General Availability (GA), I conceptualized and developed six custom security agents designed to enhance automated defense and incident response.

These agents were the result of a deep dive into the underlying architecture of AI-driven security, where I had to materialize complex ideas into functional, real-world tools without a predefined roadmap. My work was officially showcased and published during the historic announcement of the Microsoft Security Store in 2025, marking the debut of third-party security agents.

Seeing these agents evolve from initial concepts to essential tools for the SOC of the future—enabling faster, more intelligent decision-making—is my most rewarding professional achievement. It represents my commitment to pushing the boundaries.

Fabricio’s agents are available in the **Microsoft Security Store. Here’s what he’s built (so far…)**

Admin Guard Insight
An agent focused on privileged identity and access analysis. It reviews administrative roles, sensitive changes, and risk signals to identify exposure, misuse of privileges, and opportunities to strengthen security posture.
Login Investigator
An agent designed to investigate suspicious sign-in activity. It correlates authentication details, IPs, locations, devices, user risk, and related incidents to determine whether a login is legitimate or potentially malicious.
Entity Guard
An entity-centric investigation agent for users, devices, applications, or service principals. It consolidates signals from multiple sources to enrich entity context and identify abnormal behavior, exposure, and associated risks.
Data Leak Agent
An agent specialized in investigating potential data leakage and sensitive information exposure. It validates and correlates incidents across Microsoft Defender XDR and Microsoft Sentinel to produce a more reliable and contextualized investigation.
L1 SOC Triage
An agent built to support first-level SOC alert and incident triage. It helps classify events, enrich context, prioritize severity, and recommend next steps or escalation paths for analysts.
Ransomware Kill Chain Investigator
An agent focused on ransomware investigations. It correlates evidence and maps observed activity to the ransomware kill chain to help teams understand the attack, impacted assets, and priority response actions.
EWS Sunset Readiness Assessor
An agent that assesses an organization’s readiness for Exchange Web Services (EWS) deprecation. It identifies application and service principal dependencies and supports planning for migration to more modern and secure alternatives.

What impact has integrating with Microsoft Security had on your business or your customers?

Integrating with Microsoft Security has had a significant impact on both our business and our customers. For our business, it has enabled us to build higher-value security services and differentiated solutions, such as Security Copilot agents tailored to real operational challenges in identity protection, incident triage, data leakage investigations, ransomware analysis, and legacy dependency assessments.

For our customers, the impact has been: improved speed, consistency, and depth in security operations. By leveraging Microsoft Security signals and platforms such as Microsoft Defender, Microsoft Sentinel, and Entra, we help teams investigate incidents faster, reduce manual effort, improve decision-making, and strengthen overall security posture. In practice, this means customers gain more actionable insights, better prioritization, and more efficient use of their security resources.

What advice do you have for others who would like to get involved in the Microsoft Community?

My advice is to bridge the gap between learning and building. Don’t just consume content; start creating solutions for real-world challenges, such as AI-driven automation in Security Copilot or Microsoft Sentinel. Use your practical experience to help others, and remember that teaching is one of the most powerful ways to contribute. In an era of rapid AI evolution, being a proactive 'early adopter' who shares insights is the best way to grow within the Microsoft Community and help protect the global digital landscape.

Fabrício beyond Microsoft Security

Beyond my technical career, I am a lifelong learner with a deep passion for understanding how the world works, from the complexities of Quantum Computing—which I studied at the University of Coimbra—to the fundamental principles of Physics, Astronomy, and Philosophy. I am currently pursuing two Master’s degrees, as I believe that diverse knowledge fuels creativity. I am also a polyglot at heart, teaching myself Italian, Spanish, Russian, and Chinese using open-source materials. My creative side is expressed through music, as I play both the violin and the piano. In my spare time, I enjoy the discipline of sports; I have a history as both a player and coach of Rugby, and I am a fan of Ice Hockey. My future plans include completing my Doctorate and embracing a nomadic lifestyle to experience different cultures and perspectives. For me, life is about the continuous pursuit of wisdom and the belief that we can always expand the boundaries of our own understanding.

Connect with Fabrício on LinkedIn.

____________________________________________________________________________________________

Learn and Engage with the Microsoft Security Community

Follow = Click the heart in the upper right when you're logged in 🤍.

Join the Microsoft Security Community and be notified of upcoming events, product feedback surveys, and more.
Get early access to Microsoft Security products and provide feedback to engineers by joining the Microsoft Security Advisors.

Join the Microsoft Security Community LinkedIn Group and follow the Microsoft Entra Community on LinkedIn

Why UK Enterprise Cybersecurity Is Failing in 2026 (And What Leaders Must Change)

Alex_Zold — Mon, 20 Apr 2026 16:31:29 GMT

Enterprise cybersecurity in large organisations has always been an asymmetric game. But with the rise of AI‑enabled cyber attacks, that imbalance has widened dramatically - particularly for UK and EMEA enterprises operating complex cloud, SaaS, and identity‑driven environments.

Microsoft Threat Intelligence and Microsoft Defender Security Research have publicly reported a clear shift in how attackers operate: AI is now embedded across the entire attack lifecycle. Threat actors use AI to accelerate reconnaissance, generate highly targeted phishing at scale, automate infrastructure, and adapt tactics in real time - dramatically reducing the time required to move from initial access to business impact.

In recent months, Microsoft has documented AI‑enabled phishing campaigns abusing legitimate authentication mechanisms, including OAuth and device‑code flows, to compromise enterprise accounts at scale. These attacks rely on automation, dynamic code generation, and highly personalised lures - not on exploiting traditional vulnerabilities or stealing passwords.

The Reality Gap: Adaptive Attackers vs. Static Enterprise Defences

Meanwhile, many UK enterprises still rely on legacy cybersecurity controls designed for a very different threat model - one rooted in a far more predictable world.

This creates a dangerous "Resilience Gap."

Here is why your current stack is failing- and the C-Suite strategy required to fix it.

1. The Failure of Traditional Antivirus in the AI Era

Traditional antivirus (AV) relies on static signatures and hashes. It assumes malicious code remains identical across different targets. AI has rendered this assumption obsolete. Modern malware now uses automated mutation to generate unique code variants at execution time, and adapts behaviour based on its environment.

Microsoft Threat Intelligence has observed threat actors using AI‑assisted tooling to rapidly rewrite payload components, ensuring that every deployment looks subtly different. In this model, there is no reliable signature to detect. By the time a pattern exists, the attacker has already moved on. Signature‑based detection is not just slow - it is structurally misaligned with AI‑driven attacks.

The Risk: If your security relies on "recognising" a threat, you are already breached. By the time a signature exists, the attacker has evolved.
The C-Suite Pivot: Shift investment from artifact detection to EDR/XDR (Extended Detection and Response). We must prioritise behavioural analytics and machine learning models that identify intent rather than file names.

2. Why Perimeter Firewalls Fail in a Cloud-First World

Many UK enterprise still rely on firewalls enforcing static allow/deny rules based on IP addresses and ports. This model worked when applications were predictable and networks clearly segmented.

Today, enterprise traffic is encrypted, cloud‑hosted, API‑driven, and deeply integrated with SaaS and identity services. AI‑assisted phishing campaigns abusing OAuth and device‑code flows demonstrate this clearly. From a network perspective, everything looks legitimate: HTTPS traffic to trusted identity providers. No suspicious port. No malicious domain. Yet the attacker successfully compromises identity.

The Risk: Traditional firewalls are "blind" to identity-based breaches in cloud environments.
The C-Suite Pivot: Move to Identity-First Security. Treat Identity as the new Control Plane, integrating signals like user risk, device health, and geolocation into every access decision.

3. The Critical Weakness of Single-Factor Authentication

Despite clear NCSC guidance, single-factor passwords remain a common vulnerability in legacy applications and VPNs.

AI-driven credential abuse has changed the economics of these attacks. Threat actors now deploy adaptive phishing campaigns that evolve in real-time. Microsoft has observed attackers using AI to hyper-target high-value UK identities- specifically CEOs, Finance Directors, and Procurement leads.

The Risk: Static passwords are now the primary weak link in UK supply chain security.
The C-Suite Pivot: Mandate Phishing‑resistant MFA (Passkeys or hardware security keys). Implement Conditional Access policies that evaluate risk dynamically at the moment of access, not just at login.

Legacy Security vs. AI‑Era Reality

4. The Inherent Risk of VPN-Centric Security

VPNs were built on a flawed assumption: that anyone "inside" the network is trustworthy. In 2026, this logic is a liability.

AI-assisted attackers now use automation to map internal networks and identify escalation paths the moment they gain VPN access. Furthermore, Microsoft has tracked nation-state actors using AI to create synthetic employee identities- complete with fake resumes and deepfake communication. In these scenarios, VPN access isn't "hacked"; it is legally granted to a fraudster.

The Risk: A compromised VPN gives an attacker the "keys to the kingdom."
The C-Suite Pivot: Transition to Zero Trust Architecture (ZTA). Access must be explicit, scoped to the specific application, and
continuously re‑evaluated using behavioural signals.

5. Data: The High-Velocity Target

Sensitive data sitting unencrypted in legacy databases or backups is a ticking time bomb. In the AI era, data discovery is no longer a slow, manual process for a hacker.

Attackers now use AI to instantly analyse your directory structures, classify your files, and prioritise high-value data for theft. Unencrypted data significantly increases your "blast radius," turning a containable incident into a catastrophic board-level crisis.

The Risk: Beyond the technical breach, unencrypted data leads to massive UK GDPR fines and irreparable brand damage.
The C-Suite Pivot: Adopt Data-Centric Security. Implement encryption by default, classify data while adding sensitivity labels and start board-level discussions regarding post‑quantum cryptography (PQC) to future-proof your most sensitive assets.

6. The Failure of Static IDS

Traditional Intrusion Detection Systems (IDS) rely on known indicators of compromise - assuming attackers reuse the same tools and techniques. AI‑driven attacks deliberately avoid that assumption.

Threat actors are now using Large Language Models (LLMs) to weaponize newly disclosed vulnerabilities within hours. While your team waits for a "known pattern" to be updated in your system, the attacker is already using a custom, AI-generated exploit.

The Risk: Your team is defending against yesterday's news while the attacker is moving at machine speed.
The C-Suite Pivot: Invest in Adaptive Threat Detection. Move toward Graph‑based XDR platforms that correlate signals across email, endpoint, and cloud to automate investigation and response before the damage spreads.

From Static Security to Continuous Security

Closing Thought: Security Is a Journey, Not a Destination

For UK enterprises, the shift toward adaptive cybersecurity is no longer optional - it is increasingly driven by regulatory expectation, board oversight, and accountability for operational resilience.

Recent UK cyber resilience reforms and evolving regulatory frameworks signal a clear direction of travel: cybersecurity is now a board‑level responsibility, not a back‑office technical concern. Directors and executive leaders are expected to demonstrate effective governance, risk ownership, and preparedness for cyber disruption - particularly as AI reshapes the threat landscape.

AI is not a future cybersecurity problem.
It is a current force multiplier for attackers, exposing the limits of legacy enterprise security architectures faster than many organisations are willing to admit.

The uncomfortable truth for boards in 2026 is that no enterprise is 100% secure. Intrusions are inevitable. Credentials will be compromised. Controls will be tested.

The difference between a resilient enterprise and a vulnerable one is not the absence of incidents, but how risk is managed when they occur.

In mature organisations, this means assuming breach and designing for containment:

Access controls that limit blast radius
Least privilege and conditional access restricting attackers to the smallest possible scope if an identity is compromised
Data‑centric security using automated classification and encryption, ensuring that even when access is misused, sensitive data cannot be freely exfiltrated

As a Senior Enterprise Cybersecurity Architect, I see this moment as a unique opportunity. AI adoption does not have to repeat the mistakes of earlier technology waves, where innovation moved fast and security followed years later.

We now have a rare chance to embed security from day one - designing identity controls, data boundaries, automated monitoring, and governance before AI systems become business‑critical.

When security is built in upfront, enterprises don’t just reduce risk - they gain the confidence to move faster and unlock AI’s value safely.

Security is no longer a “department”.
In the age of AI, it is a continuous business function - essential to preserving trust and maintaining operational continuity as attackers move at machine speed.

References:

Inside an AI‑enabled device code phishing campaign | Microsoft Security Blog

AI as tradecraft: How threat actors operationalize AI | Microsoft Security Blog

Detecting and analyzing prompt abuse in AI tools | Microsoft Security Blog

Post-Quantum Cryptography | CSRC

Microsoft Digital Defense Report 2025 | Microsoft

https://www.ncsc.gov.uk/news/government-adopt-passkey-technology-digital-services

Hunting Infostealers - Trusted Platform Abuse

FeliciaCarter — Wed, 15 Apr 2026 16:00:00 GMT

In this part of the “Hunting Infostealers” series, we explore the growing abuse of trusted communication services and software ecosystems—including messaging platforms like WhatsApp and seemingly benign PDF converter tools—to propagate malware and deploy credential stealers such as Eternidade Stealer, lowering user suspicion and complicating detection. Throughout the blog, we map observed activity to Microsoft Defender XDR coverage and provide actionable guidance to help organizations detect, mitigate, and respond to infostealers.

Platform Abuse (WhatsApp, PDF Converters)
Since late 2025, Platform abuse has become an increasingly prevalent tactic in the modern threat landscape, wherein adversaries deliberately exploit the legitimacy, scale, and user trust associated with widely used applications and services. By weaponizing platforms such as WhatsApp and seemingly benign PDF conversion tools, threat actors are able to disguise malicious activity within normal user behavior, enabling efficient malware delivery, lateral propagation, and evasion of traditional security controls.

WhatsApp Abused to Deliver Eternidade Stealer

During the third week of November 2025, Microsoft Defender Experts (DEX) identified a WhatsApp platform abuse campaign that leverages a multi-stage infection chain and worm-like propagation techniques to distribute malware. The activity begins with the execution of an obfuscated Visual Basic script, which drops a malicious batch file that launches multiple PowerShell instances to download additional payloads from adversary-controlled command-and-control domains. These payloads include a Python script responsible for WhatsApp Web–based dissemination of the malware in a worm-like manner, as well as a malicious MSI installer that ultimately delivers the Eternidade Stealer. To ensure successful execution, the batch script also installs the required Python dependencies on the compromised system.

The Python script establishes communication with a remote server and leverages the open-source project WPPConnect to automate message sending from hijacked WhatsApp accounts. As part of this process, it harvests the victim’s entire contact list while filtering out groups, business contacts, and broadcast lists. The malware then collects, for each contact, the associated WhatsApp phone number, name, and an indicator showing whether the contact is saved. This information is exfiltrated to an attacker-controlled server via an HTTP POST request. In the final stage of this propagation mechanism, the malware sends a malicious attachment to all harvested contacts, using a predefined messaging template populated with time-based greetings and contact names to increase the likelihood of interaction.

The malicious MSI installer drops several components, including encrypted payload files with .dmp and .tda extensions, an AutoIt executable, and a script loader disguised as a .log file. Despite its benign appearance, the .log file functions as an AutoIt-based malicious script that conducts environment reconnaissance, performs anti-detection checks, and loads payloads in memory using large hex-encoded binary blobs to initialize native components. The encrypted .tda file acts as an injector and employs a process hollowing technique to execute the final payload. Specifically, the injector reads the .dmp file, decrypts the embedded payload, and injects the Eternidade Stealer into svchost.exe, allowing the malware to run stealthily under the guise of a trusted system process.

Eternidade Stealer, a Delphi-based credential stealer, continuously monitors active windows and running processes for strings associated with banking portals, payment services, and cryptocurrency exchanges and wallets. These include, but are not limited to, Bradesco, BTG Pactual, MercadoPago, Stripe, Binance, Coinbase, MetaMask, and Trust Wallet, highlighting its focus on harvesting sensitive financial and cryptocurrency-related information

WhatsApp Abuse to Deliver Eternidade Stealer Attack Chain

Malicious Crystal PDF installer campaign

In late September 2025, Microsoft Defender Experts (DEX) discovered a malicious campaign conducted by an unknown threat actor centered on an application masquerading as a PDF editor named Crystal PDF. The campaign leveraged malvertising and search engine optimization (SEO) poisoning techniques, using misleading advertisements to lure users into downloading a malicious payload.

The attack chain begins when a user clicks the download button for the PDF editor on crystalpdf[.]com. The request is redirected to one of two actor-controlled domains, from which the CrystalPDF.exe payload is downloaded. Users most likely arrived at this website through deceptive advertisements distributed via Google Ads, which served as the primary lure for the campaign. Microsoft suspects that Google Ads were used based on the URL format observed in telemetry: hxxps://smartdwn[.]com/download?v=<GUID>&campaign_id=<ID#>&utm_source=google_b2b&subid=<domainSource>&kw=true&gad_source=5&gad_campaignid=<ID#>&gclid=<>.

When CrystalPDF.exe is downloaded and executed on the device, it performs several actions to establish persistence and enable further activity. A copy of the CrystalPDF.exe payload is created in the AppData\Local\Temp\crys directory, and a malicious scheduled task is created to ensure continued execution on the compromised device. In addition, a second binary named Crystal PDF.exe (note the space in the filename) is dropped in the user’s Desktop folder.

The attacker configures the payload to run daily at 7:15 AM local system time using a scheduled task named Crystal_updater. When triggered, this scheduled task launches the malicious CrystalPDF.exe, which initiates network connections to three command-and-control domains: negmari[.]com, ramiort[.]com, and strongdwn[.]com.

The secondary executable, Crystal PDF.exe, stored in the Desktop directory, establishes network connections to multiple cloudconvert[.]com-related domains. CloudConvert is a legitimate service used to convert files into different formats, including converting various document types into PDF files. Analysis of this file indicates that it is a clean file and is designed to appear as a legitimate application that leverages CloudConvert to provide document-to-PDF conversion functionality.

Despite presenting itself as a legitimate PDF conversion and merging tool, CrystalPDF.exe ultimately functions as an information stealer. It covertly hijacks Firefox and Chrome browsers and attempts to access sensitive files located in the AppData\Roaming directory, which stores user-specific configuration and profile data that must persist across sessions. This includes cookies and session data, sign-in and credential caches, and profile settings. By harvesting credentials, tokens, and session cookies stored in the browser, the attacker can bypass standard authentication mechanisms and impersonate the user to gain unauthorized access to accounts and services that the user is authorized to use.

Crystal PDF Installer Attack Chain

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the impact of trusted platform abuse used to deliver infostealers as discussed in this report. These recommendations draw from established Defender blog guidance patterns and align with protections offered across Microsoft Defender XDR.

Organizations can follow these recommendations to mitigate threats associated with this threat:

Strengthen user awareness & execution safeguards

Educate users on social‑engineering lures, including malvertising redirect chains, fake installers, and ClickFix‑style copy‑paste prompts.

Control outbound traffic & staging behavior

Block direct access to known C2 infrastructure where possible, informed by your organization’s threat‑intelligence sources.

Protect against cross‑platform payloads

Harden endpoint defenses around LOLBIN abuse, such as wscript.exe executing Visual Basic scripts.
Evaluate activity involving AutoIt and process hollowing, common in platform‑abuse campaigns.

Microsoft also recommends the following mitigations to reduce the impact of this threat.

Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a majority of new and unknown threats.
Run EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.
Enable network protection and web protection in Microsoft Defender for Endpoint to safeguard against malicious sites and internet-based threats.
Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
Allow investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
Turn on tamper protection features to prevent attackers from stopping security services. Combine tamper protection with the DisableLocalAdminMerge setting to prevent attackers from using local administrator privileges to set antivirus exclusions.
Microsoft Defender XDR customers can also implement the following attack surface reduction rules to harden an environment against LOLBAS techniques used by threat actors:

o Block execution of potentially obfuscated scripts

o Block executable files from running unless they meet a prevalence, age, or trusted list criterion

o Block JavaScript or VBScript from launching downloaded executable content

Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Tactic	Observed activity	Microsoft Defender coverage
Execution	- Payloads downloaded using PowerShell	Microsoft Defender for Endpoint - Suspicious Powershell download or encoded command execution
Persistence	- Registry Run key created - Scheduled task created for recurring execution	Microsoft Defender for Endpoint - Anomaly detected in ASEP registry - Suspicious Scheduled Task Launched
Defense Evasion	- Unauthorized code execution facilitated by DLL sideloading and process injection - Python script execution - Renamed AutoIT interpreter binary and AutoIT script	Microsoft Defender for Endpoint - An executable file loaded an unexpected DLL file - A process was injected with potentially malicious code - Suspicious Python binary execution - Rename AutoIT tool
Discovery	- System information queried using WMI and Python	Microsoft Defender for Endpoint - Suspicious System Hardware Discovery - Suspicious Process Discovery - Suspicious Security Software Discovery

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender XDR Threat analytics

Malicious Crystal PDF installer campaign

Hunting queries

Microsoft Defender XDR

Microsoft Defender XDR customers can run the following queries to find related activity in their networks:

Use the following queries to identify activity related to WhatsApp Abused to Deliver Eternidade Stealer

// Identify the files dropped from the malicious VBS execution DeviceFileEvents | where InitiatingProcessCommandLine has_all ("Downloads",".vbs") | where FileName has_any (".zip",".lnk",".bat") and FolderPath has_all ("\\Temp\\")

// Identify batch script launching powershell instances to drop payloads DeviceProcessEvents | where InitiatingProcessParentFileName == "wscript.exe" and InitiatingProcessCommandLine has_any ("instalar.bat","python_install.bat") | where ProcessCommandLine !has "conhost.exe"

// Identify AutoIT executable invoking malicious AutoIT script DeviceProcessEvents | where InitiatingProcessCommandLine has ".log" and InitiatingProcessVersionInfoOriginalFileName == "Autoit3.exe"

Use the following queries to identify activity related to Malicious CrystalPDF Installer Campaign

// Identify network connections to C2 domains DeviceNetworkEvents | where InitiatingProcessVersionInfoOriginalFileName == "CrystalPDF.exe"

// Identify scheduled task persistence DeviceEvents | where InitiatingProcessVersionInfoProductName == "CrystalPDF" | where ActionType == "ScheduledTaskCreated

Indicators of compromise

Indicator	Type	Description
2c885d1709e2ebfcaa81e998d199b29e982a7559b9d72e5db0e70bf31b183a5f 6168d63fad22a4e5e45547ca6116ef68bb5173e17e25fd1714f7cc1e4f7b41e1 3bd6a6b24b41ba7f58938e6eb48345119bbaf38cd89123906869fab179f27433 5d929876190a0bab69aea3f87988b9d73713960969b193386ff50c1b5ffeadd6 bdd2b7236a110b04c288380ad56e8d7909411da93eed2921301206de0cb0dda1 495697717be4a80c9db9fe2dbb40c57d4811ffe5ebceb9375666066b3dda73c3 de07516f39845fb91d9b4f78abeb32933f39282540f8920fe6508057eedcbbea	SHA-256	Payloads related to WhatsApp malware campaign
598da788600747cf3fa1f25cb4fa1e029eca1442316709c137690e645a0872bb 3bc62aca7b4f778dabb9ff7a90fdb43a4fdd4e0deec7917df58a18eb036fac6e c72f8207ce7aebf78c5b672b65aebc6e1b09d00a85100738aabb03d95d0e6a95	SHA-256	Payloads related to Malicious Crystal PDF installer campaign
hxxps://empautlipa[.]com/altor/installer.msi	URL	Used to deliver VBS initial access payload (WhatsApp Abused to Deliver Eternidade Stealer)
Negmari[.]com Ramiort[.]com Strongdwn[.]com	Domain	C2 servers (Malicious Crystal PDF installer campaign)

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.

References

Infostealers Strike Again: Malicious Installers Pass Through EDRs Undetected

SpiderLabs IDs New Banking Trojan Distributed Through WhatsApp

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

Credential Exposure Risk & Response Workbook

Jon_Nordstrom — Wed, 15 Apr 2026 10:00:00 GMT

How to set up the Workbook

Use the steps outlined in the Identify and Remediate Credentials article to get the right rules in place to start capturing credential data. You may choose to use custom regex patterns or more specific SITs that align with your scenario. This workbook will help you once that is done.

This workbook transforms credential leakage detection into a measurable, executive-ready capability.

End‑to‑end situational awareness: Correlates alerts across workloads, departments, credential types, and users to surface material exposure quickly.
Actionable triage & forensics: Drill from trends to the artifact (message/file/URL), accelerating containment and root‑cause analysis.
Risk‑aligned decisions: Quantifies exposure and response performance (creation vs. resolution trends) to guide investment and policy changes.
Audit‑ready governance: Captures decisions, timelines, and outcomes for PCI/PII controls, identity hygiene, and secrets management.

Prerequisites

License requirements for Microsoft Purview Information Protection depend on the scenarios and features you use. To understand your licensing requirements and options for Microsoft Purview Information Protection, see the Information Protection sections from Microsoft 365 guidance for security & compliance and the related PDF download for feature-level licensing requirements.
Before you start, all endpoint interaction with Sensitive content is already being included in the audit logging with Endpoint DLP enabled (Endpoint DLP must be enabled). For Microsoft 365 SharePoint, OneDrive Exchange, and Teams you can enable policies that generate events but not incidents for important sensitive information types.
Install Power BI Desktop to make use of the templates Downloads - Microsoft Power BI

Step-by-step guided walkthrough

In this guide, we will provide high-level steps to get started using the new tooling.

Get the latest version of the report that you are interested in. In this case, we will show the Board report.
Open the report. If Power BI Desktop is installed, it should look like this:

3. You must authenticate with the https://api.security.microsoft.com, select Organizational account, and sign in. Then click Connect.

4. You will also have to authenticate with httpps://api.security.microsoft.com/api/advancedhunting, select Organizational account, and sign in. Then click Connect.

What the Workbook Delivers

The workbook moves programs to something that is measurable. Combined with customers' outcome‑based metrics (operational risk, control risk, end‑user impact), it enables an executive‑level, data‑driven narrative for investment and policy decisions.

End‑to‑end situational awareness: Correlates alerts across workloads, departments, credential types, and users to surface material exposure quickly.
Actionable triage & forensics: Drill from trends to the artifact (message/file/URL), accelerating containment and root‑cause analysis.
Risk‑aligned decisions: Quantifies exposure and response performance (creation vs. resolution trends) to guide investment and policy changes.
Audit‑ready governance: Captures decisions, timelines, and outcomes for PCI/PII controls, identity hygiene, and secrets management.

Troubleshooting tips:

If you are receiving a (400): Bad request error, it is likely that you do not have the necessary tables from the endpoint in Advanced Hunting. Those errors may also show if there are empty values passed from the left-hand side of the KQL queries.

Detection trend

Apply filtering to this view based on the DLP policies that monitor credentials.

Trend Analysis Over Time
Displays daily detection counts, helping identify spikes in credential leakage activity and enabling proactive investigation.
Workload and Credential Type Breakdown
Shows which workloads (e.g., Endpoint, Exchange, OneDrive) and credential types are most affected, guiding targeted security measures.
Detection Source Visibility
Highlight which security tools (Sentinel, Cloud App Security, Defender) are catching leaks, ensuring monitoring coverage, and identifying gaps.
Detailed Credential Exposure
Lists exposed credentials for quick validation and remediation, reducing the risk of misuse or compromise. (This part is dependent on the AI component)
Supports Incident Response
Enables rapid triage by correlating detection trends with specific credentials and sources, improving response times.
Compliance and Audit Readiness
Provides clear evidence of credential monitoring and leakage detection for regulatory and governance reporting.

Credential incident trends

Lifecycle Tracking of Credential Alerts
Visualizes creation and resolution trends over time, helping teams measure response efficiency and identify periods of heightened risk.
Workload and Credential Type Breakdown
Shows which workloads (Endpoint, Exchange, OneDrive) and credential types are most impacted, enabling targeted mitigation strategies.
Incident Type Analysis
Highlights the distribution of alerts by category (e.g., CredRisk, Agent), supporting prioritization of critical incidents.
Detailed Alert Context
Provides message IDs and associated credentials for precise investigation and remediation, reducing time to contain threats.
Performance and SLA Monitoring
Tracks resolution timelines to ensure compliance with internal security SLAs and regulatory requirements.
Audit and Governance Support
Offers clear evidence of alert handling and closure, strengthening accountability and reporting.

Content view

Workload-Level Risk Visibility
Highlights which workloads (e.g., SharePoint, Endpoint) have the highest credential exposure, enabling targeted security hardening.
Departmental Risk Breakdown
Shows which departments (Security, Logistics, Sales) are most impacted, helping prioritise remediation for critical business areas.
Credential Type Analysis
Identifies exposed credential types such as API keys, shared access keys, and tokens, guiding policy enforcement and rotation strategies.
User and Document Correlation
Links exposed credentials to specific users and documents, supporting rapid investigation and containment of leaks.
Comprehensive Drill-Down
Enables navigation from department → credential type → user → document for precise root cause analysis.
Governance and Compliance Support
Provides auditable evidence of credential exposure across workloads and departments, strengthening regulatory reporting.

For endpoint, this view is an excellent way to catch applications that are not treating secrets in a safe way and expose them in temporary files.

Force-directed graph

Visual Alert Correlation
Displays a force-directed graph linking users to alert categories, making it easy to identify patterns and clusters of credential-related risks.
High-Risk User Identification
Highlights users with multiple or severe alerts, enabling prioritisation for investigation and remediation.
Credential Type and Department Context
Shows which credential types and departments are most associated with alerts, supporting targeted security measures.
Alert Severity and Details
Provides a detailed table of alerts with severity and category, helping analysts quickly assess impact and urgency.
Improved Threat Hunting
Enables analysts to trace relationships between users, alert types, and credential exposure for deeper root cause analysis.
Compliance and Reporting
Offers clear evidence of monitoring and categorisation of credential-related alerts for governance and audit purposes.

Security incidents correlated to credential leakage

Focused on Credential Leakage
Provides a dedicated view of alerts related to exposed credentials, enabling quick detection and response.
Role-Based Risk Analysis
Breaks down incidents by department and role, helping prioritise remediation for high-risk groups such as developers and security teams.
User-Level Investigation
Allows drill-down to individual users involved in credential-related alerts for rapid containment and corrective action.
Credential Type Insights
Highlight which types of credentials (e.g., API keys, passwords) are most vulnerable, guiding policy improvements and rotation strategies.
Alert Source Correlation
Displays which security tools (Sentinel, MCAS, Defender) are detecting leaks, ensuring coverage and identifying monitoring gaps.
Compliance and Governance Support
Offers auditable evidence of credential monitoring, supporting regulatory and internal security requirements.

App and Network correlated to credential leakage

For network detection, adjust the query in production to remove standard applications if they are too noisy. We have seen cases where Word and other commonly used applications make calls using FTP services as an example. While other applications may add too much noise.

Token Detection Event Traceability
Shows detected Token credentials events linked directly to individual User IDs and Device IDs for investigation.
Application Usage Context
Identifies that the detected activity is associated with the application ms‑teams.exe as an example.
External URL Association
Displays the Remote URL connected to the token detection event.
Remote IP Visibility
Lists the Remote IP addresses associated with the activity.
Entity-Level Correlation
Links UserId, DeviceId, Application, Remote URL, and Remote IP within a single event flow. You can select port used or how Apps are linked as well.
Detection Count Aggregation
Summarises the number of credential events tied to each correlated entity path.

Turn detection into decisions. Deploy the workbook today to get measurable insights, accelerate triage, and deliver audit-ready governance. Start driving risk-aligned investment and policy changes with confidence.

The PBI report is located here.

Based on what you identify, you may be using tools such as Data Security Investigations to go deeper. We are also working on surfacing the AI triaging in a context that will enrich the DLP analyst experience.

Why External Users Can’t Open Encrypted Attachments in Certain Conditions & How to Fix It Securely

samsul_ahamed — Mon, 13 Apr 2026 16:57:02 GMT

When Conditional Access policies enforce MFA across all cloud apps and include external users, encrypted attachments may require additional considerations. This post explains why.

This behavior applies only in environments where all of the following are true:

Microsoft Purview encryption is used for emails and attachments
A Conditional Access (CA) policy is configured to:

Require MFA
Apply to all cloud applications
Include guest or external users

The Situation: Email Opens, Attachment Doesn’t

When an email is encrypted using:

Microsoft Purview Sensitivity Labels, or
Information Rights Management (IRM)

Any attached Office document automatically inherits encryption. This inheritance is intentional and enforced by the service, Ensures consistent protection of sensitive content. That inheritance is mandatory and cannot be disabled.

So far, so good. But here’s where things break for external recipients.

The Hidden Dependency: Identity & Conditional Access

Reading an encrypted email and opening an encrypted attachment are two different flows.

External users can usually read encrypted emails by authenticating through:

One-Time Passcode (OTP)
Microsoft personal accounts
Their own organization’s identity

However, encrypted attachments use Microsoft Rights Management Services (RMS) — and RMS expects an identity the sender’s tenant can evaluate.

If your organization has:

A global Conditional Access policy
Enforcing MFA for all users
Applied to all cloud apps

external users can get blocked even after successful email decryption.

This commonly results in errors like:

“This account does not exist in the sender’s tenant…”

AADSTS90072: The external user account does not exist in our tenant and cannot access the Microsoft Office application. The account needs to be added as an external user in the tenant or use an alternative authentication method.

When It Works (and Why It Often Doesn’t)

External access to encrypted attachments works only when one of these conditions is met:

The sender trusts the recipient’s tenant MFA via Cross‑Tenant Access (MFA trust)
The recipient already exists as a guest account in the sender’s tenant

In real-world scenarios, these conditions often fail:

External recipients use consumer or non‑Entra identities
Recipient domains are not predictable
Guest onboarding does not scale
Cross‑tenant trust is intentionally restricted

In such cases, Conditional Access policies designed for internal users can affect RMS evaluation for external users.

So what’s the alternative?

The Practical, Secure Alternative

When the two standard access conditions (cross‑tenant trust or guest presence) cannot be met , you can refine Conditional Access evaluation without weakening encryption. The goal is not to remove MFA, but to ensure it is applied appropriately based on identity type and access path.

In this scenario:

MFA remains enforced for all internal users, including access to Microsoft Rights Management Services (RMS)
MFA remains enforced for external users across cloud applications other than RMS

The Key Idea

Let encryption stay strong, but stop blocking external RMS authentication.

This is achieved by:

Keeping the existing Conditional Access policy that enforces MFA for all internal users across all cloud applications, including RMS
Excluding guest and external users from that internal‑only policy
Deploying a separate Conditional Access policy scoped to guest and external users to:

Continue enforcing MFA for external users where supported
Explicitly exclude Microsoft Rights Management Services (RMS) from evaluation

RMS can be excluded from the external‑user policy by specifying the following application (client) ID:

RMS App ID: 00000012-0000-0000-c000-000000000000

Why This Is Still Secure

This approach:

✅ Keeps email and attachment encryption fully intact
✅ Internal security posture is unchanged
✅ External users remain protected by MFA where applicable
✅ Allows external users to authenticate using supported methods
✅ Avoids over-trusting external tenants
✅ Scales for large, unpredictable recipient sets

Final Takeaway

Encrypted attachment access is governed by identity recognition and policy design, not by email encryption alone.

By aligning Conditional Access with how encrypted content is evaluated, organizations can enable secure external collaboration while maintaining strong protection standards

Azure Key Vault HSM Platform One Retirement: What Purview BYOK Customers Need to Know

AdamBell — Tue, 21 Apr 2026 22:12:44 GMT

What is changing?

In early 2024, Azure Key Vault introduced a modernized hardware security module (HSM) platform based on FIPS 140-2 Level 3 certified HSMs. As part of this evolution, the legacy HSM Platform One will be retired on September 15, 2028. Many Information Protection customers who use BYOK today rely on this legacy platform.

Why this matters for BYOK customers

BYOK configurations for Information Protection require that the tenant root key is stored in Azure Key Vault. Azure Key Vault does not support exporting keys once imported. In short, affected customers will need to migrate their BYOK key to a new Key Vault on the modern HSM platform and update their Purview configuration to reference it.

If no action is taken before the retirement date, encryption and decryption operations for Information Protection will become unavailable until the key is successfully migrated.

Why act now (even though retirement is in 2028)?

Although the retirement date is several years away, Microsoft strongly recommends that customers begin planning now. Migrating sooner allows customers to move to the most secure configuration available today. More critically, some customers may no longer have access to the original on-premises key material that was used during initial BYOK setup. Recovering, regenerating, or replacing this key material can take significant time and coordination across security, compliance, and HSM teams.

What should customers do next?

For customers using BYOK with Information Protection:

Review the MS Learn page - Configure BYOK (bring your own key) for the Azure Rights Management service root key | Microsoft Learn
Confirm whether your tenant key is using legacy HSM Platform
If so, follow the steps in the section - Migrating from Azure Key Vault hsmPlatform 1 to hsmPlatform 2
If your organization no longer has access to the original key material, begin planning immediately and engage with Microsoft support to explore your options

Learn more

In February, we also published a Message Center post (MC1234660) to notify those customers affected (i.e. using BYOK currently) about the Azure Key Vault HSM Platform One retirement and its impact on Information Protection tenants using Bring Your Own Key (BYOK).

Updated guidance for configuring and managing BYOK with Information Protection is available on Microsoft Learn.

Manage the root key for your tenant's Azure Rights Management service | Microsoft Learn

We recommend reviewing this documentation in detail to understand prerequisites, supported configurations, and migration considerations.

Microsoft will continue to communicate updates through the Microsoft 365 Message Center and Tech Community as the retirement date approaches.

VPN Integration not persistent

schimpanze — Thu, 09 Apr 2026 13:31:08 GMT

Hello,

We tried to configure VPN Integration for MDI from supported Cisco VPN GW. We established the RADIUS Accounting logs to be sent to DC with MDI sensors installed. Yet when we enabled this in Defender Portal (Settings > Identities > VPN) by checking the box and inserting the shared secret, the configuration is not persistent. We hit save, and we are presented with the success green message, but once we refresh the page or go elsewhere in the portal, the checkbox is not checked. Has anyone encountered the same issue?

Thanks, Simon