Network Discovery Scans

Last updated: December 19, 2025

Network Discovery is used to identify devices on a local network and convert eligible devices into Targets for follow-on scans (such as vulnerability, secure baseline, and data sensitivity scans). It is typically the first scan performed in a new environment because it establishes asset visibility and validates connectivity, permissions, and allowlisting.

This article describes Network Discovery from an operational perspective: what it does, how it works, what it requires, and its limitations.

Important Platform Requirement

Network Discovery scans must be performed using a Windows-based scan agent.

  • Network Discovery is not supported on Linux or macOS agents.

  • A Windows scan agent acts as the network sensor (probe) for all Network Discovery activity.

If Network Discovery is required, ensure at least one Windows scan agent is deployed within the target network.

What Network Discovery Does

A Network Discovery scan enumerates devices within a defined IP scope and attempts to collect identifying and security-relevant network attributes. Depending on network permissions and credentials, it can enrich results with additional details such as operating system, hostname, and service information.

Network Discovery is commonly used to:

  • Establish an inventory of network-connected devices

  • Identify unmanaged or unknown assets

  • Prepare scannable Targets for additional scan types

  • Validate credentialed access before running authenticated scans

Execution Model

  • Execution method: User-installed Windows scan agent

  • Agent type required: Windows only

Credential Behavior (Critical)

Remote scanning and enrichment require valid Windows credentials.

  • Credentials must use NTLM / NetBIOS authentication

  • UPN-based credentials (user@domain.com) are not supported

  • Azure AD / Entra ID credentials are not supported for sensor-based discovery

These requirements apply regardless of where credentials are configured (agent-level or scan-level).

Credential Format and Field Requirements

Network Discovery relies on NTLM-based Windows authentication. Credentials must be provided using NetBIOS conventions and entered correctly into the Cyrisma credential fields.

Supported Authentication Models

  • NTLM / NetBIOS authentication

  • Domain-based and non-domain (workgroup) Windows environments

Unsupported Authentication Models

  • UPN-based authentication (user@domain.com)

  • Azure AD / Entra ID–only identities

Credential Field Usage (Important)

When configuring credentials in Cyrisma, the Username and Domain fields must be populated correctly based on the environment being scanned.

Domain-Based Environments

  • Enter the NetBIOS domain name in the Domain field

  • Enter only the username in the Username field

  • Do not include the domain prefix in the Username field

Providing a domain-qualified username (for example, DOMAIN\username) in the Username field while also supplying a Domain value will cause authentication to fail.

Non-Domain (Workgroup) Environments

  • The Domain field may be left blank

  • Enter a local user account in the Username field

  • The local account must exist on the target systems and have administrative rights

Credential Entry Examples

Scenario

Domain

Username

Result

Domain-joined systems

CORP

scanner

Authentication succeeds

Workgroup systems

(blank)

local_admin

Authentication succeeds

Domain entered twice

CORP

CORP\scanner

Authentication fails

UPN format

(any)

user@corp.local

Authentication fails

Where Credentials Are Configured

Credentials for Network Discovery can be configured in one of two locations. Both methods enforce the same field and format requirements.

Option 1: Agent-Level Credentials (Persistent)

Configuration fields:

  • Username: Domain or local user (no domain prefix)

  • Password

  • Domain:

    • NetBIOS domain name for domain-joined environments

    • Leave blank for non-domain (workgroup) environments

These credentials are used whenever the agent performs remote scanning.

Option 2: Scan-Level Alternative Credentials (Per Scan)

Configuration fields:

  • Username: Domain or local user (no domain prefix)

  • Password

  • Domain:

    • NetBIOS domain name for domain-joined environments

    • Leave blank for non-domain (workgroup) environments

Scan-level credentials apply only to that scan and override agent-level credentials if provided.

Limitations of Sensor-Based Network Discovery

1) Network Dependency

Targets must be:

  • Online

  • Reachable from the probe device

  • Accessible across network segments

Scans may fail or return partial results if:

  • Targets are on isolated VLANs

  • Routing or firewall rules restrict connectivity

  • Devices are only reachable via VPN

2) Credential Requirements

Remote visibility and enrichment depend on valid credentials.

  • Credentials may be domain-based or local, depending on the environment

  • Incorrect, expired, or misformatted credentials will limit results

  • Credential management complexity increases in larger environments

  • The Windows agent service runs as LocalSystem by default, which often lacks remote network access

If remote access fails:

  • Use explicit credentials (agent-level or scan-level) rather than LocalSystem

  • Ensure the account has administrative rights on target systems

  • Restart the agent service after updating credentials

3) Azure AD (Entra ID) Limitations

Sensor-based Network Discovery does not support Azure AD–joined machines.

  • Azure AD authentication differs from NTLM-based authentication

  • NTLM is required for remote sensor-based scanning

  • UPN-based authentication is not supported

As a result, remote Network Discovery of Azure AD–joined machines is not supported. These systems require alternative scanning approaches.

Prerequisites

Choose an Appropriate Probe Device

For best results, the Windows scan agent acting as the probe should:

  • Have stable uptime

  • Have access to all target subnets

  • Not be heavily restricted by endpoint protection tools

Define the Scan Scope

  • Start with a single subnet (for example, /24)

  • Expand only after validating results

  • Confirm routing and firewall rules permit reachability

Data Collected

Depending on permissions and network conditions, Network Discovery may collect:

  • Discovered IP addresses and hostnames

  • Open TCP/UDP ports

  • Operating system fingerprinting

  • Service and protocol information

  • SNMP results (if available)

Not all devices will return the same level of detail.

Results and Target Creation

After Network Discovery completes:

  • Eligible devices can be merged into Targets

  • Targets become available for follow-on scans

Some discovered devices may not be eligible to merge (for example, printers or IoT devices), depending on platform support.

Troubleshooting Common Issues

Results Are Empty

Common causes:

  • Incorrect probe placement

  • Incorrect IP scope

  • Network filtering or IDS/IPS interference

Recommended actions:

  • Validate probe routing and subnet placement

  • Confirm scan scope accuracy

  • Coordinate with network teams to allow discovery traffic

  • Review agent logs

Devices Found but No OS Identified

Common causes:

  • Insufficient or misconfigured credentials

  • Endpoint protection blocking scanning activity

Recommended actions:

  • Confirm Domain and Username fields are entered separately

  • Validate credentials using administrative shares

  • Update the agent service to use a service account with network rights

  • Confirm endpoint protection allowlisting is applied

IP Addresses Shown Instead of Hostnames

Common causes:

  • DNS resolution issues

  • Network restrictions

Recommended actions:

  • Validate DNS forward and reverse lookups from the probe device

  • Confirm DNS reachability and configuration

Logs and Diagnostics

Agent-side logs can be reviewed on the probe device. A common Windows path is:

C:\Cyrisma_Agent

Endpoint protection allowlisting should reference the consolidated Whitelisting & Network Allowlisting documentation for approved paths and executables.

Best Practices

Deploy at least one Windows scan agent per network

  1. Place the scan agent in the same network it is scanning whenever possible

  2. Start with small scan scopes and expand gradually

  3. Use NetBIOS / NTLM credentials with administrative rights

  4. Populate Username and Domain fields correctly based on the environment

  5. Leave the Domain field blank for non-domain (workgroup) environments

  6. Avoid UPN and Azure AD–only credentials

  7. Validate DNS before scanning

  8. Ensure endpoint protection does not interfere with agent activity