rss.livelink.threads-in-node

Level up your Azure Network Security Skills with our Upcoming Webinar Series

andrewmathu — Tue, 09 Jun 2026 17:09:00 GMT

As network and application-layer threats continue to evolve, security and infrastructure teams need more than product knowledge. They need practical, scenario-driven guidance they can apply to real workloads. To support that, the Azure Network Security team is hosting a series of upcoming technical webinars covering the capabilities our customers rely on every day: Azure Web Application Firewall (WAF), Azure Firewall, Azure DDoS Protection and Azure Bastion.

Each session is focused on demos, the latest enhancements, and the design and operational decisions you face when securing modern Azure environments. Whether you are protecting customer-facing web applications, hardening east-west and egress traffic, or securing remote administrative access at scale, there is a session in this lineup for you.

These webinars are ideal for Security Architects and Engineers, Network and Infrastructure teams, SOC Analysts, Cloud Platform Owners, Partner Technical Consultants, and any practitioner responsible for the security posture of workloads running on Azure.

Below is the schedule of the upcoming live deliveries.

Upcoming Events

Azure WAF Layer 7 DDoS defense in practice

Date and time: Thursday, June 18, 2026, at 8am PST

View event details and join

As web applications become primary targets for sophisticated application-layer attacks, Azure Web Application Firewall continues to evolve to meet the needs of modern application security teams facing volumetric and targeted application-layer threats. In this webinar, we will explore how Azure WAF enables a layered, adaptive approach to application-layer DDoS mitigation, helping organizations detect and block malicious request patterns through intelligent inspection, control traffic flow to prevent resource exhaustion from abusive sources, progressively challenge suspicious clients to verify legitimacy without disrupting real users, and combine multiple defense mechanisms into a cohesive mitigation strategy that adapts to evolving attack techniques. Whether you're securing customer-facing web apps or business-critical services, this session will equip you with practical approaches to building resilient application-layer defenses on Azure.

Azure Firewall IDPS Detections and Sentinel Integration

Date and time: Thursday, July 9, 2026, at 8am PST

View event details and join

As network threats grow in complexity, organizations need visibility that extends beyond simple traffic filtering into intelligent detection and unified investigation workflows. Azure Firewall's Intrusion Detection and Prevention capabilities continue to evolve to meet the needs of modern security operations teams facing advanced lateral movement, exploitation attempts, and command-and-control activity. In this webinar, we will explore how Azure Firewall identifies malicious network patterns in real time, how detection signals flow seamlessly into Microsoft Sentinel to enrich the broader security narrative, and how security teams can correlate firewall intelligence with other data sources to accelerate threat hunting, streamline incident response, and build a more connected and actionable view of their network security posture.

What's New in Azure Bastion

Date and time: Thursday, July 23, 2026, at 8am PST

View event details and join

Secure remote access to cloud workloads remains a critical requirement as organizations scale their Azure environments and adapt to evolving operational demands. Azure Bastion continues to evolve to meet the needs of modern infrastructure teams seeking seamless, browser-based connectivity without exposing virtual machines to the public internet. In this webinar, we'll explore the latest enhancements to Azure Bastion covering new capabilities that improve connectivity options, streamline the administrative experience, expand protocol and session support, and strengthen the overall security posture of remote access workflows. Whether you're managing a handful of VMs or operating at enterprise scale, this session will bring you up to speed on what's new and how these improvements can simplify and secure your day-to-day operations.

What's New in Azure Firewall

Date and time: Thursday, August 6, 2026, at 8am PST

View event details and join

As network architectures grow more distributed and threat landscapes more dynamic, organizations need a cloud-native firewall that keeps pace with both modern workload patterns and adversary techniques. Azure Firewall continues to evolve to meet the needs of network and security teams managing hybrid environments, multi-region deployments, and increasingly complex east-west and north-south traffic flows. In this webinar, we will explore the latest enhancements to Azure Firewall covering new policy and rule management capabilities, improvements that expand protocol and traffic inspection coverage, and deeper integrations across the Azure security ecosystem to streamline operations. Whether you are standardizing perimeter protection across a global Azure footprint or modernizing segmentation for business-critical workloads, this session will bring you up to speed on what is new and how these improvements can simplify and strengthen your day-to-day network security operations.

What's New in Azure Web Application Firewall

Date and time: Thursday, August 27, 2026, at 8am PST

View event details and join

Web applications remain primary entry points for attackers, and organizations need a Web Application Firewall that adapts as quickly as the threats targeting their workloads. Azure Web Application Firewall continues to evolve to meet the needs of modern application security teams defending against an expanding mix of OWASP-class attacks, automated abuse, and business logic threats across diverse hosting models. In this webinar, we will explore the latest enhancements to Azure WAF. We will cover new detection and rule capabilities that improve protection accuracy, tuning and exclusion improvements that reduce false positives without weakening coverage, and expanded visibility and analytics that accelerate investigation. Whether you are securing customer-facing web apps or managing WAF policies at scale, this session will bring you up to speed on what's new and how these improvements can simplify and strengthen your application protection strategy

Past Recordings:

View additional past webinars from Azure Network Security on Microsoft Security Community YouTube.

Stay connected with the Azure Network Security community

Influence product feedback and join the Threat Protection Advisors Program

Stay up-to-date and follow the Azure Network Security Blog | Microsoft Community Hub

Engage with peers, ask and answer questions in the Azure Network Security discussion board

Learn and Engage with the Microsoft Security Community

Log in and follow this Microsoft Security Community Blog and post/ interact in the Microsoft Security Community discussion spaces.

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..

Learn about the Microsoft MVP Program.

Join the Microsoft Security Community LinkedIn and the Microsoft Entra Community LinkedIn

Ask Microsoft Anything: Microsoft Defender expands protection to AWS RDS

Trevor_Rusher — Tue, 09 Jun 2026 16:19:01 GMT

Hey all! We are currently answering questions over on the event page here:

https://aka.ms/DefenderAWSExpansionAMA

Come join and learn something about Defender for Cloud and the expansion of protection!

Elevate your telemetry using custom data collection in Microsoft Defender

Theo_Cohen — Tue, 09 Jun 2026 16:00:00 GMT

At Ignite in November, we announced that Microsoft Defender is now the only endpoint protection solution that allows data-hungry security teams to meet specific telemetry needs by optimizing their data collection right within the Defender portal, without the need to rely on fragmented and siloed solutions. Since then, we've heard from customers that this tool has been a game changer, enabling them to hunt through new data types as well as richer data on events already reported. The release of custom data collection was a key milestone in our ongoing journey to make Defender easy to manage and customize.

Security teams have been asking for guidance and examples of how to get the most out of the tool, so today we're sharing how some organizations can use custom data collection and dynamic tagging to detect command and control (C2) communications, giving defenders elevated visibility and deeper telemetry into attacker activity across the environment.

See the data you want to see

Defender's default telemetry is tuned to balance performance and signal-to-noise across millions of devices, so it focuses on the events most useful for high-fidelity detection at fleet scale, but many organizations want richer, more granular signals for deeper hunting, compliance, or auditing purposes. Custom data collection lets you go beyond what Defender already captures without ever leaving the Defender portal. Easily build custom collection rules based on your organization’s specific needs using natural language; no PhD required! It includes several highly requested data types, including AMSI for hunting over script content, and Kerberos for hunting auth-based and network attacks.

This truly integrated custom data offering is possible thanks to Microsoft’s platform approach, as the additional telemetry can be collected and analyzed via Defender and stored via Microsoft Sentinel. It puts you in complete control of any customized, add-on data, including exactly which data types are collected and how long they are stored. No other security solution has fully integrated and customizable telemetry collection and analysis.

Example custom telemetry scenario: detecting C2 communications

Many organizations have a set of assets that require special attention, like internet-facing servers, domain controllers, and other high-value endpoints where deeper telemetry can make the difference between catching an intrusion early and discovering it after the damage is done.

Imagine your organization has received threat intelligence on attacks using stealthy C2 frameworks: HTTPS beacons with jittered intervals, DNS-based data exchange, and persistence via scheduled tasks and registry modifications. You want richer visibility into those internet-facing servers and high-value endpoints so you can hunt for these patterns proactively, instead of reconstructing them after the fact.

Dynamic tags scope these high-value devices into a targeted group, and custom data collection captures the extra process, network, and registry events from them, giving analysts the telemetry they need to hunt for beaconing, suspicious DNS patterns, and persistence before attackers establish a foothold.

To detect C2 communications using dynamic tagging, follow these steps:

Step 1: Tag your devices

Custom Data Collection rules are scoped to dynamic tags; once set, those tags are automatically applied and removed based on conditions you define. Configure them in Settings > Microsoft Defender XDR > Asset Rule Management.

Tag	Rule name	Conditions	Tag to apply
Internet-facing servers	InternetFacing-Servers	Internet facing = true AND OS platform equals Windows Server 2022	C2-Watchlist
Devices under active investigation	HighSev-Investigation	Manual tag equals UnderInvestigation	HighSev-Verbose

Bringing manual tags into the dynamic model

Custom data collection is built around dynamic tags by design: one leading, unified tagging experience that's more flexible and customizable. Dynamic tags can be driven by device properties, group membership, OS, or by existing manual tags, so anything your team already tags manually flows naturally into custom data collection through a simple Asset Rule Management rule, exactly as Tag 2 above does.

In this example, analysts manually tag a device UnderInvestigation during incident response. The dynamic rule picks up that manual tag and applies HighSev-Verbose, which custom data collection rules can target. The analyst doesn't need to know about dynamic tags they tag the device the way they always have, and custom data collection activates automatically.

Step 2: Build your collection rules

Navigate to Settings > Endpoints > Rules > Custom Data Collection. Select your Microsoft Sentinel workspace in the top-right corner.

Before creating rules, confirm you meet every prerequisite in the custom data collection documentation , in particular, your tenant must be onboarded to the Unified Security Operations Platform (USOP).

Rule 1: Outbound network connections from high-risk processes

Capture connections from processes commonly abused by C2 frameworks living-off-the-land binaries and scripting engines.

Setting	Value
Rule name	C2-OutboundConnections
Table	DeviceCustomNetworkEvents
Action	Connection Success
Condition	InitiatingProcessFileName Equals: powershell.exe, rundll32.exe, regsvr32.exe, mshta.exe, certutil.exe, msiexec.exe
Scope	Devices tagged C2-Watchlist

Rule 2: DNS query activity

Many C2 frameworks use DNS for beaconing or data exchange. Default telemetry captures limited DNS data. This rule collects all DNS queries from monitored devices.

Setting	Value
Rule name	C2-DNSActivity
Table	DeviceCustomNetworkEvents
Action	Connection Success
Condition	RemotePort equals 53
Scope	Devices tagged C2-Watchlist

Rule 3: Persistence mechanisms

C2 implants establish persistence via scheduled tasks, registry run keys, or services. Capture process creation events for common persistence tools.

Setting	Value
Rule name	C2-Persistence
Table	DeviceCustomProcessEvents
Action	Process Created
Condition	FileName in (schtasks.exe, reg.exe, sc.exe, at.exe)
Scope	Devices tagged C2-Watchlist

Rule 4: Full process and script telemetry during investigations

When a device gets the HighSev-Verbose tag, collect everything.

Setting	Value
Rule name	HighSev-AllProcesses
Table	DeviceCustomProcessEvents
Action	Process Created
Condition	Broad (all process creation events)
Scope	Devices tagged HighSev-Verbose

Setting	Value
Rule name	HighSev-ScriptCapture
Table	DeviceCustomScriptEvents
Action	Script execution
Condition	Broad (all script events) – add a condition which is always true such as FileName not equals “”
Scope	Devices tagged HighSev-Verbose

Collection profiles summary

Tag	Rules active	What gets collected	Use case
C2-Watch list	OutboundConnections, DNSActivity, Persistence	Network connections from, DNS queries, persistence tool usage, DLL sideloading	Persistent C2 monitoring
HighSev-Verbose	AllProcesses, ScriptCapture	Every process creation, all script execution	Full-depth incident response

Important: when you remove the HighSev-Verbose tag after closing an incident, collection automatically drops back to baseline, no manual rule cleanup needed. This is what makes verbose collection safe to leave configured: it's only active while the tag is.

Step 3: Hunt

Rules deploy within 20 minutes to an hour. Query the data in AH directly.

Detect beaconing patterns processes making regular-interval outbound connections:

Find DNS queries to high-entropy domains (potential DGA):

Spot persistence being established:

Leverage the telemetry from your new collection rule into a Custom Detection so high-value findings raise alerts automatically, instead of waiting for the next manual hunt.

Custom data collection effectively extends your endpoint protection into a targeted, general-purpose log collector, one that's now ready to serve advanced hunting, custom detections, and auditing or regulatory use cases, while default fleet-wide telemetry stays tuned for performance and signal-to-noise. By combining dynamic tagging with purpose-built collection rules, your highest-risk devices are always streaming the signals that matter most, ready for detection and investigation before and during an incident.

Learn more

To learn more about endpoint protection with Microsoft Defender, check out our website.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
To learn more about custom data collection and how to get started, see our documentation.

Exempt a specific container in MDC

ABhatia610 — Tue, 09 Jun 2026 15:25:11 GMT

I have this recommendation showing in defender.

Immutable (read-only) root filesystem should be enforced for containers

There are multiple containers inside AKS that are showing as "Unhealthy"

airflow/db1
airflow/sql1
airflow/scheduler1

Is there a way to exempt a specific container or the whole recommendation has to be exempted.

Thanks

Detecting AI agents and non-human identities in Microsoft Sentinel: the classic-agent blind spot

Marcel_Graewer — Tue, 09 Jun 2026 13:57:23 GMT

Build 2026 made the direction official. The industry is moving from the app era into the agent era, and Microsoft spent a real share of the keynote on securing agents across their lifecycle, from discovering what is exploitable to governing what is running in production. On the identity side the centerpiece is Microsoft Entra Agent ID, now generally available, which gives AI agents first-class identities and extends Conditional Access, Identity Protection, and full audit logging to them.

That is good news for agents you build the new way. It is not the whole picture, and the gap is where most SOCs will get hurt first.

Modern agents are covered. Classic agents are not.

Entra Agent ID draws a hard line between two kinds of agent.

Modern agents are created through the Agent ID platform, each backed by an agent identity blueprint. They carry a proper Agent ID, a full audit trail, and the complete set of governance capabilities, including Identity Protection for Agents, which establishes a baseline for an agent's normal activity and flags anomalies automatically.

Classic agents are everything that came before, or that gets built outside the platform: AI agents implemented as ordinary service principals or app registrations, for example Copilot Studio agents created before Agent ID was enabled, or any home-grown automation calling Graph with client credentials. In the Entra agent registry they appear with "Has Agent ID: No," and that flag matters, because the Agent ID protections apply to identities that actually hold an Agent ID. Classic agents sit outside Identity Protection for Agents and Conditional Access for Agents.

Here is the uncomfortable part. The non-human identities you already run, the service principals behind your pipelines, your integrations, your scripts, your pre-platform Copilot Studio bots, are almost all classic agents. They tend to outnumber your human accounts, they have no MFA in any meaningful sense, and a credential added to one does not show up in the Azure portal. The new platform protections do not reach them. Until you migrate them, the only place you get detection coverage on that population is your SIEM.

So this is the job Sentinel does that Agent ID does not: detect risky behavior on the classic, service-principal-backed agents that the platform cannot yet protect.

The telemetry you have, and the one switch people forget

Three tables carry most of the signal.

AADServicePrincipalSignInLogs records service principal authentications, the client-credentials sign-ins your agents and automation use. No user, no MFA, just an app proving it holds a secret or certificate.

AADManagedIdentitySignInLogs does the same for managed identities.

AuditLogs records directory changes, including the one that matters most for persistence: a new credential added to an application or service principal.

One practical warning before any of this works. Service principal and managed identity sign-in logs are not streamed by default. You have to enable those categories explicitly in the Entra diagnostic settings feeding your workspace. Plenty of teams write the detection, never check, and never notice the table is empty. Verify that first.

Detection 1: a new credential on a service principal or app

Adding a secret or certificate to an existing service principal is one of the cleanest persistence techniques in a Microsoft cloud. The attacker compromises a privileged user or app, drops a fresh credential on a service principal that already holds useful Graph permissions, and now has access that survives password resets and session revocation. It maps to MITRE T1098.001, Account Manipulation: Additional Cloud Credentials. For a classic agent it is especially nasty, because there is no Identity Protection baseline watching it.

// Detection 1: new secret or certificate added to an application or service principal // MITRE T1098.001 - Account Manipulation: Additional Cloud Credentials AuditLogs | where OperationName has_any ("Add service principal", "Certificates and secrets management") | where Result =~ "success" | extend Initiator = coalesce( tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName)) | extend InitiatorIp = tostring(InitiatedBy.user.ipAddress) | mv-apply Target = TargetResources on ( where Target.type =~ "Application" | extend TargetName = tostring(Target.displayName), TargetId = tostring(Target.id), KeyChanges = Target.modifiedProperties ) | mv-apply Prop = KeyChanges on ( where tostring(Prop.displayName) =~ "KeyDescription" | extend NewKeys = parse_json(tostring(Prop.newValue)), OldKeys = parse_json(tostring(Prop.oldValue)) ) | extend AddedKeys = set_difference(NewKeys, OldKeys) | where array_length(AddedKeys) > 0 | project TimeGenerated, Initiator, InitiatorIp, TargetName, TargetId, AddedKeys | order by TimeGenerated desc

The operation filter catches the three shapes this event takes in the log: "Add service principal," "Add service principal credentials," and "Update application - Certificates and secrets management." The modifiedProperties parsing isolates the KeyDescription change, and set_difference confirms a key was actually added rather than removed, so rotating out an old credential does not, on its own, fire the rule.

False positives come from legitimate rotation and from automation that provisions app credentials (CI/CD, infrastructure as code). The initiator is the discriminant. A credential added by your deployment pipeline's service account at the usual time is routine. The same change initiated by an interactive admin out of hours, or by an account that never normally touches app credentials, is what you want to surface. Allow-list the expected initiators, not the targets.

Detection 2: a classic agent signing in from a first-seen IP

A service principal that has only ever authenticated from your Azure regions and suddenly signs in from somewhere new is a strong signal that its credential has been lifted and is being used elsewhere. Service principals have stable, boring network behavior, which makes a first-seen IP a far cleaner indicator for them than it is for roaming human users. This is the behavioral baseline Identity Protection gives you for free on modern agents, rebuilt in KQL for the classic ones it ignores. MITRE T1078.004, Valid Accounts: Cloud Accounts.

// Detection 2: classic-agent service principal signing in from a previously unseen IP // MITRE T1078.004 - Valid Accounts: Cloud Accounts let baseline = 14d; let detection = 1d; let KnownIPs = AADServicePrincipalSignInLogs | where TimeGenerated between (ago(baseline + detection) .. ago(detection)) | where tostring(ResultType) == "0" | summarize KnownIPSet = make_set(IPAddress) by AppId; AADServicePrincipalSignInLogs | where TimeGenerated > ago(detection) | where tostring(ResultType) == "0" | lookup kind=leftouter KnownIPs on AppId | where set_has_element(KnownIPSet, IPAddress) == false | summarize FirstSeen = min(TimeGenerated), Resources = make_set(ResourceDisplayName, 10) by ServicePrincipalName, AppId, IPAddress | order by FirstSeen desc

The query builds a per-application baseline of source IPs over the previous two weeks, then flags any successful sign-in today from an address outside that set. Two tuning notes. Brand-new service principals have no baseline, so they surface on first use. That is usually worth seeing once, but you can exclude AppIds younger than the baseline window if it gets noisy. And if your agents egress through shifting cloud IP ranges, widen the comparison from an exact IP to the autonomous system number or a known-range allow-list, otherwise you will chase your own infrastructure.

This complements Agent ID, it does not replace it!

The endgame is not to run these rules forever. It is to shrink the population they apply to. Inventory your tenant for agents marked "Has Agent ID: No," prioritize the ones holding sensitive Graph permissions, and migrate them onto the Agent ID platform, where Identity Protection and Conditional Access take over the baselining you are doing here by hand. Microsoft has signaled a migration path from classic to modern agents. Treat these two detections as the coverage you need in the meantime, and as a permanent safety net for anything that never makes the move.

If you do one thing this week: enable the service principal sign-in log category, deploy detection 1, and pull a list of every service principal that had a credential added in the last 90 days. That list alone tends to be more interesting than people expect.

Cheers, Marcel

Ways to fetch quarantine files

Dhwani_Shah — Tue, 09 Jun 2026 05:36:57 GMT

We are working with quarantine files and have a few questions:

1. Is there a public API available to retrieve quarantined files from Microsoft Defender for Endpoint?

2. Is there a documented method to map an alert or a file SHA-1/SHA-256 hash to the corresponding object in the Defender quarantine store?

3. Is there a way to retrieve quarantined files other than using a PowerShell script through the Live Response API?

Tools for Azure AD B2C migration now available

NamitaSingh — Mon, 08 Jun 2026 20:38:36 GMT

If you rely on Azure AD B2C for customer identity, you’re likely starting to evaluate what comes next. With Azure AD B2C no longer receiving new features and several features recently added to Microsoft Entra External ID, planning your migration is easier and can help you with this important next step in your identity strategy.

Below you’ll find tooling, guidance, and a partner ecosystem resource to help you migrate with confidence. This post walks through what’s available and how to get started.

What’s new: Platform updates and migration tooling

Microsoft has invested significantly in Microsoft Entra External ID to help Azure AD B2C customers migrate with confidence and ease. Over the past three months, several new features have reached general availability.

Azure AD B2C Migration tooling: Just-in-Time (JIT) migration, High-Scale Compatibility (HSC) mode, and the published Migration Guidance document and architecture blueprint.

Native authentication GA features in Entra External ID: Email and SMS one-time passcode (OTP) MFA, social identity providers via browser-delegated (web-view) flows, single sign-on (SSO) from native apps to web views, and refresh token transfer to Apple Watch.

Web and federated in Entra External ID: Sign-in and sign-up with alias, Microsoft Entra ID federation with External ID (public preview), and self-service password reset (SSPR) with phone SMS OTP.

For a complete list of recent platform updates, see the What’s new in Microsoft Entra blog.

Where Azure AD B2C stands today

Azure AD B2C has reached a significant milestone in its lifecycle. It has served as a reliable foundation for customer identity, and that doesn’t change for existing customers. What has changed is where Microsoft is investing going forward. Two facts define what that means for existing customers:

May 2025 — End of sale: New Azure AD B2C tenants can no longer be purchased. Existing tenants remain supported.
No new features: All platform innovation is now exclusive to Microsoft Entra External ID. Azure AD B2C will not receive new capabilities going forward.

Your existing Azure AD B2C environment continues to function. Starting your migration early helps you stay in control of sequencing, validation, and user experience. For questions about planning, contact support.

What is Microsoft Entra External ID?

Microsoft Entra External ID is a purpose-built, next-generation customer identity platform. It is not a rebrand of Azure AD B2C. It is a new foundation designed to simplify implementation, improve extensibility, and align with the broader Microsoft Entra ecosystem. Key platform improvements include the following.

Modern extensibility model — Custom authentication extensions replace complex custom policy XML, helping reduce implementation complexity.

Microsoft Entra ecosystem integration — Full alignment with Microsoft Entra ID, Conditional Access, Identity Governance, and Microsoft’s broader security stack.

Continuous platform innovation — Native Authentication SDKs, advanced branding controls, fraud protection, and passwordless-first flows are built exclusively into External ID.

Improved observability — Enhanced monitoring, diagnostics, and audit capabilities for identity and security teams.

Migration tooling

Two primary migration paths are available, and both are now generally available.

	Just-in-Time (JIT) Migration	High-Scale Compatibility (HSC) Mode
Status	Generally available	Generally available
Best for	Most customers seeking a clean cutover with minimal user disruption	High-scale environments (5M+ users) or complex architectural constraints
How it works	Migrates users progressively as they sign in — no bulk password reset required	Moves application traffic to External ID first
Key benefit	Full External ID feature parity from day one with minimal user impact	Supports parallel operation of B2C and External ID during transition, reducing cutover risk
Documentation	JIT Migration Documentation	HSC Mode Documentation

Choosing between JIT and HSC is less about technical capability and more about migration priorities. JIT prioritizes user experience and simplicity, while HSC prioritizes scale and operational continuity.

Alongside these tools, Microsoft has published a comprehensive migration guide and architecture blueprint covering end-to-end migration scenarios, credential migration approaches, and application sequencing guidance.

Partner ecosystem

For organizations with complex environments, migration is not just a technical exercise. It involves coordinating identity flows, applications, and user experiences across systems.

Microsoft has established a global ecosystem of qualified migration partners across EMEA, the Americas, LATAM, ANZ, and the Middle East.

Partner support includes:

Mapping custom policies to External ID equivalents
Designing credential migration strategies
Sequencing application cutovers
Running staged validation and testing
Supporting production deployment

Qualified partners meet criteria such as proven Azure AD B2C experience, active engagement with External ID, and participation in Microsoft migration readiness programs.

Examples include EY, Avanade, Edgile, Slalom, Plan B, WhoIAM, and Grit.

You can explore the full partner directory in the Migration partner directory.

Next steps: How to get started

The organizations that navigate migration most successfully are the ones that start planning early. Beginning now gives you greater control over sequencing, application transitions, and user experience changes before they become urgent. Migration challenges rarely come from the tooling itself; they come from coordination across systems, teams, and timelines.

A structured approach can help accelerate progress:

Assess

Inventory Applications, user populations, and custom policies
Understand dependencies and integrations
Inventory applications, user populations, and custom policies
Understand dependencies and integrations

Decide

Review migration guidance
Choose between JIT and HSC based on your priorities

Execute

Run a proof of concept in a non-production environment
Validate identity flows and user experience
Engage a qualified partner if needed
Align with your Microsoft account team

Migrating from Azure AD B2C to Microsoft Entra External ID is an opportunity to modernize your customer identity platform while reducing operational complexity. With the right planning, tooling, and support available today, you can move forward with confidence while maintaining a seamless experience for your users.

For additional support, contact support.

-Namita Singh - Senior Product Manager, Microsoft Entra External ID

-Pawan Nrisimha - Principal Manager of Product, Microsoft Entra External ID

-Isaac Christian - Product Marketing Manager, Microsoft Entra

Additional resources

Learn more about Microsoft Entra

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

Microsoft Entra ID security updates: What organizations need to do now

Swaroop Krishnamurthy — Mon, 08 Jun 2026 18:47:46 GMT

Microsoft Entra ID continues to strengthen identity security by modernizing how authentication and access policies are enforced. As part of this effort, Microsoft is retiring legacy capabilities and closing gaps that attackers could exploit. These updates focus on three key areas: replacing Custom controls with External MFA, enforcing Conditional Access consistently during credential registration, and requiring explicitly registered authentication methods for self-service password reset (SSPR). Together, these changes help ensure that your security policies are applied uniformly and backed by strong, user-verified signals.

Key points

Custom controls are being deprecated in favor of External MFA. Existing configurations keep working during the transition, but you should begin migration planning now. Custom controls retire September 30, 2026, and reach end of life in May 2027.
Conditional Access will be enforced consistently during credential registration. Starting July 6, 2026, policies targeting the Register security information action will also apply to Windows Hello for Business provisioning and macOS Platform Single Sign-on registration. Test policies in report-only mode before then.
SSPR will require explicitly registered authentication methods. A registration campaign begins July 6, 2026, and from September 7, 2026, SSPR will accept only registered methods — directory-sourced phone numbers and email addresses that were never formally registered will no longer be accepted.

Deprecation of Custom controls

What’s changing?

Microsoft Entra ID is deprecating Custom controls in favor of External MFA, a more integrated, standards-based capability for incorporating third-party MFA providers directly into Conditional Access. External MFA delivers deeper policy integration, a more seamless user experience, and greater flexibility than the legacy Custom controls model. While existing Custom controls configurations will continue to function during the transition period, organizations should begin planning their migration to External MFA.

When will you see this change?

Custom controls will be retired on September 30, 2026, and the service will reach end of life in May 2027.

Who will be affected by this change?

This update affects organizations currently using Custom controls to integrate third-party MFA providers with Conditional Access.

How will this affect your organization?

Organizations relying on Custom controls will need to transition to External MFA to maintain support and continue using third-party MFA solutions within Microsoft Entra ID. Moving to External MFA also enables more consistent Conditional Access enforcement and improved integration with Microsoft Entra security capabilities.

What do you need to do to prepare?

Organizations should:

Review existing Custom controls integrations
Evaluate External MFA migration requirements
Test Conditional Access policies and user experiences before migration
Begin migration planning ahead of the retirement date
Read more in the External MFA General Availability announcement and migration guidance.

Consistent Conditional Access enforcement for credential registration

What’s changing?

Microsoft is strengthening Conditional Access enforcement during credential registration flows to close a long-standing enforcement gap.

Today, policies targeting the Register security information user action are enforced in My Security Info and Microsoft Authenticator, but not during Windows Hello for Business provisioning or macOS Platform Single Sign-on registration. Conditional Access policies will be enforced consistently across these registration experiences. If users do not meet policy requirements, they will be prompted to satisfy those requirements before completing registration. MFA will continue to be required by default for passwordless credential enrollment, with Conditional Access providing an additional layer of control.

When will you see this change?

This update will roll out during the week of July 6, 2026 to all tenants.

Who will be affected by this change?

This change affects organizations using:

Conditional Access policies scoped to registration flows
Windows Hello for Business
macOS Platform Single Sign-on
Passwordless credential enrollment scenarios

How will this affect your organization?

Organizations may see additional prompts or enforcement steps during device setup and credential registration if users do not meet Conditional Access requirements. This change ensures registration flows are governed by the same security controls already applied across other authentication experiences.

What do you need to do to prepare?

Organizations should review existing registration policies and validate that users can meet Conditional Access requirements during onboarding and device setup. Microsoft recommends testing policies in report-only mode before enforcement begins.

SSPR update: Registered authentication methods required

What’s changing?

Microsoft is updating Microsoft Entra self-service password reset (SSPR) so that only explicitly registered authentication methods can be used for verification. Directory-sourced phone numbers or email addresses stored only as user object properties—but never formally registered as authentication methods—will no longer be accepted. This change aligns SSPR with Entra ID’s broader authentication model by requiring verification methods tied to user intent and proof of possession.

When will you see this change?

Beginning July 6, 2026, Microsoft will deploy an SSPR registration campaign that prompts affected administrators and end users to register authentication methods ahead of enforcement. No administrator action is required to enable this campaign.

Starting September 7, 2026, SSPR will accept only authentication methods that users or administrators have explicitly registered.

Who will be affected by this change?

This update affects organizations and users that still rely on unregistered directory-based phone numbers or email addresses for password reset verification.

How will this affect your organization?

Users without registered authentication methods may experience interruptions during password reset or account recovery flows after enforcement begins. Organizations may also see an increase in registration prompts during the transition period.

What do you need to do to prepare?

Organizations should:

Review authentication method registration coverage
Identify users relying on unregistered directory values
Encourage users to register approved authentication methods
Communicate upcoming changes to users and help desk teams

Microsoft will prompt affected users and administrators during the transition period to help organizations prepare before enforcement begins.

Now is the time to review your current configurations, identify where these changes apply in your environment, and begin preparing your users and admins before enforcement milestones arrive. Start by assessing any Custom controls dependencies, validating registration-related Conditional Access policies, and confirming that authentication methods used for SSPR are explicitly registered.

- Swaroop Krishnamurthy, Principal Product Manager

Additional resources

External MFA in Microsoft Entra ID (general availability announcement)

Learn more about Microsoft Entra

Microsoft Defender now monitors RPC activity

EdanZwick — Tue, 09 Jun 2026 16:55:28 GMT

Remote procedure call (RPC) is a protocol commonly abused by attackers that allows functions implemented in a separate process, and potentially on a remote machine, to be called as if they were local. Many core Windows and Active Directory capabilities are built on or make use of RPC, which makes it an attractive target. To help protect against remote RPC-based attacks, Microsoft Defender now monitors remote RPC calls, disrupts malicious activity that leverages them, and surfaces relevant telemetry in advanced hunting.

RPC basics

While RPC is a rich and complicated protocol, the main components that are relevant for security monitoring purposes are:

Interface: A logical grouping of functionality exposed by an RPC server. Interfaces are identified by UUID. Example interfaces include Task Scheduler, Remote Registry, and the Service Control Manager, each exposing functionality related to a different Windows OS component.
OpNum: Stands for Operation Number, an ordinal that denotes a specific function exposed by an RPC interface. Examples include RCreateServiceW (OpNum 12, Service Control Manager interface) and BaseRegQueryValue (OpNum 17, Remote Registry interface).

Many remote attack techniques and tactics are based on RPC, for example:

Lateral movement: often abuses RPC functionality for remotely creating tasks, services or invoking WMI.
Credential theft: DCsync attacks, which abuse privileged compromised accounts to remotely extract credential material from Active Directory, are based on RPC functionality for directory replication. SecretsDump and similar attacks, which remotely extract SAM or LSA secrets, are based on querying a device’s registry remotely, using RPC.
Privilege escalation: Multiple authentication coercion attacks abuse benign RPC interfaces to coerce servers to authenticate an attacker.
Discovery: Tools such as SharpHound leverage RPC calls to enumerate users, sessions and shares.

For a more comprehensive mapping of RPC interfaces to attack techniques, see work by Jonathan Johnson.

RPC auditing in Defender

Since RPC is so heavily used on Windows systems and in Active Directory domains, monitoring remote RPC traffic using network monitors is often expensive and infeasible. Additionally, if the underlying transport protocol is encrypted (such as SMB3), it might be impossible to observe RPC traffic.

To enable efficient auditing of remote RPC activity regardless of transport-layer protection, Defender research and engineering expanded the existing RPC integration with the Windows Filtering Platform (WFP) to support OpNum-level granularity. This makes it possible to identify and audit the specific RPC function being invoked, rather than only the RPC interface.

This capability is designed to help detect remote RPC-based attack techniques, where an attacker interacts with RPC interfaces exposed by a target device. For that reason, Defender focuses this monitoring on inbound remote RPC calls observed on the RPC server host. The telemetry is collected using audit-only WFP filters, which do not interfere with normal traffic, while still providing visibility into suspicious remote activity targeting the device. This approach does not require visibility into the source device.

Local RPC calls, such as inter-process communication on the same device over local transport, and outbound RPC client calls are outside the scope of this monitoring mechanism.

Using this capability, Defender monitors selected RPC calls, leverages the resulting telemetry to detect malicious activity, and exposes monitored calls in advanced hunting. Defender dynamically monitors selected remote operations from interfaces including, but not limited to: Remote Registry, Service Control Manager, Task Scheduler, and Windows Management Instrumentation (WMI). RPC monitoring for workstations is generally available, while server monitoring is currently in gradual rollout.

RPC-based detections and disruption triggers are already available in Defender and include detections such as:

Ongoing hands-on-keyboard attack via Impacket toolkit
Suspicious service creation initiated remotely
Indication of local security authority secrets theft
Unusual RPC user and session discovery
Authentication coercion attack

Example Advanced Hunting queries

1. Remote registry key save events, abused for remote credential dumping.

let remoteRegistryInterface = '338cd001-2244-31f1-aaaa-900038001003'; let registrySaveOpnums = dynamic([20, 31]); // BaseRegSaveKey, BaseRegSaveKeyEx DeviceEvents | where ActionType == 'InboundRemoteRpcCall' | extend AdditionalFields = parse_json(AdditionalFields) | extend RpcInterface = tostring(AdditionalFields.RpcInterfaceUuid), OpNum = toint(AdditionalFields.RpcOpNum) | where RpcInterface == remoteRegistryInterface and OpNum in(registrySaveOpnums)

2. Remote Service Creation events, could indicate lateral movement:

let remoteServicesInterface = '367abb81-9844-35f1-ad32-98f038001003'; let serviceCreationOpnums = dynamic([12, 24, 44, 45, 60]); // RCreateServiceW, RCreateServiceA, RCreateServiceWOW64A, RCreateServiceWOW64W, RCreateWowService DeviceEvents | where ActionType == 'InboundRemoteRpcCall' | extend AdditionalFields = parse_json(AdditionalFields) | extend RpcInterface = tostring(AdditionalFields.RpcInterfaceUuid), OpNum = toint(AdditionalFields.RpcOpNum) | where RpcInterface == remoteServicesInterface and OpNum in(serviceCreationOpnums)

3. Session discovery events, could indicate account discovery:

let srvsvcInterface = '4b324fc8-1670-01d3-1278-5a47bf6ee188'; let netrSessionEnumOpnum = 12; DeviceEvents | where ActionType == 'InboundRemoteRpcCall' | extend AdditionalFields = parse_json(AdditionalFields) | extend RpcInterface = tostring(AdditionalFields.RpcInterfaceUuid), OpNum = toint(AdditionalFields.RpcOpNum) | where RpcInterface == srvsvcInterface and OpNum == netrSessionEnumOpnum | summarize dcount(DeviceId) by AccountName, AccountDomain, AccountSid

Check out the advanced hunting tab to see monitored RPC activity in your environment and stay tuned for more updates from Defender.

Learn more

To learn more about endpoint protection with Microsoft Defender, check out our website.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

Security Review for Microsoft Edge version 149

Rick_Munck — Mon, 08 Jun 2026 11:32:08 GMT

We have reviewed the new settings in Microsoft Edge version 149 and determined that there are no additional security settings that require enforcement. The Microsoft Edge version 139 security baseline continues to be our recommended configuration which can be downloaded from the Microsoft Security Compliance Toolkit.

Microsoft Edge version 149 introduced 7 new Computer and User settings; we have included a spreadsheet listing the new settings to make it easier for you to find.

As a friendly reminder, all available settings for Microsoft Edge are documented here, and all available settings for Microsoft Edge Update are documented here.

Please continue to give us feedback through the Security Baselines Discussion site or this post.

The Worm in the Supply Chain: How Defender for Endpoint and Sentinel for SAP BTP Caught Shai-Hulud

MartinPankraz — Mon, 08 Jun 2026 10:52:16 GMT

On 29 April 2026, malicious versions of multiple SAP ecosystem npm packages were briefly published, creating a supply-chain exposure for SAP Cloud Application Programming (CAP) development environments and CI/CD pipelines.

For a brief window that morning, affected developers have executed a credential-stealing payload on a workstation or, in higher-impact cases, within a CI/CD pipeline.

SAP developers don't usually think of themselves as a juicy npm target. CAP, BTP, Fiori - that's enterprise turf, not crypto-stealer type territory – Until it is. Join me for the ride.

See our latest click-video for an even more dynamic experience of SAP compromises.

Affected packages and scope

Four official npm packages from the SAP development ecosystem were published in malicious versions that day. Security researchers are calling the campaign "Mini Shai-Hulud" - the little cousin of the worm family that has been chewing its way through open-source registries for months. So, the "mini" part is a generous description in my opinion.

Shai-Hulud has wriggled directly into the SAP supply chain, and that detail alone deserves a pause... SAP CAP is now interesting enough to have become a target.

Four packages, all wearing legitimate SAP branding, all quietly swapped for evil twins:

@cap-js/sqlite v2.2.2 @cap-js/postgres v2.2.2 @cap-js/db-service v2.10.1 mbt v1.2.48

These packages are not peripheral dependencies. The @cap-js/* modules are part of the SAP CAP Model used across custom development on SAP BTP, while mbt is the Cloud MTA Build Tool commonly embedded in CI/CD workflows that package and deploy Multi-Target Applications to BTP and on-premises environments. At roughly 930,000 weekly downloads, the combined exposure created meaningful downstream attack surface.

The good news: SAP spotted the compromise fast, yanked the bad versions, and shipped clean replacements. The official guidance lives in SAP Security Note 3747787 - which carries the list of indicators of compromise, file hashes, and mitigation steps.

Enough theory and evidence talk! Now, SHOW ME the detection!

When the worm stirs beneath the sand, weak defenses vanish first.

Observed telemetry in Microsoft Security products

See below excerpt of Microsoft Defender for Endpoint from a compromised developer machine. The worm was neutralized immediately. Check the detection time (same day of release):

Windows Defender AV detected malware ToString: DefenderDetection: File: /Users/User***/Projects/dara-api-manager-ui/node_modules/mbt/File***.js, Sha256: *** [Trojan:JS/SPchnStlr.BB], BlockingStatus: Prevented, BlockingStatusPriority: 900 DetectionTime: 2026-04-29 11:52:11Z DetectorName: Microsoft.Cyber.ObservationDetectors.DefenderConcreteDetector Observations (2): DefenderObservation Description: Defender detected and quarantined 'Trojan:JS/SPchnStlr.BB' in file 'File***.js' ThreatCategory = Trojan, ThreatFamily = SPchnStlr,

How the Threat Actors Operationalized the Stolen Data

The compromise allowed harvesting GitHub tokens, AWS/Azure/GCP secrets, npm credentials, Kubernetes config, SSH keys, .npmrc and .git-credentials files, and CI/CD environment variables.

The hackers created a public GitHub repository on the victim’s own account, tagged with the description “A Mini Shai-Hulud has Appeared“ to exfiltrate their reaping. Within hours, more than a thousand such repositories were visible in public GitHub search.

For additional views on the topic check out the blogs of our Sentinel for SAP partners: Onapsis, Pathlock, and SecurityBridge.

Containment and Impact Reduction

If you were not as lucky as the developer using Defender for Endpoint and VS Code, you need end to end monitoring of your landscape in and around SAP. Once the worm is loose with cloud tokens it may appear in various unexpected places.

Microsoft Sentinel Solution for SAP covers your ERP crown jewels, your SAP BTP landscape and allows informed correlation with the rest of your IT estate. Microsoft’s correlation engine:

ensures traceability
automatic attack disruption and
just-in-time hardening of potential attack paths.

Developers using the cloud-based IDE SAP Business Application Studio are out of reach by Defender for Endpoint but profit from threat monitoring through Sentinel for SAP BTP integrating SAP BTP’s malware scanner the same way.

See this in action in this click-video and in below screenshot.

SOC analysts get actionable insights and tailored guidance from Security Copilot once SAP BTP signals are added to the Microsoft incident graph - no matter where the threat involving SAP originates from.

Getting Started with Sentinel Solution for SAP

Rollout of Sentinel for SAP BTP can happen immediately. Learn more from our deployment guide. Check out the security content reference for more info out-of-the-box detections.

Sentinel for SAP which covers your ERP solutions and more, requires configuration of SAP Integration Suite as intermediary step. Learn more from our deployment guide. Check out the security content reference for more info out-of-the-box detections

Final Words

This incident illustrates how far the SAP BTP attack surface now extends and why patching alone is insufficient once malicious code reaches developer tooling and build infrastructure. Effective defense also requires telemetry, correlation, and response coverage across SAP and non-SAP environments.

See you out there folks!

#Kudos to Mahesh Mandva and Cameron Gardiner on riding shai-holud with me.

Feel free to reach out to talk more about SAP Cyber Security.

Cheers, Martin

Useful Links

MSSP migration to Unified portal: how are you sequencing your customer portfolio?

AnthonyPorter — Mon, 08 Jun 2026 01:13:15 GMT

Following the automation and SOAR discussion, I wanted to open a conversation specifically focused on the MSSP and multi-tenant side of the migration, because this is where the coordination challenges are an order of magnitude higher than the technical ones.

A few things I am working through before writing this up as Part 5 of the migration series.

On Workspace Manager: Microsoft's own documentation now points you away from Workspace Manager at the point of onboarding to the Defender portal, directing you to Microsoft Defender multitenant management instead. For MSSPs who built their operating model around Workspace Manager, this is a significant structural change. For those implementing now, the recommendation is to go straight to the multitenant portal. I am interested in what the transition has looked like in practice for teams who were mid-flight on Workspace Manager when this became clear.

On access delegation: one of the more honest framings I want to include in the article is around the GDAP plus Unified RBAC gap. A Microsoft employee confirmed in the RSAC 2026 thread that Unified RBAC support for GDAP in the Defender portal is on the roadmap with no firm date. MSSPs choosing between Entra B2B and the governance relationships model today are making an architectural call that is difficult to reverse. I want to present this accurately, and real experience from practitioners will sharpen that framing.

On the connector deployment constraint: you cannot deploy connectors from a managed workspace configured with Azure Lighthouse alone, you also need GDAP. This makes a layered delegation architecture, Lighthouse plus GDAP plus B2B or governance relationships, necessary rather than optional. I am curious whether MSSPs are already running this layered model or whether most are still trying to make Lighthouse work as a single mechanism.

On migration sequencing: the question I want to ask specifically is how teams are structuring their customer portfolio migration. Are you running waves based on customer complexity, based on contract renewal timing, based on customer risk appetite, or some other factor? And when something goes wrong in one tenant's migration, how are you containing the impact on the rest of the programme?

Sharing the full article once it is written. Happy to discuss anything above in more detail in the thread.

Enhancements to Device Status API & Logged-In User Email in Endpoint DLP

Harysh9 — Fri, 05 Jun 2026 19:34:11 GMT

1. The Real‑World Problem Endpoint DLP analyst Faced (What Was Missing Earlier)

Before the introduction of the Device Status API enhancements and logged‑in user visibility, Endpoint DLP teams consistently struggled in below discussed areas:

Device Visibility Was Fragmented and Manual - Customers repeatedly told us:

We know some devices are unhealthy, but we don’t know who owns them.
We export the onboarding table to Excel every week just to understand drift.
By the time we detect a policy issue, the user is already blocked or impacted.

In practice, this meant:

Device onboarding views were static snapshots, not operationally actionable.
Admins relied on manual Excel exports to track onboarding, drift, and health.
Reporting pipelines were brittle and always out of date.

2. Device Status API: Why Customers Asked for This (Beyond “Reporting”)

The Hidden Cost of Excel‑Driven Operations as earlier, customers had to:

Export device onboarding data manually.
Rebuild dashboards every time they needed updated insight.
Repeat this process weekly or even daily for compliance and SOC reviews.

This approach failed at scale and created blind spots during incidents. When a device policy sync failed or appeared unhealthy, admins had no real‑time, view to answer basic questions like:

Is this device configured correctly?
Is the OS or Defender version lagging?
Is the issue widespread or isolated?

3. What the Improvement Unlocks (New Operational Reality)

From Static Views to Continuous Monitoring with the Device Status API:

Device health, configuration status, policy sync state, OS version, and Defender version become query able signals
Customers can power custom reporting and Advanced Hunting queries that are always current
SOC and Endpoint teams finally share a single source of device truth

This fundamentally changes how customers monitor Endpoint DLP not as a setup task, but as a living control plane. The Device Status API directly addresses this gap by making device‑level status continuously available through Advanced Hunting, allowing customers to build living dashboards instead of static reports.

4. The Old Workflow (Customer Pain)

Historically, when a device showed:

Policy Sync Failed
Unhealthy
Configuration mismatch

Admins had to:

Leave the Purview console
Open Microsoft Defender for Endpoint or Intune
Correlate device IDs or names
Identify the user
Start remediation

This context‑switching cost time, accuracy, and confidence.

5. The New Reality: User Context Where It Matters

Admins can now see who is logged in directly on the device onboarding page, aligning Windows with the macOS experience like:

Immediate user context during device issues.
Faster outreach and remediation.
One unified investigative surface.

What used to require three portals and multiple teams now happens in One Place.

6. When Customers Actually Needed This Data (But Didn’t Have It)

This improvement wasn’t driven by curiosity it was driven by failure points in production. Some of the common customer scenarios listed below:

Scenario	Before	Now / After Improvement
Scenario 1: Quarterly Compliance Reviews	Teams exported Excel files days before audits, resulting in stale data. Auditors questioned the reliability of reports.	Advanced Hunting queries power live compliance dashboards. Reports are defensible because the data is always current.
Scenario 2: Incident Post‑Mortems	Teams struggled to answer whether devices were healthy at the time of the incident or if policies were enforced versus just configured. Reviews relied on assumptions.	Device status, policy sync state, and OS/Defender versions are query able facts. Incident reviews shift from guesswork to evidence‑based analysis.
Scenario 3: Silent Policy Drift	Devices drifted due to OS updates, sensor lag, or configuration changes. Issues surfaced only after a DLP violation occurred.	Policy drift becomes detectable before enforcement failures. Endpoint DLP acts as a reliability signal rather than a last‑line alarm.

7. New enhancement on Device Status API

Device status API provides admins with access to device level information to integrate onboarded device information to custom reporting or use in advanced hunting queries.
It has helped admins track down users associated with devices instead reaching out to Entra, on-premises Active Directory, or Intune team.
During troubleshooting, if a device is not receiving policies on time, the device API allows quick identification of the device owner and assists in enabling always-on diagnostics or collecting logs directly from the device via Purview console.

8. Steps to capture User UPN

Admin can find the device status by login to Security.microsoft.com as security admin. Click on Investigation and responses > Hunting > Advanced hunting.
Device data can be found under DLPInfo JSON Column in the Deviceinfo table

3. Once we run above or any custom query as per requirement, you would see below as response.

4. Click on the loggedonuser field and expand the right-side information and look for DLPUPN under inspect record.

9. User login details on the Purview onboarding page

Admins now can see who is currently logged in on the device onboarding page. This update aligns the Windows experience with macOS, allowing admins to respond quickly if necessary.
In the past, when a device displayed a "Policy Sync Failed" or "Unhealthy" status, it was necessary to switch to Microsoft Defender for Endpoint (MDE) or Intune to identify the affected user. With this update, all relevant information is now accessible in a single view, streamlining the process.

Benefits -

Admins gain faster confirmation of device ownership and user context without extra investigation.
It simplifies troubleshooting onboarding or policy issues by surfacing the user alongside other device insights like status and IP.
No impact on users or DLP policies occurs, and it's enabled by default with no action required.

10.Steps to find User UPN on Purview admin console

Final Takeaway: Why This Matters More Than It First Appears

"These enhancements evolve Endpoint DLP from a static, deployment‑centric control into a continuously observable, user‑context aware security signal, significantly reducing investigation time, operational overhead, and trust gaps at scale"

Extend Microsoft Purview data protection to AWS Bedrock agents for cross-cloud AI governance

Inwafula — Tue, 09 Jun 2026 21:17:12 GMT

Organizations are moving fast with AI, and many of those AI workloads are not staying in one cloud. A team might use Microsoft 365 and Microsoft Purview for governance and in addition to Microsoft Foundry they may still choose to run an AI agent on AWS Bedrock or on the Google Cloud Platform. The technical challenge is straightforward: how do you keep one consistent set of data security, governance, and compliance controls when the agent itself runs outside Microsoft Azure?

This is where Microsoft Purview becomes the central policy engine for your data estate. In this post, we show why that matters and then walk through a practical example: an expense approval agent running on Amazon Bedrock, protected by Microsoft Purview Data Loss Prevention (DLP) policies.

Fig 1. AWS console page showing "ExpenseApprovalAgent" details of the Agent blade

Why Purview should be the central policy engine

Most organizations do not want separate policy stacks for every cloud, every model endpoint, and every app team. That leads to duplicated controls, inconsistent enforcement, and audit gaps. The better model is to separate where workloads run from where policy decisions are made.

That is the value proposition for Microsoft Purview in cross-cloud AI scenarios.

Purview gives you:

A consistent policy layer for sensitive information types such as credit card numbers, Social Security numbers, financial data, and other regulated content.
A governance plane that can extend beyond Microsoft-hosted workloads into multi-cloud environments.
A compliance framework with auditability, policy traceability, and a familiar operational model for security and compliance teams.
A way to apply data-aware controls to AI interactions, not just to storage locations.

In practical terms, that means the same organization that already trusts Purview to govern Exchange, SharePoint, Teams, and Copilot can use Purview to govern prompts and responses in a Bedrock-based agent as well.

The key architectural shift is this: your app does not need to invent its own data policy engine. It can call Purview at the points where risk exists.

What this Bedrock agent demonstrates

The sample solution in this blog is a cross-cloud AI pattern:

The frontend is a single-page browser-based chat app.
Users authenticate with Microsoft Entra ID via MSAL.
The backend runs in AWS Lambda.
The model is Amazon Bedrock using Nova 2 Lite.
Microsoft Purview evaluates prompts and model responses for DLP policy violations.

This matters because it proves a broader point: Microsoft Purview can govern AI interactions even when the model and compute are not running in Azure.

The core architecture

Fig. 2 Architectural overview of the solution

As shown above the end-to-end flow follows this pattern:

A user signs in through Microsoft Entra ID from the frontend.
The frontend sends the user's access token and prompt to an API endpoint in AWS.
The Lambda function exchanges that token using the On-Behalf-Of flow so Purview can evaluate under the signed-in user's identity.
Purview scans the full prompt for sensitive information before the model is called.
If the prompt is allowed, the Lambda function sends the request to Amazon Bedrock.
Purview scans the model response before it is returned to the user.
The frontend shows the result along with a Purview evaluation badge.

That gives you two strong governance controls:

In-line data loss prevention enforcement, which can block risky requests before they ever reach the model.
Response-time enforcement, which can stop sensitive data from being returned even if a model generates it.

The implementation also uses the user's identity for policy evaluation. That is important because governance decisions should reflect who is asking, not just what application is running.

Why this pattern is useful for security, governance, and compliance teams

There are three reasons this pattern is worth paying attention to.

First, it aligns policy with risk rather than with hosting location. The compute might run in Lambda and the model might be in Bedrock, but Purview still remains the policy decision point.
Second, it improves operational clarity. Security teams do not have to learn a different governance toolchain for each AI stack. They can keep using Purview concepts, policy models, and audit workflows.
Third, it supports real-world adoption. Most large enterprises are hybrid and multi-cloud already. A governance pattern that only works for one vendor's runtime is not enough.

Policy definition in Purview

Two polices are needed to enforce DLP-a collection policy for Enterprise AI Apps and a DLP policy

Collection policy

2. DLP policy

Follow the steps outlined here to create the DLP policy for Enterprise AI Apps. Sample provided: purview-api-samples/DLPforCustomAIApps at main · microsoft/purview-api-samples

To replicate this scenario, follow this link to the official GitHub repo: purview-api-samples/AWSBedrock at main · microsoft/purview-api-samples

Once deployed, you will have:

An AWS Lambda function that calls Amazon Bedrock.
A browser frontend that authenticates with Microsoft Entra ID.
Microsoft Purview evaluating both prompts and responses.
A demo flow where safe prompts succeed and sensitive prompts are blocked.

With the App and agent deployed, now comes the moment when the architectural value becomes clear. The model runtime is AWS Bedrock, but the policy decision is still coming from Microsoft Purview. Below screenshot shows the prompt containing sensitive information being blocked based on the policy evaluation by Purview.

Minimal code integration requirements using the SDK

Below is the code needed to perform the integration between Purview and Bedrock to perform the in and outbound inspection of content destined to and from the Bedrock model.

Results of Purview’s verdict presented to user in the App UI

Review governance evidence in Purview Data Security Posture Management

Summary

The bigger story here is not just that Microsoft Purview can protect an Amazon Bedrock agent. It is that organizations can centralize data security, governance, and compliance policy even while their AI architecture becomes more distributed across multiple clouds.

That is the operational win. Developers keep the freedom to choose the best runtime and model platform. Security and compliance teams keep a central policy engine they already understand and trust. AI applications can be multi-cloud, but your data protection model does not have to be fragmented.

Additional resources

Configure Microsoft Purview - purview-sdk | Microsoft Learn

Microsoft Purview Developer Platform Documentation - purview-sdk | Microsoft Learn

Operational Notes on Microsoft Security Copilot Agents in Defender XDR and Microsoft Entra ID

klianos — Fri, 05 Jun 2026 09:31:28 GMT

Microsoft Security Copilot is now becoming more visible inside day-to-day security operations, especially through embedded experiences and agent-based workflows across Microsoft Defender XDR, Microsoft Entra ID, Microsoft Intune, and Microsoft Purview.

Instead of looking at Security Copilot only as a standalone prompt interface, SOC and identity teams should also understand how Security Copilot agents are deployed, how they consume Security Compute Units, how they appear in operational workflows, and where activity can be monitored.

This post summarizes practical observations from a security operations perspective, with a focus on Microsoft Defender XDR, Microsoft Entra ID, usage monitoring, and KQL-based activity review.

Licensing & Capacity Units

Requirements

Requires eligible Microsoft security licensing, typically:
- Microsoft 365 E5
- Microsoft 365 E7

Security Compute Units (SCUs)

Security Copilot capacity is measured using Security Compute Units (SCUs).
SCUs are billed based on provisioned capacity.
Indicative pricing:
- $4 per Provisionied SCU/hour
- $6 per Overage SCU/hour
Billing is calculated hourly, based on the amount of SCUs provisioned.

Included Capacity

Organizations with:
- 1,000 Microsoft 365 E5 licenses
Receive:
- 400 included SCUs
Included SCUs are shared across the tenant within a common capacity pool.

Scaling

SCU capacity can be scaled dynamically based on operational requirements and workload demand.

Data Retention

Security Copilot session and interaction data without active SCU-backed retention is typically retained for:
- 90 days

Security Copilot Agents - Microsoft Defender

This section outlines the Microsoft Security Copilot agents currently available in the Microsoft Defender portal.

NameKey characteristics Security Alert Triage Agent (Preview)

Manual setup from Defender portal
Automatically creates Unified RBAC custom role
Runs automatically when a user reports a suspicious email or when a new supported alert is generated, supported alert sources: MDI, MDC, MDO
If an alert tuning rule is enabled, it will be automatically disabled when the agent is deployed.
Creates and connects with agentic user account: Phishing Triage Agent (Security Copilot)
Automatic alert assignment to SecurityCopilotAgentUser-db16fec3-f1fb-4632-843e-46d07408c584@<tenant-domain>Alert was assigned to Phishing Triage Agent (Security Copilot).
Adds Tag Agent to the created Incidents

Threat Hunting Agent

Manual setup from Defender portal
Automatically creates Unified RBAC custom role
This agent runs manually. There isn't an automatic trigger.
Creates and connects with agentic user account: Threat Hunting Agent (Security Copilot)
Analyst Questions in natural language
Generates and executed KQL queries in Advanced hunting
Provides charts, dynamic follow-up questions and remediation actions recommendations
No activity is identified from agent's identity during agent execution

Threat Intelligence Briefing Agent

Manual setup from Defender portal
Provides automated TI briefing summary
Configured from https://security.microsoft.com/securitysettings/defender/agent_configuration-threatintelligencebriefingagent

Security Analyst Agent

Manual setup from Defender portal

Dynamic Threat Detection Agent (Preview)

Automatically enabled
always-on, runs continuously in the background
Correlates: Alerts, Security events, Behavioral anomalies, TI signals
Generates Alerts with Detection Source: Security Copilot
The Alerts can be correlated with existing Multi-Stage Incidents
No agentic user account identity is used by this agent
Available free of charge during public preview, will begin consuming Security Compute Units (SCUs) once generally available (GA)

Incidents handled by Security Alert Triage Agent:

Alerts created by Dynamic Threat Detection Agent:

Execution of Threat Hunting Agent:

View agents in use: https://security.microsoft.com/security-copilot/agents

View Unified RBAC custom roles: https://security.microsoft.com/mtp_roles

View Security Copilot user identities in Microsoft Entra ID:

Notes:

CloudAppEvents activity logs only from the following agents:

Phishing Triage Agent
Conditional Access Optimization Agent

Security Copilot Agents - Microsoft Entra ID

Conditional Access Optimization Agent

Usage Monitoring

Sign-in to Security Copilot portal using Global Admin account and navigate to the following location: https://securitycopilot.microsoft.com/usage-monitoring

Reference: https://learn.microsoft.com/en-us/copilot/security/manage-usage

Logging Activity

Copilot Agents Management:

CloudAppEvents

| where ActionType contains "CopilotAgent"

| extend AgentName = RawEventData.AgentName

| extend Workload = RawEventData.Workload

| extend ResultStatus = RawEventData.ResultStatus

| project TimeGenerated, ActionType, ResultStatus, AgentName, Application, Workload

All Copilot Workload data:

CloudAppEvents

| extend Workload = RawEventData.Workload

| where Workload == "Copilot"

| summarize EventCount = count() by ActionType, AccountDisplayName

Microsoft Defender for Cloud Customer Newsletter

Yura_Lee — Thu, 04 Jun 2026 18:30:12 GMT

What's new in Defender for Cloud?

Defender for Cloud is now integrated into the Defender portal to bring together cloud security posture management and threat protection in a single experience. Read more about it here.

Cloud security reporting in the Defender portal is now in public preview

Customers can now create, customize, and share security insights across the organization through Defender portal’s integrated cloud security reporting capabilities. With these reporting capabilities, customers can view built-in reports like CNAPP Executive Summary, create custom reports, export to PDF and more. For more details, please refer to this documentation.

Check out other updates from last month here!

Check out monthly news for the rest of the MTP suite here!

Blog(s) of the month

In May, our team published the following blog posts we would like to share:

Defender for Cloud in the field

Check out the two short videos on Defender Portal integration and Start Secure Stay Secure with Defender for Cloud

GitHub Community

Check out this PS script and CLI to help you enable Defender for API at scale:

Customer journey

Discover how other organizations successfully use Microsoft Defender for Cloud to protect their cloud workloads. This month we are featuring Loyens & Loeff, a law and tax firm, that operates in a high complex environment, sought to modernize the digital workplace with Microsoft 365 Copilot, Defender for Cloud and Purview.

Join our community!

We offer several customer connection programs within our private communities. By signing up, you can help us shape our products through activities such as reviewing product roadmaps, participating in co-design, previewing features, and staying up-to-date with announcements. Sign up at aka.ms/JoinCCP.

We greatly value your input on the types of content that enhance your understanding of our security products. Your insights are crucial in guiding the development of our future public content. We aim to deliver material that not only educates but also resonates with your daily security challenges. Whether it’s through in-depth live webinars, real-world case studies, comprehensive best practice guides through blogs, or the latest product updates, we want to ensure our content meets your needs. Please submit your feedback on which of these formats do you find most beneficial and are there any specific topics you’re interested in https://aka.ms/PublicContentFeedback.

Note: If you want to stay current with Defender for Cloud and receive updates in your inbox, please consider subscribing to our monthly newsletter: https://aka.ms/MDCNewsSubscribe

Run Global Secure Access with confidence: Introducing the GSA Operations Guide

tdetzner — Fri, 05 Jun 2026 18:04:21 GMT

In working with customers, I’ve seen the same pattern again and again: deployment gets the attention, but day 2 operations are where teams need the most structure. This guide is meant to make that part easier—with practical guidance teams can use right away.

TL;DR: Your day 2 playbook is here

What’s new? A prescriptive Microsoft Entra Global Secure Access operations guide on Microsoft Learn
Why it matters: It brings actionable, alert-first procedures for teams running Global Secure Access after deployment
What’s inside: A role matrix, automated health checks, capability-specific guides, templates, and automation scripts
Start here: Microsoft Entra Global Secure Access operations guide

The day 2 gap

Deploying Global Secure Access (GSA) is only the beginning. Day 2 challenges raise questions like:
Who monitors what? When do checks happen? How do we know everything is healthy?

The deployment guide covers rollout, and the product documentation explains configuration. But until now, there was no single resource that explained how to operate Global Secure Access in production. Customers, FastTrack, and partners built their own runbooks—and rebuilt them for each deployment.

That ends today.

Announcing the Operations Guide

The Microsoft Entra Global Secure Access operations guide is now live on Microsoft Learn.

This post-deployment playbook delivers prescriptive guidance for running Global Secure Access in production at scale. It was created by the Global Secure Access customer experience engineering team with input from Thomas Detzner, Janice Ricketts, Jeff Bley, Luis Flores, Marilee Turscak, Peter Lenzke, Mohammad Zmaili, and Ken Withe.

Who this guide empowers

This guide is for the teams that keep Global Secure Access running every day: IT administrators, network engineers, and platform operations teams that need clear answers to questions like “Who owns what?” and “How do we prevent issues before they happen?”

It also equips security leaders with structured reporting so they can demonstrate value and service health to executives. If you’re responsible for Global Secure Access performance, alerting, or automation, this is your new reference playbook. (And if you haven’t deployed yet, start with the deployment guide.)

What you’ll gain from this guide

Shared practices that work across any environment

Know your roles early: A RACI matrix so responsibilities never overlap

Manage change with confidence: A GSA-tailored change-control framework for smooth updates
Prove success with clarity: Reporting templates for operators, managers, and executives
Adopt continuous improvement: Built-in processes to spot gaps before they become issues

Capability-specific playbooks structured for speed

Every workload (Private Access, Internet Access, Remote Networks, Microsoft Traffic) follows one clear pattern so teams always know what comes next:
✔ Begin with alert-first monitoring steps that catch issues early
✔ Follow daily, weekly, monthly routines for health maintenance
✔ Automate critical workflows with Sentinel, Graph API, and PowerShell scripts
✔ Track and tune KPIs using measured baselines
✔ Diagnose and resolve quickly with symptom-to-fix troubleshooting

Don’t start from zero—use the templates

Daily health check across all GSA capabilities

Ready-made change request forms and notification playbooks
Modular checklists ready for your ITSM process

Why this guide is different

Unlike generic environment monitoring advice, this guide delivers concrete, tested procedures built from field experience. It applies an alert-first approach so teams can act on signals from Microsoft Sentinel and Azure Monitor before dashboards show trouble.

Each alert comes with an action—nothing is left unanswered. Automation is embedded throughout, including role-based access control (RBAC) hygiene checks and failover tests. Because operations demand clarity, the guide also provides measurable thresholds, baseline methods, and recovery steps that reduce noise and reinforce uptime.

Six moves to launch operational maturity

Assign roles using the RACI matrix for full coverage

Configure critical alerts before adding custom workflows
Collect 30 days of baseline data before adjusting thresholds
Automate backups and priority alert notifications early
Schedule routine checks using provided templates
Begin structured reporting starting with weekly operations and monthly management reviews

Why it matters for customers and partners

This framework reduces time to readiness after deployment, documents a defensible Day 2 plan for audits, cuts escalations by linking every alert to a clear action path, and gives FastTrack and partners a baseline for consistency in engagements.

Next up

Soon we will publish the GSA Security Operations Guide for Microsoft Entra Global Secure Access, providing a dedicated security monitoring and detection companion to the operational guides for Private Access, Internet Access, Remote Networks, and Microsoft traffic. It brings together the built-in alerts, log sources, Sentinel detections, and cross-signal investigation patterns that security teams need to identify suspicious activity and unauthorized changes across the GSA environment.

If deployment is still ahead, start with the GSA Deployment Guide.

Your move

Open the full guide
Download templates and run your first daily health check today
Post feedback and ideas to help shape future updates

-Thomas Detzner

Thomas Detzner | LinkedIn

Additional resources

Learn more about Microsoft Entra

No way to automate restoring user‑reported emails after “no threats found”

GT_deb — Thu, 04 Jun 2026 17:30:51 GMT

When a user reports an email as phishing in Defender, the message gets moved to Deleted Items. After we triage it, if we mark it as “no threats found,” there’s no way to push it back to the user’s inbox as part of that workflow.

That creates a bit of a broken experience:

User is told the email is safe with our customized email response, but has to go find it themselves
In a lot of cases they don’t (Outlook search won’t find it)
We end up with follow‑ups like “where did it go?”

Technically we could restore the email as part of our triage process, but that just shifts the effort onto the SOC. It doesn’t scale, and it’s not really the right place for that work. We have tried to create an automation to do this, but we have not been able to create an advanced hunting query based on our triage result that can then trigger an action to restore it to the mailbox.

So we end up choosing between:

Users having a bad experience, or
Analysts doing manual mailbox work

Neither is ideal.

Other platforms (like Proofpoint) handle this end‑to‑end — once something is confirmed clean, it can be returned to the user automatically.

Right now Defender stops at classification instead of completing the workflow.

Is there a reason this isn’t wired in, or anything on the roadmap to address it?

Prompted to sign in to Microsoft Defender Platform on W11/W2025 using Entra

chrisnelmes — Thu, 04 Jun 2026 12:40:24 GMT

Hi Microsoft Defender XDR community,

Since around May 18th, our users on devices that are onboarded to Microsoft Defender for Endpoint are being prompted to sign-in to the following application using Entra on login to Windows.

Application

Microsoft Defender Platform

Application ID

cab96880-db5b-4e15-90a7-f3f1d62ffe39

Is anyone aware of a change that requires user sign-in to Entra as a requirement for Microsoft Defender for Endpoint? I have tried raising a support topic on this topic.

Regards

Chris

June 4 - Secure Boot AMA

Heather_Poulsen — Wed, 03 Jun 2026 17:23:06 GMT

Microsoft is updating the Secure Boot certificates originally issued in 2011 to ensure Windows devices continue to verify trusted boot software. These older certificates begin expiring in June 2026. Devices that haven’t received the newer 2023 certificates will continue to start and operate normally, and standard Windows updates will continue to install. However, these devices will no longer be able to receive new security protections for the early boot process, including updates to Windows Boot Manager, Secure Boot databases, revocation lists, or mitigations for newly discovered boot level vulnerabilities.

Whether you are already working through Secure Boot certificate updates across your estate, or aren't sure where to start, you can get answers to your questions and helpful insights at the next Secure Boot AMA on 8:00 a.m. PDT June 4, 2026. Can't attend live? No problem. Post your questions in advance.

Visit https://aka.ms/AMA/SecureBoot to save the date and post your questions.

For detailed, step-by-step guidance, see the following resources: