Recent Blogs
Security teams face a constant tension: run the advanced analytics you need to stay ahead of threats, or hold back to keep costs predictable. Until now, Microsoft Sentinel let you set alerts to get n...
Apr 15, 2026
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, ...
Apr 15, 2026
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 Securi...
Apr 15, 2026
6 MIN READ
Cybersecurity has always been an asymmetric game. But with the rise of AI‑enabled attacks, that imbalance has widened dramatically.
Microsoft Threat Intelligence and Microsoft Defender Security Res...
Apr 15, 2026Recent Discussions
Purview Integration during Merger and Acquisitions
a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; } Hello, We are currently in the process of merging with two other organizations and are looking to integrate our Microsoft Purview environments. All three organizations have different sensitivity labeling schemes, and we would like guidance on the best approach to achieve a unified labeling strategy across the merged organization. Specifically, should we create a new, common set of sensitivity labels for the combined organization and plan a phased transition for users? One of the organizations already has the majority of its documents labeled, so maintaining those existing labels during the merger is a key concern. We are also looking for best practices to ensure that existing labels are preserved when the two additional organizations are onboarded into Purview, while still moving toward a consistent, unified labeling framework. Any suggestions or if any one had already been a part of such a merger, please share your experiencePurview DLP Behaviours in SharePoint and OneDrive
We are currently testing Microsoft Purview DLP policies for user awareness across SharePoint Online, and OneDrive. The policy is configured such that sensitive information (based on a sensitivity label-OFFICIAL Sensitive) shared externally triggers a policy tip, with override allowed (justification options enabled) and no blocking action configured. In SharePoint Online and OneDrive, users are not experiencing any DLP-related behaviour. When attempting to share labelled content externally: No policy tips are displayed No override prompts are presented No indication of DLP enforcement is shown Users are able to share content externally without any awareness prompt or restriction. Expected behaviour: Users should receive a policy tip during the sharing process Users should be prompted for justification when overriding, aligned with the DLP configuration Has anyone observed similar behaviour with DLP in SharePoint Online and OneDrive, particularly in scenarios where no blocking action is configured? Keen to understand if this is expected behaviour, a known limitation, or if there are any configuration considerations or workarounds to achieve a consistent user experience across workloads.Purview DLP Behaviours in Outlook Desktop
We are currently testing Microsoft Purview DLP policies for user awareness, where sensitive information shared externally triggers a policy tip, with override allowed (justification options enabled) and no blocking action configured. We are observing the following behaviours in Outlook Desktop: Inconsistent policy tip display (across Outlook Desktop Windows clients) – For some users, the policy tip renders correctly, while for others it appears with duplicated/stacked lines of text. This is occurring across users with similar configurations. Override without justification – Users are able to click “Send Anyway/Confirm and send” without selecting any justification option (e.g. business justification, manager approval, etc.), which bypasses the intended control. New Outlook: Classic Outlook: This has been observed on Outlook Desktop (Microsoft 365 Apps), including: Version 2602 (Build 19725.20170 Click-to-Run) Version 2602 (Build 16.0.19725.20126 MSO) Has anyone experienced similar behaviour with DLP policy tips or override enforcement in Outlook Desktop? Keen to understand if this is a known issue or if there are any recommended fixes or workarounds.Microsoft Sentinel MCP Entity Analyzer: Explainable risk analysis for URLs and identities
What makes this release important is not just that it adds another AI feature to Sentinel. It changes the implementation model for enrichment and triage. Instead of building and maintaining a chain of custom playbooks, KQL lookups, threat intel checks, and entity correlation logic, SOC teams can call a single analyzer that returns a reasoned verdict and supporting evidence. Microsoft positions the analyzer as available through Sentinel MCP server connections for agent platforms and through Logic Apps for SOAR workflows, which makes it useful both for interactive investigations and for automated response pipelines. Why this matters First, it formalizes Entity Analyzer as a production feature rather than a preview experiment. Second, it introduces a real cost model, which means organizations now need to govern usage instead of treating it as a free enrichment helper. Third, Microsoft’s documentation is now detailed enough to support repeatable implementation patterns, including prerequisites, limits, required tables, Logic Apps deployment, and cost behavior. From a SOC engineering perspective, Entity Analyzer is interesting because it focuses on explainability. Microsoft describes the feature as generating clear, explainable verdicts for URLs and user identities by analyzing multiple modalities, including threat intelligence, prevalence, and organizational context. That is a much stronger operational model than simple point-enrichment because it aims to return an assessment that analysts can act on, not just more raw evidence What Entity Analyzer actually does The Entity Analyzer tools are described as AI-powered tools that analyze data in the Microsoft Sentinel data lake and provide a verdict plus detailed insights on URLs, domains, and user entities. Microsoft explicitly says these tools help eliminate the need for manual data collection and complex integrations usually required for investigation and enrichment hat positioning is important. In practice, many SOC teams have built enrichment playbooks that fetch sign-in history, query TI feeds, inspect click data, read watchlists, and collect relevant alerts. Those workflows work, but they create maintenance overhead and produce inconsistent analyst experiences. Entity Analyzer centralizes that reasoning layer. For user entities, Microsoft’s preview architecture explains that the analyzer retrieves sign-in logs, security alerts, behavior analytics, cloud app events, identity information, and Microsoft Threat Intelligence, then correlates those signals and applies AI-based reasoning to produce a verdict. Microsoft lists verdict examples such as Compromised, Suspicious activity found, and No evidence of compromise, and also warns that AI-generated content may be incorrect and should be checked for accuracy. That warning matters. The right way to think about Entity Analyzer is not “automatic truth,” but “high-value, explainable triage acceleration.” It should reduce analyst effort and improve consistency, while still fitting into human review and response policy. Under the hood: the implementation model Technically, Entity Analyzer is delivered through the Microsoft Sentinel MCP data exploration tool collection. Microsoft documents that entity analysis is asynchronous: you start analysis, receive an identifier, and then poll for results. The docs note that analysis may take a few minutes and that the retrieval step may need to be run more than once if the internal timeout is not enough for long operations. That design has two immediate implications for implementers. First, this is not a lightweight synchronous enrichment call you should drop carelessly into every automation branch. Second, any production workflow should include retry logic, timeouts, and concurrency controls. If you ignore that, you will create fragile playbooks and unnecessary SCU burn. The supported access path for the data exploration collection requires Microsoft Sentinel data lake and one of the supported MCP-capable platforms. Microsoft also states that access to the tools is supported for identities with at least Security Administrator, Security Operator, or Security Reader. The data exploration collection is hosted at the Sentinel MCP endpoint, and the same documentation notes additional Entity Analyzer roles related to Security Copilot usage. The prerequisite many teams will miss The most important prerequisite is easy to overlook: Microsoft Sentinel data lake is required. This is more than a licensing footnote. It directly affects data quality, analyzer usefulness, and rollout success. If your organization has not onboarded the right tables into the data lake, Entity Analyzer will either fail or return reduced-confidence output. For user analysis, the following tables are required to ensure accuracy: AlertEvidence, SigninLogs, CloudAppEvents, and IdentityInfo. also notes that IdentityInfo depends on Defender for Identity, Defender for Cloud Apps, or Defender for Endpoint P2 licensing. The analyzer works best with AADNonInteractiveUserSignInLogs and BehaviorAnalytics as well. For URL analysis, the analyzer works best with EmailUrlInfo, UrlClickEvents, ThreatIntelIndicators, Watchlist, and DeviceNetworkEvents. If those tables are missing, the analyzer returns a disclaimer identifying the missing sources A practical architecture view An incident, hunting workflow, or analyst identifies a high-interest URL or user. A Sentinel MCP client or Logic App calls Entity Analyzer. Entity Analyzer queries relevant Sentinel data lake sources and correlates the findings. AI reasoning produces a verdict, evidence narrative, and recommendations. The result is returned to the analyst, incident record, or automation workflow for next-step action. This model is especially valuable because it collapses a multi-query, multi-tool investigation pattern into a single explainable decisioning step. Where it fits in real Sentinel operations Entity Analyzer is not a replacement for analytics rules, UEBA, or threat intelligence. It is a force multiplier for them. For identity triage, it fits naturally after incidents triggered by sign-in anomaly detections, UEBA signals, or Defender alerts because it already consumes sign-in logs, cloud app events, and behavior analytics as core evidence sources. For URL triage, it complements phishing and click-investigation workflows because it uses TI, URL activity, watchlists, and device/network context. Implementation path 1: MCP clients and security agents Microsoft states that Entity Analyzer integrates with agents through Sentinel MCP server connections to first-party and third-party AI runtime platforms. In practice, this makes it attractive for analyst copilots, engineering-side investigation agents, and guided triage experiences The benefit of this model is speed. A security engineer or analyst can invoke the analyzer directly from an MCP-capable client without building a custom orchestration layer. The tradeoff is governance: once you make the tool widely accessible, you need a clear policy for who can run it, when it should be used, and how results are validated before action is taken. Implementation path 2: Logic Apps and SOAR playbooks For SOC teams, Logic Apps is likely the most immediately useful deployment model. Microsoft documents an entity analyzer action inside the Microsoft Sentinel MCP tools connector and provides the required parameters for adding it to an existing logic app. These include: Workspace ID Look Back Days Properties payload for either URL or User The documented payloads are straightforward: { "entityType": "Url", "url": "[URL]" } And { "entityType": "User", "userId": "[Microsoft Entra object ID or User Principal Name]" } Also states that the connector supports Microsoft Entra ID, service principals, and managed identities, and that the Logic App identity requires Security Reader to operate. This makes playbook integration a strong pattern for incident enrichment. A high-severity incident can trigger a playbook, extract entities, invoke Entity Analyzer, and post the verdict back to the incident as a comment or decision artifact. The concurrency lesson most people will learn the hard way Unusually direct guidance on concurrency: to avoid timeouts and threshold issues, turn on Concurrency control in Logic Apps loops and start with a degree of parallelism of . The data exploration doc repeats the same guidance, stating that running multiple instances at once can increase latency and recommending starting with a maximum of five concurrent analyses. This is a strong indicator that the correct implementation pattern is selective analysis, not blanket analysis. Do not analyze every entity in every incident. Analyze the entities that matter most: external URLs in phishing or delivery chains accounts tied to high-confidence alerts entities associated with high-severity or high-impact incidents suspicious users with multiple correlated signals That keeps latency, quota pressure, and SCU consumption under control. KQL still matters Entity Analyzer does not eliminate KQL. It changes where KQL adds value. Before running the analyzer, KQL is still useful for scoping and selecting the right entities. After the analyzer returns, KQL is useful for validation, deeper hunting, and building custom evidence views around the analyzer’s verdict. For example, a simple sign-in baseline for a target user: let TargetUpn = "email address removed for privacy reasons"; SigninLogs | where TimeGenerated between (ago(7d) .. now()) | where UserPrincipalName == TargetUpn | summarize Total=count(), Failures=countif(ResultType != "0"), Successes=countif(ResultType == "0"), DistinctIPs=dcount(IPAddress), Apps=make_set(AppDisplayName, 20) by bin(TimeGenerated, 1d) | order by TimeGenerated desc And a lightweight URL prevalence check: let TargetUrl = "omicron-obl.com"; UrlClickEvents | where TimeGenerated between (ago(7d) .. now()) | search TargetUrl | take 50 Cost, billing, and governance GA is where technical excitement meets budget reality. Microsoft’s Sentinel billing documentation says there is no extra cost for the MCP server interface itself. However, for Entity Analyzer, customers are charged for the SCUs used for AI reasoning and also for the KQL queries executed against the Microsoft Sentinel data lake. Microsoft further states that existing Security Copilot entitlements apply The April 2026 “What’s new” entry also explicitly says that starting April 1, 2026, customers are charged for the SCUs required when using Entity Analyzer. That means every rollout should include a governance plan: define who can invoke the analyzer decide when playbooks are allowed to call it monitor SCU consumption limit unnecessary repeat runs preserve results in incident records so you do not rerun the same analysis within a short period Microsoft’s MCP billing documentation also defines service limits: 200 total runs per hour, 500 total runs per day, and around 15 concurrent runs every five minutes, with analysis results available for one hour. Those are not just product limits. They are design requirements. Limitations you should state clearly The analyze_user_entity supports a maximum time window of seven days and only works for users with a Microsoft Entra object ID. On-premises Active Directory-only users are not supported for user analysis. Microsoft also says Entity Analyzer results expire after one hour and that the tool collection currently supports English prompts only. Recommended rollout pattern If I were implementing this in a production SOC, I would phase it like this: Start with a narrow set of high-value use cases, such as suspicious user identities and phishing-related URLs. Confirm that the required tables are present in the data lake. Deploy a Logic App enrichment pattern for incident-triggered analysis. Add concurrency control and retry logic. Persist returned verdicts into incident comments or case notes. Then review SCU usage and analyst value before expanding coverage.
MFA Options for Employees without Phones
Hello everbody, we're currently trying to implement MFA in our company, but approximately 1/10 of our employees have a workphone and are not allowed to use their personal phone. Since we also recently introduced Intune, the idea was to just use Windows Hello for Business, but when trying to provision it, we realized that you need to have MFA active for an account to be able to even activate it? Which kinda defeats the purpose. So my question is, is there some way to circumvent the MFA requirement for WHfB? Or what other options do we realistically have? Thanks in Advance!
DLP Policy - DSPM Block sensitive info from AI sites
Having issues with this DLP policy not being triggered to block specific SITs from being pasted into ChatGPT, Google Gemine, etc. Spent several hours troubleshooting this issue on Windows 11 VM running in Parallels Desktop. Testing was done in Edge. Troubleshooting\testing done: Built Endpoint DLP policy scoped to Devices and confirmed device is onboarded/visible in Activity Explorer. Created/edited DLP rule to remove sensitivity label dependency and use SIT-based conditions (Credit Card, ABA, SSN, etc.). Set Paste to supported browsers = Block and Upload to restricted cloud service domains = Block in the same rule. Configured Sensitive service domain restrictions and tested priority/order (moved policy/rule to top). Created Sensitive service domain group for AI sites; corrected entries to hostname + prefix wildcard a format (e.g., chatgpt.com + *.chatgpt.com) after wildcard/URL-format constraints were discovered. Validated Target domain = chatgpt.com in Activity Explorer for paste events. Tested multiple SIT payloads (credit card numbers with/without context) and confirmed detection occurs. Confirmed paste events consistently show: Policy = Default Policy, Rule = JIT Fallback Allow Rule, Other matches = 0, Enforcement = Allow (meaning configured rules are not matching the PastedToBrowser activity). Verified Upload enforcement works: “DLP rule matched” events show Block for file upload to ChatGPT/LLM site group—proves domain scoping and endpoint enforcement works for upload. Disabled JIT and retested; paste events still fall back to JIT Fallback Allow Rule with JIT triggered = false. Verified Defender platform prerequisites: AMServiceVersion (Antimalware Client) = 4.18.26020.6 (meets/exceeds requirements).Hybrid Join Lifecycle Model
Microsoft Entra hybrid join is still a common reality in enterprise environments. For many organizations, it remains necessary because legacy applications still rely on Active Directory machine authentication, Group Policy is still in use, and on-premises operational dependencies have not fully been retired. At the same time, the long-term direction for endpoint identity is increasingly cloud-native. That creates an important architectural question: Should hybrid join be treated as a permanent device state, or as a lifecycle stage in a broader modernization journey? In practice, hybrid join is often discussed as a binary condition: the device is either hybrid joined or it is not. But from an operational perspective, that view is too limited. In real enterprise environments, hybrid join behaves much more like a lifecycle. A device moves through provisioning, registration, trust establishment, management attachment, steady-state operation, recovery, retirement, and eventually transition. That distinction matters because most hybrid join issues do not fail loudly. They usually appear as stale objects, pending registrations, broken trust, inconsistent management ownership, and environments that remain temporarily hybrid far longer than intended. Why a lifecycle model is useful Treating hybrid join as a lifecycle helps explain why so many organizations struggle with it even when the initial implementation appears technically correct. The challenge is usually not the first successful join. The challenge is everything that happens around it: Provisioning quality Trust validation Management ownership Drift detection Stale object cleanup Exit criteria for transition to Entra join Without that lifecycle view, hybrid join often becomes a static design decision with no clear operational model behind it. The eight phases 1. Provisioning The lifecycle starts when the device is built, imaged, or provisioned. This stage is more important than it looks. If the device is provisioned from a contaminated image, or if cloning and snapshot practices are not handled carefully, later identity issues are often inherited rather than newly created. Provisioning should be treated as an identity-controlled event, not just an OS deployment task. 2. Registration The device becomes known to Microsoft Entra. This is where many environments confuse visibility with readiness. A device object may exist in the cloud, but that does not automatically mean the hybrid identity state is healthy or operationally usable. 3. Trust Establishment This is the point where hybrid join becomes real. A device should not be considered fully onboarded until both sides of trust are present and healthy. In operational terms, this means the device is not only registered, but also capable of supporting the expected sign-in and identity flows. 4. Management Attachment Once trust exists, governance becomes the next question. Many organizations still balance Group Policy, Configuration Manager, Intune, and legacy application dependencies at the same time. That is exactly why hybrid join often persists. But if management ownership is not clearly defined, organizations end up with overlapping policy planes, inconsistent control, and unclear accountability. 5. Operational Steady State Hybrid join does not stop at successful registration. The device must remain healthy over time, and that means monitoring trust health, registration state, token health, line-of-sight to required infrastructure, and management consistency. A device that was healthy once is not necessarily healthy now. 6. Recovery Every real environment eventually encounters drift. Pending states, broken trust, orphaned records, reimaged devices, and inconsistent registration scenarios should not be treated as unusual edge cases. They should be expected and handled with formal recovery playbooks. Recovery is not an exception to the lifecycle. It is part of the lifecycle. 7. Retirement Retirement is one of the weakest areas in many hybrid environments. Devices are replaced or decommissioned, but their identity records often remain behind. That leads to stale objects, inventory noise, and administrative confusion. A proper lifecycle model should include a controlled retirement sequence rather than ad hoc cleanup. 8. Transition This is the most important strategic phase. The key question is no longer whether a device can remain hybrid joined, but whether there is still a justified reason to keep it there. Hybrid join may still be necessary in many environments today, but in many cases it should be treated as transitional architecture rather than the target end state. Practical takeaway Looking at hybrid join as a lifecycle creates a more useful framework for architecture decisions, operational ownership, troubleshooting, directory hygiene, governance, and transition planning toward Microsoft Entra join. That is the real value of this model. It does not replace technical implementation guidance, but it helps organizations think more clearly about why hybrid join exists, how it should be operated, and when it should eventually be retired. Final thought Hybrid join is still relevant in many enterprise environments, but it should not automatically be treated as a default destination. In many cases, it works best when it is managed as a lifecycle-driven operating model with defined phases, controls, and exit criteria. That makes it easier to stabilize operations today, while also creating a clearer path toward a more cloud-native endpoint identity model tomorrow. Full article: https://www.modernendpoint.tech/hybrid-join-lifecycle-model
Endpoint DLP Collection Evidence on Devices
Hello team, I am trying to setup the feature collect evidence when endpoint DLP match. Official feature documentation: https://learn.microsoft.com/en-us/purview/dlp-copy-matched-items-learn https://learn.microsoft.com/en-us/purview/dlp-copy-matched-items-get-started unfortunately, it is not working as described in the official documentation, I opened ticket with Microsoft support and MIcrosoft Service Hub, Unfortunatetly, they don't know how to setup it, or they are unable to solve the issue. Support ticket: TrackingID#26040XXXXXXX9201 Service Hub ticket: https://support.serviceshub.microsoft.com/supportforbusiness/onboarding?origin=/supportforbusiness/create TrackingID#26040XXXXXXXX924 I follow the steps to configure: based on the Microsoft documentation, I should be able to see the evidence in Activity explorer or Purview DLP alert or Defender Alerts/Incidents.Advice required for temp / agency staff
Hi All I hope you are well. Anyway, I'm hoping someone can point me in the right direction. We have Android devices in Entra Shared Device Mode (Multi App) which any of our employees with a valid UPN can logon to. All good there. What we need is a solution for temporary or agency staff. This would be staff that could be called on at very short notice and may not stay around for long. For security and audit reasons, we'd rather not create "userless" accounts. Is there anything in Entra / Entra Shared Device Mode that can achieve this? Info greatly appreciated. SKVPN Integration not persistent
Hello, We tried to configure https://learn.microsoft.com/en-us/defender-for-identity/vpn-integration 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, SimonUnderstand Why a Service Principal Was Created in Your Entra Tenant
Are you a tenant admin or member of a security team in your organization and find yourself asking “Why was this service principal created in our tenant?” Historically, answering this required correlating audit logs with Microsoft Graph queries or going through long investigations. Microsoft Entra now introduces enhanced audit log properties that make it significantly easier to understand the origin and intent behind newly created service principals directly from tenant audit logs. These new improvements surface additional insights within the Add service principal activity under the ApplicationManagement category—helping administrators determine whether a service principal was provisioned automatically by Microsoft services, triggered by a purchased subscription, or explicitly created by user or application activity. What’s in it for me as an Admins or member of the Security Team When a service principal is created, new metadata is now captured within Microsoft Entra audit logs that enables faster root‑cause analysis. These properties help distinguish between Microsoft‑driven provisioning processes and tenant‑initiated actions, allowing teams to quickly assess whether an event is expected platform behavior or something requiring deeper investigation. For example, administrators can now: Identify provisioning initiated by Microsoft services versus internal users or automation. Determine which tenant subscription or service plan enabled just‑in‑time provisioning. Recognize provisioning linked to Azure resource onboarding or managed identities. Investigate service principal creation without relying on additional Graph lookups. By leveraging these enriched audit logs, security teams can streamline investigations into newly created enterprise applications and reduce manual dependency on downstream data sources. This ultimately improves visibility into application onboarding events and supports faster decision‑making when assessing potential risk or unexpected provisioning activity within the tenant. Learn more here- Understand why a service principal was created in your tenant - Microsoft Entra ID | Microsoft LearnPurview Graph API
Hello. I'm trying to find information on the Purview Graph API and it's endpoints. It looks like the endpoints aren't posted publicly and are listed within an admin console. Can someone help me with how to view the endpoints? Also, are the graph API endpoints capable of reading and creating assets into Purview?Leveraging Microsoft Graph to Automate Compliance Workflows MS Purview
Background Microsoft Purview provides organizations with capabilities to discover, classify, protect, and govern sensitive information across Microsoft 365 workloads. As organizations increasingly rely on Purview for compliance operations such as auditing, investigations, and regulatory response, there is a growing need to automate these processes beyond the Microsoft Purview portal. Microsoft exposes key compliance capabilities through Microsoft Graph APIs, enabling organizations to integrate Purview operations directly into automation workflows. The Microsoft Purview APIs in Microsoft Graph allow applications to align with data governance, security, and compliance policies defined within the Purview portal, helping ensure that applications handling sensitive information respect organizational controls. Automating eDiscovery Operations with Microsoft Graph The Microsoft Purview eDiscovery APIs available through Microsoft Graph enable organizations to automate repetitive compliance tasks and integrate with existing investigation or legal workflows. These APIs are intended to support litigation, investigation, and regulatory scenarios by allowing administrators to programmatically manage key eDiscovery components such as cases, custodians, searches, review sets, and exports. This capability allows organizations to move from manual portal‑based workflows toward repeatable, policy‑aligned processes integrated into automation platforms or downstream compliance tooling. Programmatic Access to Audit Logs Microsoft Purview Audit captures thousands of operations across Microsoft 365 services and retains them in the unified audit log for security investigations and compliance obligations. Through Microsoft Graph, administrators can now programmatically search and retrieve audit logs using the Purview Audit Search API. This API enables administrators and applications to query and retrieve relevant audit activity logs across workloads such as Exchange, Entra ID, OneDrive, SharePoint, and Intune, providing visibility into user activity and administrative operations performed across the organization. This provides a programmatic alternative to legacy PowerShell‑based audit search methods, improving reliability and enabling automation of compliance monitoring workflows. Supporting Policy‑Aware Applications Applications that integrate with Microsoft Purview APIs through Microsoft Graph can interpret and enforce compliance policies such as sensitivity labels or data loss prevention (DLP) rules. Microsoft documents that apps built using these APIs can prevent data misuse by aligning with compliance and security requirements defined within the organization’s governance framework. This integration also allows enterprise applications to respect sensitivity labels and policy‑driven controls, ensuring that interactions with organizational data remain compliant with regulatory requirements and internal governance policies. Conclusion Microsoft Purview governs organizational data through classification, retention, auditing, and investigation capabilities. Microsoft Graph provides the automation layer that allows these governance controls to be accessed programmatically. By integrating Microsoft Graph with Microsoft Purview APIs, organizations can automate eDiscovery workflows, retrieve audit logs programmatically, and ensure that applications interacting with sensitive data respect compliance policies defined within their Microsoft 365 environment. Learning Resources Use the Microsoft Purview eDiscovery API in Microsoft Graph Use Microsoft Purview APIs for eDiscovery Overview of Microsoft Purview APIs in Microsoft Graph Introducing the Microsoft Purview Audit Search Graph APIMicrosoft Entra Conditional Access Optimization Agent - Move from Static to Continuous Protection
Conditional Access has long been Microsoft Entra’s Zero Trust policy engine—powerful, flexible, and can easily go wrong with misconfiguration over time due to large volume of policies. As the no of tenants increase the no of new users and applications the new modern authentication methods are introduced continuously, and Conditional Access policies that once provided full coverage often drift into partial or inconsistent protection. This is an operational gap which introduces complexity and manageability challenges. The solution to this is utilizing Conditional Access Optimization Agent, an AI‑powered agent integrated with Microsoft Security Copilot that continuously evaluates Conditional Access coverage and recommends targeted improvements aligned to Microsoft Zero Trust best practices. In this article, Let us understand what problem the agent can solve, how it works, how it can be best utilized with the real‑world Entra Conditional Access strategy. The Problem is Conditional Access does not break loudly Most Conditional Access issues are not caused by incorrect syntax or outright failure. Instead, they emerge gradually due to the continuous changes into the enviornment. New users are created but not included in existing policies New SaaS or enterprise apps bypass baseline controls MFA policies exist, but exclusions expand silently Legacy authentication or device code flow remains enabled for edge cases Multiple overlapping policies grow difficult to reason about Although there are tools like What‑If, Insights & Reporting, and Gap Analyzer workbooks help, they all require manual review and interpretation. At enterprise scale with large no of users and applications, this becomes increasingly reactive rather than preventative. What is the Conditional Access Optimization Agent? The Conditional Access Optimization Agent is one of the Microsoft Entra agents built to operate autonomously using Security Copilot. Its purpose is to continuously answer a critical question. Are all users, applications, and agent identities protected by the right Conditional Access policies - right now? The agent analyzes your tenant and recommends the following. Creating new policies Updating existing policies Consolidating similar policies Reviewing unexpected policy behavior patterns All recommendations are reviewable and optional, with actions typically staged in Report‑Only mode before enforcement. How the agents actually works ? The agent operates in two distinct phases - First the Analysis and then Recommendation & remediation During the analysis phase it evaluates the following. Enabled Conditional Access policies User, application, and agent identity coverage Authentication methods and device‑based controls Recent sign‑in activity (24‑hour evaluation window) Redundant or near‑duplicate policies This phase identifies gaps, overlaps, and deviations from Microsoft’s learned best practices. The next and final phase of recommendation and remediation depends on the results from the finding. Based on this the agent can suggest the following. Enforcing MFA where coverage is missing Adding device compliance or app protection requirements Blocking legacy authentication and device code flow Consolidating policies that differ only by minor conditions Creating new policies in report‑only mode Some of offer one click remediation making it easy for the administrators to control and enforce the decisions more appropriately. What are its key capabilities ? Continuous coverage validation The agent continuously checks for new users and applications that fall outside existing Conditional Access policy scope - one of the most common real‑world gaps in Zero Trust deployments. Policy consolidation support Large environments often accumulate near‑duplicate policies over time. The agent analyzes similar policy pairs and proposes consolidation, reducing policy sprawl while preserving intent. Plain‑language explanations Each recommendation includes a clear rationale explaining why the suggestion exists and what risk it addresses, helping administrators validate changes rather than blindly accepting automation. Policy review reports (This feature is still in preview) The agent can generate policy review reports that highlight spikes or dips in enforcement behavior—often early indicators of misconfiguration or unintended impact Beyond classic MFA and device controls, One of the most important use case is the agent also supports passkey adoption campaigns (This feature is still in preview) . It can include the following. Assess user readiness Generate phased deployment plans Guide enforcement once prerequisites are met This makes the agent not only a corrective tool, but it is helpful as a migration and modernization assistant for building phishing‑resistant authentication strategies. Zero Trust strategies utilizing agents For a mature Zero Trust strategies, the agent provides continuous assurance that Conditional Access intent does not drift as identities and applications evolve. The use of Conditional Access Optimization Agent does not replace the architectural design or automatic policy enforcement instead it can be utilized to ensure continuous evaluation, early‑alarm system for any policy drift and can act as a force‑multiplier for identity teams managing change at scale. The object of agent usage is to help close the gap upfront between policy intent depending on the actual use, instead of waiting for the analysis to complete upon resolving incidents and post auditing. In this modernized era, the identity environments are dynamic by default. The Microsoft Entra Conditional Access Optimization Agent reflects a shift toward continuous validation and assisted governance, where policies are no longer assumed to be correct simply because they exist. For organizations already mature in Conditional Access, the agent offers operational resilience. For those still building, it provides guardrails that scale with complexity but without removing human accountability.
Security Copilot Clinic: AI‑Driven Agentic Defense for Healthcare
Healthcare security teams are operating under unprecedented pressure. Ransomware continues to target clinical environments, identity‑based attacks are increasing in sophistication, and the risk of PHI exposure remains a constant concern — all while SOC teams face chronic staffing shortages. Microsoft Security Copilot is now available for organizations using Microsoft 365 E5, bringing generative AI assistance directly into the security tools healthcare teams already rely on. This clinic series is designed to show how Security Copilot changes day‑one operations — turning noisy alerts into clear, actionable investigations and faster containment. Why attend this clinic For healthcare CISOs, SOC leaders, and security architects, Security Copilot represents more than an AI assistant — it’s a shift in how investigations are conducted across endpoint, identity, email, data, and cloud workloads. In this session, you’ll see how Security Copilot helps healthcare security teams: Move faster with confidence by summarizing complex evidence across security signals Reduce investigation fatigue by standardizing analyst workflows Communicate risk clearly by translating technical findings into leadership‑ready insights Protect patient data without adding new tools or headcount All examples and demonstrations are grounded in real healthcare security scenarios. What we’ll explore See the full incident picture in one place Microsoft‑built Security Copilot agents embedded across Defender, Entra, Intune, and Purview automatically correlate signals from endpoint, identity, email, data, and cloud applications into a single investigation view — eliminating manual pivoting between tools. Move from alert to action faster Embedded agents analyze related signals in real time and surface prioritized investigation paths along with recommended containment actions directly in the analyst workflow. Standardize investigations and reduce noise Agent‑driven prompts and investigation structure help standardize analyst response, reduce alert fatigue, and create repeatable workflows that scale in lean SOC environments. Protect PHI and communicate risk with confidence Security Copilot uses embedded data and threat intelligence to produce leadership‑ready summaries that clearly articulate potential PHI exposure, attack progression, and business impact. Session format and audience Format 60‑minute live session End‑to‑end demo Interactive Q&A Who should attend CISOs and Security Leaders SOC Managers and Analysts Security and Cloud Architects Clinical IT and Infrastructure Leaders Upcoming sessions Date Time (ET) Registration March 13, 2026 12:00 – 1:00 PM Session #1 March 20, 2026 12:00 – 1:00 PM Session #2 March 27, 2026 12:00 – 1:00 PM Session #3 Secure healthcare — together Security Copilot enables healthcare organizations to respond faster, investigate smarter, and communicate risk more effectively — all within the Microsoft security ecosystem teams already trust. If you’re evaluating how AI‑driven, agentic defense can support your healthcare SOC, this clinic will give you practical insight you can apply immediately.
Entra CBA Preview Bug: Issuer Scoping Policy fails group claim (AADSTS500191)
I am deploying a zero-trust, cloud-native Certificate-Based Authentication (CBA) architecture for a break-glass emergency access account in Microsoft Entra ID. I am intentionally bypassing Intune/MDM to prevent circular dependencies during an outage. The PKI is generated via OpenSSL (Offline Root CA -> Client Cert). The cryptography is flawless: - The OpenSSL chain verifies perfectly (openssl verify -CAfile...). - The Root SKI and Client AKI are a perfect 1:1 hex match. - The client cert EKU includes TLS Web Client Authentication. - The client cert SAN includes othername: UPN::[break-glass-UPN]. - The Root CA and CRL are uploaded to Entra and publicly accessible via Azure Blob Storage. The Issue: When I attempt to restrict the Root CA using the "Certificate issuer scoping policy (Preview)" targeted to a specific Security Group (e.g., sg_cba), the TLS handshake drops and Entra throws: Error: AADSTS500191: The certificate authority that issued your certificate has not been set up in the tenant. Troubleshooting Performed: 1. Group Architecture: Verified via Microsoft Graph that the user is a direct, static member of sg_cba (Security Enabled, non-dynamic, not nested). 2. Micro-Group Bypass: Created a brand-new cloud-only micro-group with only the break-glass user. Waited for replication. Same 500191 error. 3. The Control Test (Success): If I completely remove the Preview scoping policy and move the targeting to the Generally Available (GA) tenant-wide trust ("All Users"), the login succeeds immediately. (I am securing this via High-Affinity binding matching the SKI to CertificateUserIDs). The Ask: Because the tenant-wide GA policy works perfectly, it mathematically proves the certificates, CRL, and bindings are correct. The failure is entirely isolated to the Preview scoping engine failing to correlate the incoming certificate to the Security Group claim fast enough. - Has anyone successfully deployed the "Certificate issuer scoping policy (Preview)" using a targeted security group without it dropping the trust? - Are there undocumented constraints on group evaluation during the CBA TLS handshake that cause this Preview feature to fail closed?Sentinel to Defender Portal Migration - my 5 Gotchas to help you
The migration to the unified Defender portal is one of those transitions where the documentation covers "what's new" but glosses over what breaks on cutover day. Here are the gotchas that consistently catch teams off-guard, along with practical fixes. Gotcha 1: Automatic Connector Enablement When a Sentinel workspace connects to the Defender portal, Microsoft auto-enables certain connectors - often without clear notification. The most common surprises: Connector Auto-Enables? Impact Defender for Endpoint Yes EDR telemetry starts flowing, new alerts created Defender for Cloud Yes Additional incidents, potential ingestion cost increase Defender for Cloud Apps Conditional Depends on existing tenant config Azure AD Identity Protection No Stays in Sentinel workspace only Immediate action: Within 2 hours of connecting, navigate to Security.microsoft.com > Connectors & integrations > Data connectors and audit what auto-enabled. Compare against your pre-migration connector list and disable anything unplanned. Why this matters: Auto-enabled connectors can duplicate data sources - ingesting the same telemetry through both Sentinel and Defender connectors inflates Log Analytics costs by 20-40%. Gotcha 2: Incident Duplication The most disruptive surprise. The same incident appears twice: once from a Sentinel analytics rule, once from the Defender portal's auto-created incident creation rule. SOC teams get paged twice, deduplication breaks, and MTTR metrics go sideways. Diagnosis: SecurityIncident | where TimeGenerated > ago(7d) | summarize IncidentCount = count() by Title | where IncidentCount > 1 | order by IncidentCount desc If you see unexpected duplicates, the cause is almost certainly the auto-enabled Microsoft incident creation rule conflicting with your existing analytics rules. Fix: Disable the auto-created incident creation rule in Sentinel Automation rules, and rely on your existing analytics rule > incident mapping instead. This ensures incidents are created only through Sentinel's pipeline. Gotcha 3: Analytics Rule Title Dependencies The Defender portal matches incidents to analytics rules by title, not by rule ID. This creates subtle problems: Renaming a rule breaks the incident linkage Copying a rule with a similar title causes cross-linkage Two workspaces with identically named rules generate separate incidents for the same alert Prevention checklist: Audit all analytics rule titles for uniqueness before migration Document the title-to-GUID mapping as a reference Avoid renaming rules en masse during migration Use a naming convention like <Severity>_<Tactic>_<Technique> to prevent collisions Gotcha 4: RBAC Gaps Sentinel workspace RBAC roles don't directly translate to Defender portal permissions: Sentinel Role Defender Portal Equivalent Gap Microsoft Sentinel Responder Security Operator Minor - name change Microsoft Sentinel Contributor Security Operator + Security settings (manage) Significant - split across roles Sentinel Automation Contributor Automation Contributor (new) New role required Migration approach: Create new unified RBAC roles in the Defender portal that mirror your existing Sentinel permissions. Test with a pilot group before org-wide rollout. Keep workspace RBAC roles for 30 days as a fallback. Gotcha 5: Automation Rules Don't Auto-Migrate Sentinel automation rules and playbooks don't carry over to the Defender portal automatically. The syntax has changed, and not all Sentinel automation actions are available in Defender. Recommended approach: Export existing Sentinel automation rules (screenshot condition logic and actions) Recreate them in the Defender portal Run both in parallel for one week to validate behavior Retire Sentinel automation rules only after confirming Defender equivalents work correctly Practical Migration Timeline Phase 1 - Pre-migration (1-2 weeks before): Audit connectors, analytics rules, RBAC roles, and automation rules Document everything - titles, GUIDs, permissions, automation logic Test in a pilot environment first Phase 2 - Cutover day: Connect workspace to Defender portal Within 2 hours: audit auto-enabled connectors Within 4 hours: check for duplicate incidents Within 24 hours: validate RBAC and automation rules Phase 3 - Post-migration (1-2 weeks after): Monitor incident volume for duplication spikes Validate automation rules fire correctly Collect SOC team feedback on workflow impact After 1 week of stability: retire legacy automation rules Phase 4 - Cleanup (2-4 weeks after): Remove duplicate automation rules Archive workspace-specific RBAC roles once unified RBAC is stable Update SOC runbooks and documentation The bottom line: treat this as a parallel-run migration, not a lift-and-shift. Budget 2 weeks for parallel operations. Teams that rushed this transition consistently reported longer MTTR during the first month post-migration.
Co Authoring with Sensitivity Labels
Hello, I am working with sensitivity labels with my organization. We currently have Standard, Confidential, and Highly Confidential which all are encrypted. I have Co-Authoring turned on but I have some trouble with. We a lot of documents being collaborated on. Standard: Co-Authoring functions normal and Auto-Save is toggled on. Highly Confidential: Custom Permission in Sensitivity Label (View, Edit, Reply, Forward) I asked copilot and it stated even though my permissions are selected custom I have "Edit" on their for my internal users it is reading it as Co authoring; Co-Authoring is on and functioning but internal end users Auto-Save is toggled off and they are being asked to save a copy of the document or excel sheet then upload it again to SharePoint. Why isn't "Auto-Save" toggled on for "Highly Confidential" label? Can it be adjusted so it can be on? Do I have to make adjustments to my permissions in the Sensitivity label? Any help is appreciated. Thank you!Introducing the Entra Helpdesk Portal: A Zero-Trust, Dockerized ITSM Interface for Tier 1 Support
Hello everyone, If you manage identity in Microsoft Entra ID at an enterprise scale, you know the struggle: delegating day-to-day operational tasks (like password resets, session revocations, and MFA management) to Tier 1 and Tier 2 support staff is inherently risky. The native Azure/Entra portal is incredibly powerful, but it’s complex and lacks mandatory ITSM enforcement. Giving a helpdesk technician the "Helpdesk Administrator" role grants them access to a portal where a single misclick can cause a major headache. To solve this, I’ve developed the Entra Helpdesk Portal (Community Edition)—an open-source, containerized application designed to act as an isolated "airlock" between your support team and your Entra ID tenant. Why This Adds Value to Your Tenant Instead of having technicians log into the Azure portal, they log into this clean, Material Design web interface. It leverages a backend Service Principal (using MSAL and the Graph API) to execute commands on their behalf. Strict Zero Trust: Logging in via Microsoft SSO isn’t enough. The app intercepts the token and checks the user’s UPN against a hardcoded ALLOWED_ADMINS whitelist in your Docker environment file. Mandatory ITSM Ticketing: You cannot enforce ticketing in the native Azure Portal. In this app, every write action prompts a modal requiring a valid ticket number (e.g., INC-123456). Local Audit Logging: All actions, along with the actor, timestamp, and ticket number, are written to an immutable local SQLite database (audit.db) inside the container volume. Performance: Heavy Graph API reads are cached in-memory with a Time-To-Live (TTL) and smart invalidation. Searching for users or loading Enterprise Apps takes milliseconds. What Can It Do? Identity Lifecycle: Create users, auto-generate secure 16-character passwords, revoke sign-in sessions, reset passwords, and delete specific MFA methods to force re-registration. Diagnostics: View a user's last 5 sign-in logs, translating Microsoft error codes into plain English. Group Management: Add/remove members to Security and M365 groups. App/SPN Management: Lazy-load raw requiredResourceAccess Graph API payloads to audit app permissions, and instantly rotate client secrets. Universal Restore: Paste the Object ID of any soft-deleted item into the Recycle Bin tab to instantly resurrect it. How Easy Is It to Setup? I wanted this to be universally deployable, so I compiled it as a multi-architecture Docker image (linux/amd64 and linux/arm64). It will run on a massive Windows Server or a simple Raspberry Pi. Setup takes less than 5 minutes: Create an App Registration in Entra ID and grant it the necessary Graph API Application Permissions (e.g., User.ReadWrite.All, AuditLog.Read.All). Create a docker-compose.yml file. Define your feature toggles. You can literally turn off features (like User Deletion) by setting an environment variable to false. version: '3.8' services: helpdesk-portal: image: jahmed22/entra-helpdesk:latest container_name: entra_helpdesk restart: unless-stopped ports: - "8000:8000" environment: # CORE IDENTITY - TENANT_ID=your_tenant_id_here - CLIENT_ID=your_client_id_here - CLIENT_SECRET=your_client_secret_here - BASE_URL=https://entradesk.jahmed.cloud - ALLOWED_ADMINS=email address removed for privacy reasons # CUSTOMIZATION & FEATURE FLAGS - APP_NAME=Entra Help Desk - ENABLE_PASSWORD_RESET=true - ENABLE_MFA_MANAGEMENT=true - ENABLE_USER_DELETION=false - ENABLE_GROUP_MANAGEMENT=true - ENABLE_APP_MANAGEMENT=true volumes: - entra_helpdesk_data:/app/static/uploads - entra_helpdesk_db:/app volumes: entra_helpdesk_data: entra_helpdesk_db: 4.Run docker compose up -d and you are done! I built this to give back to the community and help secure our Tier 1 operations. If you are interested in testing it out in your dev tenants or want to see the full architecture breakdown, you can read the complete documentation on my website here I’d love to hear your thoughts, feedback, or any feature requests you might have!Do XDR Alerts cover the same alerts available in Alert Policies?
The alerts in question are the 'User requested to release a quarantined message', 'User clicked a malicious link', etc. About 8 of these we send to 'email address removed for privacy reasons'. That administrator account has an EOM license, so Outlook rules can be set. We set rules to forward those 8 alerts to our 'email address removed for privacy reasons' address. This is, very specifically, so the alert passes through the @tenant.com address, and our ticketing endpoint knows what tenant sent it. But this ISN'T ideal because it requires an EOP license (or similar - this actually hasn't been an issue until now just because of our customer environments). I've looked at the following alternatives: - Setting email address removed for privacy reasons as the recipient directly on the Alert Policies in question. This results in the mail going directly from microsoft to our Ticketing Portal - so it ends up sorted into Microsoft tickets. and the right team doesn't get it. SMTP Forwarding via either Exchange AC User controls or Mail Flow Rules. But these aren't traditional forwarding, and they have the same issue as above. Making administrator @tenant.com a SHARED mailbox that we can also login to (for administration purposes). But this doesn't allow you to set Outlook rules (or even login to Outlook). I've checked out the newer alerts under Defender's Settings panel - XDR alerts, I think they're called. Wondering if these can be leveraged at all for this? Essentially, trying to get these Alerts to come to our external ticketing address, from the tenants domain (instead of Microsoft). I could probably update Autotask's rules to check for a header, and set that header via Mail Flow rules, but.. just hoping I don't have to do that for everyone.
Events
Accidental changes and security compromises can quickly cascade across your tenant. Learn how to recover with confidence using Microsoft Entra Backup and Recovery.
Tune in to see how this Microsof...
Online
Purview Lightning Talks Join the Microsoft Security Community for Purview Lightning Talks; quick technical sessions delivered by the community, for the community.
You’ll pick up practical Pu...
Online