What each connector actually pulls, and what's still not self-service
Custelis feeds your existing security stack instead of replacing it - Entra ID, Defender, Purview, Active Directory, and an outbound SIEM/SOAR export. Here's exactly what each one does, what it needs, and where the honest limits are.
The thing to know before anything else: connecting Entra ID, Defender, Purview, or Active Directory isn't a self-service "click connect" flow yet - you can see connection status and last-sync time for each in the product, but the actual credentials (an app registration's client secret, an LDAP bind password) are configured by our team during setup, not entered by you in a settings page. Teams and Slack notification webhooks are the one integration that's genuinely self-service today. We'd rather say that plainly than let "Built" imply more than it does.
The connectors
| Connector | What it pulls | Requires | Test coverage | Self-service today |
|---|---|---|---|---|
| Microsoft Entra ID | Risky sign-ins (Identity Protection) + a directory size summary (user/group counts) | App registration: tenant, client ID, client secret (Graph API, admin-consented) | Full - faked-API test + full orchestrator test | No |
| Microsoft Defender | Device posture (health, risk score) and security alerts from Defender for Endpoint | App registration: tenant, client ID, client secret (Security Center API) | Full - faked-API test + full orchestrator test | No |
| Microsoft Purview | DLP compliance alerts from the last sync window | App registration: tenant, client ID, client secret (Graph Security API) | Full - faked-API test + full orchestrator test | No |
| Active Directory | LDAP directory summary - user/OU counts and a small display-name sample | Host, base DN, bind DN, bind password (LDAP) | Partial - the no-credentials no-op is tested; the actual LDAP bind/search path doesn't have automated test coverage yet | No |
| SIEM / SOAR export | Outbound: Custelis's own audit, alert, DLP, risk, USB, and file events, as CEF or JSON | An HTTPS endpoint + token, or a syslog host/port - set via environment config, off by default | Partial - HTTPS/CEF path fully tested; syslog delivery isn't covered by an automated test yet | No (env-configured, not per-org) |
| Teams / Slack | Notification delivery for alerts and DPDP-queue events | An incoming webhook URL | N/A - configuration only, no upstream data pull to test | Yes - Admin → Integrations |
How the four Microsoft/AD connectors actually work
Once configured, each runs on an hourly scheduled job. Every connector is a guarded no-op: missing any required credential and it returns nothing - no HTTP call, no LDAP bind, nothing logged as a failure. None of the four ever reads passwords, session tokens, or cookies from the source system; Entra ID and Defender pull only identity-risk and device-posture signals, Purview pulls only its own DLP alert metadata, and Active Directory pulls only directory-structure counts and display names, never credentials.
What comes back feeds the same engines that power the rest of the product - a risky sign-in becomes a risk signal and a reviewer alert through the same pipeline described in how Custelis's DLP engine decides; a Defender alert updates a device's security status directly; a Purview DLP alert is evaluated by the same DLP engine used for USB and email events, escalating to a risk event and alert if it warrants one.
One honest limitation worth calling out: Purview's classification is a heuristic
Purview's own DLP alerts don't hand back a clean, structured classification in every case - the connector infers likely classification, source, and destination from keyword patterns in the alert content (for example, an alert mentioning "client" is treated as client-confidential; one mentioning "usb" is treated as a USB destination). That's a reasonable signal, not a precise parse of Purview's actual policy taxonomy. If exact classification fidelity matters for your use case, verify this directly rather than assume it matches Purview's own labeling one-to-one.
SIEM/SOAR export is architecturally different from the other four
The four Microsoft/AD connectors pull data in from a third-party tenant. SIEM export pushes Custelis's own already-collected events out, formatted as CEF (for tools like ArcSight/QRadar) or JSON, over HTTPS or syslog. It's off by default and runs every five minutes once enabled, with a per-source cursor so a restart or a failed delivery never loses or duplicates events on a successful run.
What "Built" means on this page: a real API/LDAP client with real request/response handling, guarded to fail safely with no credentials, wired into the actual scheduled job that runs in production - not a mockup or a roadmap slide. It does not yet mean self-service setup for the four inbound connectors, and for Active Directory and SIEM's syslog path specifically, it doesn't yet mean the same depth of automated test coverage the other connectors have.
Ask about connecting your stack
No credit card to start. Intrusive features stay off until your own DPIA is recorded.
Try for free