CrowdStrike Endpoint Security

Endpoint Protection

Overview

The CrowdStrike Endpoint Security (ES) connector integrates with the CrowdStrike Falcon Spotlight and Devices modules, synchronizing endpoint devices, Spotlight vulnerabilities, and vulnerability definitions. Evaluation logic data is included inline with vulnerabilities via the evaluation_logic facet.

---

Data retrieved from CrowdStrike Endpoint Security

Connector Object	Required	Maps to Data Model
🖥️ Device	Yes	Host
⚠️ Vulnerability	Yes	Vulnerability
📖 Vulnerability Definition	Yes	Vulnerability Definition

Model relationships

note

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

note

As part of aligning with the broader suite of CrowdStrike solutions, the connector formerly known as CrowdStrike was renamed to CrowdStrike Endpoint Security in connector version 3.2.0.

note

Note: A caller-supplied filter still wins. An explicit last_seen_within: is not overridden. An explicit updated_timestamp: or closed_timestamp: suppresses the change window entirely and reverts the guard to the clamped 3–45 day span, on the reasoning that a caller bounding the change timestamps themselves is choosing the incremental window.

note

Note: host_info.machine_domain is not a supported filter field for the Spotlight API. The field is present in the API response but cannot be used for server-side filtering. Attempting to filter by this field returns a 400 Bad Request: invalid filter error. This is a CrowdStrike API limitation.

Setup

Connection settings

When setting up a data integration, select CrowdStrike Endpoint Security from the Connector dropdown and provide the following:

Setting	Required	Default	Description
API URL	Yes	https://<region>.crowdstrike.com	CrowdStrike API URL
Client ID	Yes	—	CrowdStrike API client Id
Client secret	Yes	—	CrowdStrike API client secret
Page size	No	5000	The number of records to fetch for each paged request
Parallel requests	No	8	The maximum number of concurrent API requests, 1 to 32, defaulting to 8. Lower this if CrowdStrike reports rate limiting. A value of 0 or below is ignored and leaves the default in place; a value above 32 is reduced to 32.
Maximum retries	No	10	The maximum number of retry attempts before giving up a request
Vulnerability scan workers	No	8	How many vulnerability time windows are collected from CrowdStrike at the \
Full sync time windows	No	32	How many time windows a first-time full vulnerability sync is divided \
Incremental sync time windows	No	16	How many time windows an incremental vulnerability sync is divided \

Authentication

CrowdStrike uses OAuth 2.0 Client Credentials flow.

Endpoint

Method	URL
POST	https://<region>.crowdstrike.com/oauth2/token

Request Headers

Header	Value
Content-Type	application/x-www-form-urlencoded

Request Body

client_id=<your-client-id>&client_secret=<your-client-secret>

Sample Response

{
  "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI...",
  "expires_in": 1799,
  "token_type": "bearer"
}

Response Fields

Field	Type	Description
access_token	String	Bearer token for API requests
expires_in	Integer	Token lifetime in seconds
token_type	String	Token type (always bearer)

Usage

Once authenticated, all subsequent API requests include the bearer token:

Authorization: Bearer <access_token>

---

Sync Behavior

The connector performs incremental (delta) syncs. When a since timestamp is provided, each model applies a time-based FQL filter; otherwise the first run behaves as a beginning-of-time (full) sync.

• Device — Incremental. When since is set, a last_seen:>='<timestamp>' FQL clause is appended (unless the caller's filter already specifies last_seen:); otherwise all devices are enumerated.
• Vulnerability — Incremental. Uses the Spotlight combined-vulnerabilities endpoint. An incremental sync bounds itself on when the vulnerability changed — (closed_timestamp:>='<since>',updated_timestamp:>='<since>') — while a beginning-of-time sync pulls the full open set under last_seen_within:'45'. See the Sync Duration Parameter section below for why those are different questions.
• Vulnerability Definition — Incremental. Shares the same Spotlight combined-vulnerabilities pipeline, and the same change window, as Vulnerability.

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

---

How to obtain CrowdStrike Endpoint Security credentials

Generate a CrowdStrike client secret

For the CrowdStrike Endpoint Security connector to use the CrowdStrike API, you must provide a client secret. CrowdStrike Endpoint Security does not allow retrieving the client secret for an existing user, therefore, you must generate a new client secret instead. To do so, follow these steps:

1. Log in to your organization's CrowdStrike Falcon portal as an administrator.

2. From the navigation menu, click Support and resources, and then click API clients and keys.

3. Click Create API client.

   The Create API client window displays.

4. Fill out the Client name, Description, and select the appropriate API scopes for the user.

5. Click Create.

   Your new client ID, client secret, and recommended Base URL display. You cannot view the client secret again after this. Copy and save it to a secure location.

   

Note: If you do not have permissions to create a client secret, contact your CrowdStrike Endpoint Security administrator. For additional information, see CrowdStrike documentation.

Data & mappings

Attribute mappings

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

🖥️ Device

Source Field Name	SDM Attribute
Aggregated	IP_ADDRESSES
Computed	NAME
Computed	DESCRIPTION
Computed	OPERATING_SYSTEM
device_policies.device_control.applied	DEVICE_CONTROL_POLICY_APPLIED
device_policies.device_control.policy_id	DEVICE_CONTROL_POLICY_ID
device_policies.global_config.applied	GLOBAL_CONFIG_POLICY_APPLIED
device_policies.global_config.policy_id	GLOBAL_CONFIG_POLICY_ID
device_policies.prevention.applied	PREVENTION_POLICY_APPLIED
device_policies.prevention.policy_id	PREVENTION_POLICY_ID
device_policies.sensor_update.applied	SENSOR_UPDATE_POLICY_APPLIED
device_policies.sensor_update.policy_id	SENSOR_UPDATE_POLICY_ID
DeviceResource.agent_load_flags()	AGENT_LOAD_FLAGS
DeviceResource.agent_local_time()	AGENT_LOCAL_TIME
DeviceResource.agent_version()	AGENT_VERSION
DeviceResource.bios_manufacturer()	BIOS_MANUFACTURER
DeviceResource.bios_version()	BIOS_VERSION
DeviceResource.build_number()	BUILD_NUMBER
DeviceResource.chassis_type_desc()	CHASSIS_TYPE
DeviceResource.cid()	CUSTOMER_ID
DeviceResource.connection_ip()	CONNECTION_IP
DeviceResource.connection_mac_address()	CONNECTION_MAC_ADDRESS
DeviceResource.default_gateway_ip()	DEFAULT_GATEWAY_IP
DeviceResource.device_id()	UID
DeviceResource.external_ip()	PUBLIC_IP_ADDRESSES
DeviceResource.first_login_timestamp()	FIRST_LOGIN
DeviceResource.first_login_user()	FIRST_LOGIN_USER
DeviceResource.first_seen()	FIRST_SEEN
DeviceResource.groups()	GROUPS
DeviceResource.hostname()	HOSTNAMES
DeviceResource.hostname()	PRIVATE_DNS_NAMES
DeviceResource.instance_id()	INSTANCE_ID
DeviceResource.kernel_version()	KERNEL_VERSION
DeviceResource.last_login_timestamp()	LAST_LOGIN
DeviceResource.last_login_user()	LAST_LOGIN_USER
DeviceResource.last_reboot()	LAST_STARTED
DeviceResource.last_seen()	LAST_SEEN
DeviceResource.local_ip()	PRIVATE_IP_ADDRESSES
DeviceResource.mac_address()	MAC_ADDRESSES
DeviceResource.machine_domain()	MACHINE_DOMAIN
DeviceResource.major_version()	MAJOR_VERSION
DeviceResource.minor_version()	MINOR_VERSION
DeviceResource.modified_timestamp()	SOURCE_LAST_MODIFIED
DeviceResource.notes()	NOTES
DeviceResource.os_build()	OS_BUILD
DeviceResource.os_product_name()	OS_PRODUCT_NAME
DeviceResource.os_version()	OS_VERSION
DeviceResource.ou()	OU
DeviceResource.platform_id()	PLATFORM_ID
DeviceResource.platform_name()	PLATFORM_NAME
DeviceResource.product_type_desc()	CATEGORIES
DeviceResource.provision_status()	PROVISION_STATUS
DeviceResource.reduced_functionality_mode()	REDUCED_FUNCTIONALITY_MODE
DeviceResource.serial_number()	SERIAL_NUMBER
DeviceResource.status()	STATUS
DeviceResource.system_manufacturer()	SYSTEM_MANUFACTURER
DeviceResource.system_product_name()	MODEL
DeviceResource.tags()	TAGS
Generated	LAST_CAPTURED

⚠️ Vulnerability

Source Field Name	SDM Attribute
Computed	NAME
Computed	LAST_FOUND
Computed	STATUS_CATEGORY
Computed	EVALUATION_LOGIC
Computed	EVALUATION_LOGIC_RAW
Computed	RESULTS
EvaluationLogicDetail.dataProvider()	DATA_PROVIDER
Generated	TYPE
Generated	LAST_CAPTURED
Normalized	SEVERITY
Normalized	SOURCE_STATUS
Normalized	STATUS
VulnerabilityResource.aid()	TARGETS
VulnerabilityResource.cid()	CUSTOMER_ID
VulnerabilityResource.closed_timestamp()	LAST_FIXED
VulnerabilityResource.created_timestamp()	FIRST_FOUND
VulnerabilityResource.created_timestamp()	SOURCE_CREATED_DATE
VulnerabilityResource.cve.exprt_rating()	EX_PRT_RATING
VulnerabilityResource.cve.severity()	SOURCE_SEVERITY
VulnerabilityResource.host_info.host_last_seen_timestamp()	LAST_SEEN
VulnerabilityResource.host_info.hostname()	HOSTNAMES
VulnerabilityResource.host_info.local_ip()	IP_ADDRESSES
VulnerabilityResource.id()	UID
VulnerabilityResource.status()	PROVIDER_STATUS
VulnerabilityResource.updated_timestamp()	SOURCE_LAST_MODIFIED

📖 Vulnerability Definition

Source Field Name	SDM Attribute
Calculated	SEVERITY_SCORE
Computed	NAME
Computed	AFFECTED
Computed	RECOMMENDATION
Computed	PATCH_AVAILABLE
Generated	UID
Generated	LAST_CAPTURED
Normalized	SEVERITY
VulnerabilityResource.cve.description()	DESCRIPTION
VulnerabilityResource.cve.description()	SUMMARY
VulnerabilityResource.cve.exploit_status()	EXPLOITABILITY
VulnerabilityResource.cve.published_date()	PUBLISHED_DATE
VulnerabilityResource.cve.references()	REFERENCES
VulnerabilityResource.cve.severity()	SOURCE_SEVERITY
VulnerabilityResource.vulnerability_id()	CVE_IDS
VulnerabilityResource.vulnerability_id()	CVE_RECORDS

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).

🖥️ Device

Operation options

Option	Type	Default	Description
filter	String	—	Raw FQL filter string passed directly to the Devices API
machine_domain	String	—	Filters devices by Active Directory domain

Delta sync

Supported.

API

• Type: REST · Endpoint: GET /devices/queries/devices-scroll/v1
• Default filters: When since is provided, an FQL last_seen:>='<timestamp>' clause is appended unless the caller's filter already specifies last_seen:

note

Any valid CrowdStrike FQL field for the Device resource can be used as a key-value operation option. See CrowdStrike API documentation for the full list of supported fields.

info

The filter option and individual key-value filters are mutually exclusive. When filter is provided, all other key-value filter options are ignored.

⚠️ Vulnerability

Operation options

Option	Type	Default	Description
includeEvaluationLogic	Boolean	false	When true, adds the evaluation_logic facet to the Spotlight API call and populates EVALUATION_LOGIC, EVALUATION_LOGIC_RAW, and DATA_PROVIDER attributes. When false or absent, those attributes are omitted from the connector object.
cursorRestartLimit	Integer	5	Maximum number of consecutive re-anchors of the after cursor allowed after the server-side search context expires. Each re-anchor resumes from the highest updated_timestamp already collected, so the cost is bounded by the records still outstanding. The counter resets whenever the watermark advances, so a long scan that keeps making progress is not capped; the limit only stops a scan that is stuck re-reading the same window. 0 disables recovery and fails the sync on the first expiry.
fetchWriteThreads	Integer	parallelism level, capped at 4	Number of threads writing fetched pages into the local store while the pager requests the next page. Overlapping persistence with paging makes the fetch faster. It does not protect the search context: that expires on an absolute deadline (see Emission), not on idleness. Each in-flight page holds up to pageSize deserialized records, which is why the derived default is capped. 1 restores fully serial fetching.
scanPartitions	Integer	per sync type	Number of updated_timestamp windows the Spotlight scan is split into so they can be paged concurrently. The endpoint offers cursor-only pagination, so a single query can only be paged one page at a time; splitting the query is the only way to use more than one connection. Capped at 32. Note this sets the number of windows, not the number of connections: they are paged by a pool sized min(scanConcurrency, windows), so raising this alone does not raise concurrency. Windows are drawn from a queue, so having more windows than workers is useful and is what the defaults do — because equal-width windows over a skewed updated_timestamp distribution differ widely in size, and a worker that finishes early takes the next window instead of idling. Applies to whichever sync is running, overriding both per-sync-type settings; retained because it shipped in 3.3.0. Prefer Full sync time windows and Incremental sync time windows, which can differ. 1 restores a single sequential pass.
incrementalChangeWindow	Boolean	true	Whether an incremental sync bounds itself on when the vulnerability changed rather than on how recently its host checked in. false restores the previous last_seen_within window, clamped to 3–45 days. Only affects syncs that receive a sync token; a beginning-of-time sync is identical either way.
scanConcurrency	Integer	connector setting (8)	Per-sync override for Vulnerability scan workers.
botScanPartitions	Integer	connector setting (32)	Per-sync override for Full sync time windows. Read only when no sync token is supplied.
deltaScanPartitions	Integer	connector setting (16)	Per-sync override for Incremental sync time windows. Read only when a sync token is supplied.
balancedScanWindows	Boolean	true	Whether the partitioned scan places its window boundaries at equal record counts rather than at equal spans of time. false restores equal-width windows. Reached whenever the scan is partitioned, which is the default, so it is active on an ordinary sync; a window count or scanConcurrency of 1 bypasses it. Balancing costs a bounded number of limit=1 counting probes (at most 128) and falls back to equal-width windows if any of them fails or cannot be trusted.
replayThreads	Integer	parallelism level, capped at 4	Number of threads building connector objects when a sync replays a corpus that is already in the local store. Objects are emitted one at a time under a lock, so only the build is concurrent and emit order is not guaranteed. 1 restores fully serial replay. This does not apply to a normal Vulnerability sync, which collects and emits in one pass and therefore never replays — it applies to a sync that finds a complete corpus already on disk. Applies to Vulnerability only — see the note under Vulnerability Definition.
fetchProgressSeconds	Integer	30	Interval between PROGRESS events emitted while pages are being fetched. Raising it delays cancellation via progress events, but it is no longer the only cancellation point: refusing an emitted record stops the scan at the next record, and on a platform that ignores progress events that is the only cancellation channel there is. 0 checks after every page.
maxRetries	Integer	connector setting (10)	Maximum retry attempts per Spotlight record request for this sync. The two kinds of advisory probe — the scan-boundary probes and the window-counting probes — are hard-capped at 2 retries regardless, because each has a safe fallback and a partitioned scan issues on the order of a hundred of them. 0 disables retries so a rate-limited or failing request fails immediately instead of waiting out the backoff. A negative value is ignored in favour of the connector setting.
filter	String	—	Raw FQL filter string passed directly to the Spotlight API
status	String	—	Filters vulnerabilities by status. On BOT (beginning of time) syncs, status defaults to excluding expired if not explicitly set

Delta sync

Supported.

API

• Type: REST · Endpoint: GET /spotlight/combined/vulnerabilities/v1
• Default filters: Facets host_info, cve, remediation are always requested (plus evaluation_logic when includeEvaluationLogic is true). A last_seen_within clause is appended unless the caller's filter already specifies it — '45' normally, or the clamped 3–45 day span whenever no change window is applied, which means either incrementalChangeWindow is false or the caller's filter already bounds updated_timestamp:/closed_timestamp:. Incremental syncs additionally append the parenthesised change window described under Time Frame; the parentheses matter, because a comma is OR in FQL and an unbracketed group would capture the preceding clause. On BOT syncs with no explicit status, status:! 'expired' is added.

note

Any valid CrowdStrike Spotlight FQL field can also be used as a key-value operation option to filter vulnerabilities.

info

The filter option and individual key-value filters are mutually exclusive. When filter is provided, all other key-value filter options are ignored.

📖 Vulnerability Definition

Operation options

Option	Type	Default	Description
definitionProgressSeconds	Integer	30	Minimum seconds between progress events emitted while the sync aggregates the vulnerability corpus (the phase that precedes emitting any definition). Advances the no-progress timer on platforms that count progress events; platform 11x does not, so on 11x a large standalone Vulnerability Definition sync is still bounded by that timeout regardless of this setting. 0 emits a progress event for every record processed.

Delta sync

Supported.

API

• Type: REST · Endpoint: GET /spotlight/combined/vulnerabilities/v1
• Default filters: Shares the same Spotlight pipeline as Vulnerability — definitions are derived from the same combined-vulnerabilities response (facets host_info, cve, remediation; same change window and last_seen_within guard)

note

replayThreads has no effect on this model. Building a definition merges many source vulnerabilities into one record, and that merge is order-dependent — the CVE is taken from the last open record seen, and affected-product ordering feeds the generated recommendation text. Aggregation is therefore performed serially so its output stays deterministic.

Changelog

Changelog

The CrowdStrike Endpoint Security connector has undergone the following changes:

Version	Description	Migration Steps
3.3.1	Improvements - Vulnerability syncs now collect over several connections by default, and are substantially faster. Collecting over several connections was previously off unless it was switched on by hand, so most accounts saw none of the benefit. It is now on out of the box, and no configuration is needed to get it. On a production account of 182 million vulnerabilities, a full cycle of an incremental sync — vulnerabilities and their definitions together — went from 2 hours 31 minutes to 27 minutes, a saving of 82%. Larger accounts benefit more, and on the largest a first-time sync is the difference between days and hours. Three settings control it, each with a default that needs no adjustment. Vulnerability scan workers (default 8) is how many parts of the account are collected at the same time. It is separate from Parallel requests because collection spends nearly all of its time waiting on CrowdStrike rather than using the processor — but it never exceeds Parallel requests, so an existing limit is respected. Full sync time windows (default 32) and Incremental sync time windows (default 16) are how finely each kind of sync is divided — a first-time sync covers the whole history of the account, where activity is far more unevenly spread, so it is divided more finely. Any of them can be lowered, and setting either window count to 1 restores collection in a single sequential pass. Two consequences worth knowing. A vulnerability may now be sent more than once within a sync: where the parts being collected meet, the record on the boundary is deliberately re-read rather than risk skipping it, and because each vulnerability is identified by its own id a repeat resolves to the same record. And Vulnerability scan workers is capped by Parallel requests, so an account that had lowered the latter to reduce load on CrowdStrike keeps that limit and sees no increase in concurrency. The effect is that the two together set the pool to whichever is lower, so raising only one of them will not go past the other. Note the other side of this: an account that had switched collection over several connections on by hand in 3.3.0, and left Parallel requests at its default, will see the number of parts collected at once rise to 8, because that default has itself risen. - Whether the work was divided, and into how many parts, is now visible in the logs at normal logging levels rather than only in debug output, along with a warning whenever the connector had to fall back to a simpler division. Previously a sync that quietly gave up on dividing the work looked identical to one that succeeded. - A small incremental sync is no longer divided into time windows it cannot use. Dividing the work is worthwhile when there is enough of it, and the connector now checks first: when everything an incremental sync has to collect would fit in a single page, it collects it in one request instead of measuring the account to place windows around it. That measurement is a series of small counting requests, and because it aims for an even split it did more of them the less there was to collect — so the accounts that benefited most from the more precise incremental filter above were the ones that paid most for windows they had no use for. A first-time full sync is unaffected; there is always enough to divide. - Requests to CrowdStrike now run 8 at a time by default, rather than a number derived from the processor count. The previous default was the number of processors available to the connector, capped at 4, which meant a connector running in a small container collected one page at a time no matter how much capacity the CrowdStrike account had — and, because the vulnerability scan workers are capped by this setting, that a small agent saw only half of the improvement above. Collection spends almost all of its time waiting on CrowdStrike rather than using the processor — on a measured sync, 97% of the elapsed time was spent waiting on the network — so the useful number is set by what the account's rate limit allows, not by the size of the machine. Parallel requests now defaults to 8 and accepts 1 to 32; lower it if CrowdStrike reports rate limiting. Values of 0 or below are ignored and leave the default in place, so an account cannot be left collecting one request at a time by a stray entry; a value above 32 is reduced to 32, so an account that had been configured higher should be re-entered as 32. Bug Fixes - An incremental vulnerability sync now starts a few minutes before it left off, rather than exactly where it left off. The point it resumes from comes from the platform's clock, while the timestamps it compares against come from CrowdStrike's. Comparing the two with no margin meant that if the clocks disagreed even slightly, a vulnerability changed in the gap between them belonged to no sync at all — not the one running, because its timestamp looked too new, and not the next one, which starts later still — so it would not be collected again until a full re-sync. A five-minute margin removes the possibility. Records are identified by their own id, so re-reading a few minutes of overlap resolves to the same records rather than duplicating them. - A brief network problem at the start of a vulnerability sync no longer fails the whole sync. Before dividing the work, the connector asks CrowdStrike for the oldest and newest vulnerability in scope. If either of those two requests failed — a momentary rate limit or gateway error was enough — the sync stopped and collected nothing, even though it could simply have collected without dividing the work. It now falls back to collecting in a single pass and records a warning. The same applies to the queries used to size each part of the work, and all of these are now retried only briefly rather than for as long as an ordinary request, because falling back costs less than waiting. - Collecting over several connections now divides the work evenly. The time windows the collection was split into covered equal spans of time, which is only sensible if vulnerability activity is spread evenly across that time — and it is not. On one production tenant the busiest day carried 16 times the volume of the quietest and the busiest hour 32 times the quietest, so windows of equal length held very unequal amounts of data and most of the workers finished early and waited. The effect was at its worst on a first-time full sync, where the range begins at the oldest vulnerability in the account: a single vulnerability that had not changed in years stretched the range across those years, and almost the entire account then landed in one window, leaving the sync effectively single-threaded no matter how it was configured. Windows are now placed so that each holds a comparable number of vulnerabilities rather than a comparable span of time. On a representative test this changed a four-way split from one window holding 64 of 65 records, with two holding none at all, to four windows holding 16 each. The connector works out where to place the boundaries with a small number of counting queries, capped so the cost stays negligible against the collection itself, and falls back to the previous behavior if those queries cannot be relied on. Controlled by the new optional Balanced scan windows setting, on by default, and only in effect when collection over several connections is enabled. - Having more time windows than workers now works as intended. That configuration is the one that lets a worker which finishes early pick up the next piece of work, and it is the reason the settings default that way — but the surplus time windows were not being queued. Instead the sync's own coordinating thread would stop and collect an entire window itself before handing out any more work, stalling the dispatch of everything behind it. Windows are now queued and collected by the worker pool, wherever the parallelism setting allows more than one worker. This matters most where activity is uneven: on one production tenant the busiest day carried 16 times the volume of the quietest and the busiest hour 32 times the quietest, so windows covering equal spans of time hold very unequal amounts of data, and keeping every worker fed is what shortens the sync. The defaults now set the window counts well above the worker count for this reason. - A partitioned vulnerability sync no longer fails after 30 minutes. Collecting over several connections was subject to a half-hour ceiling intended for local disk writes rather than for network transfers, so on a tenant large enough to benefit from it the sync would typically fail with a timeout instead of completing. The ceiling no longer applies; a stalled sync is now ended by the platform's own inactivity handling, and reports the failure rather than reporting success on a partial collection. - Incremental vulnerability syncs now fetch only what changed. A sync that ran after a previous one asked CrowdStrike for every vulnerability on every host that had contacted Falcon recently, rather than for the vulnerabilities that had actually changed. On one production tenant of 181.8 million records that meant each run pulled 92.3% of the entire corpus when the real day's change was 4.09% of it — between 13 and 210 times more data than needed, depending on the day's activity. Incremental syncs now ask for vulnerabilities whose own record changed since the last successful sync, which on that tenant is the difference between a run measured in hours and one measured in minutes. Two further consequences: a sync scheduled more often than every three days is now honoured, where previously CrowdStrike's own three-day minimum on the old filter silently widened it; and closed vulnerabilities are picked up reliably, including the small number whose closure does not update their record timestamp. First-time (full) syncs are deliberately unchanged and still collect every open vulnerability — bounding those the same way would have dropped anything left untouched for 45 days. If you need the previous behavior, the new Incremental change window option restores it.	N/A
3.3.0	Bug Fixes - Vulnerability syncs no longer fail to complete on platform 11x. Records are now written to the platform as they are collected from CrowdStrike, rather than after the entire collection has finished. On a large tenant that collection can take 12-14 hours, and because 11x does not recognise the connector's progress reports, a sync that produced no records for that long was cancelled before writing anything. In a full sync this also covers Vulnerability Definition, which reuses the records the vulnerability sync just collected and so makes no further calls to CrowdStrike. Synced on its own, with no recent vulnerability collection to reuse, a Vulnerability Definition sync still has to collect the corpus itself and can still hit this limit on 11x. Two consequences follow from writing records as they are collected. A sync that fails partway through may already have written some records: it still fails rather than reporting success, and the partial collection is discarded rather than reused, but the records written before the failure remain, and re-running the sync restores the full set. And a vulnerability may be sent more than once within a single sync — where a collection resumes, after CrowdStrike's paging session expires or on the final pass that picks up records changed while a partitioned sync was running, the record on the boundary is deliberately re-read rather than risk skipping it. Each vulnerability is identified by its own id, so a repeat resolves to the same record and no duplicates are created. - Vulnerability and Vulnerability Definition syncs can no longer serve stale data. Records collected during one sync could, in some circumstances, be reused indefinitely by later syncs instead of being collected fresh from CrowdStrike — so a sync would report success while returning results that never changed. Collected records are now reused only by other models within the same sync run, and only for up to 24 hours; anything older, or anything whose collection time cannot be established, is collected again. - Vulnerability and Vulnerability Definition syncs no longer fail partway through with "Search context expired, 'after' key no longer valid". CrowdStrike keeps a paging session open on its side while a sync reads through results, and that session has a time limit. On large tenants a sync outlives that limit — one run reached 1.35 million records over 49 minutes and then discarded all of them. The session now expires without ending the sync: it resumes from the last record it had already collected instead of failing. - An expired paging session is no longer retried. Retrying cannot succeed, because the session is already gone, so the connector previously spent roughly 15 minutes re-sending a dead request before giving up. It now recovers immediately. - Vulnerability syncs no longer stop early when CrowdStrike returns a partially filled page of results. The connector now reads to the true end of the result set, so no records are missed. - A sync that is interrupted partway through no longer leaves data behind that a later sync could mistake for a complete set of results. - When CrowdStrike rate-limits a request, the connector now waits exactly as long as CrowdStrike asks before retrying. It was reading the wrong response field, so every rate-limited request fell back to a fixed escalating delay starting at 30 seconds — on a large sync that turned brief throttling into many minutes of idle waiting. - The Max retries setting can now be set to 0 to disable retries. Previously 0 was silently ignored and the connector's default of 10 was used instead, so a failing request could not be made to fail fast. - The Max retries value supplied for an individual sync is now applied to vulnerability requests. It was previously ignored there, and the connector-level setting was always used. Improvements - Vulnerability and Vulnerability Definition syncs can optionally collect records from CrowdStrike over several connections at once, which can substantially shorten a large sync. CrowdStrike only allows results to be read one page at a time within a single query, so the connector splits the work into separate time windows and reads them in parallel, then performs a final pass to pick up anything that changed while the sync was running. This is controlled by the new optional Scan partitions setting and is off by default; leave it off unless you have measured that a sync needs it. - A new optional Replay threads setting shares the work of turning collected records into vulnerabilities across several threads, while records are still handed to the platform one at a time. This applies only to a sync that finds a recently collected set of records already on disk and re-sends them; a normal vulnerability sync collects and sends in a single pass and is unaffected by this setting. When it does apply, the order records arrive in is not fixed, which is safe because each vulnerability is an independent record identified by its own id. Defaults to the connector's parallelism setting capped at 4; set it to 1 for the previous behavior. Vulnerability Definition syncs are unchanged: building a definition combines many vulnerabilities into one record, and that combination depends on the order they are read in, so it continues to run one at a time to keep results consistent between syncs. - Rate-limit responses from CrowdStrike now record the remaining request budget in the logs, so how close a sync runs to the tenant's API limit is visible. - Added an optional Cursor restart limit setting (default 5) that caps how many times in a row a vulnerability sync may resume after its paging session expires. The count resets whenever the sync makes forward progress, so long syncs are not cut short — the limit only stops a sync that is stuck. Set it to 0 to restore the previous behavior of failing immediately. - Vulnerability syncs now report progress while records are being collected, so long-running syncs stay visible in the platform and can still be canceled. Note that not every platform version counts these reports as activity, which is why records are also written as they are collected rather than relying on progress reporting alone. - Vulnerability and Vulnerability Definition syncs collect records faster. Pages retrieved from CrowdStrike are now saved locally at the same time as the next page is being requested, instead of one after the other. Two optional settings tune this: Fetch write threads (how many pages are saved at once, defaulting to the connector's parallelism setting capped at 4; set to 1 for the previous one-at-a-time behavior) and Fetch progress seconds (how often a long collection phase reports progress, defaulting to 30 seconds).	N/A
3.2.24	No changes in this release.	N/A
3.2.23	New Features - Vulnerability records now include a dedicated "Last seen" attribute that maps directly to the host's last-seen timestamp from CrowdStrike. Previously this value was only folded into the aggregated "Last found" attribute; the separate field lets you build data-lifecycle logic around the host's raw last-seen date. Improvements - Spotlight Vulnerability and Vulnerability Definition syncs are significantly faster at production scale. Vulnerability Definition records are now aggregated in memory instead of being re-read and re-written to the on-disk store for every source vulnerability, and duplicate affected-application entries are detected with a lightweight key — eliminating the redundant work that previously dominated multi-hour syncs. Synced data is unchanged. - The vulnerability sync loops now log periodic progress (every 50,000 records) instead of multiple lines per record, reducing logging overhead and noise on large syncs. Bug Fixes - Vulnerability Definition sync no longer stalls and gets canceled on large tenants. Building definitions requires aggregating the entire vulnerability corpus first, and that phase previously ran (for hours, on large tenants) without reporting anything back to the platform — so the platform's no-progress timeout canceled the sync before any definitions were written. The connector now reports progress throughout the aggregation phase, keeping large beginning-of-time syncs alive to completion. - A failure while retrieving or storing vulnerability data during a Vulnerability or Vulnerability Definition sync now fails the sync loudly instead of silently continuing with partial data.	N/A
3.2.22	Improvements - Connector-sourced attribute values now take precedence over non-connector data channels (manual edits, bulk imports, UI input) when the platform consolidates records, so CrowdStrike data is no longer overridden by lower-priority sources. Bug Fixes - Behavior model: corrected 14 detection-flag attributes (Detect, Indicator, Inddet mask, Kill parent/process/subprocess, Operation blocked, Policy disabled, Process blocked, Quarantine file/machine, Registry operation blocked, Rooting, Sensor only) from text to true/false (Boolean), matching the values returned by the API. - Incident "Status" attribute corrected from a numeric type to text. - Detection "Max confidence" is now read as a number (the API field was incorrectly modeled as a timestamp). - Behavior "Pattern ID" is now stored as text consistently (it is populated from both the numeric pattern id and the string behavior id).	• Behavior, Incident, Detection: the attributes above changed data type. Re-sync the CrowdStrike Endpoint Security connector to repopulate these records with the corrected types.
3.2.21	No changes in this release.	N/A
3.2.20	No changes in this release.	N/A
3.2.19	No changes in this release.	N/A
3.2.18	New Features - Vulnerability records now include an "Evaluation logic (raw JSON)" attribute alongside the human-readable evaluation logic, and a "Data provider" attribute identifying the source of the evaluation. Evaluation logic is now populated only when the corresponding facet is enabled, avoiding unnecessary API overhead. Improvements - The standalone Evaluation Logic model has been retired; the same information is now surfaced directly on Vulnerability records.	• Evaluation Logic: this model is no longer synced. Purge existing Evaluation Logic records, then re-sync the connector so evaluation details are repopulated on Vulnerability records.
3.2.17	No changes in this release.	N/A
3.2.16	No changes in this release.	N/A
3.2.15	No changes in this release.	N/A
3.2.14	Improvements - Vulnerability Definition records now include a "Remediation titles" attribute summarizing recommended and minimum remediation titles. - Hardened timestamp parsing for vulnerability and CVE fields so records with empty or malformed dates sync reliably.	N/A
3.2.13	No changes in this release.	N/A
3.2.12	No changes in this release.	N/A
3.2.11	Improvements - Vulnerability remediation details are now parsed more completely, capturing the full set of remediation entities (reference, title, action, link, and publication date) returned by Spotlight.	N/A
3.2.10	Improvements - Vulnerability recommendations now include the normalized product name for affected products, making the affected-software list clearer.	N/A
3.2.9	No changes in this release.	N/A
3.2.8	Improvements - Simplified how the vulnerability "Last found" date is determined: open vulnerabilities use the host's last-seen time (falling back to the sync time), and closed vulnerabilities use their closed timestamp.	N/A
3.2.7	No changes in this release.	N/A
3.2.6	Improvements - Refined the vulnerability "Last found" date for open findings to prefer the host's last-seen timestamp, improving the accuracy of aging and SLA calculations.	N/A
3.2.5	Improvements - The vulnerability "Last found" date now uses the host's last-seen timestamp when available, with sensible fallbacks for open and closed findings.	N/A
3.2.4	Improvements - Reverted the previous release's evaluation-logic change: vulnerabilities again expose the multi-valued "Evaluation logic" attribute populated from the evaluation logic identifiers.	• Vulnerability: the "Evaluation logic" attribute was re-keyed back to its prior form. Re-sync the connector to repopulate this attribute.
3.2.3	Improvements - Reworked how vulnerability evaluation logic is captured, replacing the "Evaluation logic" attribute with an "Evaluation results" attribute sourced from the detailed evaluation-logic API response.	• Vulnerability: the evaluation-logic attribute was renamed and re-sourced. Re-sync the connector to repopulate this attribute.
3.2.2	Improvements - Vulnerability "Last found" now uses the source updated timestamp, and Vulnerability Definition records use a more appropriate display ordering.	N/A
3.2.1	No changes in this release.	N/A
3.2.0	Improvements - The CrowdStrike Endpoint Security integration has been re-platformed onto its own dedicated connector as part of splitting the original CrowdStrike connector into focused products (Endpoint Security, Cloud Security, and SaaS Security). The Device, Vulnerability, Vulnerability Definition, and Evaluation Logic models, their identifiers, and their attributes are unchanged.	N/A
3.1.12	Improvements - Vulnerability hostnames are now stored in the multi-valued "Hostnames" attribute, and vulnerability targets are split to correctly handle CrowdStrike instances that report identifiers in a customerID-agentID format.	• Vulnerability: the host identifier was re-keyed from "Hostname" to the multi-valued "Hostnames" attribute. Re-sync the connector to repopulate these records.
3.1.11	New Features - Added a new Evaluation Logic model that synchronizes CrowdStrike Spotlight evaluation logic as its own records.	N/A
3.1.10	New Features - Vulnerability records now include an "Evaluation logic" attribute describing the affected products and the logic CrowdStrike used to evaluate each finding.	N/A
3.1.9	New Features - Vulnerability Definition records now include an "Evaluation logic" attribute summarizing affected products and CrowdStrike's evaluation logic.	N/A
3.1.8	New Features - Device and Vulnerability records now carry lifecycle information so the platform can automatically retire assets and findings that CrowdStrike has not reported recently (devices not seen in the last 7 days; vulnerabilities tied to their host's lifecycle). - Vulnerabilities now expose both the provider's raw status and a normalized connector status for consistent reporting across platform versions.	N/A
3.1.7	New Features - Vulnerability Definition records now include an "Affected" attribute.	N/A
3.1.6	Bug Fixes - The device "Device control policy ID" attribute is now stored as text (it was previously, incorrectly, typed as a true/false value).	• Device: the "Device control policy ID" attribute changed type from boolean to text. Re-sync the connector to repopulate device records.
3.1.5	No changes in this release.	N/A
3.1.4	Bug Fixes - Corrected the vulnerability "Last found" date to use the sync time consistently.	N/A
3.1.3	Bug Fixes - Fixed vulnerability recommendation text so it is generated correctly for all findings, including those without open affected products.	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 and Vulnerability Definition records now resolve a single remediation URL, preferring the CrowdStrike link and falling back to the vendor URL when needed, and more reliably derive vulnerability and CVE identifiers.	N/A
3.0.24	Improvements - Vulnerability recommendation text now includes a dedicated "Remediation" section listing the remediation actions for the finding, and clarifies the affected/unaffected product version headings.	N/A
3.0.23	Improvements - Vulnerability results now clearly label affected versus unaffected product versions based on each product's status.	N/A
3.0.22	Improvements - Vulnerability Definition identifiers now support a configurable prefix (defaulting to CSID), making it easier to align definition UIDs with your environment. Bug Fixes - The vulnerability "Coarse score" and "Fine score" attributes are now stored as full-precision decimals instead of single-precision values.	• Vulnerability: the "Coarse score" and "Fine score" attributes changed type to double-precision decimals. Re-sync the connector to repopulate these records.
3.0.21	Improvements - Improved the vulnerability "Last found" date so open findings without an explicit last-found value fall back to the source updated timestamp or sync time.	N/A
3.0.20	Improvements - Device synchronization now uses CrowdStrike's scroll-based query endpoint for more reliable paging over large device populations. - Vulnerability Definition syncing now filters by the source updated timestamp for accurate incremental syncs.	N/A
3.0.19	Bug Fixes - The device "Last login user" attribute is now stored as text (it was previously, incorrectly, treated as a timestamp).	• Device: the "Last login user" attribute changed type from timestamp to text. Re-sync the connector to repopulate device records.
3.0.18	Improvements - Vulnerability Definitions are now streamed to the platform as they are discovered, reducing memory use and improving sync throughput.	N/A
3.0.17	New Features - Device records now include a broad set of additional attributes, including chassis type, connection IP and MAC, default gateway, kernel and OS build details, reduced-functionality mode, policy assignments, hostnames, IP addresses, login history, and last-started time.	N/A
3.0.16	No changes in this release.	N/A
3.0.15	Improvements - Improved formatting of the vulnerability results text describing affected product versions.	N/A
3.0.14	Improvements - Vulnerability records now populate "Source last modified", "Last found", and a normalized status category, improving finding aging and reporting accuracy.	N/A
3.0.13	Improvements - Temporary working data created during synchronization is now cleaned up automatically, preventing buildup of stale files between syncs.	N/A
3.0.12	Improvements - When the same CVE appears across multiple vulnerabilities, the connector now prioritizes data from open findings, and exposes the "ExPRT rating" on vulnerabilities.	N/A
3.0.11	New Features - Vulnerability Definition records now include a "Patch available" attribute indicating whether CrowdStrike reports an available remediation.	N/A
3.0.10	Improvements - Device hostnames are now normalized, and private DNS names are detected and stored in a dedicated attribute.	N/A
3.0.9	New Features - Device records now include a "Serial number" attribute. Improvements - Improved paging defaults and vulnerability storage handling for more reliable large syncs.	N/A
3.0.8	No changes in this release.	N/A
3.0.7	No changes in this release.	N/A
3.0.6	Improvements - Increased the default page size for faster synchronization, and improved parsing of remediation due dates and remediation details.	N/A
3.0.5	New Features - Added a configurable "Max retries" setting to control how many times API requests are retried on transient failures. Bug Fixes - Corrected configuration validation so the parallelism level is validated against the correct setting.	N/A
3.0.4	New Features - Device records now include an "Instance ID" attribute. Bug Fixes - Vulnerability Definition CVE identifiers are now populated from the correct CVE value.	N/A
3.0.3	Improvements - Vulnerability Definition identifiers are now prefixed with CSID- for consistency.	N/A
3.0.2	Improvements - Device synchronization now supports a configurable parallelism level and applies page-size and last-seen filters more efficiently for faster, more reliable syncs.	N/A
3.0.1	New Features - Vulnerability Definition records now include an "Exploitability" attribute (mapped from CrowdStrike's exploit status) and an "ExPRT rating" attribute. Improvements - Expired vulnerabilities are now excluded by default during synchronization.	N/A
3.0.0	Overview The CrowdStrike Endpoint Security connector integrates with the CrowdStrike Falcon platform to synchronize managed devices, their vulnerabilities, and vulnerability definitions sourced from CrowdStrike Spotlight. Category: Endpoint Protection Models	N/A