Which fits your SOC or CTI team: Cyware Intel Exchange or self-hosted OpenCTI
Choose Cyware Intel Exchange when your main requirement is a hub that a vendor operates, your members already connect to it, and your playbooks already run on it. Moving a sharing community during a renewal takes time in member onboarding and integration rework, so a team with working sharing workflows and no residency constraint may be better served by keeping them. Cyware fits organizations that want the vendor to carry platform operations and that depend on existing feeds, playbooks and member connections. Self-hosted OpenCTI fits a different job: analysts who want to model actors, campaigns, malware and indicators as a graph, and organizations that must keep intelligence inside their own cloud accounts, data centers or air-gapped networks.
OpenCTI structures data on the STIX 2 standard and exposes a GraphQL API, so analysts can query the relationships between threat actors, malware, infrastructure and reports directly. The Community Edition is licensed under Apache 2.0 and includes connectors for MISP, TheHive and MITRE ATT&CK. Playbooks, audit logs, organization-based segregation and SSO for OpenID, LDAP and SAML are listed as Enterprise Edition features, so confirm which edition covers your playbook and access requirements before you commit. OpenCTI is the stronger fit when intelligence analysis drives the workflow and the data must stay on your own infrastructure.
The decision turns on three things. First, staffing: OpenCTI needs Elasticsearch 8.0 or later, or OpenSearch 2.9 or later, plus Redis 7.1 or later, RabbitMQ 3.11 or later and S3-compatible storage such as MinIO, and someone must patch, back up and scale each of them. The OpenCTI deployment overview documents the starting sizing, including at least one platform node for every 3 workers. Second, whether sharing with members is your main job, in which case MISP is the more direct comparison. Third, how many playbooks must push intelligence to detection tools today. Ask Cyware for an inventory of those playbooks and ask for a matching Enterprise Edition scope before you choose.
Which scenarios favor each option
This table maps common Cyware Intel Exchange scenarios to the platform that fits better, and names the condition that tips the decision. Read each row as a starting point: the condition column is what you should verify in your own environment before committing. The main takeaway is that OpenCTI suits analysis-heavy teams with capacity to run its stack, while sharing communities and small teams often start with a simpler exchange model.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| SOC needs fast indicator push to detection tools | Depends on push design, not platform alone | Confirm which SIEM, firewall or EDR connectors each option supports today, and whether your playbooks need OpenCTI connectors or a SOAR tool in front of them |
| CTI team doing analysis and reporting | OpenCTI | Analysts need relationships, STIX 2.1 objects and a knowledge graph for campaign and actor work, and have capacity to operate Elasticsearch or OpenSearch, Redis, RabbitMQ and MinIO |
| Sharing community or ISAC hub | MISP | Members need sharing groups, distribution levels and server-to-server synchronization that many communities already use, and governance of who runs the hub is agreed up front |
| Data residency mandate | Either, self-hosted | Both can run inside your own infrastructure, so confirm where Intel Exchange member instances and any cloud components would store data before deciding |
| Team with no platform engineers | Neither without a support plan | Both need ongoing operation, upgrades and backups. Without an owner or a retainer, plan for the operating effort to fall back on the SOC or CTI analysts |
| Existing MISP-format feeds from members | MISP | Your partners already exchange MISP events and attributes, so fewer conversions are needed and sync stays native |
| Need for OpenCTI connectors to MITRE ATT&CK and TheHive | OpenCTI | Your workflow relies on the MITRE ATT&CK connector and integrations with TheHive, and you accept managing connector versions yourself |
How OpenCTI's components fit together in your environment
An OpenCTI deployment is more than one application. The platform serves the web interface and the GraphQL API that analysts and connectors use, while Python workers consume RabbitMQ messages to perform asynchronous writes. Connectors sit beside them to import data, enrich observables, extract files, export intelligence and consume streams. Before you compare this with Intel Exchange, map which of these pieces your team would operate itself. The Intel Exchange hub is run by Cyware, so the upgrade, queue and storage work described below moves onto your staff or your implementation partner.
The stack depends on several services you will need to size and back up. OpenCTI uses Elasticsearch 8.0 or later, or OpenSearch 2.9 or later, for indexing and search, Redis 7.1 or later, RabbitMQ 3.11 or later, and S3-compatible object storage such as MinIO for files. The documented sizing starts the platform at 2 cores and at least 8 GB RAM, and the search engine at 2 cores, 8 GB RAM and 16 GB SSD. The deployment overview also recommends at least one platform node for every 3 workers. Treat these as starting points and confirm them against your expected connector count and feed volume before you request hardware or cloud capacity.
Licensing decides which of these features you can use. The Community Edition is licensed under Apache 2.0. Audit logs, playbooks, organization-based segregation, full text indexing, AI insights and SSO configuration for OpenID, LDAP, SAML, certificate and header authentication belong to the Enterprise Edition, which carries a separate license from Filigran. If your sharing model needs per-organization data separation or audited access, confirm with the vendor which edition and license you need before you design the architecture. The OpenCTI Enterprise Edition documentation lists the features in each edition.
Where your data lives and who controls access
Moving threat intelligence off a vendor-hosted hub changes where indicators, member data and access logs sit. The cards below cover the decisions that follow from that move: where OpenCTI runs, which hosting model fits, how users sign in, what gets logged, and what evidence a compliance review will ask for.
Data location in your own environment
With self-hosted OpenCTI, the platform, its Elasticsearch or OpenSearch index, Redis, RabbitMQ and S3-compatible object storage all run in your cloud account, data center or air-gapped network. Cyware Intel Exchange data sits in the vendor-operated hub unless a deployment option says otherwise. Confirm with Cyware which data stores, backups and logs they hold, and which regions they use, before you map your own boundary.
Hosting models for each option
OpenCTI is a multi-service stack: a platform node, Python workers and connectors, plus the data services listed above. Cyware is a hosted hub with member connections. Model each option as a cloud deployment you operate, a dedicated environment, or an air-gapped install, and ask Cyware which of these it supports for your classification level. Note that OpenCTI LTS releases require a specific license key, so include that in your hosting plan.
Single sign-on options in OpenCTI
OpenCTI Enterprise Edition supports SSO through OpenID, LDAP, SAML, certificate and header authentication. This lets you keep users in your existing identity provider rather than local accounts. Check that your identity provider can deliver the attributes OpenCTI needs for organization-based segregation, and confirm which of these methods your edition and license include before you commit to a design.
Audit logs and segregation under Enterprise
Audit logs and organization-based segregation are listed among OpenCTI Enterprise Edition features. Together they let you show who viewed or changed intelligence and keep one organization's data separate from another's. Community Edition is licensed under Apache 2.0, so confirm in writing which logging and segregation controls you get without the Enterprise license, and how long you must retain audit records under your own policy.
Compliance readiness and evidence
Self-hosting gives you control over the systems and records that an assessment will examine, but it does not certify anything. Gather evidence such as access reviews, configuration baselines, backup test results, change records and sharing agreements for each platform. Independent auditors and certification bodies issue opinions. Ask Cyware for its own independent reports and for the scope they cover, and confirm them against your framework requirements.
What running OpenCTI takes week to week
Running OpenCTI is an ongoing operating job, and the first thing to plan for is the release cadence. Non-LTS releases ship when they are ready, from daily to weekly, and the version number encodes the date: a regular release follows the x.YYMMDD.z pattern, while an LTS release follows x.YYMMDD.z-lts.n. LTS releases arrive every six months and each is supported for one year, so consecutive LTS lines overlap by six months. That overlap gives you a window to move, but only if someone owns the calendar. After the one-month stabilization period, an LTS release gets only critical bug and security fixes, and the LTS line requires a specific LTS license key. Confirm with Filigran which key terms apply to your edition and who is named as the contact for renewals before you commit to an LTS line.
Most of the weekly work is testing upgrades before they reach production. Each platform upgrade should be rehearsed on a staging copy with a representative set of connectors, because connector versions and platform versions have to move together. Watch the search and queue layers closely: Elasticsearch or OpenSearch, Redis, RabbitMQ and MinIO each need their own capacity alerts, and RabbitMQ backlog is often the first sign that Python workers are falling behind. Keeping connectors current is a standing task for MISP, TheHive, MITRE ATT&CK and any custom feeds, and each one needs an owner who tracks its changes and tests it after every platform release.
Cyware Intel Exchange carries its own operating load, but the split between vendor-run and team-run work differs, so this effort should be confirmed directly with Cyware rather than assumed. Ask which upgrades, connector maintenance and infrastructure monitoring are included in the subscription, what your staff must do, and how the vendor handles release timing for your deployment. Put the answers next to a written estimate of your own weekly hours for OpenCTI, covering upgrade testing, queue and search monitoring, and connector upkeep, so the comparison rests on the same tasks on both sides.
What a move from Cyware Intel Exchange to OpenCTI involves
The sequence moves feeds, sharing relationships and automation out of Cyware Intel Exchange and into a self-hosted OpenCTI stack, with each phase closed by a verifiable output. It ends with a parallel run and a cut over that the team signs off on, so detection tools keep receiving intelligence throughout.
Inventory feeds, playbooks and connectors
The CTI lead and the SOC engineers list every feed, sharing group, playbook and downstream push to a detection tool that Cyware Intel Exchange currently handles. For each item, record the source, the data format, the consumers, the schedule and the owner. Confirm with Cyware which of these items are exportable and which exist only as configuration inside the platform. The step is done when the inventory is reviewed and every item has a disposition: migrate, rebuild, retire or keep in place.
Stand up the OpenCTI stack
The platform team deploys OpenCTI inside your own infrastructure, with the platform, Python workers, connectors, Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage such as MinIO. Size the nodes against the documented minimums and confirm the dependency versions in the deployment overview before installing. Choose between the Community Edition and the Enterprise Edition based on the features you need, such as audit logs, playbooks, organization segregation and SSO. The step is done when the platform, workers and connectors pass health checks in a non-production environment.
Export Cyware data as STIX 2.1 bundles
The CTI team exports indicators, reports, threat actors and relationships from Cyware Intel Exchange as STIX 2.1 bundles. Ask Cyware which object types and custom fields the export preserves, and log what is lost or flattened. Keep the original exports in write-once storage so the source data remains available for audit. The step is done when a sample of each object type has been exported and checked against its source record.
Import bundles and verify relationships
The platform team imports the STIX 2.1 bundles into a test OpenCTI instance and checks that indicators link to the correct observables, reports and threat actors. Compare object counts and a sample of relationships against the Cyware export and record every mismatch with its cause. Decide how custom Cyware fields will be mapped, stored as labels, external references or extensions. The step is done when the mismatch log is closed or each remaining gap has an accepted workaround signed off by the CTI lead.
Rebuild ingestion as connectors
Each feed that Cyware pulled becomes an OpenCTI import connector, or a stream or export connector where data flows out. The team confirms that a connector exists for each source, or scopes a custom connector, and runs it against the live source in staging. Credentials are moved into the secrets store, not into configuration files. The step is done when every inventoried feed ingests into OpenCTI on schedule and the ingestion log shows no unresolved errors for a full cycle.
Replace playbooks with OpenCTI playbooks or a SOAR tool
The SOC and CTI leads rebuild each Cyware playbook that pushes intelligence to detection tools. Simple enrichment or routing steps can move to OpenCTI playbooks, which are part of the Enterprise Edition feature set. Steps that open tickets, isolate hosts or update a SIEM usually belong in a SOAR platform. Test each rebuilt playbook against a sample event and confirm the detection tool receives the same indicators and context. The step is done when every playbook has a documented owner and passes the sample test.
Run in parallel and cut over
Cyware and OpenCTI run side by side for an agreed period. The team compares indicator volumes, enrichment results and detection-tool hits between the two, and resolves each difference before cutover. Cut over one feed or detection path at a time, keeping Cyware available as a rollback until the final path is confirmed. Member-facing sharing is the exception: if partner organizations connect through sharing groups, that exchange may need MISP alongside OpenCTI, so confirm member requirements before turning anything off. The step is done when the CTI lead and SOC lead sign the cut over record.
Questions buyers ask before switching from Cyware Intel Exchange
What drives the cost of moving from Cyware Intel Exchange to OpenCTI?
The cost is driven by components, not by a single license line. Cyware is paid through subscriptions for the hub and any connected member instances. Self-hosted OpenCTI removes that subscription but adds infrastructure, staff time to operate it, and the one-time cost of migration. On the infrastructure side, OpenCTI needs a platform node, workers, Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage such as MinIO. Ask any quote to separate one-time items (migration, playbook rebuild, connector setup) from recurring items (hosting, upgrades, support retainers, staff). Also ask whether the quote covers Enterprise Edition features if you need them, since those are licensed separately.
How long does a migration from Cyware Intel Exchange to OpenCTI take?
No duration is fixed by the product, so the timeline depends on your data and integrations. The main drivers are the volume of intelligence to export as STIX 2.1 bundles, how many feeds and sharing relationships must be re-created as OpenCTI connectors, how many Intel Exchange playbooks must be rebuilt or moved to OpenCTI playbooks or a SOAR tool, and how much validation your analysts need before they trust the new data. A fixed-scope engagement with agreed deliverables and timelines, set in writing before work starts, lets you compare options on the same basis. Ask any vendor or partner for a written scope that lists each feed, connector and playbook, and the acceptance tests for each.
What work does our team have to supply during the move?
Your team supplies the knowledge the platform cannot infer. That includes the owners of each feed and connector, the STIX object types and relationships your analysts rely on, the detection tools that consume intelligence (SIEM, EDR, firewalls), and the approval rules for what gets pushed to them. You also need someone who can approve network access, storage, identity integration and change windows. For OpenCTI specifically, plan for a named owner of the GraphQL API, the connectors and the upgrade process, because the Community Edition is Apache 2.0 licensed and maintained by Filigran, and you handle its updates. Confirm these responsibilities in the scope document rather than assuming them.
Can we run OpenCTI ourselves without a implementation partner?
Yes, a capable internal team can deploy and run OpenCTI, because the Community Edition is open source under Apache 2.0 and the deployment documentation describes the components. The questions to answer honestly are whether your team has the skills to operate Elasticsearch or OpenSearch, Redis, RabbitMQ and object storage, and whether it can keep pace with releases. OpenCTI publishes regular releases and LTS lines, so you should decide which channel you will follow. If you lack that capacity, DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, under fixed-scope agreements, with ongoing support available as a retainer.
Does OpenCTI replace the sharing we do with member organizations?
Not by itself. OpenCTI is an analysis and knowledge platform built on STIX 2, with a GraphQL API, connectors for MISP, TheHive and MITRE ATT&CK, and a worker model for ingestion and enrichment. It does not take the place of a sharing community's distribution model. If your members currently receive intelligence through Intel Exchange, you need to decide how that exchange continues. Many communities keep a sharing hub such as MISP for distribution and use OpenCTI for analysis. Confirm with your members which formats and transports they need, including TAXII delivery, before choosing the architecture.
Which OpenCTI features require an Enterprise license?
The OpenCTI documentation lists these as Enterprise Edition features: audit logs, playbooks, organization-based segregation, full text indexing, AI insights, and SSO configuration for OpenID, LDAP, SAML, certificate and header authentication. Enterprise Edition is licensed under the proprietary OpenCTI Enterprise Edition License, not Apache 2.0. If your Intel Exchange playbooks or access model depend on any of these, budget for that license or plan an alternative, such as a SOAR tool for automation and an external identity provider for SSO. Ask the vendor to confirm the current feature list and license terms in writing, because the documentation is the authoritative source.
How do we keep OpenCTI supported and patched after go-live?
Plan for upgrades from the first day. OpenCTI uses date-based version numbers, and non-LTS releases ship from daily to weekly. LTS releases come every six months and are supported for one year, with a six-month overlap between consecutive LTS versions. LTS releases are distributed as container images but require a specific LTS license key, and after a one-month stabilization they receive only critical bug and security fixes. Choose a channel, test each upgrade in a non-production environment, and make sure someone owns the calendar. Ask any support provider how upgrades, backups and security testing are scoped and priced.
How DeployOpen helps evaluate, implement and migrate
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from Cyware Intel Exchange to OpenCTI, we start with a written scope that separates the sharing, enrichment and playbook work so your SOC and CTI teams can judge each part before committing.
How we scope
- Inventory current STIX 2.1 bundles, feeds, connectors and playbooks that run on Cyware Intel Exchange today
- Agree which feeds become OpenCTI connectors and which need a separate MISP sharing path
- Define the OpenCTI dependencies: Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
How we build
- Deploy the OpenCTI platform, workers and connectors inside your environment and size them to your feed volume
- Configure enrichment connectors, including the MITRE ATT&CK connector, and test normalization against sample bundles
- Connect playbook outputs to your detection tools and check that indicators arrive with expected STIX relationships
- Test authentication, role separation and audit logging against your identity provider settings before go-live
How we hand over
- Document the architecture, connector configuration, backup routines and upgrade steps for your own operators
- Provide a runbook for OpenCTI LTS license handling and the release cycle your team will follow
- Record the migration decisions, data mapping and any gaps against Cyware Intel Exchange functions for review
- Walk your SOC and CTI staff through daily operation, ingestion monitoring and incident response procedures
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Retainers can cover OpenCTI version upgrades and patching of the underlying data services
- Ask any proposal to state who maintains connectors, who answers platform incidents and how upgrades are tested
- Compliance readiness work can prepare evidence for independent auditors, though DeployOpen does not issue attestations
