Which fits your indicator and sharing workflow: ThreatConnect or MISP?
The core choice is this: MISP fits community sharing and self-managed infrastructure, while ThreatConnect fits teams that want built-in playbooks and case management from a vendor. Most readers arrive here because of a renewal, a roadmap question after the Dataminr acquisition of ThreatConnect, or a requirement to control where indicators are stored and shared. Start by checking four drivers: the sharing model, your automation needs, your in-house operating capacity, and your hosting constraints. These drivers usually matter more than feature counts.
On sharing, ask whether your value comes from exchanging indicators with trusted communities. MISP supports distribution levels and sharing groups down to individual attributes, along with automatic synchronization between instances, so confirm which partners you need to sync with and whether they run MISP or can accept STIX or TAXII 2.1 feeds. On automation, list every playbook you run today and classify each as enrichment, notification, blocking or case routing. MISP covers correlation, exports such as Suricata, Snort and Zeek rules, and a REST API with PyMISP, but workflow orchestration usually needs a separate tool. Confirm that tool's role before you commit.
On capacity and hosting, be honest about who will patch and upgrade the platform. MISP 2.5 is the recommended line for new deployments, and the project's download page lists an installer for Ubuntu 24.04 along with Docker, RPM, Ansible and Puppet options. Ask your team who owns those upgrades, backups and access reviews, and whether your data residency rules allow a self-managed system. If the answer is no, or if no one has time to run it, ThreatConnect's vendor-run deployment options may suit you better. Get a written scope and quote before you decide.
Which option fits which scenario
This table maps common ThreatConnect and MISP decisions to the platform that fits better, with the reason. Read the middle column first, then the reason. Where the answer depends on in-house skills or on terms only the vendor can confirm, the cell says so.
| Scenario | Better fit | Reason |
|---|---|---|
| Sharing indicators with peer organizations | MISP | Distribution levels, sharing groups and sync between instances cover trusted communities directly. Confirm what your peers run before you commit. |
| Built-in SOAR-style playbooks | ThreatConnect | Playbooks are part of the ThreatConnect product. MISP's documented features center on sharing and correlation, so plan a separate automation tool or confirm MISP modules for your workflow. |
| Taxonomies, galaxies and correlation | MISP | Shareable taxonomies, MISP galaxies and a correlation engine with fuzzy hashes and CIDR overlaps are core MISP features. |
| Data residency on your own servers | MISP, or ThreatConnect on premises | MISP is self-hosted by design. ThreatConnect lists an on-premises option, so confirm its availability, version and license terms for your environment. |
| Small team with no platform engineers | Depends on in-house skills | MISP has an Ubuntu 24.04 installer and Docker images, but upgrades, backups and sync still need a named owner. Vendor-hosted ThreatConnect moves much of that work to the vendor. |
| Vendor-managed support and response terms | ThreatConnect | Vendor support comes with the subscription. MISP support runs through project channels, so confirm response expectations or add a paid retainer with an implementation partner. |
| Exchange over TAXII 2.1 | Depends on the deployment | MISP exports STIX 1 and 2 and offers a REST API, but TAXII 2.1 server support must be confirmed for your version. Test the feed with your consumers before cutover. |
| Roadmap after the Dataminr deal | MISP | MISP's license cannot be changed by a single entity because contributor copyright is interlocked. ThreatConnect's direction under Dataminr is still settling, so ask for commitments in writing. |
Where your intelligence data lives under each model
In the public cloud model, ThreatConnect runs on infrastructure the vendor operates and that serves many customers. Your indicators, groups and cases sit in the vendor's environment, so the first questions are which cloud provider and regions host your tenant, who at the vendor can reach that data, and how that access is logged.
- Data location: Confirm the hosting provider, the regions for the primary tenant and whether backups stay in the same geography.
- Operator: ThreatConnect staff run the platform, including patching and upgrades, so your team does not manage the underlying servers.
- Identity: Ask which single sign-on protocols the tenant supports and whether user provisioning and removal can be automated.
- Sharing scope: Anything you publish to a community leaves your control boundary, so review owner and sharing settings before you join.
- Assurance evidence: Request the vendor's independent assurance reports, the systems they cover and whether your region is in scope.
Before loading regulated or customer-linked data, check the data processing terms and the subprocessor list.
Dedicated cloud keeps a single-tenant instance for one customer, with the vendor or a cloud partner operating it on infrastructure set aside for that customer. The data is isolated from other tenants, but the operating model is still a managed service, so your contract determines who controls keys, regions, maintenance windows and access.
- Isolation: Ask whether compute, storage and database resources are dedicated to your instance and whether any shared control plane touches your data.
- Key management: Find out who holds encryption keys, whether you can supply or rotate them, and how key access is logged.
- Region selection: Confirm the region is fixed in the order form and that moving the instance later is a contracted change.
- Maintenance control: Ask how upgrade windows are scheduled and whether you can request a change freeze during an audit or incident.
- Support access: Establish when vendor engineers can open your instance, how that access is approved and whether it is recorded for your review.
Write these answers into the order form or data processing addendum, because verbal assurances are hard to evidence later.
With on-premises ThreatConnect, the platform runs in your data center or your cloud account, and your team operates it. The data stays on hardware and networks you control, which makes network segmentation, backup design and log retention your responsibilities from the first day.
- Data location: Data stays in the facilities and accounts you name, so document the storage locations, replicas and backup targets.
- Operations: Your platform team owns installation, patching, database maintenance, certificates and capacity planning.
- Network path: Decide whether the instance can reach external feeds and sharing partners, and restrict outbound traffic to the endpoints you approve.
- Disconnected operation: Ask the vendor to confirm which features work in an air-gapped or restricted network and how updates are delivered.
- Licensing and support: Confirm that the license covers the deployment type and the number of environments, such as test and disaster recovery.
Keep an access log and a change record for every administrative action, since those records are the evidence an assessor will ask for.
MISP runs wherever you install it: on your own servers, in your cloud account, or in containers. Because you deploy and operate it, the data location, the database and the backups are fixed by your design. MISP 2.5 is the recommended version for new deployments, and the project's download page lists an installer for Ubuntu 24.04, Docker images, RPM packages, an Ansible role and a Puppet module.
- Installation path: Use the provided installer for Ubuntu 24.04, or pick Docker, RPM, Ansible or Puppet if your configuration management standard requires them.
- Database: MISP runs on MySQL or MariaDB with Redis. The MISP 2.5.47 release, dated September 17, 2026, introduced PostgreSQL support through a new migration system, so confirm the database choice before you build.
- Operator: Your team owns the operating system, the MISP application, TLS, backups and any sync peers you configure.
- Version currency: MISP 2.4 is end of life with security fixes only, so do not start new instances on it.
- Sync boundaries: Only the instances you connect to receive your events, so keep the peer list under change control.
Document where each database, attachment store and backup copy sits, and confirm the list with your data protection team.
Where indicators are stored matters less than who can read them and where they are forwarded. Identity decides who can log in, and sharing agreements decide which organizations receive a copy. Both apply under every model, and they differ in how much you configure yourself.
- MISP identity: The MISP 2.5 branch includes an OidcAuth plugin, described in its README, for OpenID Connect sign-in, so confirm the identity provider, claim mapping and fallback accounts before go-live.
- MISP sharing: Distribution levels and sharing groups control visibility down to individual attributes, and community governance agreements should name who may receive what.
- ThreatConnect sharing: Confirm how owners, communities and sources are defined in your tenant and who can change them.
- Ownership changes: Dataminr announced on October 21, 2025 a definitive agreement to acquire ThreatConnect, and ThreatConnect is now presented as part of Dataminr for Cyber Defense. Ask how any change of control affects your contract, data processing terms and hosting commitments.
- Compliance evidence: DeployOpen can prepare configurations, access records and control evidence for an assessment, but independent auditors and certification bodies issue the reports and certifications.
Map each sharing agreement to the storage location and the identity controls before you move any production indicators.
How MISP licensing affects your deployment decisions
MISP is free to run, but its licenses differ by component, and its governance shapes how the project can change over time. The cards below cover the software license, the data licenses, the project's governance and funding, the version you should deploy, and the obligations that follow if you modify and host it. Confirm each point with your legal counsel before you commit.
AGPL-3.0 covers the software
MISP itself is licensed under the GNU Affero General Public License version 3. Using it internally, without changes, creates few obligations beyond keeping notices intact. Compared with ThreatConnect, where you accept a vendor subscription and its terms, the MISP license governs what you can copy, modify and redistribute. Ask counsel whether your use of MISP as a shared service for partners changes your position.
Taxonomies and galaxies carry separate licenses
MISP taxonomies and galaxy data are not under the AGPL. They are licensed under CC0 1.0 Universal or the 2-clause BSD license, so you can reuse and redistribute them under different terms from the software. When you migrate ThreatConnect tags and threat actor mappings into MISP, record which license applies to each imported taxonomy or galaxy so your sharing agreements stay accurate.
Interlocked copyright limits license changes
The MISP repository states that interlocked copyright among contributors prevents any single entity from changing the license model. CIRCL, the Computer Incident Response Center Luxembourg, is associated with the project. For a team choosing between a vendor product and MISP, this means the license is not controlled by one company that could change it unilaterally. Still, review the contributor and governance details yourself before you rely on them.
Public funding supports the project
The MISP project is co-funded by the European Union. Public co-funding does not change the license terms you receive, but it is relevant when procurement or risk teams ask about project continuity. Ask your team to document the funding context alongside the license review, and confirm how the project's support model fits your own support requirements.
Deploy MISP 2.5 for new instances
MISP 2.5 is the recommended version for new deployments, while MISP 2.4 is end of life with security fixes only. The project advises against installing new 2.4 instances. If you are moving from ThreatConnect, plan your build on the 2.5 line from day one so you do not inherit an unsupported version, and check the release notes for the current 2.5 point release before you install.
AGPL duties for modified hosted instances
The AGPL requires that users interacting with a modified version over a network can receive its source code. If you change MISP, such as adding custom ThreatConnect-style playbooks or connectors, and offer that instance to partners or ISAC members, the obligation to publish those changes may apply. Keep a record of every patch and connector, and have counsel confirm how the obligation applies to your sharing model.
What a move from ThreatConnect to MISP involves
The sequence moves indicators, groups and sharing relationships out of ThreatConnect and into a MISP 2.5 instance you run, with each step ending in a check that the data and integrations behave as before. Detailed export and rebuild work sits in the sibling migration pages linked from this page.
Inventory owners, groups, feeds and integrations
Your team lists every ThreatConnect owner (organization, communities and sources), the groups and cases that matter, the feeds and sharing relationships you depend on, and every system that consumes or sends indicators, such as SIEM, EDR, firewalls, proxies and DNS blocking. Owners who are not yours to export need a decision from the community or source. The output is a single register that maps each item to a MISP destination or to a retire decision, and you know it is done when every consumer has an owner who has signed off on it.
Decide sharing groups and distribution levels
Before any data moves, the sharing model is set. Your team maps ThreatConnect owners and communities to MISP organizations, sharing groups and distribution levels, because MISP applies these down to individual attributes and controls what syncs to each partner. Legal, the information sharing lead and the community administrators should agree the rules in writing. The check is a one-page sharing matrix that names, for each data set, who may see it, who may re-share it and what leaves the organization.
Stand up MISP 2.5 on a supported platform
Platform engineering deploys MISP 2.5, the version the project recommends for new deployments. The project recommends Ubuntu 24.04 with its provided installer, and also lists Docker images, RPM packages, an Ansible role and a Puppet module, so choose the method your team can patch and back up. Do not install MISP 2.4, which is end of life with security fixes only. Confirm the current release notes and the database choice (MySQL or MariaDB, or PostgreSQL, which the 2.5 line supports through its new migration system) before building. The check is a reachable instance with TLS, authentication connected to your identity provider, and a tested backup and restore.
Export data from ThreatConnect
The threat intelligence team pulls indicators, groups and related context out of ThreatConnect through its APIs or, where it fits, over TAXII. Exports must respect the owner rules from the first step, and the export pages linked from this page describe pagination, filters, associations and tags in detail. Keep the raw exports in a restricted store with their original owner tags intact so you can re-run the import. The check is a row count and hash for each export, reconciled against ThreatConnect counts for the same filters.
Import and validate in MISP
Engineers import the exports into MISP events and attributes, mapping ThreatConnect owners to MISP organizations and tags to taxonomies or galaxies where a match exists. Imported data should get the distribution levels and sharing groups from the matrix, not MISP defaults. The threat intelligence team samples events against the source records and checks for mis-typed attributes, lost timestamps and duplicated events. The check is a signed-off validation log showing counts, sampled matches and the fixes applied.
Rebuild sync, feeds and sharing relationships
The community administrators configure MISP synchronization with trusted partners and any feeds you need, and confirm that each partner accepts the sharing rules. Partners need their own MISP instances or agreed exchange paths, and each relationship must be tested with a small test event before live traffic. Confirm the status of each sync and the content it delivers. The check is a sync status report showing every partner receiving only the events the matrix allows.
Reconnect SIEM and blocking integrations
Security engineering points SIEM, EDR, firewall, proxy and DNS consumers at MISP outputs such as the exports, restSearch via the API, PyMISP-driven scripts, or the Suricata, Snort, Zeek and RPZ formats where those fit your controls. Each consumer is changed in a test environment first, and rules that block on indicators are checked for false positives before production. Confirm the expected format for each consumer with its vendor. The check is a test log showing each integration receiving the expected indicators and each blocking action firing once on a test indicator.
Run in parallel, then retire the old workflow
ThreatConnect and MISP run side by side for a period your governance group sets, with analysts checking that new indicators appear in both and that consumers see the same results. Once the reconciliation shows no gaps and the consumers have been verified, the old feeds, playbooks and sharing links are switched off in a controlled change. Retain the exports, validation logs and sharing matrix as records of the move. The check is a signed-off cutover record and an archived copy of the final ThreatConnect export.
Questions buyers ask before choosing MISP over ThreatConnect
What drives the cost of running MISP compared with a ThreatConnect subscription?
MISP's software license is AGPL-3.0, so the recurring cost is the infrastructure and people that run it, not a per-seat fee for the platform itself. The main components are servers and storage in your environment, the MySQL or MariaDB database and Redis, backups, monitoring, staff time for upgrades and feed management, and any paid support you choose to buy. Costs rise with the number of attributes, sharing communities, feeds and synchronized instances. Ask any ThreatConnect quote to split subscription, dedicated or on-premises hosting, and add-on modules, so you can compare by component. Taxonomies and galaxies are licensed separately under CC0 1.0 or BSD-2-Clause, and the MISP download page covers the install options you can choose from.
How long does a migration from ThreatConnect to MISP take?
The timeline depends on data volume, the number of owners and sharing groups to recreate, how many SIEM, firewall and blocking integrations must be reconnected, and how much history you need to keep. Teams that only share indicators with communities usually have a smaller job than teams that also run playbooks and case management in ThreatConnect. Ask for a written scope that lists each data type, each integration and the acceptance tests for each one, and treat any duration without that breakdown as an estimate to challenge. Parallel running for a defined period is a common way to verify that feeds and exports match before you cut over.
Can an in-house team run MISP without outside help?
Yes, many teams do, provided they have Linux administration, database and web application skills, and someone who owns the sharing policy. The project recommends Ubuntu 24.04 with the provided installer for MISP 2.5, and it also supports Docker, Ansible, Puppet and RPM installs, so the operating model can be standardized. The harder part is ongoing work: applying MISP 2.5 releases, planning upgrades off 2.4 (which is end of life with security fixes only), managing feed quality, and maintaining synchronization with partner communities. Decide early whether those tasks sit with your own staff, a managed contract or a retainer.
What does DeployOpen need from our team to implement MISP?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. Engagements are usually fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. In practice we will need access to the target cloud account, data center or air-gapped network, a named owner for sharing policy and organizations, a list of current feeds and partner communities, the ThreatConnect data and integrations to be reconnected, and a test window for SIEM and blocking changes. Ongoing support, upgrades and continuous testing are available as retainers, and quotes follow from the written scope.
Does MISP have an equivalent to ThreatConnect playbooks?
MISP does not provide a built-in playbook engine equivalent to ThreatConnect playbooks, so you should plan for automation outside the platform. MISP covers correlation through exact matches and advanced patterns such as fuzzy hashes and CIDR overlaps, plus sync, sharing controls and a REST API with PyMISP for scripting. Enrichment, notification and blocking steps can be built with those tools or with a separate automation product. Confirm the exact workflow you run today in ThreatConnect, because some steps may be replaceable with MISP scripts and others may need a SOAR tool or a workflow engine.
How does TAXII 2.1 export work when moving away from ThreatConnect?
TAXII is a transport protocol, and STIX is the content format it carries. MISP exports STIX 1 and 2 and provides its own JSON, OpenIOC, CSV, text, Suricata, Snort, Zeek and RPZ outputs, plus an API described in OpenAPI through restSearch. Your MISP deployment will need a TAXII-capable path for partners or consumers that expect TAXII 2.1 collections. Confirm whether that is a MISP feature in your chosen version or a separate server component, and test it against each consumer. Check that object relationships, markings and sharing groups survive the export, because those are the fields most often lost in translation.
What changes for ThreatConnect customers after the Dataminr deal?
Dataminr announced on October 21, 2025 that it had signed a definitive agreement to acquire ThreatConnect, and ThreatConnect is now presented as part of Dataminr for Cyber Defense. The announcement describes the combined direction, but it does not give your contract terms, hosting options or product roadmap. Ask your account team in writing whether your subscription, hosting model, data residency commitments, API access and integrations will change, and when. Use that answer to set your renewal date and migration plan, since it may decide whether you move now or after the next renewal.
How DeployOpen helps you evaluate, implement and migrate
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your own infrastructure. For a ThreatConnect to MISP evaluation, that means the work happens in your cloud accounts, data center or air-gapped network, so indicators, sharing groups and sync peers never leave your control. Typical early work includes testing the MISP 2.5 installation path on your chosen operating system, deciding between the installer, Docker images or configuration management, checking how sync partners and sharing groups map to your current ThreatConnect communities, and confirming which MISP features your SIEM and blocking tools need. Ask DeployOpen to document each of these decisions in writing so your security and compliance teams can review them.
DeployOpen works on fixed-scope engagements. Scope, deliverables, timelines and responsibilities are agreed in writing before work starts, and a quote follows from that written scope. DeployOpen does not publish a price list, so the cost of an evaluation or migration depends on the systems, feeds, integrations and data volumes you define. Ongoing upgrades, backups, monitoring and support after go-live can be covered by a retainer, which is useful because MISP releases move quickly and the upgrade path from MISP 2.4, which is end of life with security fixes only, should be planned rather than rushed. DeployOpen also runs security testing of applications, APIs and infrastructure, so the MISP instance, its API keys and its sync endpoints can be tested before they carry production intelligence.
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and it is not a vendor partner or certified provider for MISP, ThreatConnect or any standards body. Independent auditors and certification bodies make those determinations. When you request a quote, ask for the scope to name the MISP version, the data sources and sharing communities in scope, the TAXII 2.1 or export paths you need, the Dataminr-related contract milestones that affect your ThreatConnect exit date, and the evidence your assessors will expect. Those written details are what make the scope, and therefore the quote, comparable across vendors.
