Which open-source threat intelligence platforms fit your team
If your SOC or CTI team needs a self-hosted platform, the choice usually depends on who you share with and what your analysts work from. Choose MISP when the main job is exchanging indicators with partners, peer groups or sector communities. Choose OpenCTI when you want a structured knowledge base of STIX-based entities and relationships, fed by a connector ecosystem. Choose Yeti when your DFIR analysts start from observables and forensic artifacts and need to pivot from them. The three overlap in places, but none is a drop-in substitute for the others without a clear use case behind the switch.
MISP fits teams whose value comes from distribution: its distribution levels and sharing groups, down to individual attributes, and its synchronization between instances are built for trusted communities. Its AGPL-3.0 license and CIRCL association are relevant if you plan to contribute back or run a sharing node. OpenCTI fits teams that want to model actors, campaigns and techniques and connect many sources, with the MISP, MITRE and CVE connectors among the documented options. Yeti fits DFIR teams that bulk search observables and tie threats to forensic artifacts, Sigma and YARA rules. Its Apache-2.0 license is permissive, but it is aimed at analysts rather than inter-organization sharing.
OpenCTI's paid Enterprise Edition changes the decision. Audit logs, playbooks and automation, organization segregation and OpenID, LDAP or SAML single sign-on require a paid Enterprise license, so confirm early whether your identity and audit requirements depend on those features. Ask Filigran or a reseller to quote the Enterprise license against your scope, and confirm how LTS builds, which need a specific LTS license key, fit your upgrade plan. If your requirements can be met by Community features, the cost comparison shifts toward operating effort, which DeployOpen scopes in writing before work starts.
Which platform suits which scenario
This table maps common threat intelligence needs to the platform that fits best, with the condition under which each fit holds. Read each row against your team's sharing model, analyst workflow and budget for paid features. The main takeaway is that MISP leads for sharing, OpenCTI for structured knowledge and Yeti for DFIR, and the paid tier matters for SSO and audit logs.
| Scenario | Best fit | Why, and under what condition |
|---|---|---|
| Sharing indicators with peers or a trusted community | MISP | Distribution levels, sharing groups and automatic synchronization between instances are built for this. The fit holds if your partners run or can join MISP instances and you accept the AGPL-3.0 terms. |
| Building a structured CTI knowledge base | OpenCTI | Its knowledge schema is based on STIX2 entities and relationships. The fit holds if analysts need to model actors, campaigns and relationships over time, and you can run Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage. |
| DFIR analysts searching observables and artifacts | Yeti | It stores observables, forensic artifact definitions, Sigma and YARA rules and reusable queries, with Timesketch integration. The fit holds if your analysts work from investigations toward TTPs and artifacts rather than exchanging feeds with other organizations. |
| Team needs SSO or audit logs in OpenCTI | OpenCTI Enterprise Edition | Audit logs, playbooks, organization segregation and OpenID, LDAP or SAML SSO require the Enterprise Edition. Confirm the license scope and cost with Filigran before you rely on the Community Edition for these controls. |
| Small team that wants to start with one tool | MISP | A single platform covers collection, storage, correlation and export, and CIRCL has provided training since 2016. The fit holds if your first need is indicator management and sharing rather than a full knowledge graph. |
| Team that must export to SIEM or detection tools | MISP | Exports to STIX 1 and 2, CSV, Suricata, Snort and Zeek rule formats are available through its REST API. The fit holds if your detection stack consumes these formats directly. |
| Team that wants MITRE ATT&CK mapping with a connector model | OpenCTI | A dedicated MITRE ATT&CK connector and connectors for MISP and CVE data feed the platform. The fit holds if you are prepared to operate connectors and workers as part of the deployment. |
How MISP, OpenCTI and Yeti differ in brief
MISP, OpenCTI and Yeti all store threat intelligence, but they were built for different work. The cards below set out each platform's license, purpose, audience, current release and the one limitation that most often changes the shortlist. Check each limitation against your own sharing model and hosting plans before you commit.
MISP for community sharing
MISP is an AGPL-3.0 platform for collecting, storing, distributing and sharing indicators, built around sharing communities, taxonomies and galaxies. It suits CSIRTs, ISACs and SOC teams that exchange indicators with peers and need distribution levels and sharing groups. The limitation to check is the AGPL obligation: if you modify MISP and make it available to users over a network, you must review what source you owe those users. Confirm this with your counsel before you customize the platform.
OpenCTI for structured knowledge
OpenCTI, designed by Filigran, organizes intelligence as STIX2-based entities and relationships and is served through a GraphQL API. It suits teams that model adversaries, campaigns and reports as a knowledge graph and feed it through connectors, including MISP and MITRE connectors. Its Community Edition is Apache-2.0, but audit logs, playbooks, organization segregation and SSO through OpenID, LDAP or SAML need the proprietary Enterprise Edition. Confirm which features your team needs before you plan the Community deployment.
Yeti for DFIR analysis
Yeti is an Apache-2.0 platform, built with Python, FastAPI and ArangoDB, that stores observables, threat actors, indicators, DFIQ objects, Sigma and YARA rules alongside threat intelligence. It suits DFIR and threat intelligence analysts who bulk search observables and pivot from a threat to its TTPs and forensic artifacts. Yeti is aimed at analysts rather than community indicator sharing between organizations, so it is a poor substitute for MISP if sharing with peers is the main requirement. Check the sharing features against your needs before adoption.
Licensing across the three
MISP uses AGPL-3.0 for its software, while its taxonomies and galaxy data are licensed under CC0 1.0 or the 2-clause BSD license. OpenCTI splits its code between Apache-2.0 and a proprietary Enterprise license, so the license of each file matters. Yeti is Apache-2.0 throughout the repository. Ask each vendor or your legal team to confirm which license covers the exact components you plan to deploy and modify.
OpenCTI operating footprint
OpenCTI is a stateless platform that depends on Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, with Python workers and connectors on top. Its documented sizing recommends at least one platform node for every 3 workers. This footprint is the main operating cost of OpenCTI, so ask your implementation partner to size the dependencies and worker count against your expected feed volume before you commit to hardware.
MISP LTS and upgrade path
MISP 2.4 is end of life with security fixes only, and the project advises against new 2.4 installs. MISP 2.5 is the recommended line for new deployments, and the 2.5.47 release introduced a database migration system with PostgreSQL support. If you are running an older MISP instance, plan the upgrade early and confirm the database backend and migration steps in writing before the work starts.
Capabilities across the three platforms
This table sets MISP, OpenCTI and Yeti side by side on license, data model, sharing, connectors, export, API, identity, automation and current release. Read each row as a check on fit: where a cell says to confirm, the supplied facts do not settle the point and a test instance or vendor answer should. The main takeaway is that MISP leads on community sharing, OpenCTI on a STIX-based knowledge graph with a paid tier for governance features, and Yeti on DFIR analyst workflows.
| Capability | MISP | OpenCTI | Yeti |
|---|---|---|---|
| License | AGPL-3.0 for the software; taxonomies and galaxies under CC0 1.0 or BSD-2-Clause | Community Edition under Apache-2.0; Enterprise Edition under a proprietary license | Apache-2.0 |
| Primary data model | MISP events containing attributes and objects, with tags, taxonomies and galaxies | STIX2-based knowledge schema of entities and relationships | Observables, entities such as threat actors and campaigns, indicators, DFIQ objects and artifacts |
| Sharing and synchronization | Distribution levels, sharing groups down to individual attributes, and event sync between instances | Confirm sharing and multi-instance options in the Enterprise documentation for your edition | Aimed at analyst work rather than inter-organization sharing; confirm any sync options in a test instance |
| Feed and connector handling | Default intelligence feeds and correlation of indicators through exact and fuzzy matching | Connectors for import, enrichment, export and stream consumption, including MISP and MITRE connectors | Pluggable data sources and analytics; confirm which feeds are bundled in your version |
| Export formats | MISP JSON, STIX 1 and 2, OpenIOC, CSV, Suricata, Snort, Zeek and RPZ | Export through connectors; confirm the formats your connector set supports | Custom export formats for SIEM and DFIR platforms |
| API | REST API with restSearch, described by OpenAPI, plus the PyMISP library | GraphQL API with a web application | Web API for automating queries and enrichment |
| Identity options | OidcAuth plugin for OpenID Connect; confirm supported providers in its README | SSO through OpenID, LDAP or SAML requires Enterprise Edition | Google access token exchange endpoint added in 2.12.0, disabled by default; confirm other providers |
| Automation | Sharing and export automation through the API; confirm scheduled workflow options for your version | Playbooks and automation require Enterprise Edition | Analyst bulk search and scripted queries through the API; confirm built-in automation |
| Current release | 2.5.50, released October 10, 2026 (MISP GitHub releases) | 7.261016.0, released October 16, 2026; LTS builds carry an lts suffix | 2.12.0, released October 2, 2026 |
How MISP events and OpenCTI's STIX knowledge schema differ
The core difference is the unit of storage. MISP organizes data as events that contain attributes (single indicators such as an IP address or file hash) and objects (grouped attributes describing one thing, such as a phishing email). Each event carries distribution levels and sharing groups that decide who sees it, and those controls can be set down to individual attributes. OpenCTI organizes intelligence as *STIX-based entities and relationships*, following the STIX2 standards through its knowledge schema, and reads it through a GraphQL API rather than an event feed. Yeti sits in a different place again: it stores *observables*, *entities* such as threat actors and campaigns, and *indicators*, alongside DFIQ objects, forensic artifact definitions, Sigma and YARA rules and reusable queries.
For correlation, MISP's engine matches exact values and advanced patterns, including fuzzy hashes and CIDR overlaps, which suits teams whose main question is whether an indicator has been seen before. OpenCTI's value is in the relationships between entities, so analysts who need to trace an intrusion set to its tools, victims and techniques will find the graph model more useful. Yeti is built for analysts who start from an observable or a threat and need the related TTPs, malware and forensic artifacts. For sharing, MISP's distribution model is the strongest of the three, and it is the choice when you must exchange data with other organizations on defined terms. Confirm with your partners which sharing groups and synchronization settings they expect before you design your own.
Migration is where the models bite. MISP exports MISP JSON, STIX 1 and STIX 2, OpenIOC, CSV, text, Suricata, Snort, Zeek and RPZ formats, and the STIX 2 export is the natural route into a STIX-based platform such as OpenCTI. STIX 1 support matters if older partners or tools still consume that version. Expect some loss in translation: distribution settings, sharing group membership and object-level context may not map one to one, so test a representative sample of events and confirm with the vendor and your own data which fields survive the export and import. Plan the mapping as a project in its own right, and budget analyst time for reviewing the results.
What licensing and editions change for each platform
MISP's platform code is licensed under the GNU AGPL version 3. That license lets your team run MISP internally, modify it and use it to provide services. If you distribute a modified version, or let users interact with a modified version over a network, the AGPL requires you to make the corresponding source code available under the same terms. The project's taxonomies and galaxy data are separate. They are licensed under CC0 1.0 Universal or the 2-clause BSD license, so they carry different obligations from the platform code. The project's repository also notes that interlocked copyright among contributors prevents any single entity from changing the license model, which matters if you plan a long-term commercial dependency.
- Internal use: Running MISP inside your organization carries no license fee under the AGPL-3.0.
- Modified distribution: Sharing a changed MISP build outside your organization triggers source availability duties.
- Galaxy and taxonomy content: Check the CC0 or BSD terms that apply to the data you import or republish.
- License stability: The repository states that contributors' interlocked copyright blocks a single entity from relicensing the project.
- Version support: MISP 2.4 is end of life with security fixes only, so new deployments should target the 2.5 line.
Ask counsel to confirm how the AGPL applies to any custom modules, integrations or hosted service you plan to offer.
OpenCTI is split into two licenses. The Community Edition is licensed under Apache License 2.0, which is permissive and allows internal use, modification and redistribution with attribution and license notices. Files marked Enterprise Edition fall under the proprietary OpenCTI Enterprise Edition License, which requires a paid subscription and is not an OSI-approved open source license. Audit logs, playbooks and automation, organization segregation, and SSO through OpenID, LDAP or SAML are Enterprise features. LTS builds, distributed as container images with the lts suffix, also require a specific LTS license key and receive only critical bug and security fixes after a one-month stabilization period.
- Community scope: The Apache-2.0 code covers the platform features outside the Enterprise files.
- Paid controls: Audit logs, playbooks, organization segregation and OpenID, LDAP or SAML SSO need an Enterprise subscription.
- LTS key: Using an LTS release requires an LTS license key in addition to the image.
- Enterprise terms: The Enterprise License restricts use to its terms and is not open source.
- Mixed codebase: Confirm which files your deployment and any custom changes touch, because the two license regimes sit in one repository.
Before you plan around OpenCTI features, confirm the current subscription terms and LTS entitlement with the vendor in writing, and have counsel review them.
Yeti is licensed under Apache License 2.0. Based on the supplied license information, the repository does not describe a separate paid edition in the same way OpenCTI does. Apache-2.0 permits internal use, modification and redistribution, provided you keep copyright and license notices and state significant changes. It also includes an express patent license from contributors. For a team that wants to fork, extend or embed Yeti in its own tooling, this is the simplest of the three license positions to explain to legal, though the terms still need review for any third-party components you add.
- Internal use: Apache-2.0 allows running Yeti in your environment without a license fee.
- Modified distribution: You may redistribute changed code under Apache-2.0 with notices and change statements.
- Patent terms: Apache-2.0 includes an express patent grant from contributors.
- Dependencies: Review the licenses of Python packages, ArangoDB and any connectors you add, since those carry their own terms.
- Edition scope: Confirm with the maintainers whether any features are offered only under other terms before you commit.
Ask counsel to review Apache-2.0 obligations for your planned modifications and the licenses of every dependency you deploy.
How to choose and pilot a threat intelligence platform
This sequence takes a team from its primary job to a tested shortlist, so the choice between MISP, OpenCTI and Yeti rests on the team's own feeds, export needs and license position rather than on feature lists alone.
Define the team's primary job
Decide which of three jobs the platform must do first: sharing indicators with partner organizations, maintaining a structured knowledge base of threat actors and campaigns, or supporting DFIR analysts working on cases and forensic artifacts. The threat intelligence lead and the SOC or DFIR manager should sign off on one primary job and one secondary job in writing. This matters because MISP is built around community sharing, OpenCTI around a STIX2-based knowledge schema, and Yeti around analyst investigation and forensic artifacts. The step is done when the shortlist is reduced to the platforms that fit the stated primary job.
List feeds and sharing partners
Inventory every intelligence feed the team already receives, including commercial feeds, government sharing programs, ISAC memberships and any trusted peer communities. For each one, record the format it arrives in, how often it updates and whether the team must redistribute it. The platform needs to ingest these sources and, where sharing is in scope, to respect the distribution rules each partner expects. The step is done when a table lists each feed, its format, its sharing constraint and the platform connector or import path that would handle it.
Check license obligations against intended use
Compare the intended use with each candidate's license. MISP and Shuffle are licensed under AGPL-3.0, OpenCTI Community Edition under Apache-2.0 with a separate proprietary Enterprise Edition License, and Yeti under Apache-2.0. Legal or compliance counsel should confirm whether hosting the platform for external partners, modifying it, or offering it to a group of organizations triggers obligations under the license in use. Also confirm that MISP taxonomies and galaxies, which carry CC0 1.0 or BSD terms, are handled as separate content. The step is done when counsel has written a short memo that states the license position for each candidate and the intended use.
Confirm current versions at decision time
Before any deployment, open each shortlisted project's release page and record the current version, release date and support status. At the time of writing, the supplied release facts cover MISP 2.5.50 with the 2.4 line in end-of-life, OpenCTI 7.261016.0 with separate LTS builds, and Yeti 2.12.0. Confirm these against the MISP releases page, the OpenCTI releases page and the Yeti releases page on the day of the decision, because release lines move quickly. The step is done when the team has a dated record of versions and of which release lines it will install.
Deploy a test instance of each shortlisted platform
Build a non-production instance of each shortlisted platform in the team's own infrastructure, using the vendor's documented installation path. For OpenCTI, this includes the platform, Python workers, connectors and the dependencies its deployment documentation lists, namely Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, sized against the documented minimums. For MISP, confirm the recommended installer path and database requirements. For Yeti, confirm its FastAPI and ArangoDB requirements. The infrastructure or platform engineering lead should own this work, and the step is done when each instance starts, authenticates a test user and reports its health.
Load a sample of real feeds
Import a representative sample of the feeds from step two into each test instance, using the connectors or import paths that the platform provides. Measure whether events or objects are created with the expected structure, whether duplicates are merged or multiplied, and how correlation or relationship mapping behaves on overlapping indicators. Run the same sample through each platform so the results are comparable. Where sharing is in scope, test synchronization or distribution settings with a second test instance. The step is done when the team has a written comparison of ingestion results, data quality issues and any connector gaps found during the test.
Test export formats for SIEM and detection tools
List the export formats the SIEM, EDR and detection engineering tools require, such as STIX, CSV, Suricata, Snort, Zeek or custom formats, and test each one from every test instance. Check that exported content loads into the target tool without manual editing and that the fields match what detections expect. Yeti's custom export support and MISP's rule-format exports should be checked against the team's own rule pipeline. The detection engineering lead should sign off on the results. The step is done when each required export has been tested end to end and any gaps are recorded as work items or open questions for the vendor.
Decide on Enterprise features before quoting
Identify which features the team needs that sit behind a paid tier, such as OpenCTI Enterprise Edition capabilities for audit logs, playbooks and automation, organization segregation and OpenID, LDAP or SAML single sign-on. Confirm which of these are required on day one and which can wait. Then request written quotes from the relevant vendors or licensors, and ask DeployOpen for a fixed-scope quote based on the agreed requirements, covering implementation, integration, hardening and documentation. The step is done when the requirements list is signed off and each quote request states the scope, the editions and the support model it covers.
Record the decision and the pilot evidence
Write a decision record that names the chosen platform, the primary job it serves, the license position from step three, the versions confirmed in step four and the test results from steps five and six. Include the open questions the pilot could not close and the owner of each one. The CISO or head of security operations should approve the record before procurement begins. The step is done when the record is stored with the project documentation and the team can show, for each requirement, the evidence that the chosen platform meets it.
What operating each platform takes in your environment
The recurring work differs more by platform than the licenses suggest. MISP is the lightest stack to describe: a PHP application on CakePHP with MySQL or MariaDB and Redis. The project recommends MISP 2.5 for new deployments and lists an installer for Ubuntu 24.04, plus Docker images, Ansible roles, Puppet and RPM packages. Your team picks one installation path and then owns the upgrade path. MISP 2.4 is end of life with security fixes only, and the project advises against installing new 2.4 instances, so any existing 2.4 estate needs a dated upgrade plan. Confirm with the project how the 2.5 database migration system, which added PostgreSQL support in 2.5.47, fits your database standard before you commit to one engine.
OpenCTI carries the heaviest operating load. Each deployment runs the platform with its UI and GraphQL API, Python workers consuming RabbitMQ messages, connectors, Elasticsearch 8.0 or later or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later and S3-compatible storage. The documented sizing starts at 2 cores and 8 GB RAM for the platform, and the search tier needs 2 cores, 8 GB RAM and 16 GB SSD, with at least one platform node for every 3 workers. Connector count and feed volume drive the worker and search tiers up, so ask the vendor for sizing against your expected feeds. For production, the LTS cadence matters most: LTS releases arrive every 6 months and are supported for one year, but they require an LTS license key and receive only critical and security fixes after a one-month stabilization. Your team must schedule upgrades within that window or fall behind.
Yeti is the smallest footprint to run, built on Python, FastAPI and ArangoDB, but its effort depends on how much your analysts depend on it. Confirm the ArangoDB backup, retention and upgrade approach with the project before production use, because the database is central to the data model. Whatever the platform, the organization must provide patching windows, storage growth planning, backup testing and an on-call owner for connector failures and feed outages. SSO and audit requirements add effort on OpenCTI, where audit logs and OpenID, LDAP or SAML configuration sit in the Enterprise Edition. For MISP, plan for sharing-community onboarding and synchronization troubleshooting. Ask any implementation partner to quote these ownership items in writing.
What buyers ask before choosing or hiring help
What does it cost to implement MISP or OpenCTI?
The software is free to download under its license, so the cost is the work to install, configure, integrate and run it. DeployOpen does not publish a price list. A quote follows from a written scope, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. The main cost drivers are the number of feeds and connectors to configure, whether single sign-on is required, how much hardening and evidence collection your assessors expect, and whether you are migrating existing indicators or cases from another tool. Ongoing support, upgrades and continuous testing are separate retainers. Ask for the quote to list each deliverable, who does each task, and which items are one-time and which recur.
Can a small team run MISP or OpenCTI itself?
A small team can run MISP on its own if it has Linux administration skills and someone willing to own upgrades, sync configuration and sharing decisions. MISP 2.5 is the recommended line for new deployments, and the project lists an installer for Ubuntu 24.04 plus Docker images and Ansible roles. OpenCTI is heavier. Its documented dependencies include Elasticsearch 8.0 or later or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later and S3-compatible storage, plus Python workers and connectors. Running it well means operating several services, not only the platform. Before deciding, confirm the staff hours you can commit to monitoring, patching and upgrading those dependencies.
How long does a pilot take?
The pilot length depends on scope: how many data sources you connect, which identity integration you need, whether sharing with partners is in scope and how much existing data you migrate. DeployOpen agrees timelines in writing as part of the fixed scope, so the answer you receive should name the deliverables and dates for your environment rather than a generic duration. When you request a proposal, ask which tasks sit on the critical path, such as identity provider configuration or access approvals for your data owners, because those are often controlled by teams outside the project.
What does the work need from our side?
Plan for three inputs from your organization. First, infrastructure: a self-hosted environment in your cloud account, data center or air-gapped network, with capacity for the platform, databases and object storage. Second, identity: the SSO provider and group structure you want to map to platform roles, and an owner who can approve the configuration. Third, data owners: people who decide which feeds, indicators and sharing groups are allowed, and who can classify sensitive intelligence before it leaves the organization. Missing any of these usually delays the pilot more than the technical build does. Ask the implementer to list these inputs in the written scope.
When is OpenCTI Enterprise worth the subscription?
OpenCTI Community Edition is licensed under Apache-2.0, but audit logs, playbooks and automation, organization segregation and SSO configuration through OpenID, LDAP or SAML require OpenCTI Enterprise Edition under a paid subscription. The subscription is worth evaluating when you need one of those features as a requirement, for example audit evidence for an assessment or segregation between business units or partners. If you only need the core knowledge graph and connectors, the Community Edition may be enough. Also check the LTS model: OpenCTI LTS releases require a specific LTS license key. Confirm pricing and terms directly with Filigran, since DeployOpen does not set those terms.
Can one platform replace MISP, OpenCTI and Yeti?
Not without trade-offs. MISP is built around community sharing, with distribution levels, sharing groups and synchronization between instances, and it exports to formats such as Suricata, Snort and Zeek. OpenCTI organizes intelligence as STIX-based entities and relationships and imports through connectors, including a MISP connector. Yeti targets DFIR analysts, storing Sigma and YARA rules, DFIQ objects and forensic artifacts alongside intelligence, with Timesketch and MITRE ATT&CK integration. Each one has a different primary user. Many teams keep MISP for sharing and connect it to whichever platform their analysts use for investigation. Map your required workflows first, then test whether one platform covers them.
Does migrating from another platform add risk?
Yes, migration risk comes from the data model, not the software. MISP events, attributes and sharing rules do not map one-to-one onto OpenCTI's STIX-based schema, and Yeti's observables and analyst objects use their own structure. Before moving data, inventory which fields, tags and distribution rules matter, and decide what must be preserved for downstream detections. Confirm with the vendor and your own test data how each import behaves, and keep the source system read-only until the new one is validated. Ask any implementer to include a migration test plan in the written scope.
How DeployOpen scopes and delivers a threat intelligence platform
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers and air-gapped networks. For threat intelligence, that means fixing the platform choice, sharing model and connector set in writing before any build starts, so the result matches your team's workflow.
How we scope
- Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We document which platform fits your use, such as MISP for community sharing or OpenCTI for STIX-based knowledge management.
- Scope covers feed sources, sharing groups or connectors, identity integration and the hosting environment you already run.
How we build
- We install and configure the chosen platform and its dependencies inside your own cloud, data center or air-gapped network.
- Connectors, feed imports, taxonomies and sharing rules are configured and tested against the data model you selected.
- Hardening, backup routines and upgrade paths are built in, with security testing available where your team wants it verified.
How we hand over
- You receive documentation of the deployed architecture, configuration, connectors and operational runbooks.
- Handover covers the steps your analysts and administrators need to add feeds, manage sharing and review logs.
- Compliance-related controls and evidence are prepared for your own assessors, since DeployOpen does not issue audit reports.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
- Upgrades are planned against each platform's own release and life cycle, including OpenCTI LTS line timing where it applies.
- Confirm with us in the quote which edition, license terms and paid features are included in the written scope.
