What an OpenCTI implementation covers and what it costs
An OpenCTI rollout is a set of linked pieces rather than a single install, and the cost follows how many of those pieces you deploy and how much each one must be configured. The platform itself provides the web application and GraphQL API. Behind it sit Python workers that consume RabbitMQ messages for asynchronous writes, Redis, Elasticsearch or OpenSearch, and S3-compatible storage such as MinIO. Connectors then bring data in for import, enrichment, file extraction, export and stream consumption. Each of these needs its own sizing, configuration, secrets handling and monitoring, and the data model and access design sit on top of all of them.
Teams usually start this work for a small set of reasons: they are standing up their first threat intelligence platform, they are replacing spreadsheets that have stopped scaling, they are moving off a MISP-only workflow to get a graph-based view of relationships, or they are consolidating feeds that several analyst teams currently pull and store separately. Each trigger changes the scope. A team consolidating feeds for several groups needs more time on access design and connector selection than a single team starting from a blank page.
On in-house versus partner: a capable platform team can deploy the stack from the published deployment documentation. The decisions that tend to benefit from prior experience are connector selection, how groups and organizations map to data segregation and roles, and which Community or Enterprise Edition features your requirements actually need. Confirm these choices against the current OpenCTI documentation and your own environment before you commit to a build plan.
What the implementation includes
The work breaks into six packages. The exact list, depth and hours depend on the written scope, so confirm each deliverable below against the signed statement of work before you compare quotes.
Architecture and sizing decisions
Before any installation, the team fixes the topology: how many platform nodes and workers, where Elasticsearch or OpenSearch runs, and how storage and networking are laid out in your environment. OpenCTI's documented minimums (2 cores and at least 8 GB RAM for the platform, and at least one platform node for every 3 workers) are the starting point, not the answer. The deliverable is a sizing and architecture record you can review. Ask for the assumptions behind each number.
Platform and dependency deployment
This package installs the platform alongside its 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. Versions must meet or exceed these minimums and match what your chosen OpenCTI release supports. The deliverable is a deployment record listing versions, hosts, network paths and secrets locations. Confirm who owns patching of each dependency after handover.
Worker and connector deployment
Python workers consume RabbitMQ messages for asynchronous writes, and connectors handle import, enrichment, file extraction, export and stream consumption. This package deploys the workers and the connectors selected in scope, sized to expected feed volume. The deliverable is a connector inventory listing each connector, its direction, its schedule and its worker assignment. Ask how deduplication and data volume will be controlled for each feed.
Data model and access design
This package designs how STIX2-based entities, marking definitions and organizations map to your analyst teams and data sharing rules. For Enterprise Edition features such as organization-based data segregation, the design also covers which groups see which data. The deliverable is an access matrix that maps roles, groups and organizations to permitted data. Confirm which features your license tier includes before the design is final.
Authentication setup
Local users and LDAP are available in the Community Edition, while SAML, OpenID Connect and other strategies require the Enterprise Edition since OpenCTI 7.260224.0. This package configures the chosen strategy against your identity provider and sets the rules for group mapping and break-glass accounts. The deliverable is a configuration baseline covering strategies, role mappings and admin account handling. Confirm the license needed for SSO before you commit to a design.
Handover and runbook
Handover closes the engagement with a runbook for routine operations: starting and stopping services, checking dependency health, rotating credentials, and running upgrades. It also records which version line you run, such as a regular release or an LTS line, and how its support window applies. The deliverable is the runbook plus a knowledge transfer session with your operators. Ask what remains in your team's hands after the last deliverable.
What drives cost and duration
Each row names one driver of OpenCTI rollout effort, explains why it adds work, and gives one practical way to keep it down, with sizing figures covered in the OpenCTI platform and Elasticsearch sizing topic.
| Driver | Why it adds effort | How to keep it down |
|---|---|---|
| Analysts and users | More accounts, groups and concurrent searches add platform load and access design work. | Start with a named pilot group and add users in waves. |
| Number and type of connectors | Each import, enrichment or export connector adds worker queues, schedules and permissions to review. | Start with MITRE ATT&CK and one trusted feed, then add connectors one at a time. |
| Feed and data volume | High-volume feeds grow the index, increase deduplication work and slow initial backfills. | Agree a scope and retention rule for each feed before the first import. |
| Number of environments | Test, staging and production each need their own platform, dependencies, connectors and data handling. | Keep staging small, seed it with sample data and reuse one deployment definition. |
| Edition and governance features | Since 7.260224.0, SSO needs the Enterprise Edition, and audit logs and playbooks also depend on it. | Confirm required features with Filigran before design and defer features not needed at launch. |
| Organization-based data segregation | Separate organizations need ownership rules, group mapping and tests proving one team cannot see another's data. | Document the segregation model early and limit it to teams with a stated need. |
| Custom connectors or playbooks | Custom code needs development, retesting against each release and an owner after handover. | Defer custom playbooks until core workflows run and reuse existing connectors where possible. |
| Compliance evidence needs | Assessors expect access records, change history, backup tests and configuration evidence collected during the build. | Name the control set and evidence owner early and automate exports of configuration and logs. |
| Hosting model | Cloud accounts, data centers and air-gapped networks differ in image sourcing, updates, identity and backup paths. | Choose one hosting model for the first environment and document how updates reach air-gapped networks. |
Implementation phases and their outputs
The sequence moves from agreed requirements to a tested, documented OpenCTI platform that your team can operate, with connectors added in controlled stages.
Confirm discovery and requirements
DeployOpen reviews your threat intelligence sources, analyst workflows, identity provider, hosting constraints and data-sharing rules with your security and IT leads. The output is a written requirements list and a scope document that sets the phase lengths and fees, which you approve before work starts.
Decide architecture and sizing
Based on requirements, the team selects the edition, deployment model and sizing for the platform, workers and dependencies, using the documented minimums as a starting point. The output is an architecture decision record covering Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, plus the release channel you will follow.
Prepare the target environment
DeployOpen prepares the cloud accounts, data center or air-gapped network, compute, DNS, certificates, network segmentation and secrets handling in the infrastructure you control. The output is a documented environment with access paths, baseline configuration and a checklist signed off by your infrastructure owner.
Build the platform and dependencies
The team installs the OpenCTI platform, its search, cache, message queue and object storage services, and the Python workers that consume queued writes. The output is a running non-production stack with health checks passing and the configuration recorded as code or runbooks.
Roll out workers and connectors in waves
Connectors are added in groups rather than all at once, starting with the sources that matter most to your analysts and watching worker load and data volume after each wave. Your team should confirm which connectors start first. The output is a connector register listing each feed, its owner, its schedule and its observed volume.
Configure the data model and access
DeployOpen sets up the knowledge model, marking definitions, organizations, groups, roles and authentication strategies to match your data-segregation rules. Where SSO is required, the Enterprise Edition licensing must be confirmed before this step. The output is a access design document and a tested set of accounts that map to real roles.
Test, accept and hand over
The team runs functional, integration and access tests against your acceptance criteria, then delivers the documentation and operations training for your administrators and analysts. The output is a signed acceptance record, a handover pack with runbooks for backup, upgrades and connector changes, and a support arrangement you choose separately.
What teams usually keep in-house and what they outsource
This table lists each part of an OpenCTI rollout with its typical owner (internal team, partner or shared) and the skills it needs, so you can see where your staff should sit in the build.
| Implementation part | Typical owner | Skills needed |
|---|---|---|
| Linux and container hosting | Partner builds, internal team operates | Linux administration, container runtime and orchestration, network and TLS configuration, patch management in your infrastructure |
| Elasticsearch or OpenSearch operations | Shared | Search cluster sizing, index lifecycle and snapshot management, storage and heap tuning, version compatibility with the platform |
| RabbitMQ and Redis | Partner sets up, internal team runs | Message queue configuration, persistence and memory settings, monitoring queue depth, failover planning |
| Identity integration | Shared, internal team approves design | Directory administration, SAML or OpenID Connect configuration, group-to-role mapping, Enterprise Edition licensing decisions for SSO |
| Threat intelligence modeling in STIX2 | Internal analysts own, partner advises | STIX2 object model, intelligence tradecraft, confidence and marking decisions, relationship design for your use cases |
| Connector configuration | Partner builds, internal team selects feeds | Connector setup and tuning, feed licensing review, deduplication and data volume control, worker capacity planning |
| Analyst workflow design | Internal analysts own, partner implements | Analyst process mapping, playbook design, dashboard and workspace setup, access model for teams and organizations |
| Taxonomy and intelligence content | Internal analysts | Domain knowledge, labeling standards, source reliability rules, ongoing curation of threat actors, campaigns and indicators |
What usually goes wrong and how to prevent it
Most OpenCTI rollouts that stall or overrun share a small set of avoidable mistakes. Each card names the prevention step and the artifact that shows it was done.
Connectors enabled before worker capacity
Turning on feeds and enrichment connectors before the worker count is planned floods RabbitMQ with messages faster than workers can write them. The documented guidance is at least one platform node for every three workers, so size workers against the connector list first. Prevention: a written worker capacity plan tied to each connector. Artifact: a sizing sheet signed off before the first connector runs in production.
Dependency versions below documented minimums
OpenCTI expects Elasticsearch 8.0 or OpenSearch 2.9 or later, Redis 7.1 or later, and RabbitMQ 3.11 or later. Installing older versions from a distribution repository or an existing shared cluster causes failures that look like application bugs. Prevention: check each dependency against the documented minimums during design. Artifact: a version matrix recorded in the architecture document and checked again at the production build.
Feeds loaded without deduplication or limits
Importing full external feeds with no deduplication or volume ceiling fills the knowledge graph with duplicate and low-value indicators, which slows search and inflates storage. Each feed should be reviewed for overlap with others and for its update cadence. Prevention: a feed inventory with a per-feed import scope and volume ceiling. Artifact: an approved feed register listing scope, owner and expected growth.
Access and marking design after data arrives
Teams that load intelligence first and design markings and groups later face costly re-labeling of existing objects and risk exposing sensitive data during the gap. Marking definitions, organizations and group-to-role mapping should be decided before the first import. Prevention: an access model that defines markings, organizations and roles. Artifact: a reviewed access matrix that the import plan references.
SSO planned without confirming Enterprise Edition
Since OpenCTI 7.260224.0, defining and using authentication strategies, including SSO, is an Enterprise Edition feature. Budgets built on the Community Edition alone will not cover SAML or OpenID Connect integration. Prevention: confirm the edition requirement with Filigran before costing the identity work. Artifact: a written edition decision that lists which features the rollout depends on.
LTS license key missing before production build
LTS releases are distributed as container images but require a specific LTS license key to run. Discovering the missing key during the production build can block the release that the team planned to standardize on. Prevention: obtain and validate the key in a non-production environment before the build is frozen. Artifact: a successful LTS deployment record in staging with the key recorded in the license register.
No test environment for connector changes
Connector updates can change how entities are created and how much data is written, and that impact is hard to reverse once it reaches production. A staging instance with representative data lets the team measure volume before a change goes live. Prevention: a non-production environment that mirrors the connector set. Artifact: a change record showing a connector was tested against staging volumes before promotion.
How the work changes by starting point
A new deployment in a cloud account you control has the fewest inherited constraints, so the scope grows mainly through design decisions made before anything is provisioned.
- Grows: account and network segmentation between the platform, workers, dependencies and connectors, plus the choice between self-run and managed services for search, queues and object storage.
- Grows: identity design. Local users, LDAP or SAML affect whether Enterprise Edition licensing is needed for SSO, so confirm this before the build.
- Shrinks: data migration, because there is usually no legacy data to map on day one.
- Answer first: which account, region and tagging rules apply, who owns the infrastructure-as-code, and which connectors the first release needs.
An existing Kubernetes cluster or virtual machine estate removes much of the infrastructure build, but it adds fit checks against standards your team already runs.
- Grows: alignment with current storage classes, ingress, certificate handling and secrets processes, which often need adjustment for OpenCTI's components.
- Grows: version checks for the dependencies OpenCTI requires, since they must run on database, search and messaging services your team may already operate at different versions.
- Shrinks: platform provisioning, where node pools, hypervisors and backup jobs already exist.
- Answer first: who operates each dependency today, whether those teams accept the documented minimum versions and sizing, and where backups for each component will be stored.
Restricted networks change how software and threat data reach the platform, so mirroring and approval work becomes a major part of scope.
- Grows: mirroring container images for the platform, workers and connectors into an internal registry, plus a repeatable process for every update.
- Grows: connector sources. Feeds and APIs that connectors normally call over the internet need a proxy, an offline import process or a documented exception, and each one should be confirmed individually.
- Grows: update planning, since patches and LTS keys must pass the same approval path as other software.
- Answer first: what the enclave allows inbound, how image provenance is verified, and who is responsible for importing threat data and on what schedule.
Moving from spreadsheets or a MISP-only setup shifts effort from infrastructure to data and workflow, because the existing process has to be understood before it can be retired.
- Grows: mapping current records, such as spreadsheet rows or MISP events, to the STIX2 knowledge model, including deduplication and handling of incomplete entries.
- Grows: analyst training and a period where old and new sources run in parallel, with a clear rule for which one is authoritative.
- Shrinks: the connector list when MISP stays in place as a feed, since an existing sharing workflow can be reused.
- Answer first: what the current process produces, which analysts and downstream tools depend on it, and what the retirement date and criteria are.
What the client needs to provide
Before a scoping call, the client should have the inputs that decide what discovery must cover. The first is hosting access: the cloud accounts, data center or air-gapped network where OpenCTI and its dependencies will run, with a named owner for each account and an agreed way to request firewall and DNS changes. Next, confirm the network and DNS decisions, including the internal hostname for the platform, whether it is reachable only from the corporate network, and where TLS certificates come from.
Identity needs its own line item. Name the identity provider, the team that owns it, and the people who can create application registrations for OpenCTI. Authentication strategies such as SAML or OpenID Connect are an Enterprise Edition feature, so the edition decision and the SSO decision should be made together. Also name a product owner for threat intelligence content. This person decides which feeds are trusted, how indicators are labeled, and who signs off on data quality. Without that owner, connector work stalls on questions nobody can answer.
Produce a list of feeds and internal sources with an owner for each one, the expected data format, and the licence terms that allow ingestion. Add the intended users and how they map to teams or organizations, since that shapes data segregation later. Then record the edition decision and whether the client will obtain an LTS license key. LTS releases require a specific key to use, so procurement needs to start early. Finally, book an approved change window for the first installation, because dependency setup and the first connector wave both need one.
Gaps in these items usually move cost into discovery. Scoping calls then spend time on ownership questions rather than design, and the first connector wave slips while access and approvals are chased. Ask the partner to list each item as a dependency in the written scope, with the client owner named next to it. Items still open at the start of build should be recorded as risks with a date to close.
Frequently asked questions
What drives the cost of an OpenCTI implementation?
The biggest drivers are the number of components you run, how much integration work they need, and how much design work comes before the build. Platform and dependencies: the OpenCTI platform, Python workers, RabbitMQ, Redis, Elasticsearch or OpenSearch, and S3-compatible storage each need installation, hardening, backups and monitoring. Connectors: each feed or enrichment service adds configuration, testing and data-quality review. Data model and access design: groups, organizations and marking rules take analysis before they take configuration. Ask any quote to itemize these parts separately, and to show which ones are one-time and which recur.
How long does an OpenCTI rollout take?
Duration depends on scope, not on a fixed template: the number of connectors, whether SSO is required, how much existing intelligence must be migrated, and whether the environment is new or already runs dependencies. Work that involves identity integration, data governance decisions and infrastructure approvals often sets the critical path, because it waits on people outside the build team. Ask for a written schedule with dependencies named, the staff time assumed from your side, and the milestones where your sign-off is required. Confirm the timeline against your own change-approval process before committing.
Can our platform team implement OpenCTI without outside help?
Yes, if the team already runs containers or Kubernetes, operates search clusters, message queues and identity providers, and has time for threat intelligence data design. Most of the difficulty is rarely the first install. It is sizing the search and queue layers, deciding how connectors are staged, and agreeing on the data model before analysts depend on it. Assess your team against those skills, and treat the platform as an ongoing operation with its own on-call duties. A partner is most useful when the scope is fixed in writing and the team needs a known deliverable set.
What does the work need from our own staff?
Expect requests for named people from security operations, threat intelligence, identity and infrastructure teams. Security operations and threat intelligence staff define which feeds matter, how indicators should be handled and who owns the data. Identity staff supply the SSO provider, group mappings and the role model. Infrastructure staff provide hosts or cluster capacity, network paths, storage, backup targets and approvals. Confirm these time commitments in the scope document, since slow answers on access and data decisions are a common reason for schedule slip.
Does the edition we choose change the scope of the work?
Yes. The Community Edition is licensed under Apache License 2.0, while the Enterprise Edition uses a proprietary license. Since OpenCTI 7.260224.0, authentication strategies including SSO are an Enterprise Edition feature, and the Enterprise Edition also adds audit logs, playbooks, organization-based data segregation and priority intelligence requirements. Those features add configuration and testing work and a licensing line to the cost. LTS releases also require a specific LTS license key. Confirm the edition, license terms and feature list with Filigran before the scope is fixed.
Can we add connectors after the initial rollout?
Yes. OpenCTI deployments are designed to add connectors over time, and the workers that process them scale with the connector set. Adding a connector later still requires checking worker capacity, deduplication behavior and the volume of data it will create, so plan for that work each time. Ask any quote to state whether connector onboarding is in scope after go-live, how many are included, and how new connectors are tested against your data before they reach analysts.
How DeployOpen scopes, delivers and hands over OpenCTI
DeployOpen plans, implements, integrates, documents and supports OpenCTI inside your own cloud accounts, data centers or air-gapped networks, starting from a written scope. The plan and cost work is agreed before any build begins, so the platform, workers, dependencies, connectors and access design are priced as distinct parts.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Scope covers platform, worker and dependency layout, connector selection, data model and access design for your team.
- Confirm with us which authentication strategies you need, since SSO depends on the Enterprise Edition.
How we build
- We build the platform, Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage in your environment.
- Connectors are deployed in priority order, with worker capacity checked against the documented sizing guidance.
- Each build step is tested against your data, access rules and network isolation before the next step starts.
How we hand over
- Handover includes configuration documentation, connector inventory, access model records and the deployment architecture.
- Runbooks cover startup order, dependency checks, backup routines and how to add or remove connectors.
- Your team is walked through the operating procedures so they can run the platform after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
- Upgrade planning reflects whether you run continuous releases or the licensed LTS line, which you confirm with us.
- Support scope, response expectations and service levels are written into the retainer agreement, so confirm them there.
