CrowdStrike Falcon Integration
Bring your own EDR: connect a read-only Falcon API client and get a daily agent-health report for every Falcon-protected device, beside the rest of your security data.
Many small businesses already run CrowdStrike Falcon. This integration does not replace it; it pulls the smallest useful slice of your tenant, the health of each sensor, and turns it into ordinary device runs in the Monitoring Hub and the Security Attestation Report. Software inventory, vulnerability data, and alert contents are deliberately never read.
What you get
Once a day, one Device run per Falcon host with these checks:
| Check | Passes when | Severity |
|---|---|---|
| EDR sensor online | The host has checked in within the last 7 days | High |
| EDR sensor healthy | The sensor is not in reduced-functionality mode (RFM) | Medium |
| EDR prevention policy assigned | A prevention policy is applied to the host | Medium |
| EDR no active alerts | No Falcon alerts for the host are still New, In Progress, or Reopened | High |
Each run is scored Healthy (all pass) or At Risk (any fail), appears in the hub with the target <hostname> (EDR) and the submitter system:falcon, and opens into the same device posture report as an agent scan. The (EDR) suffix keeps a Falcon health row distinct from a Blue Lantern agent scan of the same machine; both can exist.
Hosts unseen for more than 30 days stop producing runs entirely, so retired laptops age out of your fleet count instead of failing forever. Hosts marked suppressed or hidden in the Falcon console are skipped.
Setup
- Create an API client in your Falcon console. Go to Support and resources → API clients & keys → Create client and grant exactly three scopes, all read-only: Hosts: Read, User Management: Read, and Alerts: Read. Your cloud region (
us-1,us-2,eu-1, orus-gov-1) is displayed next to the created client. - Connect. Open Integrations → Add Integration → CrowdStrike Falcon, and enter the client ID, client secret, and region. The credential is validated against CrowdStrike before anything is stored, so a successful connect means it genuinely works. A failure names the cause: a bad region reads as a rejected credential, so check that first.
- Wait for the first scan. The scanner runs daily; the first health runs appear in the Monitoring Hub after the next sweep.
What each scope is for
- Hosts: Read is the only required scope. It powers all three health checks.
- Alerts: Read enables the no active alerts check. Reads are presence-only: alert ids are counted per host, and no alert content is ever stored. Without this scope the check is simply omitted from each device report.
- User Management: Read improves device-owner attribution (below). Without it, a host's most recent login username is recorded but not matched to an email.
Device ownership
The device record itself carries no email, so ownership is worked out in a strict order and never guessed:
- A
FalconGroupingTagstag of the formemail:[email protected]on the host is treated as an exact override. - Otherwise the most recent interactive login username (system and daemon accounts filtered out) is matched to a console user email by an unambiguous local-part match, for example the local user
amyburgermatching[email protected]. If two candidates match, nobody is attributed rather than the wrong person. - When only a username is known, the device report shows it flagged as unverified.
Managing the integration
- Credential rotation. The Falcon row's Reconnect button re-opens the connect form; submitting it re-runs the connection against the same integration, so rotating the client secret is just a reconnect.
- Errors. A revoked or invalid credential at scan time sets the integration to error with a plain-language reason, and non-fatal scan issues are shown on the row even while it is connected. There is no re-authorization flow to complete; fix the credential and reconnect.
- Removal. Remove stops the daily scans and erases our copy of the credential. The API client itself stays in your Falcon console until you delete it there.
- Limits. One Falcon tenant (CID) per account. Fleets are capped at 500 devices per scan.
Billing and privacy
Falcon monitoring is covered by an active Seat License, like every monitor. We read device health fields (hostname, platform, last seen, sensor version and mode, prevention-policy status), login history for attribution, and alert counts. We never read host contents, detections, software inventory, or vulnerability data. The client secret is stored in AWS Secrets Manager and is never returned by any API.