Microsoft Defender for Endpoint

Endpoint Protection

Overview

The Microsoft Defender for Endpoint connector integrates with the Microsoft Defender for Endpoint (ATP) REST API to synchronize endpoint inventory and threat-and-vulnerability-management (TVM) data into the Brinqa platform. It retrieves onboarded machines, installed software, and software vulnerabilities, and maps them to hosts, packages, installed packages, vulnerability findings, and vulnerability definitions.

The connector synchronizes the following categories of data:

• Machines — Onboarded devices from the Defender for Endpoint inventory, mapped to hosts
• Packages — Distinct software products discovered across machines
• Installed Packages — Software installations linking a package to the machine it is installed on
• Vulnerabilities — Per-device software vulnerability findings
• Vulnerability Definitions — CVE/recommendation definitions behind the vulnerability findings

Category: Endpoint Protection

---

Data retrieved from Microsoft Defender for Endpoint

Connector Object	Required	Maps to Data Model
Machine	Yes	Host
Vulnerability	Yes	Vulnerability
Vulnerability Definition	Yes	Vulnerability Definition
Package	Yes	Package
Installed Package	Yes	Installed Package

Model relationships

note

For detailed steps on how to view the data retrieved from Microsoft Defender for Endpoint in the Brinqa Platform, see How to view your data.

Setup

Connection settings

When setting up a data integration, select Microsoft Defender for Endpoint from the Connector dropdown and provide the following:

Setting	Required	Default	Description
API URL	Yes	https://api.securitycenter.microsoft.com	Microsoft Defender for Endpoint API URL
Login URL	Yes	https://login.microsoftonline.com	Microsoft Identity Platform authentication URL
Client ID	Yes	—	The service principal client ID. The client ID is generated during service principal registration.
Client secret	No	—	The service principal client secret or password.
Tenant ID	Yes	—	The tenant or domain the credential is authorized for. The tenant ID is generated during service principal registration.
Private key	No	—	The service principal certificate credential's private key and public key.
Maximum retries	No	5	The maximum number of retry attempts before giving up a request
Parallelism	No	4	Number of threads used to download export files in parallel (1-8, default 4; higher values are capped at 8). Applies to the vulnerability export and the software inventory export, both of which are fetched as files - incremental (delta) vulnerability syncs page through the API sequentially and are unaffected by this setting.
Fail sync on error	No	false	Fail the sync when an export file cannot be downloaded or processed. When disabled (default) the affected file is logged and skipped and the rest of the sync completes.
SAS URL validity (hours)	No	6	Number of hours the Azure Blob SAS download URLs remain valid (1–6, default 6)
Connect timeout (seconds)	No	—	How long to wait for a connection to Microsoft to be established. Default is 300.
Read timeout (seconds)	No	—	How long to wait for Microsoft to start answering a request. Default is 120. Raise this if syncs fail with "Read timed out" on a large tenant, where some requests take longer to answer than the default allows.
Export manifest read timeout (seconds)	No	—	How long to wait for Microsoft to answer a request for an export manifest. Default is 900. Microsoft builds a snapshot of every device in the organization before answering, so on a large tenant this takes considerably longer than an ordinary request; raise it if a vulnerability, package or installed package sync fails with "Read timed out" while getting export files.

Authentication

The connector authenticates a service principal using the OAuth 2.0 client-credentials flow, and supports two mutually exclusive credential types — a client secret or a certificate (private key). When a private key is configured, certificate-based authentication is used and the client secret is ignored; otherwise the client secret is used.

Endpoint

Method	URL
POST	{loginUrl}/{tenantId}/oauth2/v2.0/token

Request Body (form-urlencoded)

Parameter	Value
grant_type	client_credentials
client_id	{clientId}
client_secret	{clientSecret}
scope	https://securitycenter.onmicrosoft.com/windowsatpservice/.default

Usage

Once authenticated, all subsequent API requests include the bearer token, which is cached until expiry and refreshed automatically:

Authorization: Bearer <access_token>

The OAuth scope https://securitycenter.onmicrosoft.com/windowsatpservice/.default is used for both the client-secret and certificate flows.

Key and Certificate Generation

1. Generate the private key and certificate in a terminal:

   # Generate private key
   openssl genpkey -algorithm RSA -out private_key.pem
   
   # Generate certificate signing request (enter the requested information at the prompts)
   openssl req -new -key private_key.pem -out csr.pem
   
   # Generate self-signed certificate
   openssl x509 -req -in csr.pem -signkey private_key.pem -out certificate.pem

2. Upload certificate.pem in the Azure portal.

3. Pass private_key.pem and certificate.pem together in the Private key input field (concatenated):

   -----BEGIN PRIVATE KEY-----
   <private_key.pem>
   -----END PRIVATE KEY-----
   -----BEGIN CERTIFICATE-----
   <certificate.pem>
   -----END CERTIFICATE-----

---

Sync Behavior

The connector supports both full and incremental (delta) syncs, and the effective behavior depends on the model and whether a sync-since timestamp is provided:

• Machine — Incremental. When a since timestamp is set, lastSeen gt {since} is added to the $filter; otherwise all machines are enumerated.
• Vulnerability — Incremental with full fallback. When since is null, a full software-vulnerabilities export is downloaded; when since is set, only changes since that time are fetched (SoftwareVulnerabilityChangesByMachine, capped to a maximum of 14 days in the past).
• Vulnerability Definition — Incremental. When a since timestamp is set, updatedOn ge {since} is added to the CVE-catalog $filter; otherwise the full catalog is enumerated.
• Package and Installed Package — Full only. The software listing has no time-based change filter, so every sync enumerates all software and its machine references.

Per-model incremental details are documented under each model's Sync Duration Parameter below.

---

How to obtain Microsoft Defender for Endpoint credentials

Register a Microsoft Azure application

You must create a new application for the Microsoft Defender for Endpoint connector to authenticate with Azure AD and access the Microsoft Defender for Endpoint APIs. To register an application in your Azure AD tenant, follow these steps:

1. Log in to your Microsoft Azure Portal as an administrator.

2. Navigate to and click Microsoft Entra ID.

3. On the left-hand side of the page, click App registrations, and then click New registration.

4. Give your new application a name, select the supported account types, and provide an optional Redirect URI. If you do not have a redirect URI, you can leave the field as is.

   

5. Click Register.

Note: For additional details about registering an application in Azure AD and creating a service principal, see Microsoft Azure documentation.

Obtain Microsoft Azure credentials

After you have created your new Microsoft Azure application, your client and tenant ID display. Copy the Application (client) ID and Directory (tenant) ID as show below:

To obtain your client secret, follow these steps:

1. Click Certificates & secrets and then click New client secret.

2. Provide a description, set an expiry date, and then click Add.

   The new client secret displays. You cannot view the client secret again. There is both a Value and Secret ID. The Value field is what is needed for authentication. Copy the Value field and save it in a secure location.

   

Assign permissions

After you have created your new Microsoft Azure application and obtained the authentication credentials, you must assign the required permissions for the application to access your data. To do so, follow these steps:

1. Navigate to API permissions > Add a permission > APIs my organization uses and select WindowsDefenderATP.

2. Click Application permissions, grant the following permissions, and then click Add permissions:

   • Machine: Machine.Read.All

   • Security Recommendation: SecurityRecommendation.Read.All

   • Software: Software.Read.All

   • User: User.Read.All

   • Vulnerability: Vulnerability.Read.All

3. Click Grant admin consent for default directory, and then click Yes in the confirmation dialog. Your API permissions should resemble the following:

   

Note: For additional information about Azure AD permissions, see Microsoft Azure documentation.

Generate a private key and certificate

If you choose to authenticate using a private key, you must generate a private key and certificate, upload the certificate to Azure, and then enter the combined string into the Private key field in the integration configuration.

Use your organization's approved method to generate the private key and certificate. If no method is available, or for testing purposes, you can follow the steps below to create a self-signed certificate using OpenSSL:

1. Open your terminal and generate a new private key:

   openssl genpkey -algorithm RSA -out private_key.pem

2. Generate a certificate signing request (CSR). Enter the required information when prompted:

   openssl req -new -key private_key.pem -out csr.pem

3. Generate a self-signed certificate:

   openssl x509 -req -in csr.pem -signkey private_key.pem -out certificate.pem

4. In the Microsoft Azure Portal, navigate to your registered Azure application.

5. On the left-hand side of the page, click Certificates & secrets, click the Certificates tab, and then click Upload certificate.

   Upload the certificate.pem file you created in step 3.

6. Click Add.

7. Combine private_key.pem and certificate.pem into a single string, and paste the result into the Private key field in the integration configuration. Use the following format:

   -----BEGIN PRIVATE KEY-----
   <contents of private_key.pem>
   -----END PRIVATE KEY-----
   -----BEGIN CERTIFICATE-----
   <contents of certificate.pem>
   -----END CERTIFICATE-----

Note: For more information, see the Microsoft documentation on certificate credentials.

Data & mappings

Attribute mappings

Expand the sections below to view the mappings between the source and the Brinqa data model attributes:

Machine

Source Field Name	SDM Attribute
aadDeviceId (excludes all-zero GUID)	AAD_DEVICE_ID
agentVersion	AGENT_VERSION
computerDnsName (normalized)	HOSTNAMES
computerDnsName (private)	PRIVATE_DNS_NAMES
computerDnsName (public)	PUBLIC_DNS_NAMES
computerDnsName → lastExternalIpAddress → lastIpAddress → first ipAddress → aadDeviceId	NAME
constants	CATEGORIES
defenderAvStatus	AV_STATUS
derived from healthStatus	STATUS
deviceValue	DEVICE_VALUE
exclusionReason	EXCLUSION_REASON
exposureLevel	EXPOSURE_LEVEL
firstSeen	FIRST_SEEN
healthStatus	HEALTH_STATUS
ipAddresses (Ethernet), lastIpAddress, lastExternalIpAddress	IP_ADDRESSES
ipAddresses[].macAddress (normalized)	MAC_ADDRESSES
isAadJoined	IS_AAD_JOINED
isExcluded	IS_EXCLUDED
isPotentialDuplication	POTENTIAL_DUPLICATION
lastSeen	LAST_SEEN
local IPs from ipAddresses, lastIpAddress	PRIVATE_IP_ADDRESSES
machine tags (InstanceId) or vmMetadata.vmId	INSTANCE_ID
machine.id	UID
machineTags	TAGS
managedBy	MANAGED_BY
managedByStatus	MANAGED_BY_STATUS
mergedIntoMachineId	MERGED_INFO_MACHINE_ID
non-local IP / lastExternalIpAddress	PUBLIC_IP_ADDRESSES
onboardingStatus	ONBOARDING_STATUS
operatingSystem else computerDnsName	DESCRIPTION
osArchitecture	OS_ARCHITECTURE
osBuild	OS_BUILD
osPlatform	OS_PLATFORM
osPlatform + version + osArchitecture + osBuild	OPERATING_SYSTEM
osProcessor	OS_PROCESSOR
osVersion	OS_VERSION
rbacGroupId	RBAC_GROUP_ID
rbacGroupName	RBAC_GROUP_NAME
riskScore	SOURCE_RISK_RATING
sync timestamp	LAST_CAPTURED
vmMetadata.cloudProvider	CLOUD_PROVIDER
vmMetadata.resourceId	CLOUD_RESOURCE_ID
vmMetadata.subscriptionId	CLOUD_SUBSCRIPTION_ID

Vulnerability

Source Field Name	SDM Attribute
cveId	CVE_ID
derived (software + disk/registry paths)	RESULTS
derived from status	STATUS_CATEGORY
deviceId	TARGETS
deviceId	DEVICE_ID
deviceName	HOSTNAMES
deviceName	DEVICE_NAME
diskPaths	DISK_PATHS
eventTimestamp	SOURCE_LAST_MODIFIED
eventTimestamp when status is Fixed	LAST_FIXED
firstSeenTimestamp	FIRST_FOUND
joined MachineResource.lastSeen	DEVICE_LAST_SEEN
lastSeenTimestamp	LAST_FOUND
MSID-{cveId}-{recommendationReference}	TYPE
normalized status	STATUS
normalized status (default active)	SOURCE_STATUS
normalized vulnerabilitySeverityLevel	SEVERITY
rbacGroupName	RBAC_GROUP_NAME
recommendationReference	RECOMMENDATION_REFERENCE
recommendedSecurityUpdate	RECOMMENDED_SECURITY_UPDATE
recommendedSecurityUpdateId	RECOMMENDED_SECURITY_UPDATE_ID
registryPaths	REGISTRY_PATHS
softwareName	SOFTWARE_NAME
softwareVendor	SOFTWARE_VENDOR
softwareVersion	SOFTWARE_VERSION
status	PROVIDER_STATUS
sync timestamp	LAST_CAPTURED
vuln.id	UID
vuln.id	NAME
vulnerabilitySeverityLevel	SOURCE_SEVERITY

Vulnerability Definition

Source Field Name	SDM Attribute
!recommendation.hasUnpatchableCve (fallback securityUpdateAvailable)	PATCHABLE
cvssV3	CVSS_V3_BASE_SCORE
cvssVector (parsed by the CVSS utility)	CVSS metrics (CVSS_V2_, CVSS_V3_)
derived from exploitVerified / publicExploit / exploitInKit	EXPLOITABILITY
exploitTypes	EXPLOIT_TYPES
exploitUris	EXPLOITS
exploitUris	REFERENCES
MSID-{cveId}-{recommendationReference} (or MSID-{cveId} / MSID-{recommendation})	UID
normalized severity	SEVERITY
publishedOn	PUBLISHED_DATE
recommendation.recommendationName (fallback recommendedSecurityUpdate)	RECOMMENDATION
recommendation.relatedComponent (fallback software)	AFFECTED
severity	SOURCE_SEVERITY
updatedOn	SOURCE_LAST_MODIFIED
vulnerability.description	SUMMARY
vulnerability.description	DESCRIPTION
vulnerability.id (when CVE-*)	CVE_IDS
vulnerability.id (when CVE-*)	CVE_RECORDS
vulnerability.id, then vulnerability.name / recommendation name	NAME

Package

Source Field Name	SDM Attribute
constant active	STATUS
constant Package	CATEGORIES
software.activeAlert	ACTIVE_ALERT
software.exposedMachines	EXPOSED_MACHINES
software.id	UID
software.impactScore	IMPACT_SCORE
software.name	NAME
software.publicExploit	PUBLIC_EXPLOIT
software.vendor	VENDOR
softwareInventory[].softwareVersion	VERSIONS

Installed Package

Source Field Name	SDM Attribute
constant active	STATUS
machine.id	TARGETS
MD5 of (software.id, machine.id)	UID
software.id	TYPE
software.id + :: + machine.id	NAME
softwareInventory.deviceName	DNS_NAMES
softwareInventory.osPlatform	OPERATING_SYSTEM
softwareInventory.rbacGroupId	RBAC_GROUP_ID
softwareInventory.rbacGroupName	RBAC_GROUP_NAME

Operations & API

Operations & API

Expand each connector object to see its operation options, delta-sync behavior, and the API it uses. See connector operation options for how to apply operation options (keys and values are case-sensitive).

Machine

Operation options

Option	Type	Default	Description
filter	String	Raw OData $filter expression
computerDnsName	String	Filter by computerDnsName eq
machineTags	String	Filter by machineTags eq
exposureLevel	String	Filter by exposureLevel eq
onboardingStatus	String	Filter by onboardingStatus eq
healthStatus	String	Filter by healthStatus eq
osPlatform	String	Filter by osPlatform eq
riskScore	String	Filter by riskScore eq
rbacGroupId	String	Filter by rbacGroupId eq (unquoted)

Delta sync

Supported. The connector performs an incremental (delta) sync via the since sync token, filtering on lastSeen.

API

• Type: REST — Defender for Endpoint API (base https://api.securitycenter.microsoft.com) · Endpoint: GET api/machines

Vulnerability

Operation options

Option	Type	Default	Description
rbacGroupId	String	Comma-separated RBAC group IDs (in-memory filter)
rbacGroupName	String	Comma-separated RBAC group names, matched ignoring case (in-memory filter). Set with rbacGroupId and a record matching either one is kept, since both name the same set of groups. A record carrying no group fails the test
severity	String	Comma-separated severities (in-memory filter)
status	String	Comma-separated statuses (in-memory filter)
deviceLastSeenWithinDays	String	Whole number of days, 1 or more. Keeps only findings whose device has reported to Defender within that window, measured once from the start of the run against the joined device lastSeen. How much of the fleet it can judge depends on the machine listing the run reads — see below. A value that is not a whole number of days, or is below 1, fails the sync rather than being ignored. Needs the device data it measures, so includeDeviceData: "false" together with this option is refused up front
pageSize	String	pageSize sent to SoftwareVulnerabilityChangesByMachine on incremental syncs (max 200,000). Omitted by default, so the API default of 50,000 applies. Ignored by full exports, which are fetched as files
includeDeviceData	String	false skips the device fetch that enriches findings, omitting only DEVICE_LAST_SEEN. Defaults to true

Delta sync

Supported. The connector performs an incremental (delta) sync via the since sync token, filtering on sinceTime.

API

• Type: REST — Defender for Endpoint API

Vulnerability Definition

Operation options

Option	Type	Default	Description
filter	String	Raw OData $filter expression
id	String	Filter by id eq
cvssV3	Number	Filter by cvssV3 ge
severity	String	Filter by severity eq
pageSize	String	pageSize sent to SoftwareVulnerabilityChangesByMachine when definitions are built from an incremental per-device read (max 200,000). Omitted by default, so the API default of 50,000 applies
rbacGroupId, rbacGroupName, status	String	Read by the shared vulnerability collection, with the same meaning as on Vulnerability, and only when this model gathers findings itself. In an ordinary run it does not: the Vulnerability sync has already collected them in the same transaction and this model replays that corpus, which no filter is re-applied to. Note severity above is a different thing — an OData $filter on the definition catalog — even though both read the same option key

Delta sync

Supported. The connector performs an incremental (delta) sync via the since sync token, filtering on updatedOn.

API

• Type: REST — Defender for Endpoint API

Package

Operation options

Option	Type	Default	Description
filter	String	Raw OData $filter expression
id	String	Filter by id eq
name	String	Filter by name eq
vendor	String	Filter by vendor eq

Delta sync

Not supported. The connector performs a full sync of Package on every run and applies no incremental date filter.

API

• Type: REST — Defender for Endpoint API

Installed Package

Operation options

This object does not support any operation options.

Delta sync

Not supported. The connector performs a full sync of Installed Package on every run and applies no incremental date filter.

API

• Type: REST — Defender for Endpoint API

Changelog

Changelog

The Microsoft Defender for Endpoint connector has undergone the following changes:

Version	Description	Migration Steps
3.6.4	Improvements Scoping Vulnerabilities by Device Group Name Vulnerabilities could already be limited to particular device groups, but only by RBAC group id — a number that has to be looked up in the Defender console before it can be configured. The rbacGroupName option now accepts the group names themselves, as they read in Defender, matched ignoring case and comma-separated for several groups. rbacGroupId still works and both can be set together; a finding in any of the named or numbered groups is kept. Excluding Vulnerabilities on Devices That Have Stopped Reporting A new deviceLastSeenWithinDays option keeps only findings whose device has reported to Defender within the given number of days, so a scope no longer carries vulnerabilities for machines that have been silent for months. The window is measured once at the start of a run, so every record in one sync is judged against the same boundary, and a device that is missing from the listing or reports no last-seen time at all counts as not seen. How much of the fleet it can judge depends on the device listing the run has to hand. A run that fetched the whole listing — a full device export with no group or other narrowing options, or a vulnerability sync that fetched the listing for itself — applies the window to every finding. A run that inherits the shorter listing an incremental device sync left behind cannot tell a device that has gone quiet from one it simply was not told about; rather than discard findings on that basis it keeps them, and records once that the window could not be applied in full. The same holds if the device listing could not be retrieved at all, or came back empty: an outage — or a registration whose permissions let it read vulnerabilities but no machines — suspends the window rather than reading every device as gone. A finding one run excluded can therefore come back in a later one that cannot rule its device out, so treat the window as a way to keep long-dead devices out of a scope rather than a guarantee about any single finding. The option reads the device data the connector joins onto each finding, so it needs includeDeviceData to be on; asking for the window while that is switched off is refused with an explanatory message rather than quietly excluding every finding. A value that is not a whole number of days, or is below one, stops the sync rather than being ignored. Group and severity scoping applies to full exports and incremental syncs alike. All of it cuts inside the connector, so the excluded records are never delivered. Bug Fixes - Vulnerability Definition syncs no longer fail with NoSuchFieldError: CLEAR_CURRENT_TOKEN_ON_CLOSE — Since 3.6.2, a Vulnerability Definition sync failed as soon as it began reading back the vulnerabilities collected earlier in the same run, so no definitions were delivered. The connector packaged a newer version of the library it uses for its temporary local store than the connector agent supports. It now packages a version that matches the agent, and the sync completes as before.	N/A
3.6.3	No changes in this release.	N/A
3.6.2	Improvements - The local vulnerability store is substantially smaller on disk — While collecting vulnerabilities, the connector writes every record to a temporary local store so the Vulnerability Definition sync can read them back without collecting them a second time. Records were filed under an identifier that bears no relation to the CVE, so the many copies of one CVE — one per affected device, each differing only in its device fields — were scattered across the store and the text they share was written out again for every device. They are now filed by CVE first, so those copies sit together and the shared text is stored once for the whole group. On a tenant where the same vulnerabilities appear across many devices this is a severalfold reduction in the disk space a sync needs. The records delivered are unchanged. - The last stage of a vulnerability sync no longer looks like a hang — Once collection finishes, the connector reorganizes its local copy of the records so the next stage can read them efficiently. On a large tenant that takes a considerable time, and it previously wrote nothing to the log while it ran — indistinguishable from a stuck sync, and the likeliest reason someone would end a run that was in fact healthy. It now reports the record count and store size before it starts, and the elapsed time and resulting size when it finishes. Bug Fixes - A dropped connection while downloading an export file no longer fails the sync — The vulnerability and software inventory exports are read from large files. When the connection was cut part-way through one of them, the sync failed with EOFException even though the same request would have succeeded a moment later; on the largest tenants that ended a 50-minute sync with nothing to show for it. The download of that file is now retried, up to Maximum retries times, with the same backoff used elsewhere. Records are never delivered twice on a retry: once any record from a file has reached the sync, a later failure on that same attempt (a dropped connection or a parse error) is no longer retried and instead fails (or skips) that file immediately, so an already-synced prefix can never be replayed. Expired download links keep their existing recovery. - An export whose file list changed while downloading is no longer treated as complete — If a download link expired and the manifest it was refreshed from turned out to list a different number of files than the original, the file was previously skipped (or, if its index still fell within the new list, the wrong file could be read) without any indication that the export was incomplete. That case now fails the download like any other error, so it is retried, skipped, or fails the sync according to the same failSyncOnError setting every other download error follows. - Stopping a vulnerability sync now stops it immediately — When an incremental Vulnerability or Vulnerability Definition sync was cancelled, the request to stop was recorded but not acted on: the connector carried on downloading the rest of the change window page by page, and carried on handing records to a consumer that had already stopped listening. On a tenant with a busy 14-day window that could mean a long wait, and needless calls to Microsoft, after the sync had to all appearances been cancelled. It now stops at the record the cancellation arrived on, without requesting another page. - A vulnerability sync that stops early is no longer reused as though it had finished — The connector reuses the records collected by a recent sync rather than downloading them again. It decided a previous collection was complete simply because it had left something behind, so a sync that was cancelled or that failed part-way left a partial set of records that the next sync treated as the whole thing — reporting a short list of vulnerabilities with nothing to indicate anything was missing. A collection is now marked only once it has run to completion, and only a marked collection is reused. Anything else is collected again. Reuse is also limited to collections from the last 24 hours, and a sync that runs without a transaction identifier always collects fresh. One case is unchanged: with Fail sync on error disabled, which is the default, an export file that cannot be downloaded is still skipped with a logged error and the collection still counts as complete.	N/A
3.6.1	New Features - Request timeouts can now be configured — How long the connector waits to establish a connection to Microsoft, and how long it waits for Microsoft to start answering, were fixed at 5 minutes and 2 minutes and could not be changed. Both are now connector settings, Connect timeout (seconds) and Read timeout (seconds). The defaults are unchanged, so an existing configuration behaves exactly as it did before. Raise the read timeout if syncs fail with "Read timed out" against a tenant large enough that some requests take longer than two minutes to answer. A value outside the supported range is rejected when the configuration is saved rather than being silently ignored. - The wait for an export manifest can be set separately — Before handing over the vulnerability or software inventory export, Microsoft builds a snapshot of every device in the organization. On a large tenant that takes considerably longer than an ordinary request, but it shared the same two-minute limit, so on the largest tenants it timed out and the Vulnerability, Vulnerability Definition, Package and Installed Package syncs failed without reading a single record. That request now has its own setting, Export manifest read timeout (seconds), defaulting to 15 minutes. The longer wait applies only to that one request per sync; every other request continues to use the general read timeout. Improvements - A timed-out request now reports the limit it exceeded — A request that timed out logged only "Read timed out", which did not say how long it had waited. There was no way to tell from the log whether the request was close to succeeding and a longer limit would help, or whether the endpoint was not answering at all. The timeout in effect for the request is now logged alongside the error. - Large vulnerability definition syncs use less memory — While building Vulnerability Definition records, the connector kept the identifier of every definition it had already produced in memory for the duration of the sync. On a large tenant that is one entry for every distinct CVE and recommendation pairing across the whole vulnerability catalog and every device's software, all held at once. That record is now kept on disk alongside the other temporary data the sync already writes, and is discarded when the sync finishes. The definitions produced are unchanged. Bug Fixes - A vulnerability definition is no longer delivered more than once in a sync — Definitions are built from the software vulnerability export, which arrives as several files downloaded at the same time. The check deciding whether a definition had already been produced was not safe to run from more than one download at once, so when rows sharing a CVE and recommendation landed in different export files, the same definition could be sent twice in a single sync. Each definition is now produced exactly once, however the export is split. Definition identifiers are unchanged and vulnerability findings continue to resolve to their definition exactly as before.	N/A
3.6.0	Bug Fixes - A vulnerability timestamp in an unexpected format no longer fails the software vulnerability sync — The first-seen, last-seen and event timestamps on software vulnerabilities were read by a routine that raised an error whenever a value did not match one of the formats it recognized. That error surfaced while Microsoft's response was still being parsed, so it would end the entire sync rather than skip the one record. An unrecognized timestamp is now left unset on the vulnerability and the sync continues. Every timestamp format Microsoft currently sends is read exactly as before and no timestamp that resolves today changes value, so this removes a way the sync could fail rather than correcting data you are seeing now.	N/A
3.5.18	Improvements - A failed sync now names the request that failed — When Microsoft refused a request, the log reported only the error it returned — "Resource was not found" — with no indication of which request had failed, leaving no way to identify the cause without reproducing the run with debug logging enabled. The endpoint, its parameters and the error are now logged together whenever a request fails. The accompanying summary line was also printing {0} and {1} in place of the number of products processed and the error itself; it now reports both. Bug Fixes - The Package and Installed Package syncs no longer exhaust Microsoft's hourly API quota — Both syncs asked Microsoft about one software product at a time: one request per product for its versions, and another per product for the devices it is installed on. On a large software inventory a single pass exceeds Microsoft's published limit of 4,500 requests per hour, after which Microsoft refuses further requests and instructs waits of 20 to 45 minutes. This happened on every hourly run, leaving the connector throttled for most of each hour and, in the worst case, unable to finish a software sync at all. Both syncs now read Microsoft's software inventory export instead — a single request per sync that returns the same information for the entire organization as downloadable files, which do not count against the API quota. The two syncs share one export, so where a sync of both models previously made thousands of per-product requests, it now makes one — on top of the handful of paged requests that list the software catalog itself. One attribute changes as a consequence: Rbac group ID on Installed Package is not part of the export's documented columns, so it is populated only when Microsoft includes it and is no longer guaranteed to be present. Rbac group name is unaffected, no other Package or Installed Package attribute changes, and record identifiers are unchanged — no re-synchronization is needed. - Products no longer lose their versions and installed devices, or end the sync outright, because of their identifier — Every product used to be looked up by an identifier placed in the request URL, and identifiers are built from the vendor and product name. A product whose identifier contained an @ (such as @bfb4a0784d7a-_-collectd) made Microsoft reject the request as malformed, which ended both syncs and discarded every record the run had not yet delivered; a product whose identifier contained a / (such as ps-ec/ebt-_-dahlia_1.9.1) was reported as missing, so it synced as a package but silently lost its Versions attribute and its device relationships on every run. Individual products were also lost whenever Microsoft refused, throttled, or failed to answer that one product's request. The connector no longer looks products up one at a time, so none of these failures can occur: every product the software catalog lists syncs, and its versions and devices come from the shared export.	N/A
3.5.15	Bug Fixes - Device first-seen dates now reach the platform — Machine set a first-seen date on every device from Microsoft's firstSeen field, as documented, but did not declare the attribute, so the value was published with nothing to map it onto and was dropped. Machine now declares FIRST_SEEN. Devices synced from this release forward carry the date Microsoft first observed them. - Device source risk rating uses the platform attribute definition — Machine declared its own copy of this attribute rather than the platform's. The copy was identical in name, title, and type but carried no mapping metadata, and shadowing a platform attribute this way is what caused the Defender for Cloud schema failure fixed in the same release. SOURCE_RISK_RATING is unchanged for reporting purposes.	N/A
3.5.13	Bug Fixes - Device MAC addresses are now captured for all network interfaces — Previously only interfaces Microsoft reported with an interface type of "Ethernet" were captured. Devices surfaced through Device Discovery — such as printers and other IoT/unmanaged devices — are frequently reported with a different or missing interface type even when physically connected via Ethernet, which caused their MAC addresses to be silently omitted even though they are visible in the Microsoft Defender portal. These MAC addresses now sync correctly. Shared placeholder MAC addresses (all-zero, broadcast, and the Microsoft KM-TEST loopback) are excluded so unrelated devices are not incorrectly merged into a single asset.	N/A
3.5.12	Improvements - The Fail sync on error setting now governs software products as well as vulnerability export downloads. Leaving it disabled (the default) lets a sync finish while skipping the individual products Microsoft no longer has (404); enabling it makes those failures fail the sync instead. Any other read failure — expired credentials, revoked permissions, an API error — fails the sync regardless of this setting. - Software items skipped during a sync are now reported as errors in the connector log — each skipped item names the endpoint that returned 404, and each sync ends with a count of how many items were skipped, so partial results are never silent. Bug Fixes - Package and Installed Package syncs aborted completely when a single software product was missing — Both object types fetch additional detail for each software product individually. When Microsoft returned 404 for one product — which happens routinely on large inventories, as products are removed from the catalog between being listed and being read — that object type stopped processing and every other record in the run was discarded. The missing product is now skipped and the remaining records sync normally; a package whose version detail is missing still syncs, without its Versions attribute. - A failed software listing was reported as a successful sync — When the software listing that drives Package and Installed Package failed part-way — expired credentials, revoked permissions, an API outage — the error was logged and the sync still reported success, so a run that imported only part of the inventory, or none of it, looked no different from a complete one. Such a failure now fails the sync, making it visible in the connector run history.	N/A
3.5.11	New Features - Device enrichment can now be skipped on vulnerability syncs — A new includeDeviceData operation option controls whether the connector fetches device records in order to enrich vulnerability findings. It defaults to true, so existing behavior is unchanged. Setting it to false skips the device fetch entirely, which shortens vulnerability sync time on large tenants; the only attribute omitted is Device last seen. Improvements - Vulnerability export downloads now run with bounded parallelism using a proper thread pool, preventing unbounded thread growth on tenants with many export part files. - The Parallelism setting now defaults to 4 instead of the connector host's processor count, and values above 8 are capped. Because the connector host is shared with every other running sync, scaling this setting with the core count let a single vulnerability sync open one export download per core, competing with other connectors for memory and bandwidth. Export downloads are limited by network throughput rather than by thread count, so the lower default does not slow syncs down. Existing configurations above the cap keep working and are capped at run time rather than rejected. The setting applies to full vulnerability syncs only — delta syncs page through the API sequentially and are unaffected. - The Azure Blob SAS download-URL validity window is now configurable through the new SAS URL validity (hours) setting (1–6 hours, default 6, matching Microsoft's maximum). - Delta vulnerability syncs allow the page size to be controlled via the pageSize operation option. When not set, the API default (50,000 records per page) is used, which avoids a behavior where passing an explicit page size caused the endpoint to return empty results. Bug Fixes - Incremental vulnerability syncs returned no records — Timestamps sent as request filters had their colons percent-encoded (%3A), a form that Microsoft's vulnerability changes endpoint does not accept; it responded with an empty result set rather than an error, so incremental syncs appeared to succeed while silently importing nothing. Query values are now encoded per RFC 3986, which leaves colons intact, and incremental vulnerability syncs return data again. - Vulnerability export files expired mid-download, losing data silently — The Azure Blob SAS download URLs were valid for only 1 hour. On large tenants whose export took longer than that to download, the remaining files failed and those vulnerabilities were dropped from the sync without an error. The validity window is now requested at 6 hours (Microsoft's maximum) by default. - Export downloads now recover from an expired SAS URL instead of failing — If a download URL still expires mid-sync, the connector re-fetches the export manifest for fresh URLs and retries the affected files, rather than failing those files with a 403. Recovery is no longer limited to the first occurrence: a sync long enough to outlast more than one validity window keeps recovering, where previously every file that expired after the first recovery was skipped and its vulnerabilities dropped from the sync without an error. - Incremental syncs skipped changes at the publication boundary — The sync watermark advanced to the time the sync ran, but Microsoft publishes vulnerability changes in roughly 6-hour batches, so the watermark landed inside a window that had not been published yet and the changes in it were never requested again. The watermark now advances to the newest change actually received, and a window that returns no records leaves it untouched so the changes are picked up once they publish. - An interrupted incremental sync no longer skips changes — The watermark is now advanced only once every record in a delta window has been handed over, rather than progressively as records arrive. Microsoft does not return a delta window in timestamp order, so a sync that stopped part-way through — a restart, a connectivity loss — could leave behind a watermark newer than changes it had not yet delivered; because the query start time snaps to a 6-hour batch boundary, those changes were never requested again. An interrupted sync now resumes from where the previous completed sync finished and re-reads the window, so no change can be passed over.	N/A
3.5.10	No changes in this release.	N/A
3.5.9	No changes in this release.	N/A
3.5.8	No changes in this release.	N/A
3.5.7	Bug Fixes - Vulnerability findings now reliably link to their Vulnerability Definitions. Definitions are now built from the same per-device vulnerability data as the findings, so every finding that carries a CVE or a recommendation resolves to a definition — including cases where Microsoft's security-recommendation catalog did not associate a device's CVE with its recommendation (for example, certain Linux/Red Hat packages), which previously left those findings without a matching definition. Improvements - Vulnerability Definitions now reflect the specific recommendation reported for a device, while still keeping a definition for every CVE in the catalog. - When a recommendation is not present in the recommendation catalog, the affected software and recommended update shown on the definition fall back to the values reported on the device. - Vulnerability findings expose the source CVE ID and recommendation reference as their own attributes (CVE_ID, RECOMMENDATION_REFERENCE), making the definition linkage easy to verify.	• Vulnerability Definition: Definition identifiers and sources have changed. — Action: Delete existing Vulnerability Definition data, then run a full sync of Vulnerability Definitions and Vulnerabilities so findings re-link to the new definitions.
3.5.6	No changes in this release.	N/A
3.5.5	No changes in this release.	N/A
3.5.4	No changes in this release.	N/A
3.5.3	No changes in this release.	N/A
3.5.2	No changes in this release.	N/A
3.5.1	No changes in this release.	N/A
3.5.0	No changes in this release.	N/A
3.4.32	No changes in this release.	N/A
3.4.31	No changes in this release.	N/A
3.4.30	No changes in this release.	N/A
3.4.29	Improvements - Vulnerabilities that map to more than one Defender security recommendation are now synchronized as one record per recommendation, giving a more complete view of remediation options for each finding. - Vulnerability definitions that lack a CVE identifier now fall back to the associated recommendation reference so they are still synchronized instead of being dropped.	• Vulnerability: A single source vulnerability may now produce multiple records (one per recommendation). Re-sync the Defender for Endpoint connector to rebuild vulnerability data.
3.4.28	No changes in this release.	N/A
3.4.27	No changes in this release.	N/A
3.4.26	No changes in this release.	N/A
3.4.25	No changes in this release.	N/A
3.4.24	No changes in this release.	N/A
3.4.23	New Features - Added a "Device last seen" attribute to the Machine model, recording when each device was most recently observed by Defender for Endpoint.	N/A
3.4.22	No changes in this release.	N/A
3.4.21	Improvements - Reverted the vulnerability definition identifier scheme introduced in the previous release back to the original CVE-based identifier.	• Vulnerability Definition: Vulnerability definition identifiers changed. Re-sync the Defender for Endpoint connector to rebuild vulnerability definition data.
3.4.20	Improvements - Vulnerability definition identifiers are now generated using a shared utility that combines the CVE and recommendation references, improving consistency of definition keys.	• Vulnerability Definition: Vulnerability definition identifiers changed. Re-sync the Defender for Endpoint connector to rebuild vulnerability definition data.
3.4.19	No changes in this release.	N/A
3.4.18	No changes in this release.	N/A
3.4.17	New Features - Added software, recommendation, and device-context attributes to the Machine model — including software name, version and vendor, recommended security update details, disk and registry paths, RBAC group, and device ID.	N/A
3.4.16	No changes in this release.	N/A
3.4.15	No changes in this release.	N/A
3.4.14	No changes in this release.	N/A
3.4.13	No changes in this release.	N/A
3.4.12	No changes in this release.	N/A
3.4.11	No changes in this release.	N/A
3.4.10	No changes in this release.	N/A
3.4.9	No changes in this release.	N/A
3.4.8	No changes in this release.	N/A
3.4.7	No changes in this release.	N/A
3.4.6	No changes in this release.	N/A
3.4.5	No changes in this release.	N/A
3.4.4	No changes in this release.	N/A
3.4.3	No changes in this release.	N/A
3.4.2	No changes in this release.	N/A
3.4.1	No changes in this release.	N/A
3.4.0	No changes in this release.	N/A
3.3.10	No changes in this release.	N/A
3.3.9	No changes in this release.	N/A
3.3.8	No changes in this release.	N/A
3.3.7	No changes in this release.	N/A
3.3.6	No changes in this release.	N/A
3.3.5	No changes in this release.	N/A
3.3.4	Improvements - Renamed the machine "Source risk score" attribute to "Source risk rating" to better reflect the categorical risk value reported by Defender for Endpoint.	• Machine: The "Source risk score" attribute was renamed to "Source risk rating". Re-sync the Defender for Endpoint connector so machine data reflects the new attribute.
3.3.3	No changes in this release.	N/A
3.3.2	Bug Fixes - The machine "Source risk score" attribute is now stored as text rather than a number, matching the categorical risk values (for example, "High") returned by Defender for Endpoint.	• Machine: The "Source risk score" attribute changed type from numeric to text. Re-sync the Defender for Endpoint connector to rebuild machine data with the corrected type.
3.3.1	New Features - Added the Package and Installed Package models, synchronizing the software packages discovered by Defender for Endpoint and the per-device installed package inventory.	N/A
3.3.0	No changes in this release.	N/A
3.2.2	No changes in this release.	N/A
3.2.1	No changes in this release.	N/A
3.2.0	No changes in this release.	N/A
3.1.18	Dependency Upgrades - Added the CVSS calculator library used for normalizing vulnerability severity scores.	N/A
3.1.17	No changes in this release.	N/A
3.1.16	New Features - Added "Potential duplication" and "Merged info machine ID" attributes to the Machine model, surfacing devices that Defender for Endpoint has flagged as potential duplicates or merged.	N/A
3.1.15	No changes in this release.	N/A
3.1.14	Improvements - Machine tags are now split into key/value pairs, making tag values easier to consume downstream.	N/A
3.1.13	No changes in this release.	N/A
3.1.12	Dependency Upgrades - Updated the local storage and data model libraries used during synchronization.	N/A
3.1.11	No changes in this release.	N/A
3.1.9	No changes in this release.	N/A
3.1.8	No changes in this release.	N/A
3.1.7	No changes in this release.	N/A
3.1.6	No changes in this release.	N/A
3.1.5	No changes in this release.	N/A
3.1.4	No changes in this release.	N/A
3.1.3	No changes in this release.	N/A
3.1.2	No changes in this release.	N/A
3.1.1	No changes in this release.	N/A
3.1.0	Improvements - Vulnerability definitions now fall back to the related component when a product name is unavailable, reducing blank product values. - Software vulnerability export downloads now recover gracefully from individual file errors instead of failing the sync.	N/A
3.0.3	New Features - Added the Vulnerability and Vulnerability Definition models, synchronizing per-device vulnerability findings and the underlying vulnerability definitions (including exploit type information) from Defender for Endpoint.	N/A
3.0.2	Overview The Defender for Endpoint connector integrates with Microsoft Defender for Endpoint to synchronize managed devices and their security posture. Category: Endpoint Protection Models	N/A