ThreatQ vs OpenCTI: which to choose

Which threat intelligence platform fits your team: ThreatQ or self-hosted OpenCTI

The choice between ThreatQ and self-hosted OpenCTI turns on who will run the platform, which feeds and tools you must connect on day one, and whether your analysts need to model intelligence as a graph. Most teams arrive here because of a renewal, a licensing change, a data residency rule or a wish to reduce lock-in. None of those reasons settles the question alone. OpenCTI fits teams that want their intelligence modeled on the STIX 2 standard, with relationships between adversaries, campaigns, malware and indicators stored as a knowledge graph, and that have engineers comfortable operating Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage. ThreatQ fits teams that want its Threat Library, dynamic scoring and vendor-supported integrations running with less internal platform work, and that can accept the commercial terms that come with them.

The first thing to confirm is connector coverage. List every feed, sandbox, SIEM and EDR integration you use today, then check which of them exist as OpenCTI connectors and which you would need to build or maintain. OpenCTI ships connectors for MISP, TheHive and MITRE ATT&CK, and the GitHub repository describes the connector model in more detail (OpenCTI on GitHub). Second, decide where the data may live. If a residency rule requires the platform inside your own cloud account, data center or air-gapped network, self-hosting OpenCTI meets that requirement directly, provided your storage and backup plan stays inside the same boundary.

Third, be honest about staffing. OpenCTI runs as several services, including the platform, Python workers and connectors, so someone must own upgrades, sizing and on-call response. Non-LTS releases ship often, while LTS releases need a license key, so your upgrade process must account for both. If you lack that capacity in-house, a fixed-scope implementation and a support retainer can cover the gap, and a written scope lets you compare that cost against ThreatQ's licensing. Run a short pilot that loads a representative feed set and one investigation workflow before you commit to either platform.

Which scenarios favor ThreatQ and which favor OpenCTI

This table matches common buyer situations to the platform that usually fits them better, with the condition that changes the answer. Read each row against your own staffing, data residency rules and sharing needs before deciding. The main takeaway is that OpenCTI rewards teams that can run a multi-service stack and model STIX 2 relationships, while ThreatQ suits teams that mainly aggregate feeds and push indicators.

Buyer scenario	Better fit	Why and conditions
Small team that mainly aggregates feeds and pushes indicators to a SIEM or EDR	ThreatQ	Feed ingestion and scoring are the core workflow. Confirm the feeds you need are supported and that your SIEM or EDR connectors exist before comparing.
Team that needs a STIX 2 knowledge graph of actors, campaigns and malware	OpenCTI	OpenCTI structures data on STIX 2 and exposes a GraphQL API. Confirm the object types and relationships you need map cleanly from your current data.
Team with strict data residency that must keep all intelligence on its own servers	OpenCTI (self-hosted)	Both can run on premises, but OpenCTI's full stack (Elasticsearch or OpenSearch, Redis, RabbitMQ, MinIO) stays in your environment. Confirm the deployment model each vendor offers for your residency rules.
Team without platform engineers to run search, queues and object storage	ThreatQ (vendor-operated option) or a managed partner	OpenCTI has several stateful dependencies that need patching and capacity planning. If no one owns them, ask ThreatQ for a SaaS or managed option, or budget for operations staff.
ISAC or community sharing need with peer exchange of indicators	MISP or OpenCTI, confirm with your community	MISP has built-in synchronization between instances with granular sharing controls. Confirm which format and platform your sharing partners already use before choosing.
Team that wants investigations, cases and playbooks tied to intelligence	OpenCTI	OpenCTI offers playbooks in its Enterprise Edition and connectors for TheHive and MISP. Confirm which features your license tier includes and whether case management meets your workflow.
Team that must avoid a new proprietary license cost for the core platform	OpenCTI Community Edition	The Community Edition is Apache 2.0 licensed, but Enterprise features such as audit logs and SSO are under a separate license. Confirm which features you need before assuming the free tier covers them.
Team that already runs ThreatQ integrations across many tools and wants no change	ThreatQ	Migration cost and retraining are real. Stay on ThreatQ until the requirements above change, and confirm how the Securonix relationship affects your roadmap.

How OpenCTI models intelligence as a STIX 2 knowledge graph

The main shift is from a store of indicators with attached context to a graph of typed objects and relationships. In ThreatQ, teams usually think in indicators, adversaries, events and attributes, with scores and tags sitting on each record. OpenCTI structures data on the STIX 2 standard instead, so an indicator, a malware family, an intrusion set, a campaign, a vulnerability and an observable are separate objects, and the links between them (for example, indicates, uses, targets or attributed-to) are first-class records that can be queried and displayed. Before migration, the team should map each ThreatQ indicator type and adversary relationship to a STIX object type and relationship type, and list the cases where a ThreatQ attribute has no clean STIX equivalent and must be carried as a label, external reference or custom property.

The graph is what changes analyst work. An analyst can start from an observed domain, pivot to the indicator it matches, then to the intrusion set that uses it, the campaigns linked to that set, and the victims or sectors those campaigns target. Those pivots are the reason to adopt a graph model, so the reader should test them with real cases before committing. The GraphQL API gives access to these objects and relationships for integrations and custom views, and the MITRE ATT&CK connector can bring techniques into the same graph. Confirm in a proof of concept which ATT&CK objects the connector imports and how often it refreshes them in your version.

The investment sits in modeling conventions. A graph is only as useful as its consistency: teams must agree how to name intrusion sets, when to create an indicator versus an observable, how confidence and labels are applied, and who may create relationships. Without these rules, duplicate objects and conflicting links accumulate quickly. Assign an owner for the data model, write the conventions down before importing history, and review a sample of imported records against the source feeds. Plan this work as a one-time design effort plus ongoing curation, since STIX conventions and the connector set both evolve across OpenCTI releases.

Where connectors and case management need the closest check

ThreatQ and OpenCTI both collect, enrich and share intelligence, but they reach feeds, detection tools and partners in different ways. The cards below mark the points where a move is most likely to stall, and what to verify in your own environment before committing.

Connector coverage for existing feeds

ThreatQ customers often rely on a long list of commercial and open feeds, each with its own parser and schedule. OpenCTI ships connectors for MISP, TheHive and MITRE ATT&CK, and its connector catalog is what decides whether each of your feeds has a ready path. The gap matters most when a feed is only available as a ThreatQ integration. Before deciding, list every active feed, confirm whether an OpenCTI connector exists for it, and budget for writing and testing a custom connector for any that do not.

Enrichment and export connectors

Enrichment connectors add context to indicators, while export connectors push STIX data to other tools. Confirm that every enrichment lookup your analysts use today has an OpenCTI equivalent, and that the lookup keys, rate limits and licensing of each external service still work under your own infrastructure. The gap is widest for enrichment sources that ThreatQ reaches through its own adapters.

Detection tool pushes to SIEM and EDR

Many ThreatQ deployments exist mainly to push indicators into SIEM and EDR tools. OpenCTI exposes its data through its GraphQL API and stream connectors, so each push must be rebuilt as a connector, script or export that your detection platform accepts. The gap matters when detection rules depend on score thresholds. Confirm which fields, scores and expiry rules each downstream tool expects before cutover.

Investigations and case management

ThreatQ investigations gather indicators, adversaries and notes into a working record. OpenCTI models investigations and cases on the STIX 2 knowledge graph, which suits relationship-driven analysis but changes how analysts group and close work. Ask your analysts to walk through three recent investigations in OpenCTI, and check whether case ownership, task tracking and evidence attachments meet your team's workflow.

Playbooks in Enterprise Edition

Automated enrichment and dissemination in OpenCTI playbooks are part of the Enterprise Edition, which is licensed under a proprietary license rather than Apache 2.0. If your ThreatQ automation depends on triggered workflows, confirm which playbook features you need, whether they are in the Community Edition, and what the Enterprise license costs and covers. Community alternatives such as Shuffle may need to fill the gap.

Sharing with partners

ThreatQ sharing depends on how your partners connect to it. OpenCTI shares through its platform, connectors and STIX data, while MISP offers granular synchronization between instances and a long-established community sharing model. Confirm which partners need to receive data, in what format and with what handling restrictions, and test that each partner can ingest the output before you retire the existing channel.

Who operates each platform and what the deployment needs

In a SaaS deployment, the vendor or its hosting partner runs the ThreatQ platform, including infrastructure, most availability work and platform upgrades. Your team still administers the content that makes the platform useful: feed subscriptions, user access, scoring choices and the integrations that push data to detection tools. Data location and processing terms sit in the contract and its data processing documents, so review them closely if residency is part of your reason for looking at alternatives.

Upgrades: the vendor schedules platform releases, so your team has less control over timing.
Hosting: infrastructure, backups and capacity are contracted services rather than systems your staff operate.
Feeds and content: analysts still curate sources, scoring rules and workflows.
Integrations: connectors to SIEM and EDR tools run on your side and need their own credentials and maintenance.
Data residency: confirm in writing where indicators, cases and attachments are stored and processed.

Ask the vendor which duties are theirs, which are yours, and what the contract says about data export at exit.

What drives the cost of ThreatQ and self-hosted OpenCTI

Cost of ownership splits into what you license, what you run, and what people do over time. ThreatQ and self-hosted OpenCTI place these costs in different places, so the same work can land on a vendor invoice in one case and on your own staff in the other. Use the cards to build a quote request that compares like with like.

Platform licensing

ThreatQ is a commercial subscription, and the terms, bundling and any Securonix arrangement should be confirmed in writing with the vendor. OpenCTI Community Edition is licensed under Apache 2.0, so the software itself carries no license fee. If you need Enterprise Edition features such as audit logs, playbooks, organization-based segregation or SSO options beyond the community build, that is a separate license from Filigran under the OpenCTI Enterprise Edition License. Ask whether Enterprise features are in scope before comparing totals.

Servers and search cluster

OpenCTI's documented sizing starts with the platform at 2 cores and at least 8 GB RAM, and Elasticsearch or OpenSearch at 2 cores, 8 GB RAM and 16 GB SSD. The platform also recommends at least one platform node for every 3 workers. Costs rise with feed volume, retention and worker count, and they recur as hardware or cloud instances. Confirm whether ThreatQ's on-premises or SaaS pricing includes hosting, and size your OpenCTI estimate from your own indicator volume.

Supporting services and storage

A self-hosted OpenCTI deployment also needs Redis 7.1 or later, RabbitMQ 3.11 or later, and S3-compatible storage such as MinIO. Each adds an instance to patch, back up and monitor, and the storage line grows with uploaded files and exported data. Ask your team which of these you already run, because a shared Redis or object store can remove a recurring cost that a standalone deployment would carry.

Staff to operate the platform

This is usually the largest recurring cost in self-hosting, and it is the one ThreatQ's subscription largely absorbs. Plan for people who run the platform, manage the search cluster, rotate credentials, handle upgrades and respond to incidents on the threat intelligence stack. Estimate the share of time from your own staffing model. Ask any implementation partner to state in the written scope which operating tasks they take on and which stay with your team.

Connector development and maintenance

ThreatQ connects feeds and integrations through its own catalog, while OpenCTI relies on connectors for MISP, TheHive, MITRE ATT&CK and other sources, plus import, enrichment, export and stream connectors. Where a ThreatQ feed or SIEM push has no ready connector, someone must build and maintain it. This cost is one-time for the first build and recurring as upstream APIs and data formats change. Inventory every ThreatQ feed and integration before estimating it.

Upgrades and LTS licensing

OpenCTI uses date-based versions and offers regular releases from daily to weekly, plus LTS releases every 6 months, each supported for 1 year. LTS releases are distributed as container images but require a specific LTS license key to use, and after a one-month stabilization receive only critical bug and security fixes. Plan upgrade windows and test time as a recurring cost, and confirm with Filigran which license applies to your chosen release line. For ThreatQ, ask how version upgrades and support tiers are priced.

Support and quote requirements

Commercial support is part of ThreatQ's subscription, while for OpenCTI you pay for support separately, whether to Filigran, a managed provider or a retainer. Ask each vendor for a written quote covering licensing term, support level, upgrades and any bundling with other Securonix products. For self-hosting, request a scope that lists hosting, backups, upgrades, connector work and feed curation so the two totals can be compared line by line.

How a move from ThreatQ to OpenCTI runs at a high level

The sequence moves ThreatQ's feeds, indicators, adversaries and integrations into OpenCTI in a controlled order, so each stage can be checked before the next starts. The end state is OpenCTI as the system of record, with detection tools fed from it and ThreatQ retired on evidence rather than on schedule.

Inventory feeds, indicators, adversaries and integrations
Start by listing every ThreatQ feed, data source, indicator type, adversary and object relationship that analysts rely on, along with each outbound push to SIEM, EDR, ticketing or sharing tools. Record who owns each item, how often it updates and which downstream system consumes it. The output is a signed-off inventory that the platform team and the SOC both agree is complete. Confirm exact export options and object types with ThreatQuotient or your ThreatQ administrator, since the inventory depends on what your instance actually holds.
Map ThreatQ objects and scores to STIX 2
Map each ThreatQ object type and score to its STIX 2 equivalent and to the OpenCTI fields that carry scoring, labels and confidence. Decide where ThreatQ's dynamic scoring logic becomes an OpenCTI scoring rule or an analyst convention, and document what cannot be carried over one to one. Review the mapping with threat intelligence analysts using a sample of real records. The output is a written mapping specification with worked examples and a list of open decisions.
Build or configure connectors for each feed
For each feed in the inventory, decide whether an existing OpenCTI connector covers it, a community or custom connector is needed, or the data is loaded by a one-time import. Build and test connectors in a non-production OpenCTI instance, checking that indicators, relationships and sources arrive as the mapping specifies. The output is a tested connector register showing owner, source, schedule and last successful run for each feed.
Load historical data and run both platforms in parallel
Import the historical ThreatQ data that the mapping says must move, then run ThreatQ and OpenCTI side by side on the same feeds. Compare object counts, relationship integrity, scores and alert volumes for an agreed period, and log each discrepancy with its cause. The output is a parallel-run report that analysts and detection engineers have reviewed and accepted, with every open discrepancy either fixed or documented as accepted.
Repoint SIEM and EDR integrations to OpenCTI
Move each detection integration from ThreatQ pushes to OpenCTI outputs, such as stream consumers, exports or connectors that write to the SIEM or EDR platform. Test each integration in a staging copy of the detection tool, confirming that indicator types, expiry and tagging behave as the detection rules expect. The output is a signed-off integration list where every consumer shows a working source in OpenCTI and a named owner.
Cut over and decommission ThreatQ
Switch analyst workflows and feed ownership to OpenCTI on an agreed date, keeping ThreatQ read-only for a defined retention period. Retain an export of ThreatQ data under your records policy before any licence or infrastructure is ended. Confirm the retention period, the export format and the licence end date with ThreatQuotient or Securonix in writing before cutover. The output is a decommissioning record showing that all feeds and integrations run from OpenCTI, the archive exists and access to ThreatQ has been removed.
Operate and review the new platform
After cutover, assign people to maintain connectors, monitor feed health and review scoring against analyst outcomes. Keep OpenCTI on a supported release line, planning upgrades using the product life cycle documentation. The output is a documented operating model with named owners for connectors, upgrades and backups, so the platform stays current after the migration team leaves.

Questions buyers ask before choosing OpenCTI over ThreatQ

How much staffing does it take to self-host OpenCTI?

Plan for a small platform team that owns the stack, with the effort driven by how many components you run and how much you customize. A self-hosted deployment needs the platform (UI and GraphQL API), Python workers, connectors, and these dependencies: Elasticsearch 8.0 or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later, and S3-compatible storage such as MinIO. The documented sizing starts at 2 cores and 8 GB RAM for the platform, 2 cores, 8 GB RAM and 16 GB SSD for the search service, and at least one platform node for every 3 workers. Ask who will patch each dependency, monitor queues, back up search indexes, and maintain each connector, because those tasks recur after go-live. The OpenCTI deployment overview lists the components in detail.

How long does a ThreatQ to OpenCTI migration take?

The length depends on what you move and how much you remap, so confirm the timeline against a written scope rather than a generic estimate. The main drivers are the volume of indicators and related objects to export, how much of ThreatQ's scoring and data model must be mapped to STIX 2 objects and OpenCTI scoring, and how many feeds must be recreated as connectors. The number of SIEM and EDR integrations that need repointing also matters, as does how long you run both platforms in parallel to validate detections. Teams with clean, well-documented feeds and a small set of consumers typically move faster than teams with many custom enrichments. Ask any provider to break the timeline into data export, mapping, connector build, integration cutover and validation.

Can our own team run the OpenCTI migration without a partner?

Yes, if your team already runs Linux services, search clusters, message queues and identity integration, and has someone who can write and maintain connectors against the GraphQL API. The skills gap is usually in connector development, data mapping and upgrade discipline, not in installation. If those skills are thin, you can split the work: your team keeps ownership of daily operations while an outside party handles scoped pieces such as the deployment, connector builds or hardening. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure. Most engagements are fixed-scope with agreed deliverables and timelines, and ongoing support is available as a retainer.

What does an OpenCTI implementation need from our side?

The implementation needs access, decisions and data from your organization before any build starts. Expect to provide the ThreatQ export or access to it, an inventory of feeds, enrichments and downstream pushes to SIEM and EDR tools, and the infrastructure where OpenCTI will run, whether that is your cloud account, data center or air-gapped network. You will also need an identity directory for single sign-on, decisions on organization-based segregation and sharing rules, and named owners who can approve data mapping and cutover. Written scope, deliverables and timelines are agreed before work starts, so the more complete this inventory is at that point, the more accurate the quote will be. Ask for a written list of assumptions with any quote.

How do OpenCTI LTS licensing and release cycles affect upgrades?

LTS releases shape your upgrade plan, because they require a specific LTS license key and receive only critical bug and security fixes after stabilization. OpenCTI publishes non-LTS releases from daily to weekly, and LTS releases every 6 months, each supported for 1 year, which gives a 6-month overlap between consecutive LTS versions. LTS builds ship as container images, and after a one-month stabilization period only critical bug and security fixes follow. The version pattern is x.YYMMDD.z for regular releases and x.YYMMDD.z-lts.n for LTS. Choose between tracking regular releases and staying on an LTS line based on how much change your team can absorb, and confirm the license terms for your key with Filigran before you commit. The product life cycle documentation sets out the schedule.

Does OpenCTI cover every ThreatQ integration we use today?

Do not assume full coverage: check each feed, enrichment and outbound push against the connector catalog and your own requirements. OpenCTI documents connectors for MISP, TheHive and MITRE ATT&CK, and its deployment model includes connectors for import, enrichment, file extraction, export and stream consumption. An integration with no existing connector needs a custom connector built against the API, or an export that your SIEM or EDR can ingest. Feeds that depend on proprietary ThreatQ logic will need a decision on whether to rebuild the logic or accept a different output. Build a table with one row per integration, the connector that covers it, and the owner who signs off on the result.

How do OpenCTI Community and Enterprise editions differ?

The Community Edition is licensed under Apache 2.0, while the Enterprise Edition uses the separate OpenCTI Enterprise Edition License. Enterprise adds audit logs, playbooks, organization-based segregation, full text indexing, AI insights and SSO configuration for OpenID, LDAP, SAML, certificate and header authentication. Check which of these your controls require, especially audit logging, segregation between business units or partners, and SSO with your identity provider, because those requirements decide whether the Enterprise license is needed. Confirm current feature availability and license terms in the Enterprise Edition documentation and with the vendor before you size the budget, since the license is a recurring cost to include in the comparison.

What to confirm with ThreatQuotient and in your own environment

Before comparing platforms on features, confirm the facts about your current ThreatQ deployment. Ask ThreatQuotient or your account contact for the current licensing terms, the term end date, and whether your agreement is affected by the Securonix arrangement. Get written answers on what happens to support, updates and data access if the contract ends, and on whether the export tooling you need is included. These answers set your timeline and your negotiating position, so they belong in the first week of the evaluation, not the last.

Next, inventory what ThreatQ actually does for you. List every feed, every enrichment source and every detection integration that pushes or pulls indicators, including the SIEM and EDR tools that consume them. Record which Threat Library objects, scores and adversary records your analysts use day to day, and which exist only because nobody removed them. This list tells you which OpenCTI connectors you must build or validate, and which integrations need to be repointed to the new platform's outputs. Also confirm the volume and retention of indicators you keep, including how long expired or low-scoring indicators stay searchable, because that drives storage sizing directly.

Then check your own environment. Document data residency obligations for threat data, including whether indicators derived from customer or incident data can leave a given jurisdiction or network zone. Confirm whether you need air-gapped operation or a sharing community's rules on where data is hosted. On the operations side, decide who will run OpenCTI's Elasticsearch or OpenSearch cluster, Redis, RabbitMQ, MinIO and connector workers, who is on call for queue backlogs, and who curates feeds day to day. Check that the team has the skills and hours for these tasks. Treat every item here as a check to complete with evidence, not as a conclusion already reached.

How DeployOpen helps evaluate, implement and migrate OpenCTI

DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For ThreatQ vs OpenCTI, we start with your feed inventory, sharing obligations and detection tool integrations, then build and hand over an OpenCTI deployment you operate.

How we scope

Inventory current ThreatQ feeds, indicator volumes, scoring rules and SIEM and EDR push integrations
Map which connectors, playbooks and sharing groups your OpenCTI deployment needs in writing
Agree deployment location, dependency choices and who will operate the platform before work starts
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing first

How we build

Deploy OpenCTI with its Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage dependencies
Configure connectors for feeds and MITRE ATT&CK, and test enrichment and export paths against sample data
Set up SSO and access segregation according to your identity provider and organization model
Test the platform, its API and its exposed services as part of hardening before go-live

How we hand over

Document the architecture, configuration, connector inventory, scoring decisions and runbooks
Train your analysts and platform operators on daily workflows and connector troubleshooting
Define the upgrade approach for regular and LTS releases so your team can plan maintenance
Provide backup and restore procedures and confirm them with your team before handover

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover
Retainer scope is agreed in writing, covering release upgrades, connector changes and incident support
Compliance readiness work prepares systems and evidence for your assessors, without issuing audit reports
Request a quote from your written scope, since DeployOpen does not publish a price list

ThreatQ vs OpenCTI