Study guide
Technical reference and lesson notes
Purpose of This Lesson
This lesson explains how Microsoft Defender for Endpoint can identify unmanaged devices on a network using Device Discovery.
For the SC-200 exam, this matters because a Microsoft Security Operations Analyst is responsible for understanding where security visibility exists — and where it does not. A device that is connected to the network but not onboarded into Defender for Endpoint creates a monitoring gap. That unmanaged device may be missing endpoint detection and response, vulnerability management, attack surface reduction, automated investigation, and remediation capabilities.
Device Discovery helps analysts and administrators identify those gaps so they can decide whether a device should be onboarded, excluded, scanned, investigated, or escalated to another team.
In a real SOC workflow, unmanaged device discovery supports:
- Asset visibility
- Endpoint coverage validation
- Threat exposure reduction
- Vulnerability management
- Incident scoping
- Identification of unknown or rogue devices
- Prioritization of onboarding efforts
Key Concepts
What Is an Unmanaged Device?
An unmanaged device is a device that Defender for Endpoint can see or infer exists, but that is not fully onboarded into Microsoft Defender for Endpoint.
This could include:
- A Windows workstation not onboarded to Defender for Endpoint
- A server missing the Defender for Endpoint sensor
- A Linux or macOS device on the network
- A mobile device
- A network device
- A device enrolled in Intune but not onboarded into Defender for Endpoint
- A device seen through identity, network, or third-party telemetry
The main issue is that unmanaged devices may be present in the environment but lack full Microsoft Defender for Endpoint protection and visibility.
From a security operations perspective, unmanaged devices are important because attackers often target unmanaged or poorly monitored systems. These devices can become blind spots during incident response.
Where Device Discovery Is Configured
Device Discovery is configured in the Microsoft Defender portal.
A common navigation path is:
Microsoft Defender portal → Settings → Endpoints → Device Discovery
Microsoft portal names and blade locations can change over time, so for exam purposes, focus less on the exact click path and more on the product and feature relationship:
- Product: Microsoft Defender for Endpoint
- Portal: Microsoft Defender portal
- Feature: Device Discovery
- Purpose: Discover unmanaged devices on the network
Device Discovery Modes
Microsoft Defender for Endpoint supports different discovery modes.
The two major modes covered in this lesson are:
| Discovery Mode | Description | When It Matters |
|---|---|---|
| Basic discovery | Passively discovers unmanaged devices based on network events captured by onboarded devices | Useful for lightweight visibility with minimal active scanning |
| Standard discovery | Recommended/default discovery mode that uses broader discovery methods | Best option when you want more complete unmanaged device visibility |
Basic Discovery
Basic discovery uses passive network observation.
In this mode, devices that are already onboarded into Microsoft Defender for Endpoint observe network activity and help identify other devices they communicate with.
For example, an onboarded workstation may communicate with another device on the same network. Defender for Endpoint can use that observed activity to identify that another device exists, even if the second device is not onboarded.
Important characteristics of Basic discovery:
- Passive discovery method
- Relies on onboarded devices observing network traffic or communication events
- Helps identify unmanaged devices
- Does not require active authenticated scanning
- Provides visibility but may be less complete than Standard discovery
This is useful because security teams do not always have a perfect inventory. Passive discovery helps Defender for Endpoint identify devices that may otherwise be missed.
Standard Discovery
Standard discovery is the recommended mode.
It includes passive discovery but can also use additional signals and integrations to improve device visibility.
Standard discovery can identify unmanaged devices using sources such as:
- Onboarded Defender for Endpoint devices
- Microsoft Intune integration
- Microsoft Configuration Manager integration
- Log Analytics-related data sources
- Microsoft Defender for Identity signals
- Third-party integrations
- Alerts or telemetry related to unmonitored devices
Standard discovery is more complete than Basic discovery because it is not limited only to passive observation from onboarded endpoints.
For the SC-200 exam, remember that Standard discovery is the preferred mode when you need better device visibility across the environment.
Onboarded Devices as Discovery Sensors
One of the key ideas is that onboarded devices can help discover unmanaged devices.
An onboarded device acts as a discovery point because it can observe network communications with other systems.
Example:
- A managed Windows workstation is onboarded into Defender for Endpoint.
- That workstation communicates with another device on the same network.
- Defender for Endpoint detects that the second device exists.
- If the second device is not onboarded, it may appear as an unmanaged device.
This is important because Defender for Endpoint does not only protect individual endpoints. It can also contribute to broader network visibility.
Intune Integration and Device Discovery
Microsoft Intune can help identify device management gaps.
A device might be enrolled in Intune but not onboarded into Microsoft Defender for Endpoint. In that case, Microsoft has management information about the device, but the endpoint may still lack full Defender for Endpoint monitoring.
This creates an important operational distinction:
| State | Meaning |
|---|---|
| Enrolled in Intune | Device is managed by Microsoft Intune |
| Onboarded into Defender for Endpoint | Device has Defender for Endpoint sensor/security telemetry |
| Enrolled in Intune but not onboarded to Defender for Endpoint | Device is managed, but endpoint security visibility may be incomplete |
For SC-200, this matters because Intune and Defender for Endpoint are related but not the same thing.
Intune is primarily for endpoint management. Defender for Endpoint is for endpoint security monitoring, investigation, detection, response, vulnerability management, and EDR.
Microsoft Configuration Manager and Discovery
Microsoft Configuration Manager, formerly known as SCCM, can also contribute to endpoint visibility.
Many environments still use the term SCCM, even though the product name changed to Microsoft Endpoint Configuration Manager and is now part of the broader Microsoft Intune family of endpoint management solutions.
In the context of Defender for Endpoint discovery, Configuration Manager can help identify devices that exist in the enterprise but may not yet be onboarded into Defender for Endpoint.
For real-world operations, this is useful because many organizations have multiple inventory sources:
- Active Directory
- Configuration Manager
- Intune
- Defender for Endpoint
- Vulnerability scanners
- CMDB systems
- Network monitoring tools
The SOC analyst should understand that Defender for Endpoint Device Discovery is part of asset visibility, but it may need to be compared with other inventory sources.
Microsoft Defender for Identity Signals
Microsoft Defender for Identity can also help expose unmanaged device activity.
Defender for Identity monitors identity-related activity, especially around Active Directory and authentication behavior. If Defender for Identity sees users or authentication activity associated with devices that are not fully onboarded into Defender for Endpoint, that can help surface unmanaged assets.
This is important because unmanaged devices are not always discovered only through endpoint telemetry. Identity signals can reveal devices that participate in authentication activity.
For example:
- A user authenticates from a device.
- Defender for Identity observes the authentication-related activity.
- The device may not be onboarded into Defender for Endpoint.
- That device becomes relevant for investigation and coverage review.
Third-Party Integrations
Third-party integrations may also contribute discovery information.
Many environments use non-Microsoft tools for vulnerability scanning, endpoint management, asset inventory, network monitoring, or security monitoring. When integrated with Microsoft security tooling, these sources can help improve unmanaged device visibility.
For the exam, the main point is not to memorize every possible third-party integration. The key is understanding that Defender for Endpoint can use multiple telemetry sources to help identify unmanaged devices.
Alerts from Unmonitored Devices
Unmonitored or unmanaged devices may still produce signals that Microsoft security tools can observe.
For example, a device may not be fully onboarded into Defender for Endpoint, but it may still be involved in activity that generates security alerts or appears in related Microsoft 365 security telemetry.
This matters during investigations because a device can appear in an incident even if it is not fully managed. The analyst must recognize that limited telemetry can affect investigation quality.
Selecting Which Devices Perform Standard Discovery
Device Discovery settings can allow administrators to choose which onboarded devices participate in Standard discovery.
The recommended option is generally to allow all supported onboarded devices to participate.
However, organizations may also choose to limit discovery to devices with selected tags.
This can be useful when:
- Only certain network segments should perform discovery
- You want to control discovery behavior in sensitive environments
- You want discovery to run from specific trusted endpoints
- You want to reduce unnecessary discovery activity
- You want to test discovery in a pilot group before broader rollout
Tags can be useful for scoping and targeting.
Example:
| Tag Strategy | Use Case |
|---|---|
| All devices | Broad discovery coverage |
| Selected tags | Controlled discovery from specific devices |
| Pilot discovery tag | Test discovery before enabling more broadly |
| Server subnet tag | Use specific servers or endpoints as discovery points |
CVE-Based Discovery Option
The transcript mentions a setting related to detecting devices with applications affected by a specific CVE.
A CVE, or Common Vulnerabilities and Exposures identifier, is a publicly tracked vulnerability identifier.
In the context of Defender for Endpoint, vulnerability-related discovery can help identify devices that may have applications affected by a specific known vulnerability.
This connects Device Discovery with Microsoft Defender Vulnerability Management concepts.
For SC-200, remember the broader relationship:
- Device Discovery helps find unmanaged devices.
- Vulnerability management helps identify weaknesses and exposures.
- CVE-based detection helps prioritize vulnerable systems.
- Unmanaged vulnerable devices represent higher risk because they may not have full endpoint protection.
Discovery Exclusions
Device Discovery supports exclusions.
Administrators can exclude specific:
- IP addresses
- IP ranges
- Subnets
This is useful when certain devices or networks should not be discovered or scanned.
Reasons to use exclusions may include:
- Sensitive systems
- Network devices that should not be scanned
- Lab networks
- Third-party managed networks
- Devices that generate false positives
- Networks outside the organization’s scope
- Environments where scanning may create operational risk
From a SOC perspective, exclusions should be documented carefully. Excluding devices or networks can reduce noise, but it can also create blind spots.
Monitored Networks
The Device Discovery settings include monitored networks.
Monitored networks help show which networks Defender for Endpoint is observing for discovery purposes.
This matters because discovery results are only useful when the analyst understands where the visibility is coming from.
A device not appearing in discovery does not always mean it does not exist. It may mean:
- The network is not monitored
- No onboarded device is communicating with it
- Discovery has not completed yet
- The device is excluded
- The device is in a segmented network
- The telemetry source is limited
- Discovery data has not fully populated
Authenticated Scans
Authenticated scans allow Defender for Endpoint to perform deeper discovery against specified devices.
The lesson shows two types of authenticated scans:
- Network device authenticated scan
- Windows authenticated scan
An authenticated scan requires information such as:
- Scan name
- Target devices, IP addresses, hostnames, or imported CSV file
- Authentication method
- Domain information, if applicable
- Username and credentials
Authentication options may include Kerberos or negotiated authentication, depending on the scan type and environment.
Authenticated scanning is more active than passive discovery. It can provide deeper information, but it also requires more planning and governance.
Authenticated Scan Inputs
When creating a Windows authenticated scan, common inputs include:
| Input | Purpose |
|---|---|
| Scan name | Identifies the scan configuration |
| Target device, hostname, or IP | Defines what should be scanned |
| CSV import | Allows bulk scan targets to be imported |
| Authentication type | Determines how the scan authenticates |
| Domain | Used when scanning domain-joined systems |
| Username | Account used to authenticate |
| Credentials | Required to perform the authenticated scan |
This is not something a SOC analyst should configure casually in production without approval. Authenticated scans can involve credentials, network access, and operational risk.
Discovery Timing
Device discovery may take time.
If you add a new unmanaged device to a network, it may not immediately appear in Defender for Endpoint. Discovery depends on telemetry, scan configuration, network communication, and Microsoft service processing.
In lab environments, a useful test is to create a new virtual machine on the same network as an onboarded device and leave it unmanaged. Eventually, Defender for Endpoint may discover it.
For the exam, remember that Microsoft security portal results are not always instant. Some settings and discovery results may take time to populate.
Microsoft Security Operations Context
How Device Discovery Fits into a SOC Workflow
Device Discovery supports the SOC by helping answer a basic but critical question:
What devices exist in the environment, and which ones are not protected?
A security analyst may use Device Discovery during:
- Incident triage
- Asset visibility review
- Vulnerability management
- Endpoint onboarding validation
- Threat hunting
- Exposure management
- Attack surface reduction planning
Triage an Alert
If an alert involves an unknown device, the analyst should determine whether the device is:
- Managed
- Unmanaged
- Onboarded into Defender for Endpoint
- Enrolled in Intune
- Known in Configuration Manager
- Associated with a user identity
- Present in Defender for Identity telemetry
- Expected on the network
- Potentially rogue or unauthorized
An unmanaged device involved in suspicious activity should be treated as a visibility and response concern.
Investigate an Incident
During incident investigation, Device Discovery can help identify whether a device in the incident has full telemetry.
Important investigation questions include:
- Is the device onboarded into Defender for Endpoint?
- Is endpoint timeline data available?
- Is vulnerability data available?
- Is the device associated with a user?
- Is the device communicating with managed endpoints?
- Is the device part of a monitored network?
- Has it appeared in other incidents or alerts?
- Is it excluded from discovery?
- Is it a legitimate asset?
If the device is unmanaged, the analyst may need to escalate to endpoint, infrastructure, or asset management teams.
Review Entities
Device Discovery can support investigation of entities such as:
- Devices
- IP addresses
- Hostnames
- Users
- Network segments
- Vulnerabilities
- Applications
- Cloud or hybrid assets
In Microsoft security operations, entities are important because incidents are not just isolated alerts. They are connected to users, devices, IP addresses, files, mailboxes, and other resources.
Determine Scope and Impact
Unmanaged devices can affect scope determination.
For example, if malware is found on one managed device and that device communicated with several unmanaged devices, the analyst may need to determine whether those unmanaged devices were also affected.
The lack of Defender for Endpoint telemetry may limit visibility, so the analyst may need additional data sources such as:
- Firewall logs
- DHCP logs
- DNS logs
- VPN logs
- Active Directory logs
- Intune inventory
- Configuration Manager inventory
- Microsoft Sentinel logs
- Network detection tools
Contain or Remediate a Threat
Containment options may be limited for unmanaged devices.
A managed Defender for Endpoint device can support response actions such as isolation, investigation package collection, antivirus scans, and remediation actions.
An unmanaged device may not support those same response actions until it is onboarded.
This is a key operational point:
You cannot rely on Defender for Endpoint response actions for devices that are not onboarded.
If an unmanaged device is suspicious, the SOC may need to escalate to:
- Endpoint engineering
- Infrastructure team
- Network team
- Identity team
- Desktop support
- Server team
- Cloud operations
- Incident response team
Containment may require network-level action instead of endpoint-level action.
Escalate to Another Team
Device Discovery findings often require cross-team coordination.
Examples:
| Finding | Likely Escalation |
|---|---|
| Unknown workstation on network | Desktop support or endpoint team |
| Unmanaged server | Server/infrastructure team |
| Unknown IP in sensitive subnet | Network team |
| Device linked to suspicious identity activity | Identity/security team |
| Vulnerable unmanaged device | Vulnerability management or asset owner |
| Device enrolled in Intune but missing Defender onboarding | Endpoint management team |
The SOC analyst should document the finding, explain the risk, and provide enough evidence for the owning team to act.
Document Findings
Good incident documentation should include:
- Device name or hostname
- IP address
- Discovery source
- Whether the device is managed or unmanaged
- Whether it is onboarded into Defender for Endpoint
- User association, if known
- Network location
- Related alerts or incidents
- Risk or exposure
- Recommended next action
- Escalation owner
- Date and time discovered
This documentation matters because unmanaged devices may require follow-up outside the SOC.
Improve Future Detection
Device Discovery can help improve future detection by identifying gaps in endpoint coverage.
Possible improvements include:
- Onboarding unmanaged devices to Defender for Endpoint
- Expanding Intune enrollment
- Reviewing Configuration Manager inventory
- Enabling Standard discovery
- Adjusting monitored networks
- Adding authenticated scans
- Reviewing discovery exclusions
- Improving asset inventory
- Creating Sentinel analytics rules for unmanaged device activity
- Creating watchlists of approved unmanaged devices or exceptions
Exam-Relevant Takeaways
For the SC-200 exam, remember these points:
- Device Discovery is a Microsoft Defender for Endpoint feature.
- It is used to identify unmanaged devices.
- Unmanaged devices are devices that are seen in the environment but are not fully onboarded into Defender for Endpoint.
- Basic discovery is passive and relies on onboarded devices observing network activity.
- Standard discovery is recommended and uses broader discovery methods.
- Onboarded devices can act as discovery sensors.
- Intune enrollment does not automatically mean a device is onboarded into Defender for Endpoint.
- Configuration Manager may help identify devices that exist in the environment.
- Defender for Identity signals may help identify devices involved in identity activity.
- Authenticated scans provide deeper discovery but require credentials and planning.
- Exclusions can reduce noise but may create visibility gaps.
- Discovery results may take time to appear.
- For unmanaged devices, Defender for Endpoint response actions may not be available until the device is onboarded.
- In an incident, unmanaged devices may require escalation to endpoint, infrastructure, network, or identity teams.
Tool / Feature Decision Guide
| Scenario | Best Microsoft Security Tool or Feature | Why |
|---|---|---|
| Identify devices on the network that are not onboarded into Defender for Endpoint | Microsoft Defender for Endpoint Device Discovery | Designed to discover unmanaged devices |
| Passively identify unmanaged devices based on onboarded device observations | Basic discovery | Uses onboarded devices to observe network activity |
| Use the recommended and broader discovery approach | Standard discovery | Provides more complete discovery using multiple signals |
| Identify devices managed by endpoint management but missing Defender onboarding | Intune integration with Defender for Endpoint | Helps compare management state with security onboarding |
| Identify devices known to Configuration Manager but missing Defender onboarding | Microsoft Configuration Manager integration | Useful in environments with existing endpoint inventory |
| Identify devices involved in authentication or identity activity | Microsoft Defender for Identity | Identity telemetry can reveal devices tied to user activity |
| Perform deeper discovery against specific devices using credentials | Authenticated scan | Provides more active discovery than passive observation |
| Exclude a subnet or IP range from discovery | Device Discovery exclusions | Prevents selected devices or networks from being discovered |
| Review which networks are being observed | Monitored networks | Helps understand discovery coverage |
| Investigate security events across multiple Microsoft data sources | Microsoft Sentinel | SIEM/SOAR platform for cross-source correlation and investigation |
| Respond directly to a managed endpoint | Microsoft Defender for Endpoint response actions | Requires device onboarding for full endpoint response capability |
| Track vulnerable devices and CVE exposure | Defender Vulnerability Management | Helps prioritize exposure and remediation |
KQL Notes
This lesson does not focus on KQL directly. However, Device Discovery concepts can connect to KQL when using Microsoft Defender Advanced Hunting or Microsoft Sentinel to investigate device inventory, unmanaged assets, or suspicious activity.
Example Only: Review Device Inventory in Advanced Hunting
DeviceInfo
| project Timestamp, DeviceName, DeviceId, OSPlatform, OnboardingStatus, SensorHealthState
| order by Timestamp desc
What This Example Does
| Query Part | Purpose |
|---|---|
DeviceInfo | Queries device inventory and device metadata |
project | Selects the most relevant columns |
OnboardingStatus | Helps identify whether the device is onboarded |
SensorHealthState | Helps identify whether the Defender sensor is healthy |
order by Timestamp desc | Shows the most recent records first |
How This Helps in an Investigation
An analyst could use a query like this to review device onboarding status and sensor health. This can help identify devices that may have incomplete Defender for Endpoint visibility.
For the SC-200 exam, focus on the idea that KQL can be used to query device, alert, identity, email, and cloud telemetry when the data is available. Device Discovery itself is configured in Defender for Endpoint settings, not by writing KQL.
Common Exam Traps
Confusing Intune Enrollment with Defender for Endpoint Onboarding
A device can be managed by Intune but still not fully onboarded into Defender for Endpoint.
Intune answers the question:
Is the device managed?
Defender for Endpoint answers the question:
Is the device protected and monitored by endpoint security telemetry?
Confusing Microsoft Defender XDR with Microsoft Sentinel
Microsoft Defender XDR correlates incidents across Microsoft Defender products.
Microsoft Sentinel is a cloud-native SIEM/SOAR that collects and analyzes data from Microsoft and non-Microsoft sources.
Device Discovery belongs to Microsoft Defender for Endpoint, not Sentinel.
Assuming Discovery Is Instant
Discovery can take time. Microsoft security portal data may not appear immediately after a device is added to the network.
For exam scenarios, avoid answers that assume instant visibility unless the question explicitly states the data is already available.
Assuming Unmanaged Devices Support Endpoint Response Actions
A device must be onboarded into Defender for Endpoint to support full Defender for Endpoint response actions.
If a device is unmanaged, response may require:
- Network isolation outside Defender for Endpoint
- Manual investigation
- Endpoint onboarding
- Escalation to another operations team
Ignoring Discovery Exclusions
Exclusions can prevent devices or networks from appearing in discovery results.
If a device is missing from discovery, consider whether it is:
- Excluded
- On an unmonitored network
- Not communicating with onboarded devices
- Not scanned yet
- Not visible to current telemetry sources
Choosing Basic Discovery When Standard Discovery Is Required
Basic discovery is passive and more limited.
Standard discovery is the recommended mode when broader unmanaged device visibility is needed.
Forgetting Credential and Governance Concerns for Authenticated Scans
Authenticated scans require credentials and may touch production systems. In a real environment, this requires planning, approval, and documentation.
Do not treat authenticated scans as a casual SOC action.
Real-World SOC Analyst Notes
Alert Fatigue and Asset Noise
Device Discovery can generate a lot of asset visibility. Not every unmanaged device is malicious.
A SOC analyst should avoid treating every unmanaged device as an incident. Instead, prioritize based on:
- Network location
- Device type
- Exposure
- Vulnerability status
- User association
- Communication with critical systems
- Suspicious activity
- Whether the device is expected or unknown
False Positives
Some discovered devices may be expected but unmanaged by design.
Examples:
- Printers
- Network appliances
- Lab systems
- Vendor-managed devices
- OT or IoT devices
- Guest network devices
- Temporary build systems
These should be reviewed and documented rather than ignored.
Investigation Quality
When an incident involves an unmanaged device, investigation quality may be limited because Defender for Endpoint may not have:
- Full process timeline
- File events
- Registry events
- Network connection history
- Logged-on user details
- Automated investigation results
- Response action capability
This should be clearly stated in incident notes.
Escalation Paths
Unmanaged device findings often require another team to act.
A strong escalation should include:
- What was discovered
- Why it matters
- Which device or IP is involved
- Whether it is known or unknown
- What risk exists
- What action is requested
- Whether the device should be onboarded, isolated, or investigated
Evidence Preservation
If an unmanaged device is suspicious, avoid taking destructive action before preserving evidence when possible.
Depending on severity, evidence may include:
- Network logs
- Firewall logs
- DHCP lease history
- DNS queries
- Authentication logs
- User association
- Switch port information
- Endpoint forensic data, if available
- Screenshots or exports from Defender portal
Automation Safety
Device Discovery itself is about visibility, but follow-up actions may involve automation or remediation.
Be careful when automating responses involving unmanaged devices because the device may not be fully classified. Automatically blocking or isolating based only on discovery status could disrupt business operations.
Change Control
Authenticated scans and discovery configuration changes may require change approval in production environments.
Reasons include:
- Credential usage
- Network scanning behavior
- Potential impact to fragile systems
- Sensitive subnet visibility
- Governance requirements
- Audit requirements
Tenant-Wide Impact
Discovery settings may affect broad visibility across the tenant. Enabling Standard discovery for all supported onboarded devices can improve coverage, but it should still be understood and communicated.
Changes to discovery settings should be documented.
Access Permissions
Not every analyst should necessarily be able to configure discovery settings or authenticated scans.
Permissions should align with role responsibilities. SOC analysts may need visibility into discovered devices, while configuration changes may be limited to Defender administrators or endpoint security engineers.
Data Retention and Cost Considerations
Device Discovery itself is a Defender for Endpoint feature, but related investigation data may also flow into Microsoft Sentinel if connected.
Sentinel cost considerations are important because Sentinel charges are commonly tied to data ingestion and retention. If discovery-related logs, endpoint telemetry, or other security data are ingested into Sentinel, the organization should understand retention and cost implications.
Quick Reference Summary
- Device Discovery is part of Microsoft Defender for Endpoint.
- It helps identify unmanaged devices on the network.
- Unmanaged devices are visibility gaps and potential security risks.
- Basic discovery is passive.
- Standard discovery is recommended and uses broader telemetry.
- Onboarded devices can help discover unmanaged devices.
- Intune-managed does not always mean Defender-onboarded.
- Configuration Manager and Defender for Identity can contribute useful signals.
- Authenticated scans provide deeper discovery but require credentials and planning.
- Exclusions can reduce noise but create blind spots.
- Monitored networks help show discovery coverage.
- Discovery results may take time to appear.
- Unmanaged devices may require escalation because Defender response actions may be limited.
- In incidents, always determine whether the device is managed, onboarded, expected, and in scope.
Flashcards
Q: What Microsoft product includes Device Discovery for identifying unmanaged endpoints?
A: Microsoft Defender for Endpoint.
Q: What is an unmanaged device in Defender for Endpoint?
A: A device that Defender can discover or observe but that is not fully onboarded into Defender for Endpoint.
Q: What is Basic discovery?
A: A passive discovery mode where onboarded devices identify unmanaged devices by observing network activity.
Q: What is the recommended discovery mode for broader unmanaged device visibility?
A: Standard discovery.
Q: Why are unmanaged devices important to a SOC analyst?
A: They represent visibility gaps and may not support full endpoint detection, investigation, or response actions.
Q: Does Intune enrollment automatically mean a device is onboarded into Defender for Endpoint?
A: No. A device can be managed by Intune but not onboarded into Defender for Endpoint.
Q: What Microsoft tool can help identify devices involved in authentication activity?
A: Microsoft Defender for Identity.
Q: What is an authenticated scan used for?
A: It performs deeper discovery against specified devices using credentials.
Q: Why should authenticated scans be handled carefully?
A: They require credentials and may affect production systems, so they need planning and governance.
Q: What can Device Discovery exclusions be based on?
A: IP addresses, IP ranges, or subnets.
Q: Why might a discovered device not support Defender for Endpoint response actions?
A: Because it is not onboarded into Defender for Endpoint.
Q: What should an analyst do if a suspicious unmanaged device is found?
A: Investigate available telemetry, document the finding, and escalate to the appropriate team for containment, onboarding, or further analysis.
Q: What is the difference between Microsoft Sentinel and Defender for Endpoint Device Discovery?
A: Sentinel is a SIEM/SOAR for cross-source detection and response, while Device Discovery is a Defender for Endpoint feature for finding unmanaged devices.
Q: Why might discovery results not appear immediately?
A: Discovery depends on telemetry, network communication, scan configuration, and Microsoft service processing time.
Q: What is the main risk of excluding networks from Device Discovery?
A: Exclusions can create visibility gaps.
Practice Questions
Question 1:
A security analyst is reviewing Microsoft Defender for Endpoint and notices several devices on the corporate network are not onboarded. The organization wants to identify unmanaged devices using the recommended discovery approach.
Which feature should be configured?
A. Microsoft Sentinel watchlists
B. Microsoft Defender for Endpoint Device Discovery using Standard discovery
C. Microsoft Defender for Office 365 Explorer
D. Microsoft Entra Conditional Access
Correct Answer:
B. Microsoft Defender for Endpoint Device Discovery using Standard discovery
Explanation:
Device Discovery in Microsoft Defender for Endpoint is used to identify unmanaged devices. Standard discovery is the recommended mode because it uses broader discovery methods than Basic discovery.
Question 2:
A device is enrolled in Microsoft Intune but does not appear to have Defender for Endpoint telemetry. What is the most accurate interpretation?
A. The device is fully protected by Defender for Endpoint because it is enrolled in Intune
B. The device is managed, but may not be onboarded into Defender for Endpoint
C. The device must be excluded from Device Discovery
D. The device can only be investigated in Defender for Office 365
Correct Answer:
B. The device is managed, but may not be onboarded into Defender for Endpoint
Explanation:
Intune enrollment and Defender for Endpoint onboarding are related but separate states. Intune manages devices, while Defender for Endpoint provides endpoint security telemetry and response capabilities.
Question 3:
A SOC analyst discovers suspicious traffic involving an unmanaged device. The analyst wants to isolate the device using Microsoft Defender for Endpoint, but the device is not onboarded.
What is the best next step?
A. Use Defender for Endpoint device isolation immediately
B. Ignore the device because unmanaged devices are outside SOC scope
C. Escalate to the appropriate endpoint or network team for containment and investigation
D. Create a Microsoft Sentinel workbook
Correct Answer:
C. Escalate to the appropriate endpoint or network team for containment and investigation
Explanation:
Defender for Endpoint response actions require the device to be onboarded. If the device is unmanaged, containment may require network-level or endpoint-team action.
Question 4:
An organization wants to perform deeper discovery against a list of Windows devices by providing credentials and target hostnames. Which option should be used?
A. Basic discovery
B. Windows authenticated scan
C. Defender for Office 365 Safe Links
D. Microsoft Sentinel entity mapping
Correct Answer:
B. Windows authenticated scan
Explanation:
Authenticated scans allow deeper discovery by authenticating to specified targets. A Windows authenticated scan can use hostnames, IP addresses, domain details, and credentials.
Question 5:
A device does not appear in Defender for Endpoint Device Discovery. Which explanation is most reasonable?
A. The device definitely does not exist
B. The device must be fully secure
C. The device may be excluded, on an unmonitored network, not communicating with onboarded devices, or not discovered yet
D. The device must be managed by Defender for Office 365
Correct Answer:
C. The device may be excluded, on an unmonitored network, not communicating with onboarded devices, or not discovered yet
Explanation:
Device Discovery depends on visibility sources, monitored networks, exclusions, telemetry, and time. A missing device does not always mean the device does not exist.