Forum Discussion

danny_grasso's avatar
danny_grasso
Brass Contributor
Mar 20, 2025

Roadmap for TVM network devices?

I see that agent based scanning for network devices is being deprecated for Defender TVM in November this year. It's not clear what the replacement solution to this will be - while the product support is not exhaustive, for perimeter devices getting TVM information as part of the Defender for Cloud for Servers license is a valuable addition.

Is there any roadmap information, or documentation that outlines how we'll be able to achieve the same outcome of TVM information for network devices for weaknesses and threats? 

I've been looking but cannot find a clear direction on this or whether I'll need to start looking at 3rd party for TVM on network devices.

1 Reply

  • This is a good question, and many organizations are trying to understand the direction here since the agent-based / Windows authenticated scanning used by Defender Threat & Vulnerability Management (TVM) for network devices is being deprecated.

    Historically, TVM could collect vulnerability information from network devices through authenticated scans using SNMP, where a Defender-onboarded machine acted as the scanning host. This allowed routers, switches, and other infrastructure devices to appear in the Defender inventory with some vulnerability insights.

    Microsoft has been gradually shifting away from that model. The main reason is that the architecture relied on:

    • A scanning host running Defender for Endpoint
    • SNMP credentials configured for infrastructure devices
    • Scheduled authenticated scans

    Instead, the platform direction appears to be moving toward discovery and telemetry-based approaches rather than active authenticated scans.

    A few components in the Defender ecosystem are relevant here.

    First, device discovery in Defender for Endpoint.
    This feature allows onboarded endpoints to identify unmanaged devices on the network (routers, switches, printers, IoT devices, etc.) using network telemetry and active probing.

    Microsoft documentation:
    https://learn.microsoft.com/en-us/defender-endpoint/device-discovery

    Second, network device discovery and assessment capabilities that were previously tied to TVM scanning.

    Documentation:
    https://learn.microsoft.com/en-us/defender-endpoint/network-devices

    However, for deeper vulnerability visibility on network and IoT devices, Microsoft is increasingly positioning Microsoft Defender for IoT as the dedicated platform.

    Microsoft Defender for IoT overview:
    https://learn.microsoft.com/en-us/azure/defender-for-iot/overview

    Defender for IoT is designed specifically to monitor:

    • network infrastructure
    • OT environments
    • unmanaged or agentless devices

    which aligns more closely with the type of devices TVM previously scanned.

    For cloud and hybrid infrastructure, Microsoft Defender for Cloud also plays a role in posture management and vulnerability assessment.

    Overview:
    https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-cloud-introduction

    So the practical architecture many organizations are moving toward is:

    • Defender for Endpoint → endpoint vulnerability management and device discovery
    • Defender for IoT → visibility and risk assessment for network / OT / IoT devices
    • Defender for Cloud → cloud and hybrid infrastructure security posture

    Because of this shift, environments that previously relied on TVM authenticated scanning for routers, switches, or firewalls are often supplementing the Defender stack with:

    • Defender for IoT
    • or dedicated vulnerability scanners such as Tenable, Qualys, or Rapid7 for network infrastructure

    At the moment Microsoft hasn’t published a very explicit “direct replacement” feature announcement for the deprecated TVM scanning model, which is why the roadmap can feel unclear. But the direction toward device discovery combined with specialized monitoring platforms like Defender for IoT appears to be the long-term approach.