ThreatQ after Securonix: stay, integrate or replace

ThreatQ after the Securonix acquisition: what changes if you do not run Securonix

If you run ThreatQ without a Securonix contract, the stated plan keeps ThreatQ available as a standalone product, so any move to another platform is a choice made against your own constraints, not a deadline. Securonix acquired ThreatQuotient in June 2025 and has said ThreatQ remains available standalone while it integrates with the Securonix SIEM. The two self-hosted options are OpenCTI, which suits teams that want a STIX 2 knowledge graph with connectors and a GraphQL API, and MISP, which suits teams whose main work is aggregating feeds and sharing indicators with trusted communities. Neither is a direct substitute for ThreatQ's Threat Library and scoring, so each path changes workflows as well as data. The OpenCTI deployment overview lists the components you would need to run it.

The sources behind this section do not confirm ThreatQ's post-acquisition roadmap. They do not say how long standalone releases will be supported, whether on-premises and SaaS terms will stay the same, or whether packaging and pricing will change at renewal. Ask for these in writing before you sign: a named support end date for the version you run, the upgrade path to any release that integrates with Securonix, the licensing terms for your deployment model, and a documented export format for indicators, adversaries and relationships. Also ask whether any SIEM or EDR integration you depend on will be changed, deprecated or moved behind a Securonix license.

Use the renewal to set a decision date. If the written commitments cover the support window you need, staying is a sound option while you test the alternatives in parallel. Export a sample of indicators with their context, load it into a MISP or OpenCTI instance on infrastructure you control, and compare how your feeds, scoring and detection exports behave. List every integration that relies on a ThreatQ-specific connector, since those determine the migration effort. The migration and cost pages linked from this page cover each path in detail. If the vendor cannot answer the roadmap and pricing questions in writing, treat that gap as a risk and plan a migration window now.

What a ThreatQ owner should confirm before deciding to stay

The Securonix acquisition changes who owns the roadmap, but the supplied facts do not say how contracts, support or integrations will change for standalone customers. Each card below is a question to put to ThreatQuotient or Securonix in writing before you renew, extend or sign a migration plan.

Contract term and renewal terms

Ask whether your current agreement stays with the same legal entity after the acquisition, and what happens at renewal. Confirm the notice period, any price uplift clause, and whether terms can change when your license is transferred or re-papered under Securonix. Get the answers in writing, because a renewal quote is the earliest point where a move to OpenCTI or MISP becomes a real option with a fixed date.

Support and roadmap for standalone use

Ask which ThreatQ releases, support tiers and security fixes are committed for customers who do not run Securonix, and for how long. Confirm whether the product roadmap still includes the connectors, feeds and APIs your team uses today. A statement that ThreatQ remains available standalone does not, by itself, say which features will receive investment.

SIEM integration tied to Securonix

List every push, pull and enrichment integration you depend on, such as indicator exports to a SIEM or EDR tool, and ask whether each one works without a Securonix subscription. Confirm whether any capability depends on Securonix components, and whether the vendor plans to change or retire the connector you rely on. Integration dependencies are often the hardest part of a move, so this list also sets the scope of any migration.

Deployment model and its continuity

If you run ThreatQ on premises, confirm the supported operating systems, database versions and upgrade path for the next two major releases. If you use the SaaS option, ask where the data is hosted, what the continuity commitments are, and how you would retrieve your data if the service were discontinued. Ask whether on-premises and SaaS releases will continue to receive the same features.

Data export rights and formats

Confirm in the contract that you own your indicators, adversary records, reports, scores and audit history, and that you can export them in full at any time, including after termination. Ask which formats the export supports, such as STIX 2 or CSV, and whether attachments, relationships and scoring history are included. Test a full export before deciding, because the export format determines how much work a move to OpenCTI or MISP will require.

How staying, integrating and replacing compare for a non-Securonix team

Staying on standalone ThreatQ keeps your workflows, Threat Library content, dynamic scoring and existing feed and SIEM integrations unchanged, which makes it the lowest-effort path in the short term. The cost is dependence on a vendor whose product roadmap now sits inside Securonix. Before renewal, ask ThreatQuotient or Securonix in writing which ThreatQ versions, deployment models (on premises or SaaS), support terms and connector commitments are guaranteed for standalone customers, and whether any pricing or bundling changes apply to you. Confirm these in the contract, not in a roadmap slide.

Integrating means keeping ThreatQ and connecting it to tools you already run without Securonix, such as your own SIEM, SOAR or EDR. This preserves institutional knowledge but leaves you with the same license and roadmap exposure, plus the maintenance of custom integrations. Replacing is the path with the largest upfront effort: you must migrate indicators, adversaries and scoring, then rebuild feeds and detection exports. Both open-source options come with different license terms. MISP is licensed under AGPL-3.0, with CIRCL among its main copyright holders, and its repository notes that interlocked copyright among contributors prevents any single entity from changing the license model. OpenCTI Community Edition is Apache 2.0, but several features you may need, such as audit logs, playbooks, organization-based segregation and SSO options, sit in the Enterprise Edition under a proprietary license. Have legal review both models against your obligations, especially if you plan to modify the code or offer it to partners.

Map each option to your own requirements before choosing. If your team mostly aggregates feeds and pushes indicators to detection tools, MISP's exports and sharing model may fit closely. If you need a STIX 2 knowledge graph and connector-based enrichment, OpenCTI may fit better, and you should confirm whether the features you rely on are in Community or Enterprise. Whichever path you choose, the ongoing work of curating feeds, maintaining connectors and running upgrades stays with your team or a partner, so put that staffing question on the decision list alongside licensing.

Which open-source option fits which ThreatQ use case

This table compares self-hosted MISP and OpenCTI against the ThreatQ use cases that usually drive a stay, integrate or replace decision. Read each row as a check against your own workflows, since several ThreatQ capabilities need confirmation before you decide. The main takeaway is that MISP fits community sharing and detection exports well, while OpenCTI fits relationship-heavy analysis, and both need scoring and automation checks first.

Requirement	Self-hosted MISP	Self-hosted OpenCTI
Sharing with partners and ISACs	Event synchronization between instances with distribution levels and sharing groups down to individual attributes.	Sharing through connectors and streams. Confirm it matches your community's trust model.
Exports to SIEM and EDR tools	Native exports to Suricata, Snort, Zeek, STIX 1 and 2, OpenIOC, CSV and RPZ.	Export and stream connectors. Confirm the formats your SIEM and EDR tools consume.
Relationship modeling and analyst context	Events, attributes, taxonomies and galaxies, including MITRE ATT&CK coverage.	STIX 2 knowledge graph queried through GraphQL, with a MITRE ATT&CK connector.
Enrichment and actions (TDR-style automation)	Correlation and REST API workflows. Confirm what automation you need beyond the API.	Playbooks are an Enterprise Edition feature. Pair with an orchestrator for ticketing and SIEM actions.
Scoring and decay of indicators	Verify the expiry and confidence rules you rely on in ThreatQ before migrating.	Verify how scores are assigned and reduced over time in your edition and version.
Core dependencies and sizing	PHP application on MySQL or MariaDB and Redis. PostgreSQL support arrives through the 2.5.47 migration system; confirm production status.	Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, with a platform node of at least 2 cores and 8 GB RAM.
Licensing and enterprise features	AGPL-3.0 software license. Taxonomies and galaxies are CC0 or BSD licensed.	Apache 2.0 Community Edition. SSO, audit logs and playbooks require the Enterprise Edition license.
Installation and upgrade path	Recommended on Ubuntu 24.04 with the provided installer, plus Docker, Ansible and Puppet options.	LTS releases require a specific license key and receive only critical and security fixes after stabilization.

How to run a MISP or OpenCTI move inside your own infrastructure

This sequence moves ThreatQ intelligence onto a self-hosted platform in stages, so the contract, data and detection feeds are settled before any production traffic changes. The result is a tested parallel system and a documented cutover that your team operates.

Confirm contract and export rights first
Before any technical work, read your ThreatQ agreement with ThreatQuotient or Securonix and confirm what happens to your data at renewal or termination, and whether you may export indicators, adversaries, attributes, relationships and scores in usable form. Ask the vendor in writing which export formats it supports and whether any fees apply. This step is done when legal and procurement have a written answer on export rights and a dated record of the renewal terms you are working under.
Inventory feeds, integrations and consumers
List every commercial and community feed ThreatQ ingests, every workflow that pushes indicators to SIEM, EDR, firewall or ticketing tools, and every analyst who relies on ThreatQ views. For each item, record the owner, the update frequency and whether the consumer reads a push or a pull. Map each feed to a planned OpenCTI connector or MISP feed, and flag any feed you cannot replicate. This step is done when the inventory is signed off and every gap has an owner.
Stand up the target platform on your own servers
For OpenCTI, provision the platform and workers, RabbitMQ 3.11 or later, Elasticsearch 8.0 or OpenSearch 2.9 or later, Redis 7.1 or later and S3-compatible storage such as MinIO, using the documented minimums as a floor and sizing for your volume with at least one platform node for every 3 workers. If you need Enterprise Edition features, obtain the license and confirm LTS key handling, since LTS releases need a specific license key and receive only critical bug and security fixes after stabilization. For MISP, deploy MISP 2.5 on Ubuntu 24.04 with the provided installer, or use the Docker, Ansible or Puppet options. Do not install new MISP 2.4 instances. This step is done when both platforms answer health checks in your own network.
Harden access, backups and sharing settings
Configure SSO, role separation and sharing groups before loading any data. For OpenCTI, review the authentication options documented for OpenID, LDAP, SAML, certificates and headers, and check whether your edition supports the segregation and audit features you need. For MISP, set distribution levels and sharing groups deliberately and review the OidcAuth plugin documentation for single sign-on. Define backup schedules for the database, search index and object storage, and test a restore. This step is done when a restore test succeeds and access reviews match your identity policy.
Import data and rebuild feeds in parallel
Load exported ThreatQ indicators and context into the new platform, mapping them to STIX 2 objects in OpenCTI or to MISP events with taxonomies and galaxies. Recreate each feed as a connector or MISP feed and run it alongside ThreatQ for a defined observation period set by your team. Compare object counts, scores, expiry and duplicate handling between the two systems and log every mismatch. This step is done when the mismatch log is triaged and analysts agree that the new platform answers their common queries.
Repoint detection tools and test exports
Replace each ThreatQ push to SIEM, EDR and firewall tools with a MISP export, such as Suricata, Snort, Zeek or CSV, or an OpenCTI connector. Test one integration at a time in a non-production detection environment and confirm that the expected indicators arrive, expire and are removed as intended. Record the endpoint, credentials and owner for each integration. This step is done when every integration has passed a test and its owner has signed off.
Cut over and retire ThreatQ on a documented date
Switch analyst workflows and detection feeds to the new platform, keep ThreatQ read-only for the agreed fallback period, and confirm that no consumer still depends on it. Then follow the export and deletion steps in your contract, and keep a retained copy of the export where your records policy requires it. This step is done when ThreatQ receives no production traffic, the deletion or retention record is filed, and the new platform's runbook covers patching, LTS or release upgrades and on-call ownership.

Which path fits which team situation

Staying suits teams with a ThreatQ contract that runs well into the future, feeds and SIEM or EDR pushes that already work, and no pressing need to change data models. The acquisition does not by itself require a move. The stated plan that ThreatQ stays available standalone is a starting point for the decision, but it does not set your terms.

Contract term and renewal: Confirm the end date, renewal mechanics and whether the contracting entity or licensing model changes after the acquisition.
Roadmap in writing: Ask your ThreatQuotient account team which versions, support windows and deployment options are committed for standalone customers.
Integration impact: Check that your SIEM, EDR and ticketing connectors are supported on the version you run and on the version you plan to run.
Deployment model: Confirm whether on-premises and SaaS deployments follow the same product direction.

Before renewing, get these answers in writing and set a review date so the decision is revisited if the product direction changes.

What do buyers ask before moving off ThreatQ?

How much does moving off ThreatQ cost, and what drives the total?

The total is set by four components: people, servers, migration work and connector work. Internal staff time to curate feeds, write exports and run the new platform is usually the largest recurring item, while servers and storage recur every year. OpenCTI has documented sizing minimums: the platform needs 2 cores and at least 8 GB RAM, and Elasticsearch or OpenSearch needs 2 cores, 8 GB RAM and 16 GB SSD, before counting workers, RabbitMQ, Redis and object storage. MISP runs on a single well-sized Ubuntu 24.04 host for many teams. Ask any quote to split one-time costs (migration, mapping, connector rebuilds) from recurring costs (hosting, licenses, upkeep) and to state which SIEM and EDR integrations are included.

How long does a ThreatQ migration take?

Duration depends on scope: how many feeds, indicators, adversaries and downstream SIEM or EDR integrations must be repointed, and how much data needs mapping. A small deployment that only aggregates feeds and pushes indicators is far less work than one with custom scoring, bespoke workflows and many connectors. Timing also depends on how fast your team can review mapped data and test detections. Ask for a schedule with phases and sign-off points, and treat any timeline without a stated scope as a rough guess.

What does the move require from our internal team?

Your team needs to own the decisions that only you can make: which feeds stay, how indicators should be scored and expired, who may share with which communities, and which detections depend on each integration. Engineers must validate exports against the systems that consume them and approve cutover. Plan for analysts to review a sample of migrated records, since mapping errors show up in day-to-day triage. Name a single owner for the project and confirm how many hours per week each contributor can give before the schedule is agreed.

Can we do the migration in-house?

Yes, if your team already runs containers or Linux services, has experience with threat intelligence data models and can maintain connectors after go-live. OpenCTI is a multi-service deployment with Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, and it needs a plan for upgrades. OpenCTI's Long Term Support releases require a specific LTS license key and receive only critical bug and security fixes after a one-month stabilization, so upgrade discipline matters. MISP is simpler to install but still needs feed curation and sharing governance. Be honest about where your skills end and whether a fixed-scope partner would cover the gap.

Can we export our ThreatQ data, and what might not transfer?

Most indicators, their types, sources and timestamps can usually be exported through ThreatQ's interfaces or API, but confirm the exact export options for your version and licensing with ThreatQuotient or Securonix before you plan. Adversary records, relationships, custom scoring and attached context often need manual mapping to STIX 2 objects for OpenCTI or to events, attributes, taxonomies and galaxies for MISP. Feed connections do not transfer, so each source must be recreated. Ask for a sample export of your own data and a field-by-field mapping before committing to a target.

Does a DeployOpen fixed-scope engagement cover a ThreatQ move?

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, so a move to OpenCTI or MISP can be scoped as a fixed engagement. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not issue audit reports or certifications, so any compliance evidence still needs an independent assessor. Ask us to list which ThreatQ integrations, feeds and exports are in scope.

What auditors and risk teams ask to see after a threat intelligence move

A move away from ThreatQ, or a decision to stay after the Securonix acquisition, is judged on records as much as on the platform. The cards below list the evidence that assessors and risk teams usually request, and what each one should show. DeployOpen prepares this evidence, but independent auditors and certification bodies are the ones who issue any opinion or certification.

Inventory of feeds and integrations

Auditors want a current list of every feed, connector and SIEM or EDR push that carries intelligence in or out. For each item, record the owner, data classification, update frequency and whether it still exists after the move. Ask ThreatQuotient or Securonix for a written list of which integrations are supported in a standalone deployment, since the stated plans for integration with Securonix SIEM do not by themselves confirm standalone support terms. Compare this inventory with the feeds configured in OpenCTI connectors or MISP feeds before cutover.

Data export and migration records

Keep a dated record of every export from ThreatQ, including record counts, data types, hashes of export files and the person who ran each job. Map each exported object to its target, such as a STIX 2 object in OpenCTI or an event with attributes in MISP, and log every field that was dropped or transformed. Reconciliation reports that compare source and target counts show whether indicators, adversaries and scores moved intact. Store these records with the change ticket so the trail survives the decommissioning of ThreatQ.

Access control and SSO configuration evidence

Export the role definitions, group mappings and authentication settings from the new platform, and capture the configuration as it stood at go-live. OpenCTI's Enterprise Edition documents SSO options for OpenID, LDAP, SAML, certificate and header authentication, and MISP supports OIDC through its OidcAuth plugin. Assessors usually ask who can read, edit and share intelligence, and whether that matches the approved access model. Confirm which of these methods your edition and version supports before you commit to a design.

Backup and upgrade records

Retain evidence that backups of the platform database, search index, object storage and message queue were taken and that a restore was tested. For OpenCTI, the dependencies include Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, so each one needs its own backup evidence. Record the version in use, the upgrade path taken and the rollback plan. OpenCTI LTS releases receive only critical and security fixes after the stabilization period, so the upgrade calendar is part of the control evidence.

Sharing-policy settings

Sharing controls decide which partners and communities receive intelligence, so auditors will ask for the policy and the configuration that enforces it. In MISP, document the distribution levels, sharing groups and synchronization partners, and export the settings that govern them. In OpenCTI, document organization-based segregation and the handling of marking definitions. Note which external sharing agreements existed under ThreatQ, and confirm that each one has an equivalent or has been formally ended. Review the settings after any change of ownership of the vendor, since terms of use and integration options may change.

What to do this quarter if you stay with ThreatQ

If you keep ThreatQ, the first task is to turn the vendor's stated plans into written terms. Ask ThreatQuotient or Securonix, in writing, for the standalone support commitment for your deployment model, the end-of-support or end-of-life policy for the version you run, and the product roadmap for on-premises and SaaS editions. Ask who your named contact is after the acquisition and whether your renewal terms, support channel and escalation path have changed. A verbal assurance from a sales contact will not help you at your next renewal, so file the answers with your contract records and note the date you received them.

Next, inventory every dependency that exists only because of the Securonix relationship. Check which ThreatQ connectors, feed subscriptions, data exchanges, user provisioning and dashboards are wired to Securonix SIEM or other Securonix products, and which SIEM and EDR pushes you run from ThreatQ today. Record each one with its owner, its configuration location and the detection tool that consumes its output. This list tells you which parts of your intelligence workflow would break under a change of vendor strategy, and it is the input any later migration plan needs, whatever tool you choose.

Build an export routine now so that your data stays portable whatever happens next. Schedule regular exports of indicators, adversaries, reports, tags, scores and relationships in formats you can read without ThreatQ, and store them on your own infrastructure with checksums and a retention rule. Test one restore into a scratch environment each quarter. Finally, set a review date on the calendar, ideally before your next renewal notice period, and assign an owner to decide between staying, integrating further or moving to self-hosted OpenCTI or MISP. Confirm the export formats and API limits with ThreatQuotient before relying on them.

How DeployOpen plans a ThreatQ exit or hardening under your constraints

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the decision to stay with ThreatQ, integrate it or move to OpenCTI or MISP is made on written scope rather than on vendor timelines. Engagements are typically fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory the ThreatQ deployment, feeds, connectors and SIEM or EDR pushes that depend on it, and confirm which are in use.
Confirm with Securonix and ThreatQuotient in writing which product, support and licensing terms apply to your contract.
Agree in writing which path is in scope: staying, integrating, or moving to OpenCTI or MISP, with deliverables and timelines.

How we build

Deploy OpenCTI or MISP in your cloud accounts, data center or air-gapped network, following the vendor's documented install path.
Re-create feeds as connectors or imports and map indicators and adversaries to the target data model during a parallel run.
Test sharing rules, exports to detection tools and access controls, and document each result as evidence for your reviewers.

How we hand over

Deliver architecture, runbooks, configuration records and an updated data flow diagram for your own operators.
Walk your analysts and platform engineers through feed curation, connector upkeep and the upgrade process.
Set out a clear cutover and rollback plan so ThreatQ can be retired only after your written sign-off.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped in writing.
Plan upgrades around the release cadence of your chosen platform, such as OpenCTI LTS lines or MISP 2.5 releases.
Ask for a quote built from the written scope, covering one-time migration work and recurring support separately.

ThreatQ after the Securonix acquisition: stay, integrate or replace