Should you run MISP and OpenCTI together or pick one?
If you already run MISP and someone asks whether to add OpenCTI, or the reverse, the decision turns on which job you need done. Both community editions are open source: MISP is licensed under AGPL-3.0 and the OpenCTI Community Edition under Apache-2.0. In the usual pairing, MISP stays the sharing hub, where distribution levels, sharing groups and synchronization with other MISP instances decide who sees each indicator. OpenCTI acts as the STIX knowledge graph, where analysts model entities, relationships and reports. The OpenCTI MISP connector is the common bridge that imports MISP events into OpenCTI so the data does not have to be re-entered by hand. Confirm the connector's import direction, filters and schedule against the versions you plan to deploy.
One platform is enough when the real need is either sharing or analysis, not both at once. If your work is mainly exchanging indicators with partners and correlating them internally, MISP covers that on its own. If your work is mainly structured analysis with STIX objects and a graph, OpenCTI may cover it, but you should check that the Community Edition provides every feature your team depends on. Factor in the Enterprise Edition gates early: audit logs, playbooks and automation, organization segregation and SSO through OpenID, LDAP or SAML all require the paid OpenCTI Enterprise Edition. If an auditor or your identity team needs those controls on OpenCTI, price the subscription into the decision from the start.
Running both means duplicating data and operations. Each platform needs its own hosting, upgrades, backups and access model. OpenCTI depends on Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, while MISP runs on PHP with MySQL or MariaDB and Redis, so you are maintaining two stacks. Before go-live, decide which system is authoritative for each indicator, who owns connector failures and how deletions and sharing changes propagate from one platform to the other. Those answers determine whether the duplicate copy stays accurate or quietly drifts. Ask your team to document them in writing and test them with a sample of real-world events before you commit to both platforms.
How the OpenCTI MISP connector imports events
This sequence shows how an OpenCTI deployment pulls MISP events into its knowledge graph while MISP keeps its own events, distribution levels and sharing groups. Each step ends with a check you can run before moving on.
Confirm which platform is the sharing hub
Before any connector is configured, the team decides which system owns sharing decisions. In this setup MISP usually remains the place where events are created, tagged with distribution levels and published to sharing groups, and OpenCTI becomes a consumer for analysis. Record this decision in writing with the people who manage MISP and the people who manage OpenCTI. You know this step is done when both teams agree on which system is authoritative for each type of data and who can change it.
Deploy the OpenCTI platform and its dependencies
The platform team installs OpenCTI with its supporting services: Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, as listed in the OpenCTI deployment documentation. OpenCTI runs as a stateless platform with a GraphQL API, and its Python workers consume RabbitMQ messages for asynchronous writes. Confirm the versions you install against the documented minimums. You know this step is done when the platform answers through its UI and API and the message broker and search backend are reachable from the workers.
Create a MISP API key with a scoped account
The MISP administrator creates a dedicated user for the connector and issues it an API key. Give this account the least access it needs to read the events and attributes you intend to import, and review which sharing groups and organizations it can see. MISP enforces distribution levels and sharing groups, so the connector only receives what this account is permitted to read. You know this step is done when a test query made with that key returns only the events you expect.
Register and configure the MISP connector
The OpenCTI administrator deploys the MISP connector as a worker and supplies the MISP URL, the API key and the import settings. The connector reads these values from its configuration and needs to reach the MISP instance over the network. Confirm in the connector documentation which direction the data flows, which filters apply, and which MISP object types are covered, because the connector maps MISP data into the OpenCTI knowledge schema and the mapping is one-way unless you configure otherwise. You know this step is done when the connector shows as registered in OpenCTI and reports a healthy status.
Map MISP events into STIX entities and relationships
When the connector runs, it reads MISP events and attributes and converts them into STIX-based entities and relationships in the OpenCTI knowledge schema. Attributes such as indicators, observables and threat actors become objects that can be linked, reported on and enriched inside OpenCTI. The original MISP event keeps its identifiers and is not altered by the import. You know this step is done when a sample MISP event appears in OpenCTI with its indicators and relationships, and you can trace them back to the source event ID.
Check that MISP keeps its own sharing controls
After the first import, the team verifies that MISP still holds the original events with their distribution levels, sharing groups and synchronization settings unchanged. Imported data in OpenCTI does not change what MISP shares with partner instances, and any sharing decision still happens in MISP. Compare a sample event in both systems to confirm the distribution metadata is recorded as the connector documentation describes. You know this step is done when the MISP event is unchanged and the sharing controls match the policy agreed in step one.
Monitor imports and plan for duplicate data
The operations team watches connector logs and RabbitMQ queues for failed or stalled imports, and reviews how often events are re-imported after updates in MISP. Because the same indicators now exist in two systems, decide who corrects a wrong indicator, how deletions in MISP reach OpenCTI, and which system is consulted first during an investigation. Ask your OpenCTI and MISP vendors or the community maintainers to confirm how updates and deletions propagate. You know this step is done when a runbook names an owner for each data flow and a test deletion or update behaves as the runbook says.
MISP and OpenCTI roles, licenses and operating needs
This table compares the parts that matter once MISP and OpenCTI run side by side: license, data model, sharing, dependencies and current releases. Read each row as a question to answer for your own environment before deciding which system holds the authoritative copy of intelligence.
| Area | MISP | OpenCTI |
|---|---|---|
| License | AGPL-3.0 for the software. Taxonomies and galaxies carry separate CC0 1.0 or BSD-2-Clause terms. | Community Edition under Apache-2.0. Files marked Enterprise Edition need a paid subscription under the OpenCTI Enterprise Edition License. |
| Paid features to confirm | No separate paid edition is named in the supplied facts. Confirm feature scope with CIRCL and the project before assuming parity. | Audit logs, playbooks and automation, organization segregation and OpenID, LDAP or SAML SSO require Enterprise Edition. |
| Core data model | Events containing attributes and objects, with taxonomies, galaxies and warning lists for tagging and context. | STIX-based entities and relationships in a knowledge schema, queried through a GraphQL API. |
| Sharing model | Distribution levels and sharing groups down to individual attributes, with synchronization between MISP instances and trusted communities. | Connectors import and export data. Sharing across organizations depends on connector setup and the Enterprise Edition controls you need. |
| Integration path between them | Source of indicators and events that the OpenCTI MISP connector imports. | Consumes MISP events through its connector. Confirm mapping and deduplication behavior in your own test instance. |
| Core dependencies | PHP with CakePHP, MySQL or MariaDB, and Redis. | Elasticsearch 8.0 or later or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later and S3-compatible storage. |
| Operating footprint | One PHP application stack with a relational database. Confirm sizing with CIRCL guidance and your sync volume. | Platform, Python workers and connectors, plus search, queue, cache and object storage. The documented sizing recommends at least one platform node for every 3 workers. |
| Current release line | MISP 2.5.50 is the current release. MISP 2.5 is the recommended line for new deployments. | OpenCTI 7.261016.0 is the current release. LTS builds such as 7.260309.0-lts.8 need a specific LTS license key. |
What changes whether duplication is worth it
Running MISP and OpenCTI together only pays off when a specific requirement pulls data into both places. The factors below are the conditions that tip the decision, and each one should be checked against your sharing obligations, analyst workflow and staffing before you commit to two stacks.
Required sharing community
If your sharing partners, sector community or national CERT exchange indicators in MISP, MISP stays the sharing hub. Confirm which communities require MISP sync and which distribution levels and sharing groups they expect. If the community only needs indicators, you may not need a second platform for them at all. Ask the community operators which format and sync method they accept before you design the flow.
Knowledge graph or indicators
Analysts who need to model actors, campaigns, malware relationships and reports over time gain more from OpenCTI's STIX-based entities and relationships than from a flat set of MISP attributes. If your analysts mainly correlate and distribute indicators, MISP may already cover the work. Test a realistic analyst workflow on both platforms before you assume the graph is needed.
Administrative load on two stacks
Each platform brings its own upgrade path, backups and dependencies. OpenCTI depends on Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, while MISP runs on PHP with MySQL or MariaDB and Redis. Count the people who will patch, monitor and restore both systems, and confirm their time is funded. A two-person team often struggles to keep two stacks current.
SSO and audit logging placement
OpenCTI's audit logs, playbooks, organization segregation and SSO through OpenID, LDAP or SAML sit in Enterprise Edition. Check whether your identity and audit requirements must be enforced on the platform that holds the analyst data. If they must, confirm that the MISP side meets the same controls, such as its OpenID Connect plugin, and that one identity source governs both.
Sync frequency and duplicated volume
The OpenCTI MISP connector imports MISP events into OpenCTI, so every event you bring across is stored twice and can drift from its source. Estimate how often events change and how many objects each sync creates. High change rates raise the chance of stale or conflicting copies. Test a sample feed for a full sync cycle and measure object counts, duplicates and update conflicts before you scale it.
Enterprise Edition feature needs
Decide which Enterprise Edition features the team needs, such as playbooks, audit logs or organization segregation, and whether the license covers them. OpenCTI Enterprise Edition requires a paid subscription, and LTS builds need a specific license key. Ask Filigran for a written quote covering each feature and the support window, and compare that cost against running MISP alone for the same workflow.
What duplicating data costs in operations
Running both platforms means the same indicator can live in MISP and in OpenCTI at once, and each copy then needs its own rules. Decide which system owns the lifecycle of an indicator, how a copy imported through the MISP connector is deduplicated against records created natively in OpenCTI, and what happens when a source revokes an indicator in MISP. If the revocation does not reach OpenCTI, analysts will keep working from stale data. Access controls also multiply: MISP distribution levels and sharing groups do not automatically carry over to OpenCTI markings, so confirm how each copy is restricted before you rely on either one for sensitive intelligence.
The operational cost is mostly recurring. You run two upgrade cycles: MISP is on the 2.5 line, and OpenCTI ships standard releases or LTS builds on its own schedule. The OpenCTI product life cycle documentation says LTS releases need a specific LTS license key, so confirm with Filigran whether your subscription covers the LTS line you plan to run. Each platform also needs its own backups, restore tests and dependency management, since OpenCTI relies on Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, while MISP uses its own database and Redis stack. Ask whoever will run both platforms to estimate the hours per month for patching and restore testing, and get that figure in writing from the implementer's quote.
Measure before you commit. Track how many indicators exist in both systems, how often a revocation in one fails to appear in the other, how long a restore of each platform takes in a test environment, and how many upgrade windows you would need in a year. If those numbers show frequent drift or heavy operator load, one platform is probably enough for your use case. OpenCTI's deployment overview lists the dependencies to count when you build that operating model.
How to test the pairing in your own environment
This sequence tests whether MISP and OpenCTI can share one threat intelligence flow without losing context or creating conflicting records. Each step leaves a written record, from partner requirements to object counts after re-import and an upgrade effort log, so the decision rests on your own environment.
List sharing partners and sync dependencies
The sharing lead lists every organization that receives data from your MISP instance and records how each one takes it: through MISP synchronization, the REST API, feeds, or STIX and CSV exports. Note the distribution levels and sharing groups applied to each partner. The step is complete when every partner has one recorded method, and each partner that depends on MISP synchronization is flagged, because those are the relationships most exposed if OpenCTI becomes the hub.
Stand up non-production MISP and OpenCTI
The platform team deploys a MISP instance and an OpenCTI instance in a non-production environment, using the versions you plan to run. MISP 2.5 is the recommended line for new deployments. OpenCTI needs Elasticsearch 8.0 or later or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later and S3-compatible storage. The step is done when all services report healthy and the exact versions are written into the test record.
Run a sample MISP connector import
Configure the OpenCTI MISP connector against the test MISP instance and scope it to a sample of events that covers your distribution levels and at least one sharing group. Start the import and review the connector logs for errors and skipped events. The step is complete when the connector finishes and you can trace sampled OpenCTI objects back to their source MISP event identifiers. This confirms that the mapping from MISP attributes to STIX objects behaves the way your analysts expect.
Compare object counts after re-import
Record counts by object type in MISP and in OpenCTI for the sample set. Then edit several events in MISP, revoke or delete some indicators, and run the connector again. Check whether revoked or removed indicators are updated, flagged or left behind in OpenCTI, and whether the counts match the source. Ask the connector maintainers to confirm how revocations and deletions map before you rely on the result. The step is done when the before and after table is signed off by the analyst lead.
Check SSO and audit needs against Enterprise
The security lead writes the required features in a matrix: SSO through OpenID, LDAP or SAML, audit logs, playbooks and automation, and organization segregation. OpenCTI's documentation states that audit logs, playbooks, organization segregation and SSO through OpenID, LDAP or SAML require the Enterprise Edition, which is licensed under the OpenCTI Enterprise Edition License. Mark which items are must-have. Check MISP authentication options separately in the OidcAuth plugin README. The step is done when each requirement has a verified edition, plugin or configuration source.
Log admin hours for upgrade tasks
The platform owner logs every hour spent on upgrade-related work for both systems across a set test period. Use the tasks you expect to repeat: applying MISP point releases, moving between MISP major lines, updating OpenCTI and its dependencies, aligning connector versions, and handling the license key that OpenCTI LTS builds require. Separate hands-on time from waiting time. The step is done when the log gives hours per task type, which you can compare with the scope and cost of any retainer quote.
Decide on one hub or two
The sharing lead, analyst lead and platform owner review the test records together and choose one of three paths: keep MISP as the sharing hub with OpenCTI as an analysis layer fed by the connector, make OpenCTI the hub, or run a single platform if your partners and analysts are fully served by it. Write down which partners depend on MISP synchronization and who will run each system after go-live. The step is done when the decision names the hub, the owner of each system and the open questions to confirm with vendors before any contract is signed.
Questions teams ask before running both platforms
Can OpenCTI replace MISP if we only want one threat intelligence platform?
Sometimes, but only if your sharing work and your analysis work can both live in one tool. MISP is built for exchanging indicators with sharing communities, using distribution levels, sharing groups and synchronization between instances, and it exports to STIX 1 and 2, CSV, Suricata, Snort and Zeek formats. OpenCTI organizes intelligence as STIX-based entities and relationships and is strongest for analysis and knowledge management. If partners or communities expect MISP sync, removing MISP means rebuilding those exchanges, so confirm with each community which formats and sync methods it accepts. Also confirm that the features you need, such as audit logs, playbooks and SSO options, are available in the edition you plan to use.
Does the OpenCTI MISP connector import everything from our MISP instance?
No, not by default. The connector imports the data its configuration allows, and differences appear in how MISP events and attributes are mapped into STIX entities and relationships. Before relying on it, confirm in the connector documentation which MISP objects, galaxies, tags and distribution settings are carried over, which are skipped, and which are transformed. Test with a representative sample of events from your own instance, then compare counts and relationships on both sides. Plan for mapping differences to be found during testing, and decide who signs off on what the analysts will see in OpenCTI.
Who should own the sharing hub, MISP or OpenCTI?
In most designs MISP should own sharing, because its distribution model and synchronization with trusted communities are what partners usually expect. OpenCTI then consumes from MISP for analysis, reporting and knowledge management. The main risk is two-way editing: if analysts change the same indicator in both platforms, you end up with two versions of one record. Document a one-way flow where you can, decide which platform is the system of record for each field, and assign a named owner for connector health, sync failures and schema changes. Ownership should be written down before the first import, not after the first conflict.
What does running both platforms cost in effort, and what drives it?
Costs fall into one-time work, such as architecture, connector configuration and mapping tests, and recurring work, such as upgrades, backups and access reviews for two systems. The OpenCTI deployment overview documents minimum sizing for the platform and for Elasticsearch or OpenSearch, and it recommends at least one platform node for every three workers. OpenCTI also depends on Redis, RabbitMQ and S3-compatible storage, each of which needs operating. Recurring effort grows with release cadence: OpenCTI ships non-LTS releases from daily to weekly, while LTS builds require a specific license key. Ask any provider to split the quote by platform, by connector work and by ongoing support so you can see which items recur.
Can our own team run both platforms without outside help?
Yes, if the team already runs Linux services, containers or configuration management, and has operated Elasticsearch or OpenSearch, RabbitMQ and Redis in production. Check that someone can own the MISP upgrade path, including the 2.5 line, and that someone holds the OpenCTI license decisions and LTS planning. Also confirm who responds when a connector stops importing at 2 a.m. If those skills are thin, outside help can cover design, implementation and documented runbooks under a written, fixed scope, with ongoing support available as a retainer. Either way, the team that will operate the stack should be part of the design work.
What must we ask a partner or vendor before committing to both platforms?
Ask for the scope in writing, including which connectors, mappings and data types are covered and what is excluded. Ask which MISP version and which OpenCTI edition they assume, and which features in your plan need the Enterprise Edition. Ask how they will test the connector against a sample of your events, who owns the runbooks after handover, and how upgrades are handled for MISP and for OpenCTI LTS releases. Ask what evidence they will hand over for your compliance file, and what they will not provide. Get deliverables, timelines and support terms in one document before work starts, so each item can be checked against what was delivered.
How DeployOpen evaluates and implements a MISP and OpenCTI setup
DeployOpen approaches MISP and OpenCTI as two systems with separate jobs, so the first decision is which one owns sharing and which one owns analysis. We plan, implement, integrate, harden, document and support both inside your own infrastructure, under a written scope agreed before work starts.
How we scope
- Written scope names which platform is the sharing hub and which holds analyst knowledge.
- Scope lists the connectors, import rules and distribution levels that move data between the two.
- Scope states hosting targets, including cloud accounts, data centers or air-gapped networks, and who operates each system.
- Scope records the license and edition needed for each platform, including any OpenCTI Enterprise features you require.
How we build
- We install MISP and OpenCTI in your environment, with OpenCTI dependencies such as Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage sized to the agreed workload.
- We configure the OpenCTI MISP connector and test which events, attributes and objects import, and how identifiers are kept.
- We test authentication, sharing groups and role mappings, and document which SSO features your chosen edition actually provides.
How we hand over
- Handover documents the data flow, duplicate records, sync schedules and the owner of each import and export path.
- Runbooks cover upgrades for MISP 2.5 and the OpenCTI release line you choose, including LTS license requirements where they apply.
- Deliverables include configuration records and test results so your team can rebuild or audit the setup later.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- A retainer can cover connector health checks, version upgrades and re-testing when either platform changes its data model.
- Ask any quote to separate one-time build work from recurring retainer scope, so you can see what repeats each year.
