Redefining Security for an AI Driven World
Vendors are being challenged to help customers address these challenges not as a point-solution vendor but as an end-to-end security and AI platform partner. By integrating identity, data governance, threat protection, and AI services into a unified ecosystem, Microsoft can deliver coordinated defenses, continuous compliance monitoring, and operational efficiency gains that fragmented toolsets cannot match. The sections that follow examine each challenge in depth — why it persists, what makes it hard, and specifically how Microsoft helps organizations bridge the gap. Challenge 1: Safeguarding Data Privacy in the AI Era AI systems are voracious consumers of data, and their adoption is outpacing the governance structures meant to protect it. More than 80% of business leaders cite leakage of sensitive data as their primary concern with generative AI, and nearly 48% have responded by banning all use of GenAI in the workplace entirely. Meanwhile, AI is raising the value of human-generated data as a critical training input while introducing entirely new avenues for potential data leakage through models and AI-powered applications. Why This Challenge Persists Fragmented tooling is the most immediate obstacle. Organizations are managing security, compliance, and data governance through disconnected platforms, creating siloed visibility that undermines cohesive protection. Only 31% of organizations have established a global data architecture, and just 25% maintain a global data quality program — two foundations essential for trustworthy AI innovation. Without enterprise-wide data classification and access controls, AI systems cannot distinguish what is too sensitive to surface. At the same time, shadow AI compounds the risk. When employees turn to unapproved AI tools to boost productivity, sensitive data can flow to services outside IT's purview. According to Microsoft's guide on securing the AI-powered enterprise, 80% of business leaders worry that sensitive data could slip through the cracks due to unchecked AI use. AI models also inherit the permissions of their users, meaning an over-permissioned employee can unknowingly expose critical data to an AI system. Gartner has estimated that by 2025, generative AI will account for 10% of all data produced, further blurring the boundary between what is corporate-controlled and what is AI-generated. Regulatory stakes add urgency: Gartner projects that by 2027, at least one global company will see its AI deployment banned by a regulator for non-compliance with data protection or AI governance legislation. How can organizations bridge the gap? Microsoft Purview provides a unified platform that combines data classification, data loss prevention (DLP), and AI-specific posture management to address fragmentation head-on. Its Data Security Posture Management (DSPM) for AI centralizes visibility into how AI applications interact with sensitive data across the organization — including Microsoft 365 Copilot, enterprise AI apps, and third-party AI tools. Security teams can see, for example, how many unlabeled files were referenced by Copilot and where the greatest concentrations of unprotected data reside. Sensitivity labels created in Purview travel with documents and are enforced at inference time: when an AI app retrieves a file labeled "Highly Confidential," the system ensures the requesting user holds the required EXTRACT and VIEW usage rights before returning data. In practice, an executive running a Copilot query on a labeled strategy document would see the sensitivity label clearly marked alongside the response. Purview's DLP policies now extend to AI scenarios directly, including inline browser protection that can block or warn users attempting to paste sensitive data into third-party generative AI sites such as ChatGPT in Microsoft Edge, Chrome, or Firefox. For organizations handling the most sensitive workloads, Azure Confidential Computing protects data even while it is being processed, using hardware-based Trusted Execution Environments (TEEs) that keep information encrypted in memory — invisible even to cloud operators. This capability is especially relevant for AI training and inference on regulated data, where customers need verifiable proof that their information was never exposed in plaintext during processing. The net result is defense-in-depth for data: discover where sensitive information lives, classify it so AI systems respect boundaries, enforce policies at the point of AI interaction, and encrypt data in use for the highest-risk scenarios — all governed through a single compliance surface. Challenge 2: The AI-Weaponized Threat Landscape Adversaries are using AI to accelerate, scale, and personalize attacks faster than traditional defenses can respond. In the past year, 67% of all phishing attacks employed some form of AI, and organizations now face an average of 66 data security alerts per day — up from 52 in 2023. Under this pressure, 73% of cybersecurity experts admit they have missed, ignored, or failed to respond to high-priority security alerts. Why This Challenge Persists The speed differential is the core problem. AI-enabled threat actors can now use models to autonomously discover, chain, and exploit vulnerabilities, compressing the window from discovery to exploitation from months to hours. Attackers leverage generative AI for malware generation, automated vulnerability scanning, customized exploits, password cracking, sophisticated phishing and social engineering, and deepfake-based impersonation of data, email, and voice. At the same time, AI systems themselves introduce novel attack surfaces. A staggering 88% of organizations, according to a Gartner Peer Community survey of 332 participants, are concerned about indirect prompt injection attacks — where malicious instructions embedded in data manipulate an AI's behavior to reveal confidential information or bypass controls. AI models are also susceptible to fabrications, initially known as hallucinations, in essence biased outputs, and data poisoning — risks that traditional vulnerability management frameworks were never designed to address. From an operational standpoint, SOC analysts already spend nearly three hours per day on incidents, accumulating costs that reach billions in aggregate. Layering AI-driven attacks on top of this existing overload threatens to break conventional security operations entirely. How can organizations bridge the gap? Microsoft counters the asymmetry with AI-powered defense at cloud scale, grounded in threat intelligence no single organization could replicate alone. Microsoft processes more than 100 trillion security signals per day from endpoints, cloud services, identity systems, and the edge, and tracks 1,500 unique threat actor groups — including 600 nation-state actors, 300 cybercrime groups, and 200 influence operations groups. This intelligence feeds directly into detection models and product updates, ensuring customers benefit from patterns observed across billions of users and devices worldwide. Microsoft Security Copilot is the most visible expression of this strategy. A generative AI security assistant combining advanced OpenAI models with a Microsoft-developed security-specific model, it helps analysts investigate and remediate incidents in natural language — from triaging complex alerts into actionable summaries, to reverse-engineering malicious scripts, to generating KQL queries for threat hunting. Early deployment data shows that Defender XDR customers using Security Copilot experienced a 30% reduction in incident resolution time in just three months. For securing AI models themselves, Microsoft Defender for Cloud now offers AI model security (in public preview since March 2026), which scans custom AI models in Azure Machine Learning registries and workspaces for embedded malware, unsafe operators, and exposed secrets — integrated directly into CI/CD pipelines so risky models are stopped before reaching production. The Microsoft Digital Defense Report 2025 reinforced this posture with seven top recommendations, led by managing cyber risk at the boardroom level, prioritizing identity protection, and investing in people alongside tools. Microsoft's approach treats AI threats not as a separate domain but as an intensification of the broader threat landscape that demands coordinated, platform-level defense. Challenge 3: Identity and Access Governance for AI Agents AI is creating an entirely new class of digital actors that most identity systems were never designed to manage. According to IDC, there will be approximately 1.3 billion AI agents operating across enterprises by 2028. These agents — which range from simple automation bots to fully autonomous decision-making systems — require resource access, generate data, and interact with users and services in ways that fundamentally differ from traditional applications or human users. Why This Challenge Persists Most organizations lack lifecycle management, ownership models, and policy controls for non-human identities, and AI agents amplify these gaps significantly. Industry analysts argue that AI agents should not be treated as just another non-human identity; they introduce complex delegation chains between humans, agents, and services that require distinct identity, accountability, and audit models. Traditional human-in-the-loop controls may not scale for agentic systems, yet new identity-centric governance mechanisms are only beginning to emerge. Compounding the issue, the indeterministic nature of large language models means that an AI agent with broad access privileges may behave unpredictably — potentially taking actions its developers did not anticipate. Without proper controls, forgotten or orphaned agent identities can become easy targets for attackers, and the resulting security incidents may be difficult to attribute or contain. How can organizations bridge the gap? Microsoft extends its identity-first Zero Trust architecture to AI through Microsoft Entra Agent ID (in public preview). The core idea: every AI agent receives a unique, first-class identity — discoverable, manageable, and securable alongside human users, applications, and devices. Once registered, an agent's access can be scoped using the same enterprise-grade controls as any other identity: conditional access policies, role-based access control, lifecycle governance, and risk-based protection. Conditional Access for Agents allows organizations to evaluate an agent's context and risk level before granting a token. Policies can enforce controls such as restricting agents to specific network locations or blocking access when risk signals are elevated. Microsoft is also developing RBAC guardrails specifically tailored to AI agent behaviors, acknowledging that LLM-based agents present heightened risk when granted broad role assignments. For lifecycle management, Microsoft provides mechanisms for IT administrators to create automated lifecycle policies for agent identities — including periodic attestation by designated sponsors, automated cleanup of unmonitored agents, and notifications when agent identities approach expiration. This directly addresses the "agent sprawl" problem identified by CISOs and security architects. At a broader level, Microsoft Agent 365 delivers a unified control plane for agents, aggregating posture, and real-time risk signals from Defender, Entra, and Purview into a single dashboard — providing discovery of both Microsoft and third-party agents, AI posture tracking, and governance controls to delegate remediation tasks to the appropriate teams. The Security Dashboard for AI (in GA now) answers the executive-level questions: Which AI assets exist in our environment? What is their current security posture? Where must we take action? — covering Microsoft 365 Copilot, Copilot Studio agents, Foundry apps, and third-party AI including Google Gemini, OpenAI ChatGPT, and MCP servers Challenge 4: Regulatory Compliance and Ethical AI Governance The regulatory landscape for AI is evolving faster than most organizations can track, and the stakes — legal, financial, and reputational — are escalating. More than 52% of business leaders admit they are unsure how to navigate rapidly evolving AI regulations. Frameworks like the EU AI Act (whose first obligations took effect on February 2, 2025), GDPR, and sector-specific rules such as DORA are converging to create a compliance environment that demands continuous adaptation. Why This Challenge Persists The EU AI Act alone adopts a risk-based approach to AI regulation, classifying systems by their potential impact on health, safety, and fundamental rights and imposing corresponding obligations for documentation, transparency, human oversight, and testing. Organizations must map every AI deployment to the correct risk category — and misclassification can lead to regulatory violations. Simultaneously, the responsibilities of security leaders are expanding to include governance and regulatory compliance oversight that traditionally belonged to legal or compliance teams. The NC State University Executive Perspectives on Top Risks survey of 1,540 board members and C-suite executives ranked regulatory uncertainty and fragmentation as the eighth-highest near-term risk (2026–2028), and AI implementation risks as sixth. Among AI-specific concerns, 24% of respondents identified lack of governance and accountability for AI deployments as a top three worry. Culturally, building internal consensus around what constitutes "responsible" AI use — across diverse business units with different risk appetites — remains a persistent organizational challenge. How can organizations bridge the gap? Microsoft's Responsible AI program, anchored by six durable principles established in 2018 — Fairness, Reliability & Safety, Privacy & Security, Inclusiveness, Transparency, and Accountability — provides a governance blueprint that has proven stable even as AI technology evolves rapidly. These principles shape design, deployment, and oversight choices across Microsoft's products, and the company shares the lessons openly through its 2025 Responsible AI Transparency Report and customer guidance. In preparing for the EU AI Act specifically, Microsoft has taken a proactive, layered approach to compliance, conducting impact assessments and adversarial red teaming on high-risk models and systems, and extending its Sensitive Uses governance program to ensure additional oversight for the most consequential AI deployments. Microsoft has also documented its approach to EU AI Act implementation to help customers understand how its products and services are being built to comply. Operationally, the Security Dashboard for AI provides board-ready analytics and compliance insights, aggregating risk signals across Entra, Defender, and Purview into a single executive view with recommendations and direct remediation paths. This makes AI governance visible and actionable within the same tools security leaders already use for broader risk management. Microsoft also fosters community-driven governance through initiatives like the Security for AI Accelerated Collaboration Forum (ACF), which brings together CISOs, security architects, SOC leaders, identity and data owners, and platform engineers to share challenges, shape roadmap priorities, and develop reusable governance frameworks. Challenge 5: Integration Complexity and Workforce Readiness Even when the right AI security tools exist, most organizations struggle to integrate them into existing technology stacks and to equip their people to use them effectively. Among executives surveyed by NC State University, 31% identified integrating AI with existing technologies, business processes, and workforce as a top-three AI concern, 29% pointed to equipping the workforce to realize AI's value proposition, and 28% flagged the inability to deploy AI at a competitive pace. Why This Challenge Persists Years of tool proliferation have left enterprises with fragmented security architectures. Organizations rely on disconnected platforms for endpoint protection, cloud workload security, identity management, and data governance — and AI capabilities are now being added to each domain independently. Microsoft's own research notes that organizations using fragmented platforms across security, compliance, and data teams see exacerbated security outcomes. When a data loss prevention alert in one system cannot be correlated with an identity anomaly in another, threats slip through. At the same time, AI security as a discipline lacks comprehensive resources and seasoned experts. Because major cloud AI platforms only became generally available in 2021–2023, organizations must often develop protective measures without much external guidance or established precedent. The cybersecurity workforce shortage is well documented; the additional demand for professionals who understand both machine learning and security compounds it further. The broader threat environment amplifies the urgency: cyberthreats have grown 5X in scale, Microsoft now tracks over 1,500 threat actor groups (up from roughly 300 just a few years ago), and the median time for an attacker to access confidential data after a successful phishing attack is just 1 hour 12 minutes. Teams that cannot integrate and respond quickly are structurally disadvantaged. How can organizations bridge the gap? Microsoft's primary answer to integration complexity is a unified, cloud-native security platform in which AI, identity, data governance, and threat protection work as a coordinated system. Security Copilot, for instance, is embedded within and integrates across Microsoft Defender XDR, Microsoft Sentinel, Microsoft Intune, Microsoft Entra, and Microsoft Purview. An analyst can use a single natural language interface to investigate incidents drawing on data from any of these products, generate remediation steps, build reports for stakeholders, and automate routine tasks with autonomous Security Copilot agents — all without switching consoles. The inclusion of Security Copilot in Microsoft 365 E5 and E7 licensing simplifies adoption further. Customers receive a monthly allocation of SCUs or Secure Computing Units to empower Security Copilot, eliminating the need for separate AI security procurement. This positions integrated, agentic AI-powered security as a default capability rather than an add-on. For endpoint-level visibility into AI agent sprawl, Microsoft Defender for Endpoint now automatically discovers supported AI coding agents on onboarded Windows 11 devices — including OpenClaw, Claude Code, Codex, Cursor, GitHub Copilot CLI, ChatGPT Desktop, Gemini CLI, and others — and surfaces them in the Defender portal inventory for investigation and correlation with existing device telemetry. On workforce enablement, Microsoft operates the Security Copilot Adoption Hub, which provides role-specific guidance for CISOs, threat intelligence analysts, IT admins, and data security administrators on how to embed AI into their daily workflows. The broader Microsoft Learn platform now offers modules on securing AI applications and responsible AI governance. Microsoft's role here is as a force multiplier: by consolidating tools, reducing integration burden, and actively investing in customer readiness, Microsoft enables organizations to convert AI from a source of complexity into an operational advantage — without leaving security behind. Conclusion: Turning AI Security into Competitive Advantage The five challenges examined here — data exposure, adversarial threats, identity sprawl, regulatory uncertainty, and integration complexity — will only intensify as AI adoption accelerates. Yet for organizations that address them proactively, the payoff extends well beyond risk mitigation. Robust AI security has become a source of trust with customers and regulators, a prerequisite for bold innovation, and a differentiator in markets where competitors may still be scrambling to catch up. Microsoft's contribution is structural: an integrated platform where identity, data governance, threat intelligence, and compliance converge — backed by principles of Responsible AI that have remained durable since 2018 and by threat visibility at a scale (more than 100 trillion signals per day, 1,500+ tracked threat actor groups) that no single enterprise can replicate. For executive leadership, the actionable imperative is to treat AI security not as a technical footnote but as a boardroom priority — one that spans the CIO, CISO, Chief Data Officer, and business-unit leaders working together. As Microsoft's own AI security guidance articulates, cross-team collaboration, employee training, and transparent governance are just as essential as firewalls and encryption in building a secure AI future. The organizations that internalize this lesson will be those best positioned to harness AI's full potential — securely, responsibly, and at scale. Tech Resources: Defense at AI speed: Microsoft’s new multi-model agentic security system tops leading industry benchmark Securing AI and Navigating risks and compliance for the future Entra agent Identities for AI agents Secure Dashboard for AI Microsoft Security Copilot Microsoft Security Copilot FAQDetermine Defender for Endpoint offboarding state for Linux devices
There are certain instances when a machine or machines are offboarded that the corresponding status takes an unusual amount of time to report in the Defender portal. The status that is shown in the portal is “Can be onboarded,” however this status doesn’t clarify with absolute certainty that the machine was offboarded from the platform. The status “Can be onboarded” means that either the endpoint was offboarded from the platform or, that it is a new device discovered by the “Device Discovery” service of MDE and the platform is highlighting this for you as something to address and cover the security gap that represents an endpoint without protection. Figure 1.”Can be onboarded” status of a device. In advanced hunting in the Defender portal, there’s not a direct field that reflects if a device was offboarded but if it is onboarded that is visible using a KQL query. If a device is onboarded, this is shown in the portal, under Assets -- Device Inventory -- All devices, but not if it is offboarded. Figure 2. Onboarding status as seen in the Device Inventory view. To circumvent this existing challenge, I am using a similar approach to what I described in the article “Determine offboarding state using Powershell” and you can run a bash script that determines with a high level of confidence that a device was offboarded from the platform without the need to wait for the 7 days period it takes a device to be deemed as inactive in the console. This script can be handy in situations where offboarding is happening on devices that are experiencing communication issues or sensor issues and offboarding is the option to fix the problem and you would like to know straight away if the process was successful. In essence, the bash script checks three indicators present in Linux system to confirm if the key services responsible for sending telemetry to the portal are up and running. The key parameters are listed below: Confirm the onboard file exists in this path: "/etc/opt/microsoft/mdatp/mdatp_onboard.json" Check the Defender daemon process is running: wdavdaemon/mdatp Check mdatp rpm package is installed These two last parameters are informational only to report the status of the wdavdaemon and if the rpm package for Defender is installed, but it provides two key pieces of information: If service is still running but machine is offboarded, this is the expected behavior unless you also uninstall the MDE agent from the Linux endpoint. If the service and rpm package show as not installed and the device also shows as offboarded that means the machine hasn't been onboarded to Defender for Endpoint High level execution of the script: Scans computer(s) to determine onboarding method in MDE: The script proceeds through several logical steps: It first checks if the onboarding file exists and attempts to extract the organization ID from it using either jq or a portable grep/awk fallback. Next, it determines if the MDE package is installed by querying the system’s package manager. It then checks if the Defender service is running, using systemd if available, or falling back to process checks otherwise. The script also locates the Defender CLI and, if present, queries its health status and extracts additional metadata such as org ID, machine ID, health state, and app version. In theory, to make it scalable and reach to more devices, this bash script could be pushed to Linux endpoints using any of the Linux management tools like Chef, Ansible or Puppet. Finally, the script synthesizes these findings to decide the overall status: it reports “ONBOARDED” if the Defender agent is healthy, the service is active, or both the package and onboarding file are present; otherwise, it reports “OFFBOARDED.” The output summarizes key findings, making it easy for administrators or automation systems to quickly assess the Defender state on Linux endpoints. For further troubleshooting with Linux devices: Microsoft Defender for Endpoint on Linux resources - Microsoft Defender for Endpoint | Microsoft Learn Parameters used in the script: The script contains different parameters to evaluate with a great level of certainty if a device was onboarded using one of the known methods: ONBOARD_FILE: The path to the Defender onboarding artifact (/etc/opt/microsoft/mdatp/mdatp_onboard.json). Its presence and contents are used to determine onboarding state and extract the organization ID. onboard_state: Indicates whether the onboarding file is present ("Present") or missing ("Missing"). org_from_file / org_from_cli: The organization (tenant) ID, extracted from the onboarding file or from the Defender CLI health output, respectively. pkg_status: Reflects whether the Defender package (mdatp) is installed, and via which package manager (Installed(rpm), Installed(dpkg), or NotInstalled(...)). svc_state: The running state of the Defender service or process (active, inactive, UnitMissing, NoSystemd, etc.), determined via systemd or process checks. MDATP_CLI: The path to the Defender CLI binary, used to query health and metadata. healthy: Indicates if the Defender agent is healthy (true/false), as reported by the CLI. edr_machine_id: The unique machine ID assigned by Defender, extracted from the CLI health output. app_version: The installed version of the Defender agent, also from the CLI health output. overall: The final computed status, either "ONBOARDED" or "OFFBOARDED", based on the combination of health, service, package, and onboarding file checks. - HOW TO RUN - EXAMPLE Open a terminal window in the Linux device you want to check and navigate to the directory where the script is saved. Run the following command to make it executable: chmod +x MDE_CheckOffboardingState_Linux.sh Run the Script with Sufficient Privileges: Sudo bash ./MDE_CheckOffboardingState_Linux.sh Check the output of the script. If the endpoint is onboarded you will see an output similar to this: Fig. 3 Linux device is onboarded in Defender for Endpoint If the endpoint hasn’t been onboarded to Defender for Endpoint or it has been offboarded, the output of the shell script will be similar to this: Fig. 4 A Linux device that is offboarded from Defender for Endpoint Linux shell scripting code: Code disclaimer: The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages. NOTE: When using your scripting editing tool of choice, be aware of any additional spaces added as a result of the copy/past operation into your editing tool. #!/usr/bin/env bash # Check Microsoft Defender for Endpoint (MDE) offboarding/onboarding status on Linux # v3 - robust unit detection, non-systemd fallback, smarter CLI/Org ID parsing # Output is ASCII-only, suitable for CI/logging. # USAGE DISCLAIMER # The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are # provided AS IS without warranty of any # kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of # merchantability or of fitness for a # particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation # remains with you. In no event shall # Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for # any damages whatsoever (including, # without limitation, damages for loss of business profits, business interruption, loss of business information, or other # pecuniary loss) arising out of the use # of or inability to use the sample scripts or documentation, even if Microsoft # has been advised of the possibility of such damages. # Author: Edgar Parra - Microsoft v1.1 #!/usr/bin/env bash # Check Microsoft Defender for Endpoint (MDE) offboarding/onboarding status on Linux # v3-modified - authoritative offboarding via artifact files only set -euo pipefail ONBOARD_FILE="/etc/opt/microsoft/mdatp/mdatp_onboard.json" OFFBOARD_FILE="/etc/opt/microsoft/mdatp/mdatp_offboard.json" # ---- helper: trim ---- _trim() { sed -e 's/^[[:space:]]\+//' -e 's/[[:space:]]\+$//' ; } # ---- 1) Onboarding artifact check ---- onboard_state="Missing" if [[ -s "$ONBOARD_FILE" ]]; then onboard_state="Present" fi offboard_state="Missing" if [[ -s "$OFFBOARD_FILE" ]]; then offboard_state="Present" fi # ---- 2) Package presence (rpm or dpkg) ---- pkg_status="Unknown" if command -v rpm >/dev/null 2>&1; then if rpm -q mdatp >/dev/null 2>&1; then pkg_status="Installed(rpm)" else pkg_status="NotInstalled(rpm)" fi elif command -v dpkg >/dev/null 2>&1; then if dpkg -s mdatp >/dev/null 2>&1; then pkg_status="Installed(dpkg)" else pkg_status="NotInstalled(dpkg)" fi fi # ---- 3) Service/process state (informational only) ---- svc_state="Unknown" if systemctl is-active --quiet mdatp 2>/dev/null; then svc_state="active" else svc_state="inactive" fi # ---- 4) CLI presence (informational only) ---- MDATP_CLI="$(command -v mdatp 2>/dev/null || true)" [[ -z "$MDATP_CLI" ]] && MDATP_CLI="/opt/microsoft/mdatp/bin/mdatp" # ---- 5) Decide OFFBOARDING STATUS (AUTHORITATIVE LOGIC ONLY) ---- overall="NOT_OFFBOARDED" if [[ "$offboard_state" == "Present" && "$onboard_state" == "Missing" ]]; then overall="OFFBOARDED" fi # ---- 6) Output ---- echo "========== Microsoft Defender for Endpoint (Linux) ==========" echo "Offboarding status (authoritative): $overall" echo "mdatp_offboard.json: $offboard_state ($OFFBOARD_FILE)" echo "mdatp_onboard.json: $onboard_state ($ONBOARD_FILE)" echo "mdatp service status (informational): $svc_state" echo "mdatp RPM status (informational): $pkg_status" echo "=============================================================" Conclusion The purpose of this script is to be used as an alternative to discover faster if a device has been offboarded or never onboarded in Defender for Endpoint. It provides a swift approach for when deployments occur and you need to know faster when a device has been offboarded. It streamlines your deployment and allows you to move faster. We understand that waiting 7 days for a device to be marked as “Can be onboarded” in the Defender portal, feels like a long wait but the reasons for this are security. To allow devices that have been offline for a period of time that may reconnect with Defender. Additional benefit An additional benefit of this script is that it can also be run from Live Response console but only on devices that are onboarded in Defender for Endpoint. For devices that are not onboarded, Live Response is not available. However, running the script will tell you if the device is properly onboarded and the output of the script will be shown in the Live Response console. This is a practical way to run the script remotely without the need to logon to the device directly and find out quickly if the device was onboarded properly. Fig. 5 Running the shell script from the Live Response console and output is shown in the Live Response console.Determine Defender for Endpoint offboarding state of Windows machines using PowerShell
There are certain instances when a machine or machines are offboarded that the corresponding status takes an unusual amount of time to report in the Defender portal. The status that is shown in the portal is “Can be onboarded”, however this status doesn’t clarify with absolute certainty that the machine was offboarded from the platform. The status “Can be onboarded” means that either the endpoint was offboarded from the platform or, that it is a new device discovered by the “Device Discovery” service of MDE and the platform is highlighting this for you as something to address and cover the security gap that represents an endpoint without protection. Figure 1.”Can be onboarded” status of a device. In advanced hunting in the Defender portal, there’s not a direct field that reflects if a device was offboarded but if it is onboarded that is visible using a KQL query. If a device is onboarded, this is shown in the portal, under Assets --> Device Inventory --> All devices, but not if it is offboarded. Figure 2. Onboarding status as seen in the Device Inventory view. To circumvent this existing challenge, Powershell can come to the rescue, and you can run a script that determines with a high level of confidence that a device was offboarded from the platform without the need to wait for the 7 days period it takes a device to be deemed as inactive in the console. This script can be handy in situations where offboarding is happening on devices that are experiencing communication issues or sensor issues and offboarding is the option to fix the problem and you would like to know straight away if the process was successful. In essence, the script checks an indicator in the registry and the status of the key service that is responsible for sending telemetry to the portal and a true indication that the device is onboarded in Defender for Endpoint, the Sense.exe service. The registry key: 'HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status', REG_DWORD: OnboardingState. High level execution of the script: Scans computers to determine if devices are offboarded from MDE: The script checks one or more Windows computers (locally by default, or remotely via PowerShell remoting) and infers whether the device appears OFFBOARDED from MDE by looking at: Registry onboarding indicators (OnboardingState and OnboardedInfo) The state of the SENSE service (Sense) Then it outputs: A human-readable status (ASCII only) It pipes the results to a .csv file Optionally exports CSV Fairly simple script but it allows administrators to check on the fly if a device has been offboarded from Defender for Endpoint. I wanted to keep it simple, but this script could be run from Configuration Manager or Intune to check in bulk what devices are offboarded from MDE. PowerShell scripting code: Code disclaimer: The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages. NOTE: When using your scripting editing tool of choice, be aware of any additional spaces added as a result of the copy/past operation into your editing tool. <# .SUMMARY Checks if a device appears OFFBOARDED from Microsoft Defender for Endpoint (MDE). .DESCRIPTION - Reads onboarding indicators in the registry. - Checks the SENSE service state. - Outputs a simple, ASCII-only status. - Can run locally (default) or against one/many remote computers via PS Remoting. .PARAMETER ComputerName One or more computers to check. Default = local computer. .PARAMETER OutCsv Optional path to write results as CSV. .PARAMETER Quiet If set, returns $true when OFFBOARDED and $false otherwise (for local-only use). .NOTES Registry indicators are based on the typical onboarding keys used by MDE. References: - MS Learn: Offboard devices (status becomes Inactive after 7 days; data retained up to 180 days). - Author: Edgar Parra - Microsoft v1.0 #> [CmdletBinding()] param( [string[]]$ComputerName = @($env:COMPUTERNAME), [string]$OutCsv, [switch]$Quiet ) # --- inner checker that runs LOCALLY on a target (used both locally and via Invoke-Command) --- $localCheck = { $regPaths = @( 'HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status', 'HKLM:\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection\Status' ) $onboardingStates = @() foreach ($p in $regPaths) { if (Test-Path $p) { try { $val = Get-ItemPropertyValue -Path $p -Name 'OnboardingState' -ErrorAction SilentlyContinue if ($null -ne $val) { $onboardingStates += [int]$val } } catch { } } } # SENSE service check $senseStatus = try { $svc = Get-Service -Name 'Sense' -ErrorAction Stop $svc.Status.ToString() } catch { 'NotInstalled' } # Determine likely state # If any OnboardingState == 1 OR SENSE Running, treat as not offboarded $isOnboarded = ($onboardingStates -contains 1) -or ($senseStatus -eq 'Running') # Build result [PSCustomObject]@{ ComputerName = $env:COMPUTERNAME SenseService = $senseStatus OnboardingState = if ($onboardingStates.Count) { ($onboardingStates -join ',') } else { 'N/A' } AppearsOffboarded = if ($isOnboarded) { $false } else { $true } Notes = if ($isOnboarded) { 'OnboardingState==1 and/or SENSE Running' } else { 'No onboarding indicators and SENSE not running' } } } $results = @() foreach ($comp in $ComputerName) { if ($comp -ieq $env:COMPUTERNAME -or $comp -eq '.' -or $comp -eq 'localhost') { $results += & $localCheck } else { try { $res = Invoke-Command -ComputerName $comp -ScriptBlock $localCheck -ErrorAction Stop $res | ForEach-Object { $_.ComputerName = $comp } $results += $res } catch { $results += [PSCustomObject]@{ ComputerName = $comp SenseService = 'Unknown' OnboardingState = 'Unknown' AppearsOffboarded = $null Notes = "Error: $($_.Exception.Message)" } } } } # Output if ($OutCsv) { $results | Export-Csv -NoTypeInformation -Path $OutCsv -Encoding UTF8 Write-Host "Saved results to $OutCsv" } if ($ComputerName.Count -eq 1 -and $Quiet) { # local single-check boolean mode return [bool]$results[0].AppearsOffboarded } # Human-readable summary (ASCII only) $results | ForEach-Object { $status = if ($_.AppearsOffboarded -eq $true) { 'OFFBOARDED' } elseif ($_.AppearsOffboarded -eq $false) { 'ONBOARDED' } else { 'UNKNOWN' } Write-Host ('[{0}] Status: {1} | SENSE: {2} | OnboardingState: {3} | Notes: {4}' -f ` $_.ComputerName, $status, $_.SenseService, $_.OnboardingState, $_.Notes) } # Also emit objects so you can pipe to Select-Object/Where-Object if you want $results Additional information: Offboarding devices from Defender for Endpoint. Offboarding devices via API explorer. In the next publication, I will aboard how to do this same process but for devices running Linux. Stay tuned!! and thank you for reading!
