ThreatConnect vs OpenCTI

The main change for analysts is that OpenCTI treats relationships as the primary view of intelligence. Data is structured on the STIX 2 standard, so indicators, threat actors, campaigns, malware and MITRE ATT&CK techniques are stored as linked objects rather than as rows in a list of indicators. The web application and the GraphQL API both expose those links, which means an analyst can start from a campaign and walk outward to its infrastructure and techniques, or start from an indicator and see which actors and reports reference it. ThreatConnect organizes much of its work around indicators, groups and associations, so teams moving across should expect to re-learn how they pivot through an investigation. This model pays off when the team does real relationship analysis and shares intelligence in STIX. If your analysts build attribution hypotheses, track how actors reuse infrastructure over time, or exchange structured objects with partners, the graph reduces manual correlation. The cost is learning time. Analysts used to tag-and-list workflows will need to understand STIX object types, relationship types and how observables and indicators differ before the graph becomes useful. Plan a short pilot with a few analysts on real investigations, and measure whether pivots get faster or whether people keep exporting to spreadsheets.

Confirm two points before you commit. First, playbook-style automation in OpenCTI is covered by features listed in the OpenCTI Enterprise Edition documentation, including playbooks, so check the OpenCTI Enterprise Edition documentation against the automations your ThreatConnect playbooks actually run today. Second, if your enrichment, ticketing or blocking steps go beyond what those features cover, budget for a separate automation tool and confirm its integration path with your SIEM and SOAR. Ask your implementation partner to map each existing playbook to either an OpenCTI feature, a connector or an external tool before anyone decides the graph model is the right fit.

OpenCTI uses date-based version numbers, in the form x.YYMMDD.z for regular releases and x.YYMMDD.z-lts.n for LTS releases, where the date marks the release or LTS branching date. Non-LTS releases ship when ready, anywhere from daily to weekly, so a team that tracks only the latest tag will be upgrading often. LTS releases arrive every six months and each is supported for one year, which gives a six-month overlap between consecutive LTS versions. That overlap is the window you should plan around: it is the time to test the next LTS line in staging before the current one leaves support. Before planning any upgrade, confirm the current release line on the OpenCTI releases page, since the LTS hotfix numbering moves quickly.

The operating model depends on which line you run. A non-LTS deployment needs a regular upgrade routine, a staging instance that mirrors your connectors and Elasticsearch or OpenSearch mappings, and someone who reads release notes for breaking changes to connectors you depend on. An LTS release needs a specific LTS license key and is distributed as container images. After a one-month stabilization period it receives only critical bug and security fixes, so new features and most improvements will not reach you on that line. Ask your Filigran contact, in writing, how the LTS key is issued, renewed and tied to your deployment, and whether it is covered under the OpenCTI Enterprise Edition License or a separate agreement. Those answers determine whether the key is a recurring cost in your model.

The effort of tracking this is recurring and easy to underestimate. Someone must watch the release feed, schedule a staging upgrade inside each overlap window, retest connectors, and confirm that the Python workers and RabbitMQ consumers still match the platform version. Ask any implementation partner to price this as a named recurring activity, separate from the initial build, and to state whether upgrades are included in a support retainer or billed per release. Also decide who approves moving production from a non-LTS line to an LTS line, because that choice changes your upgrade cadence, your key obligations and your exposure to fixes.

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 public statements establish the ownership change and the new product positioning. They do not state how the ThreatConnect product line, its three deployment models (public cloud, dedicated cloud and on premises), its v3 API, its playbooks or its contract terms will change after the transaction. If you run ThreatConnect today, treat the roadmap, hosting options, support model and pricing as open questions until the vendor answers them in writing. Dataminr's announcement is the natural starting point for reading the vendor's own product material, but it should not be read as a commitment on any of these points. Before a renewal or a new commitment, ask the vendor for written answers to a short list of questions. Ask whether the on premises and dedicated cloud deployments will continue to be offered, and for how long, and whether a self-hosted install will receive the same major versions as the cloud offering. Ask who will support your environment after the transaction closes, which support tiers and response commitments apply, and whether the contract will be assigned to Dataminr or stay with the current entity. Ask whether the TAXII 2.1 server and the v3 API will keep their current behavior, and whether any change to data export or API rate limits is planned. Ask about pricing changes at renewal and whether bundles that combine ThreatConnect with other Dataminr products will be offered. For the OpenCTI comparison, the deal matters mainly as a risk to plan around, not as a reason to choose one platform. If your playbooks, owners and tags are tied to ThreatConnect features, document them now so that a migration plan can be built regardless of what the vendor decides. OpenCTI is licensed under Apache License 2.0 for its Community Edition and under a separate Enterprise Edition License for paid features, and it is designed and developed by Filigran, so its governance does not depend on the ThreatConnect ownership change. Note the terms of your current agreement, such as notice periods and data return obligations, and get the export path confirmed before you sign anything new.