OpenCTI and Microsoft Sentinel integration

The integration runs as two separate data paths, and each needs its own decisions. The outbound path carries indicators from OpenCTI to a Sentinel workspace. A connector consumes the stream of indicator events, applies its filters, and sends matching indicators through the Upload Indicators API to the target workspace. The platform does not call Sentinel directly. The work happens in a connector container that runs alongside the platform. Ask whether the connector consumes the stream continuously or runs on a schedule, because that decides whether changes reach Sentinel as they happen or in batches. Confirm the filter options, such as indicator type, labels or marking definitions, against the connector's own documentation before you enable it.

Both paths depend on the worker model. The deployment overview describes Python workers that consume RabbitMQ messages for asynchronous writes, and connectors use the same message-driven pattern to exchange data with the platform. A stalled queue, a stopped worker or an exhausted RabbitMQ volume can delay indicators leaving OpenCTI or incidents entering it, even when the web interface looks healthy. Plan monitoring for queue backlog and connector logs from day one. Size the worker count against the documented guidance of at least one platform node for every 3 workers, then validate that sizing against your own indicator volume and the number of connectors you intend to run.

The inbound path reads Sentinel incidents and creates corresponding STIX objects in OpenCTI. The connector queries Sentinel for incidents within a configured scope, converts each one into STIX objects, and writes them through the platform so they enter the knowledge graph like any other data. Before go-live, decide which incident fields map to which STIX object types, and which workspace and time window the connector reads. Confirm in the connector documentation whether updates to an existing Sentinel incident are reflected in OpenCTI or whether they create duplicate objects. That behavior determines how analysts will read the imported data and how much cleanup you will need later.

Direction, filters and frequency for each path are set in the connector configuration. Outbound and inbound settings are usually held in separate connector instances, so their values can differ, and you should record the value chosen for each. Check those settings again after any upgrade, because option names and defaults can change between connector releases. Test with a small, clearly labeled set of indicators first. Confirm that the objects appear in Sentinel, then trigger a known test incident and check that the expected STIX objects appear in OpenCTI. Widen the scope only after both checks pass. Confirm the minimum OpenCTI version that the connector supports with its documentation and your chosen release line.

The connector can sign in to Microsoft Sentinel in two main ways: with an Entra app registration that authenticates by client secret or certificate, or with a managed identity assigned to the Azure host the connector runs on. Settle this decision before deployment, because it determines where the connector can run, who owns the credential, and how rotation is handled. Confirm in the connector's documentation which option it supports, since support can vary by connector version and packaging.

An app registration is owned by your identity team. That team creates the object, holds the secret or certificate, and sets its expiry. The credential has to be stored in the OpenCTI deployment's secret handling, and rotation becomes a recurring task. If the secret expires before it is replaced, streaming stops, so add the expiry date to your team's calendar and to the connector runbook. A certificate reduces the risk of a copied secret but still needs protected key storage and renewal. Sign-in activity appears in Entra logs under the app's service principal, which helps attribute writes to this connector. The main advantage is portability: an app registration works from any network that can reach Entra ID and Sentinel, including a self-hosted OpenCTI in your own data center.

A managed identity removes the stored secret from the connector configuration and from the rotation calendar. The trade-off is placement. Managed identities are available only to Azure resources that support them, so the connector must run on a supported Azure host, such as a virtual machine or a container or app service that supports managed identities. Verify the host types the connector package supports. If OpenCTI runs on premises or in another cloud, you would need a separate Azure-hosted component to run the connector, which adds a network path, an Azure resource and its patching to operate. Ownership also shifts: the identity's lifecycle follows the host, so decommissioning or recreating that host changes the identity and the role assignments attached to it.

Whichever option you choose, scope the permissions tightly. Grant access only to the single Sentinel workspace the connector writes to or reads from, and only to the actions the connector needs, such as uploading indicators or reading incidents. Check which built-in Azure roles cover those actions in your tenant, and confirm whether a custom role is needed. Record the decision, the identity owner, the scope and the expiry or review date in your configuration records. Repeat the permission review whenever the connector or OpenCTI version changes, because required actions can change between releases.

Define what passing looks like before you send a single test indicator. Write down expected results for each check in a test record: the TLP marking and labels each seeded indicator should carry, the fields you expect to see in the Sentinel workspace, the expiry behavior you expect after a revocation, and the number of objects you expect after each restart. If the expected result is written after the test runs, a surprising outcome becomes a debate instead of a fail. Keep the record with the change ticket so the auditor or the next engineer can see what was decided in advance.

Seed a small, known set of test indicators in OpenCTI. Include a few with each TLP marking your connector filters are meant to handle, and give each one a distinct label so you can trace it. Confirm in the Microsoft Sentinel workspace that each indicator arrives with the expected threat indicator fields, including the confidence, valid-from and valid-until values and the tags you mapped. Then revoke one test indicator and an expired one in OpenCTI and confirm the change propagates. Check that the revoked or expired indicator is no longer active in Sentinel, and record how long the change took to appear so you can compare it with your own tolerance for stale intelligence.

Restart the connector deliberately and check for duplicate creation. Run the same seeded set through at least one restart of the stream or import connector and count the indicators in Sentinel afterward. Duplicates usually point to a missing external identifier, a changed indicator name, or a connector state file that was not persisted. Repeat the check after a restart of the whole OpenCTI platform, because the work queue and worker state can change what gets re-sent. Create a test incident in Sentinel, confirm it appears in OpenCTI, and compare its title, severity, status and mapped attributes against your mapping document.

Confirm that restricted data stays inside OpenCTI. Mark a test indicator with the most restrictive TLP marking your policy covers, then query the Sentinel workspace and the connector logs to confirm it never appears. Check the connector configuration as well, because a filter that is correct in the UI can still be overridden by an older configuration file. Ask your security team to sign off on this check, since it is the one most likely to matter during an incident review.

Review the connector logs and the OpenCTI work queue after the platform restart. Look for repeated authentication failures against the Entra app registration or managed identity, throttling responses from the Upload Indicators API, and messages that stay in the queue without being processed. Record any warnings and decide in advance which ones block acceptance. Confirm with Microsoft documentation and your own Sentinel tenant which API limits and token lifetimes apply, rather than assuming the values from a previous setup.