This chapter covers Microsoft Defender for Endpoint onboarding—the critical process of connecting devices to the Defender for Endpoint service for threat detection and response. For the SC-900 exam, understanding onboarding methods and requirements is essential, as it directly maps to objective 3.3 (Describe the capabilities of Microsoft Defender for Endpoint). Approximately 5-10% of exam questions touch on deployment and configuration aspects, including onboarding. This chapter will provide a deep, mechanistic understanding of how onboarding works, the different methods available, and what candidates must know to pass exam questions.
Jump to a section
Think of Defender for Endpoint onboarding like issuing electronic badges to employees in a secure office building. Each device is an employee who needs a badge to enter and be monitored. The onboarding process is like registering each employee in the HR system, programming their badge with specific permissions, and installing readers at every door. Once badged, every swipe logs entry time, location, and identity. If an employee tries to enter a restricted area, the system alerts security. Similarly, onboarding a device to Defender for Endpoint involves enrolling it into the Microsoft 365 Defender portal, deploying a sensor (the badge), and configuring policies. The sensor then reports telemetry (swipe logs) to the cloud backend. If the device exhibits suspicious behavior (like trying to access a known malicious IP), an alert is triggered. Just as a badge can be deactivated if an employee leaves, a device can be offboarded by removing the sensor. The key is that without onboarding, the device is invisible to the security system—like an employee without a badge wandering the building unmonitored.
What is Defender for Endpoint Onboarding?
Microsoft Defender for Endpoint (MDE) is an enterprise-grade endpoint security platform that provides preventative protection, post-breach detection, automated investigation, and response. However, before MDE can protect a device, the device must be onboarded—a process that installs the MDE sensor and establishes a trusted connection to the Microsoft 365 Defender cloud service. Onboarding is the foundational step; without it, no telemetry flows, no alerts fire, and no automated actions occur.
Onboarding is not a one-size-fits-all operation. Microsoft provides multiple methods to accommodate different environments: on-premises Windows, Windows Server, Linux, macOS, Android, and iOS. Each platform has specific onboarding packages and procedures. The SC-900 exam focuses primarily on Windows 10/11 and Windows Server, but candidates should be aware of cross-platform support.
How Onboarding Works Internally
When a device is onboarded, the following sequence occurs:
Installation of the MDE sensor: The onboarding package (a script or group policy object) installs the Microsoft Defender for Endpoint sensor service (MsSense.exe on Windows). This service is the core component that collects telemetry from the operating system, including process creation, network connections, file system events, registry changes, and kernel-level activities.
Certificate enrollment: The sensor generates a device identity certificate or uses a pre-provisioned certificate. This certificate is used to authenticate the device to the MDE cloud service. The onboarding package contains a unique OrgID and WorkspaceID that link the device to your tenant.
Establishing a cloud connection: The sensor connects to the MDE cloud endpoints (e.g., *.endpoint.microsoft.com, *.events.data.microsoft.com) over HTTPS (TCP/443). It sends an initial heartbeat and begins streaming telemetry.
Policy download: The sensor downloads the latest security policies from the cloud, including configuration for real-time protection, cloud-delivered protection, and sample submission settings.
Verification: The device appears in the Microsoft 365 Defender portal under Assets > Devices with an onboarding status of "Onboarded". The sensor starts sending regular health signals (every 5 minutes by default).
Key Components, Values, and Defaults
Onboarding package: A file (e.g., WindowsDefenderATPLocalOnboardingScript.cmd) that contains the tenant-specific Workspace ID and Org ID. These IDs are unique per tenant and must be kept confidential.
Sensor service: MsSense.exe (Windows), mdatp (Linux), wdavdaemon (macOS). Runs as a system service.
Heartbeat interval: 5 minutes. If the cloud doesn't receive a heartbeat for 30 minutes, the device status changes to "Inactive".
Telemetry streams: Events such as process creation (Event ID 4688), network connection (Event ID 5156), file creation/modification, registry changes, and DNS queries.
Communication ports: TCP 443 (HTTPS) to cloud endpoints. No inbound ports required.
Offboarding: Reverses onboarding by removing the sensor and certificate. The device stops sending telemetry and is removed from the portal after 7 days of inactivity.
Configuration and Verification Commands
For Windows devices, onboarding can be performed via: - Local script: Run the onboarding script as Administrator. - Group Policy: Deploy the onboarding configuration via Administrative Templates > Windows Components > Microsoft Defender for Endpoint. - Microsoft Endpoint Manager (Intune): Use the Endpoint Security > Microsoft Defender for Endpoint > Onboarding policy. - Microsoft Configuration Manager: Use the Microsoft Defender for Endpoint onboarding wizard.
To verify onboarding status on a Windows device:
Get-MpComputerStatus | Select-Object AMProductVersion, AMEngineVersion, AMServiceEnabled, AntispywareEnabled, AntivirusEnabled, IoavProtectionEnabled, OnboardingState, OrgIdThe OnboardingState property should be 1 (onboarded). The OrgId should match your tenant.
For Linux:
mdatp healthLook for license_state as active and org_id matching your tenant.
Interaction with Related Technologies
Defender for Endpoint integrates with: - Microsoft Defender Antivirus: MDE uses the antivirus engine for real-time protection. Onboarding enables cloud-delivered protection and block-at-first-sight. - Microsoft Defender for Identity: MDE shares signals with Defender for Identity for cross-domain detection. - Microsoft 365 Defender: All alerts and incidents from MDE are aggregated in the Microsoft 365 Defender portal. - Microsoft Intune: Device compliance policies can use MDE risk levels. - Azure Sentinel (SIEM): MDE can stream alerts to Sentinel via API or connector.
Onboarding Methods Deep Dive
#### Local Script Onboarding
The simplest method for single devices. The onboarding script is downloaded from the Microsoft 365 Defender portal (Settings > Endpoints > Onboarding). The script contains the Workspace ID and Org ID. When run, it:
Creates the registry key HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status with OnboardingState = 1.
Installs the sensor if not present.
Configures the service to start automatically.
Triggers an immediate health check.
#### Group Policy Onboarding
For domain-joined devices, Group Policy can deploy the onboarding configuration. The policy settings are located at:
Computer Configuration > Administrative Templates > Windows Components > Microsoft Defender for Endpoint > Onboarding
You must specify the onboarding script content (the XML/script from the portal) in the policy. The policy applies at next Group Policy refresh (90 minutes by default, 5 minutes for domain controllers).
#### Microsoft Endpoint Manager (Intune) Onboarding
For Azure AD-joined or hybrid-joined devices, Intune provides a streamlined onboarding experience. In the Endpoint Security node, create a policy for Microsoft Defender for Endpoint onboarding. The policy automatically distributes the onboarding configuration to enrolled devices. Intune also supports automatic enrollment of devices via Windows Autopilot.
#### Microsoft Configuration Manager Onboarding
Configuration Manager (current branch 2002+) can onboard devices via the Microsoft Defender for Endpoint onboarding wizard. This method uses the Configuration Manager client to deploy the sensor and configuration. It supports co-management with Intune.
Offboarding
Offboarding is the reverse process. It removes the sensor and certificate, stopping all telemetry. Offboarding scripts are available in the portal. After offboarding, the device remains visible in the portal for 7 days (inactive) before being automatically removed. Offboarding is necessary when retiring a device or migrating to a new tenant.
Supported Platforms
Windows 7 SP1, 8.1, 10, 11 (Pro, Enterprise, Education)
Windows Server 2008 R2 SP1 through 2022 (including Server Core and Nano Server via roles)
Linux (Ubuntu, RHEL, CentOS, SUSE, Debian, Oracle Linux)
macOS (10.15 Catalina, 11 Big Sur, 12 Monterey, 13 Ventura)
Android (Microsoft Defender for Endpoint on Android)
iOS (Microsoft Defender for Endpoint on iOS)
For non-Windows platforms, onboarding uses a similar process but with platform-specific packages (e.g., .deb, .rpm, .pkg). The SC-900 exam may ask about supported platforms but will not test detailed Linux onboarding commands.
Common Pitfalls
Incorrect Workspace ID: If the onboarding package is from a different tenant, the device will not authenticate. The device will show as "Onboarding pending" or "Inactive".
Firewall blocks: The sensor requires outbound HTTPS to specific Microsoft endpoints. A common misconfiguration is blocking *.endpoint.microsoft.com or ctldl.windowsupdate.com.
Proxy configuration: If the environment uses an authenticated proxy, the sensor may fail to connect. Use the Set-MpPreference cmdlet to configure proxy settings.
Certificate issues: The device must trust the Microsoft certificate chain. If the device is offline for an extended period, certificates may expire.
Exam Focus
The SC-900 exam tests conceptual understanding rather than hands-on configuration. Key areas include:
Purpose of onboarding (establishing trust and telemetry)
Available methods (local script, Group Policy, Intune, Configuration Manager)
Supported platforms (Windows, Linux, macOS, Android, iOS)
Offboarding effect (stops telemetry, device removed after 7 days)
Integration with Microsoft 365 Defender
Common exam questions include: - "Which method should you use to onboard 500 domain-joined Windows 10 devices?" (Answer: Group Policy) - "What happens when a device is offboarded?" (Answer: It stops sending telemetry and is removed after 7 days) - "Which component is installed during onboarding?" (Answer: Microsoft Defender for Endpoint sensor)
Candidates often confuse onboarding with Microsoft Defender Antivirus installation. Remember: MDE onboarding installs the sensor, not just the antivirus. The antivirus may be part of the solution but is separate.
Download the onboarding package
From the Microsoft 365 Defender portal, navigate to Settings > Endpoints > Onboarding. Select the operating system (e.g., Windows 10/11) and deployment method (e.g., Local Script). Click 'Download onboarding package'. The package is a .cmd file (Windows) or .sh file (Linux/macOS) that contains your tenant-specific Workspace ID and Org ID. This package must be kept confidential as it authenticates devices to your tenant. If leaked, a malicious device could impersonate your tenant's device.
Run the onboarding script on the device
On the target device, open an elevated command prompt (Run as Administrator) and execute the downloaded script. The script performs several actions: (1) Creates registry keys under HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection to store the Org ID and Workspace ID. (2) Installs the Microsoft Defender for Endpoint sensor service (MsSense.exe) if not already present. (3) Sets the service startup type to Automatic. (4) Triggers an initial health check and attempts to connect to the MDE cloud. The script typically completes within 30 seconds. No reboot is required.
Verify onboarding status on the device
After running the script, verify that onboarding succeeded using PowerShell: Get-MpComputerStatus | Select-Object OnboardingState, OrgId. OnboardingState should be 1 (onboarded). OrgId should match the ID from the portal. Alternatively, check the registry: HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status\OnboardingState = 1. Also verify that the service 'Microsoft Defender for Endpoint' (MsSense) is running. If the service is not running, check the event log for errors (Event Viewer > Applications and Services Logs > Microsoft > Windows > SENSE).
Confirm device appears in the portal
Within 5-10 minutes of successful onboarding, the device should appear in the Microsoft 365 Defender portal under Assets > Devices. The status column shows 'Onboarded'. If the device does not appear, check network connectivity: the device must be able to reach *.endpoint.microsoft.com and *.events.data.microsoft.com on TCP 443. Also verify that the device has internet access and that proxy settings are configured correctly. If the device shows as 'Inactive' or 'Onboarding pending', wait 30 minutes for the first heartbeat.
Configure initial policies and test
Once onboarded, the device will automatically download the latest MDE policies from the cloud. To verify end-to-end functionality, you can run a simulated attack test using the Microsoft 365 Defender portal's 'Simulations' feature (Settings > Endpoints > Evaluation lab). This runs a benign attack script that generates alerts. Check that alerts appear in the portal within 10 minutes. Also ensure that real-time protection is enabled (Get-MpComputerStatus shows AMServiceEnabled = True). If needed, adjust policies via the portal to match your security requirements.
In a large enterprise with 10,000 Windows 10 devices, onboarding is typically automated via Group Policy or Intune. For example, a financial services firm uses Intune to onboard all Azure AD-joined laptops. The Intune policy pushes the onboarding configuration silently during device enrollment. This ensures every new device is protected from day one. The firm also uses Configuration Manager for 500 on-premises servers that are not Azure AD-joined. The Configuration Manager client distributes the onboarding script as a software deployment. A common challenge is handling devices that are frequently offline or in remote locations with limited connectivity. The MDE sensor is designed to buffer telemetry locally when offline and upload when connectivity resumes. However, if a device is offline for more than 30 days, the certificate may expire, requiring re-onboarding.
Another scenario involves a university with mixed platforms: Windows, macOS, and Linux. They use Microsoft Endpoint Manager to onboard all managed devices. For Linux servers (Ubuntu and RHEL), they deploy the .deb or .rpm package via Ansible. The onboarding script is embedded in the package. After onboarding, they use the mdatp command-line tool to verify health. A common misconfiguration is forgetting to add the Linux repository for updates; without it, the sensor may fall out of date and stop reporting.
A third scenario is a healthcare provider using Microsoft Defender for Endpoint on mobile devices (Android and iOS). Onboarding is done via the Microsoft Defender for Endpoint app from the app store. The app requires the user to sign in with their corporate credentials. IT configures the app via Intune App Protection Policies. The challenge here is user compliance: if a user does not install the app or sign in, the device remains unprotected. The provider uses conditional access policies to block access to corporate email if the device is not onboarded.
In all scenarios, performance impact is minimal. The MDE sensor uses less than 10% CPU on average and has a small memory footprint (around 200 MB). However, on heavily loaded servers, the sensor may cause slight performance degradation during high I/O operations. Microsoft recommends excluding the sensor processes from antivirus scans to avoid conflicts.
The SC-900 exam tests Defender for Endpoint onboarding primarily under objective 3.3: 'Describe the capabilities of Microsoft Defender for Endpoint.' Expect 2-3 questions on onboarding concepts. The exam focuses on:
Purpose of onboarding: Establishing a trusted connection and enabling telemetry flow. A common wrong answer is that onboarding installs Microsoft Defender Antivirus. Reality: Onboarding installs the MDE sensor; antivirus is a separate component that may already be present.
Onboarding methods: Candidates often confuse Group Policy and Intune. Group Policy is for on-premises domain-joined devices; Intune is for cloud-managed (Azure AD-joined) devices. The exam may ask: 'You need to onboard 100 devices that are joined to Azure AD. Which method should you use?' Answer: Microsoft Endpoint Manager (Intune).
Offboarding behavior: A common trap is that offboarding immediately removes the device from the portal. Reality: The device becomes inactive and is removed after 7 days. Another trap: offboarding uninstalls Microsoft Defender Antivirus. Reality: Only the MDE sensor is removed; antivirus remains.
Supported platforms: The exam may list Windows, Linux, macOS, Android, iOS. A wrong answer might include 'Windows 7' (not supported) or 'iOS' (supported). Actually, Windows 7 SP1 is supported with ESU. iOS is supported via the Defender app.
Integration with Microsoft 365 Defender: Onboarding enables alerts to appear in the unified portal. A wrong answer might say alerts appear only in the Defender for Endpoint portal. Reality: Alerts appear in the Microsoft 365 Defender portal.
To eliminate wrong answers, focus on the mechanism: onboarding is about installing a sensor that sends telemetry to the cloud. Any answer that suggests local-only protection or removal of antivirus is likely incorrect. Also remember that onboarding does not require a reboot, and the sensor communicates over HTTPS outbound only.
Onboarding installs the MDE sensor (MsSense.exe) and establishes a cloud connection using a tenant-specific Workspace ID and Org ID.
The default heartbeat interval is 5 minutes; a device is marked inactive after 30 minutes of no heartbeat.
Offboarding stops telemetry; the device is removed from the portal after 7 days of inactivity.
Supported platforms include Windows 10/11, Windows Server, Linux, macOS, Android, and iOS.
Onboarding methods: Local Script, Group Policy, Microsoft Endpoint Manager (Intune), Microsoft Configuration Manager.
Onboarding does not require a reboot and does not install Microsoft Defender Antivirus.
The sensor communicates outbound over HTTPS (TCP 443) only; no inbound ports are needed.
Proxy settings can be configured via the Set-MpPreference PowerShell cmdlet.
These come up on the exam all the time. Here's how to tell them apart.
Local Script Onboarding
Best for single devices or small numbers.
Manual execution required on each device.
No dependency on Active Directory.
Script must be run with administrative privileges.
No centralized reporting of onboarding status.
Group Policy Onboarding
Best for domain-joined Windows devices in bulk.
Automated via Group Policy refresh (90 minutes default).
Requires Active Directory domain.
Policy can be scoped to OUs.
Centralized management via Group Policy Management Console.
Mistake
Onboarding installs Microsoft Defender Antivirus.
Correct
Onboarding installs the Microsoft Defender for Endpoint sensor, not the antivirus. Microsoft Defender Antivirus is a separate component that may already be installed on Windows 10/11. The sensor integrates with the antivirus but does not replace it.
Mistake
Onboarding requires a reboot.
Correct
No reboot is required after running the onboarding script. The sensor service starts automatically and begins telemetry collection without a restart.
Mistake
Offboarding immediately removes the device from the portal.
Correct
Offboarding stops telemetry, but the device remains visible in the portal for 7 days with an 'Inactive' status. After 7 days, it is automatically removed.
Mistake
Onboarding is only for Windows devices.
Correct
Defender for Endpoint supports Windows, Linux, macOS, Android, and iOS. Onboarding packages are available for each platform.
Mistake
The onboarding script contains the tenant's global admin credentials.
Correct
The script contains only the Workspace ID and Org ID, which are tenant-specific identifiers. No passwords or admin credentials are included.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Onboarding installs the MDE sensor and connects the device to the cloud service, enabling telemetry and protection. Offboarding reverses this: it removes the sensor and certificate, stopping all telemetry. After offboarding, the device remains visible in the portal for 7 days as 'Inactive' before being automatically removed. Offboarding is used when retiring a device or migrating to a different tenant.
No, the MDE sensor requires outbound internet connectivity to Microsoft cloud endpoints (TCP 443). If the device is offline, the sensor cannot register or send telemetry. However, once onboarded, the sensor can buffer telemetry locally for up to 30 days and upload when connectivity is restored. For air-gapped environments, consider using Microsoft Defender for Endpoint for Government or a dedicated cloud instance.
The MDE sensor is lightweight, typically using less than 10% CPU and 200 MB of memory. On modern hardware, the performance impact is negligible. However, on older or heavily loaded servers, there may be slight overhead during high I/O operations. Microsoft recommends excluding sensor processes from antivirus scans to avoid conflicts.
First, verify that the device has internet access and can reach the required endpoints (e.g., *.endpoint.microsoft.com). Check if a firewall or proxy is blocking outbound HTTPS. On the device, run `Get-MpComputerStatus` to confirm the onboarding state and Org ID. If the Org ID is missing or incorrect, re-run the onboarding script. Also check the SENSE event log for errors.
No, each onboarding package is tenant-specific. The Workspace ID and Org ID are unique to your tenant. Using a package from another tenant will cause authentication failure. You must download a separate package for each tenant.
Yes, you can use Microsoft Endpoint Manager (Intune) or Configuration Manager to deploy onboarding policies. These tools automate the distribution of the onboarding configuration. Alternatively, you can use a third-party management tool to run the onboarding script remotely.
The sensor automatically renews its certificate as long as it can reach the cloud. If the device is offline for more than 30 days, the certificate may expire, causing the device to become unresponsive. In that case, you need to re-onboard the device by running the onboarding script again.
You've just covered Defender for Endpoint Onboarding — now see how well it sticks with free SC-900 practice questions. Full explanations included, no account needed.
Done with this chapter?