Synqly Adds Microsoft Defender EASM Integration for Exposure Data

Synqly’s Vulnerabilities Unified API now supports Microsoft Defender External Attack Surface Management. Security vendors building on Synqly can connect directly to Defender EASM and give their OEM customers visibility into internet-facing assets and the findings tied to them, without carrying the engineering cost of building and maintaining that connector on their own.

What is Microsoft Defender EASM?

Microsoft Defender External Attack Surface Management, generally shortened to Defender EASM, is part of Microsoft’s security portfolio and is built to discover and inventory the assets an organization exposes to the public internet, including domains, hosts, and infrastructure a security team may not know it owns.

Rather than starting from an asset list the organization already maintains, Defender EASM builds that list from the outside in, the same way an attacker doing reconnaissance would. That approach is what makes it useful for finding shadow IT, forgotten subdomains, and infrastructure left behind after an acquisition or a migration.

What the Synqly Microsoft Defender EASM Integration Does

OEM customers building on Synqly can query assets and query findings from a customer’s Defender EASM environment through one consistent API, rather than writing a separate connector for Defender EASM’s own data model. Both operations support filtering, so a product asks for exactly the subset of the external attack surface it needs:

Operation	Filter by
Query assets	Device hostname, IP address, device name, device type, status, and labels applied within Defender EASM, so a product pulls a targeted subset rather than every discovered asset.
Query findings	Severity, confidence, finding title, and remediation state, so a product can tell a high-confidence, high-severity exposure from a low-confidence one still awaiting validation before routing it downstream.

Together, these two capabilities give security products the raw material to fold externally discovered attack surface data into the same risk view they already build from internally sourced vulnerability data, closing a gap that exists whenever an organization only scans what it already knows it owns.

Full configuration and setup instructions are covered as part of the Vulnerabilities Connector documentation on the Synqly documentation site.

How This Fits Synqly’s Existing Microsoft Coverage

This integration extends Microsoft’s presence inside the Synqly ecosystem rather than introducing Microsoft for the first time. Synqly customers already connect to Microsoft across several categories:

• Vulnerability management through Microsoft Defender for Endpoint.
• SIEM through Microsoft Sentinel.
• Identity through Microsoft Entra ID.
• Network security through Microsoft Azure Network Security.

This new Defender EASM integration adds a second Microsoft provider to the Vulnerabilities category specifically, alongside Defender for Endpoint. Each integration is documented in full on its own page.

Where to Find More Details

Full details on the Microsoft Defender EASM integration, including supported capabilities and schema mappings, live on the Microsoft Defender EASM integration partner page. A full list of every live integration is also maintained on the Synqly integrations page.

How the Vulnerabilities Unified API Works

This Defender EASM integration is part of Synqly’s Vulnerabilities Unified API, built around a problem most OEM security vendors already know well. A vulnerability scanner can only report on what it has been pointed at, and an organization’s own asset inventory is rarely a complete map of what it has actually exposed to the internet over the years.

Instead of standing up and maintaining a separate connection to Defender EASM alongside every other vulnerability and exposure management platform a customer might run, product teams integrate with Synqly once and pick up new providers, including this Defender EASM integration, as Synqly adds them. For a team deciding where to spend limited engineering time, that tends to be the deciding factor: less time on provider-specific schemas, and more time on the detection and prioritization work that differentiates a security product in a crowded market.