Keep Recorded Future data and run the platform yourself with OpenCTI
If the problem is the platform rather than the intelligence, self-hosted OpenCTI can store, enrich and share Recorded Future data through its connectors while your subscription stays in place. Typical triggers include a renewal price increase, a data residency rule that requires indicators and analyst notes to stay in your own cloud account or data center, or lock-in concerns when every query, graph and sharing decision lives in a vendor's portal. OpenCTI structures data on the STIX 2 standard and exposes a GraphQL API, so the knowledge graph stays under your control. The platform depends on Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage such as MinIO, all of which your team would operate.
The edition choice matters for two controls. OpenCTI Community Edition is licensed under Apache 2.0, while Enterprise Edition uses a proprietary license. The OpenCTI Enterprise Edition documentation places audit logs and SSO (OpenID, LDAP, SAML, certificate and header authentication) in the Enterprise feature set. If your access policy requires SSO through your identity provider or an audit trail of who changed what, include the Enterprise license in the plan and confirm with Filigran which terms apply to your use. Enterprise LTS releases also require a specific license key, so ask how key renewal fits your change calendar.
The feed itself stays licensed by Recorded Future. Moving the platform does not move the entitlement, so confirm with Recorded Future which data products, API access and redistribution rights your contract covers before you share anything from OpenCTI with partners. Create a dedicated, least-privilege API token for the connector, store it in a secrets manager and set a rotation schedule. Confirm that the Recorded Future connectors you need support your OpenCTI version. Plan sizing from the deployment overview, which documents a minimum of 2 cores and 8 GB RAM for the platform, and recommends one platform node for every 3 workers.
What a self-hosted OpenCTI platform must meet
Six requirements decide whether a self-hosted OpenCTI deployment fits your policy before you connect Recorded Future. Several depend on the Enterprise Edition and on your license terms, so confirm each one with the control owner who will sign off on it.
Data stays in your infrastructure
OpenCTI depends on Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage such as MinIO, and each one holds intelligence data. Confirm that every component runs inside your cloud account, data center or air-gapped network. Also confirm that the Recorded Future connector sends only the query data your policy allows, and that backups of the search index and object store fall under the same retention and access rules as the platform itself.
STIX 2 data model
OpenCTI structures its knowledge on the STIX 2 standard, so indicators, reports, threat actors and relationships are stored as typed objects with identifiers. Confirm how Recorded Future risk list fields and enrichment results map to STIX objects in your deployment. Check that identifiers survive import and export, because downstream tools and sharing partners depend on them to correlate the same entity.
GraphQL API access control
OpenCTI exposes a GraphQL API that the web application and connectors both use, so API access is effectively platform access. Confirm which roles can read, create or delete objects, and which service accounts hold tokens for connectors. Store those tokens in your secrets manager, set a rotation schedule, and review them whenever a connector or analyst leaves the team.
SSO and authentication options
Enterprise Edition supports OpenID, LDAP, SAML, certificate and header authentication. Confirm which of these matches your identity provider and your MFA policy before go-live. Header authentication depends on a trusted reverse proxy that sets the identity, so check how that proxy is hardened and who controls its configuration.
Audit logs and organization segregation
Audit logs, playbooks, organization-based segregation and full text indexing are listed as Enterprise Edition features. Segregation matters if different teams, business units or sharing partners must not see each other's intelligence. Confirm that your auditors accept the audit log format, the retention period you need, and how segregated data is handled in backups and exports.
LTS license and upgrade cadence
Regular OpenCTI releases use the x.YYMMDD.z format and ship from daily to weekly. LTS releases arrive every six months, are supported for one year, and require a specific LTS license key. After a one-month stabilization period, they receive only critical bug and security fixes. Confirm who holds the license key, how you will fund and schedule upgrades, and which LTS line your change process can support.
What stays in the Recorded Future portal
Recorded Future keeps the parts of the service that OpenCTI cannot reproduce. Its own collection, its analyst-written reporting, the search and alerting it runs in its portal, and the enrichment logic behind its risk scores all stay with the vendor. OpenCTI only receives what the Recorded Future connectors pull into it: the indicators, entities and relationships exposed through the API or streams your subscription allows. Anything you query, browse or get alerted on inside the portal after the migration is not automatically in OpenCTI, so teams should list their daily portal workflows before cutting over and decide which ones need a replacement.
Confirm your entitlements with Recorded Future before you design the connector setup. Subscriptions differ in which API endpoints, risk list exports, STIX or TAXII collections and token types they include, and in whether connector or third-party platform use is permitted at all. Ask the vendor in writing which data sets your contract covers for ingestion into a self-hosted platform, how many API tokens you may hold, and whether the rate limits apply per token or per organization. Check these terms against the connector documentation in the OpenCTI repository so the design you approve matches what your contract allows.
Plan for the gap between what is pulled and what is visible. Once the connector runs, OpenCTI shows the imported objects with the provenance and labels the connector assigns, but it will not show Recorded Future's proprietary context unless that context arrives as data. Decide which analysts keep portal access during the transition, who owns the alerts that previously came from portal saved searches, and how often someone compares the two systems for missing indicators. Record these decisions in the migration plan, because they determine whether you keep a portal seat, which affects the subscription you negotiate.
Enrichment and Recorded Future connectors compared
Import connectors pull intelligence from an external source into OpenCTI and store it as STIX 2 objects in the knowledge base. OpenCTI handles connector writes asynchronously through Python workers that consume RabbitMQ messages, so a large batch can take time to appear in the interface. Import is the role that gives you a local copy, which keeps search, graph views and reports usable when the Recorded Future API is unreachable.
- What it writes: indicators, observables, and the relationships and labels the connector maps onto them, stored in OpenCTI's own indexes.
- Cadence: set by the connector's schedule and by how often the source publishes changes, so freshness is only as good as the last successful run.
- Retention: imported objects remain in OpenCTI after the subscription ends unless you delete them, so review your Recorded Future license terms before you decide what to keep.
- Failure visibility: a failed run leaves a gap that shows mainly in connector logs, so monitor those logs as part of normal operations.
Confirm in the connector documentation for your release which object types it creates, whether it supports incremental updates and revocations, and what its default schedule is.
Enrichment connectors work in the opposite direction. An analyst or playbook selects an observable such as an IP address, domain or file hash, and the connector asks Recorded Future for context and attaches the answer to that observable in OpenCTI. Because lookups are not stored in bulk, the knowledge base does not grow from enrichment alone, and each answer reflects the moment of the query.
- What it writes: the risk scores, risk context and related entities returned for the looked-up observable, attached as enrichment data.
- Trigger: either manual, from the interface, or automatic when an observable is created, depending on how the connector and your playbooks are configured.
- Quota dependency: every lookup consumes Recorded Future API capacity, so enriching a large imported set can exhaust your allowance quickly. Confirm your allowance and rate limits with Recorded Future before you enable automatic enrichment.
- Connectivity dependency: if the API is unreachable or returns errors, lookups fail, and cached answers are returned only if the connector provides a cache.
Check which enrichment entities and scores the connector writes, whether it caches results, and how it behaves when the API returns an error.
The two roles age differently. Import data is current only as of its last scheduled run, while enrichment data is as current as the query. Knowing which clock governs each object tells you how far to trust a score when you are writing a report or triaging an alert.
- Import freshness: the age of the newest imported object, which is determined by the schedule and by whether the connector pulls only changes.
- Enrichment freshness: the time of the lookup, which is the most current option unless the connector serves a cached answer.
- Backlog: RabbitMQ queues grow when workers process messages more slowly than they arrive, which delays when imported or enriched data appears.
- Air-gapped networks: neither role reaches Recorded Future from an isolated network, so an air-gapped design relies on file transfer for import and cannot use live enrichment.
- Timestamps: confirm whether the connector records the time the source observed an indicator or the time OpenCTI ingested it, because the two differ in reporting.
Confirm the schedule defaults, incremental behavior and timestamp fields for your OpenCTI release before you set any reporting SLA internally.
Most teams run import and enrichment side by side, which creates overlap that has to be managed deliberately. The same indicator can arrive through an import run and a later lookup, and the two sources may disagree about a score. Planning for these cases before go-live avoids confusing analysts and playbooks.
- Duplicates: the same indicator arriving through import and enrichment can produce overlapping objects, so check how the connector and the platform deduplicate.
- Score conflicts: imported and enriched scores can differ in age, so decide which one your playbooks and dashboards use.
- Worker capacity: the deployment overview recommends at least one platform node for every 3 workers, so size connector workers against your planned import and enrichment load.
- Ownership: assign one team to own connector tokens, schedules, logs and upgrades.
- Version pinning: OpenCTI uses date-based version numbers, and LTS releases require a specific license key, so record the exact version when you test connector behavior.
Test both roles on a staging instance with volumes that resemble your own before you enable them in production.
Which OpenCTI and supporting components fit this model
This table compares the OpenCTI editions, MISP as an optional sharing companion, and the self-hosted dependencies that OpenCTI needs. Read each row against your requirement for Recorded Future data ingestion, access control and sharing. The main takeaway is that OpenCTI carries the platform load, while MISP and the connectors must be confirmed for your chosen release.
| Component | How it meets the constraint | Trade-offs |
|---|---|---|
| OpenCTI Community Edition | Apache 2.0 licensed platform for storing STIX 2 data, with a GraphQL API and connector support for Recorded Future enrichment and import | Lacks some enterprise controls, so confirm whether audit logs, segregation and SSO meet your assessor's expectations before choosing it |
| OpenCTI Enterprise Edition | Adds audit logs, organization-based segregation, playbooks, full text indexing and SSO options such as OpenID, LDAP and SAML | Proprietary license from Filigran, so budget a commercial agreement and confirm terms with the vendor |
| MISP as companion | Handles sharing and synchronization between instances with granular sharing controls, so intelligence can reach partners without going through OpenCTI | MISP is a separate platform to run and secure, and it does not replace OpenCTI's graph and enrichment model |
| Elasticsearch or OpenSearch | Provides the search and indexing layer that OpenCTI requires, at version 8.0 or OpenSearch 2.9 or later | Typically the largest memory consumer in the stack, so size it early and confirm the documented minimums for your volume |
| Redis | Caches data for the platform, requiring version 7.1 or later | Low resource use, but it is a required service that needs its own patching and backup routine |
| RabbitMQ | Carries messages between the platform and Python workers and connectors, requiring version 3.11 or later | Queue backlog from Recorded Future connectors is a common failure point, so monitor queue depth |
| MinIO or S3-compatible storage | Stores files and exports in S3-compatible object storage | Requires a storage plan for retention and backups, and you must confirm the connector and release support for your chosen store |
| Connector availability | Recorded Future connectors are used to bring data in and enrich it, and must match your OpenCTI release | Confirm connector support, license terms and version compatibility for your specific OpenCTI release before committing |
How to deploy OpenCTI and connect Recorded Future
This sequence takes a team from sizing a self-hosted OpenCTI platform inside its own network to a validated Recorded Future feed, with access, secrets, backup and upgrades handled before data is loaded. The output is a running platform that ingests Recorded Future data under the team's own controls.
Size the platform from documented minimums
The platform team confirms the documented minimums before ordering hardware or cloud capacity: 2 cores and at least 8 GB RAM for the OpenCTI platform, and 2 cores, 8 GB RAM and 16 GB SSD for Elasticsearch or OpenSearch. The same documentation recommends at least one platform node for every 3 workers, so the planned connector count sets the node count. Ask DeployOpen or your own architects to document the worker and connector plan in writing, so the sizing can be reviewed against it. Done means a signed-off sizing sheet that lists nodes, workers and storage growth assumptions.
Deploy dependencies inside your network
Deploy the supporting services inside your own cloud account, data center or air-gapped network: 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. Check each version against the OpenCTI deployment overview before installation, because these are minimums. Restrict network paths so only the platform and workers reach these services. Done means each dependency answers health checks from inside the network and no service is exposed to the internet.
Choose a release line and license
Decide between regular releases and the LTS line. Regular releases ship when ready, from daily to weekly, and suit teams that can test frequent upgrades. LTS releases arrive every 6 months, are supported for 1 year, and require a specific LTS license key. After a one-month stabilization, LTS builds receive only critical bug and security fixes, so confirm the license terms and key handling with Filigran before you commit. Record the chosen version string, such as the 7.261016.0 regular release or the 7.260309.0 LTS line, in your change record. Done means the approved version is pinned in your deployment files.
Configure single sign-on
Configure SSO before analysts log in. Single sign-on options documented for OpenCTI Enterprise Edition include OpenID, LDAP, SAML, certificate and header authentication. Confirm with Filigran whether your edition includes these options, and review the OpenCTI authentication documentation with your identity team. Map groups to organization-based segregation, so only the right analysts see Recorded Future data. Done means a test user from each group signs in through your identity provider and sees only the expected organizations.
Store the Recorded Future token securely
Place the Recorded Future API token in your secrets manager, never in configuration files, container images or shared documents. Restrict read access to the service account that runs the connector and log each retrieval. Set a rotation schedule with your security team, and confirm how Recorded Future issues and revokes tokens for your subscription. Inject the token into the connector at runtime, and test rotation in a non-production instance first. Done means the token is absent from source control and configuration exports, and a rotation test completes without an outage.
Enable and validate connectors
Enable the Recorded Future connector and the enrichment connectors that your team needs, using the settings from the connector documentation for your OpenCTI version. Start with one feed or collection scope, and check that the connector runs without errors in its logs. Confirm that Python workers consume messages from RabbitMQ and write objects to the platform. Compare a sample of imported indicators and reports against the Recorded Future portal to confirm fields and relationships. Done means a documented test set matches between the two systems and the connector logs show no repeated failures.
Set backup and upgrade routines
Define backup routines for the search index, Redis state, RabbitMQ queues where your recovery plan needs them, and object storage, then run a restore test in an isolated environment. Schedule upgrades against the release line you chose, reading release notes and testing each version in staging before production. For LTS builds, track the stabilization period and the critical-fix-only phase so you know when to move. Keep the license key in the secrets manager with the token. Done means a successful restore into a clean environment and a written upgrade calendar approved by the platform owner.
How to handle the Recorded Future API token safely
Treat the Recorded Future API token as a credential that can pull licensed intelligence out of your environment, and keep it out of any file that gets copied, committed or shared. Store it in your secrets manager or your container platform's secret store, and inject it into the Recorded Future connector at runtime, for example through an environment variable such as the one the connector documents for its API key. Do not place the value in a docker-compose.yml or .env file that lives in a Git repository or an administrator's home directory. Issue a separate token for each connector, such as one for enrichment and one for feed import, so that revoking or rotating one does not interrupt the other. Ask Recorded Future which scopes a token carries and whether it can be limited to the risk lists or collections your connectors actually use.
Set the rotation schedule yourself, with a named owner, a fixed interval and a written procedure. A sound sequence is to issue the new token, update the secret store, restart the connector, confirm that imports resume, and then revoke the old token. Keep the token out of logs by checking that connector output, container logs and any debug settings do not echo environment variables or full configuration on startup, and by testing this after each connector upgrade. Keep the token out of tickets, chat threads and runbooks. If your OpenCTI edition includes audit logs, confirm that configuration changes to connectors are recorded, and review those entries when a token is rotated. The OpenCTI authentication documentation describes how platform users sign in, which is a separate secret from the Recorded Future token but needs the same handling.
Decide who can read connector configuration inside OpenCTI before you enter the token. Platform administrators can typically see and change connector settings, so keep that role to a small, named group and review its membership on a schedule. If several teams share one OpenCTI instance, confirm whether organization-based segregation, an Enterprise Edition feature, is needed to keep one team's connector settings and data away from another. Ask the vendor and your own administrators whether connector configuration values are displayed in the user interface or only stored server-side, and test this with a non-admin account. Record the answers in your access review so that auditors and your security team can see who could have read the token.
How this changes the Recorded Future subscription you need
Can I reduce the number of Recorded Future portal seats if OpenCTI becomes my main workspace?
Often yes, but the answer depends on who still logs in to the Recorded Future portal and for what. Analysts who only pull enrichment into OpenCTI may not need a portal seat at all, while analysts who run searches, read finished reports or use the portal's alerting still do. Map each current seat to a task before the renewal, then ask Recorded Future in writing how seat counts and tiers change if some users move to read-only or no portal access. Also confirm whether seat pricing is tied to the number of users, the modules enabled or both, since that determines how much a reduction saves.
Do I need to keep my Recorded Future API and connector entitlements?
Yes, if OpenCTI is to receive Recorded Future data, because the connectors authenticate with an API token tied to your subscription. Keeping the portal seat and dropping API access is a different decision from keeping the feed itself. Confirm which API endpoints, risk list downloads and TAXII collections your subscription includes, whether the Enrichment and Recorded Future connectors fall under the same entitlement, and how many API calls or queries the contract allows per period. Store the token in a secrets manager, not in connector configuration files, and rotate it on a schedule you control.
What happens to Recorded Future data already imported into OpenCTI when the subscription ends?
Data already stored in OpenCTI stays in your own infrastructure, but its usefulness depends on the license terms you hold for Recorded Future content. Indicators, observables and relationships you imported are your operational data. Recorded Future's proprietary risk scores, analyst text and reports may be subject to usage restrictions that continue after the contract ends or that prohibit redistribution. Ask Recorded Future in writing what it allows you to retain, enrich, share with partners or reuse after termination, and check whether enrichment values can be kept or must be refreshed. Keep an inventory of imported objects by source so you can remove restricted content on a defined date.
Which terms should I request from Recorded Future in writing before renewing?
Request a written statement covering four areas: seats and tiers, API and connector entitlements, data retention and use after termination, and support for a reduced scope. Ask for the exact list of data sets, risk lists, TAXII collections and API endpoints included, the query or call limits, and the permitted uses for downstream platforms. Ask whether the contract allows a mid-term reduction, what notice period applies, and how an exit or export is handled. Compare the written answers with the order form before signing, because verbal assurances from a sales representative are not binding.
How does dropping portal seats change the subscription cost structure?
Cost moves from a single subscription line toward several components you pay for separately. Recorded Future remains a recurring cost for whatever data you keep. OpenCTI Community Edition carries no license fee, but you pay for the infrastructure it needs: Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage such as MinIO, plus compute for the platform and workers. Enterprise features such as audit logs, playbooks and SSO come under the OpenCTI Enterprise Edition License, so that is a separate quote. Your own engineering time for connector upkeep and upgrades is a recurring internal cost. Ask Recorded Future for a price that reflects the reduced scope, and get a quote from OpenCTI's vendor or from DeployOpen for the Enterprise features you need.
Will OpenCTI need an upgrade plan that affects my Recorded Future connector?
Yes, plan connector upgrades alongside OpenCTI releases, because connectors must stay compatible with the platform version you run. OpenCTI uses date-based versions, and non-LTS releases ship from daily to weekly. Long-term support releases arrive every 6 months and are supported for 1 year, and an LTS release requires a specific LTS license key. Choose a release line that fits your change window, test connector updates in a non-production instance, and confirm with Recorded Future that your entitlement covers the connector versions you deploy. Track both release lines on the OpenCTI releases page.
Can my team handle the subscription and connector changes without outside help?
Many teams can handle the commercial review internally, but the technical work of moving feeds into self-hosted OpenCTI takes sustained platform skills. The contract review needs procurement, legal and security staff who can read entitlement language and data-use clauses. The technical side needs people who can operate Elasticsearch or OpenSearch, Redis, RabbitMQ, object storage, authentication and backups. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and offers ongoing support as a retainer. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts. DeployOpen does not negotiate with vendors on your behalf unless that is written into the scope, so confirm that point in the proposal.
Evidence auditors and regulators ask for
Once Recorded Future feeds land in self-hosted OpenCTI, the evidence trail moves to your side of the boundary. DeployOpen prepares these records, but auditors and regulators decide what they conclude from them.
Access logs for platform and connectors
Keep authentication and administrative activity for the OpenCTI platform, plus the logs for each Recorded Future connector and its service account. Auditors typically ask who could read or change intelligence, and when. Confirm that logs leave the OpenCTI host, that retention meets your policy, and that someone reviews them on a schedule. Record the connector's service identity separately from any named analyst.
Token rotation records
The Recorded Future API token is a credential that grants access to paid data, so its issue, storage, rotation and revocation dates should be documented. Record where the token sits, which connector uses it, and who approved each change. Ask the connector and secrets tooling you choose how the token is injected, so it does not appear in container definitions or shared configuration files.
OpenCTI Enterprise audit logs
If you run OpenCTI Enterprise Edition, its audit logs record user and data activity inside the platform, which makes them the strongest evidence of who viewed or changed intelligence. Confirm the license covers the feature, export the logs to your central store, and test that a sample change appears with the correct user. Community Edition deployments need an alternative audit trail, so plan for it before the assessment.
Data flow and residency diagrams
Diagram where Recorded Future data is pulled, which network path it takes, where OpenCTI, its Elasticsearch or OpenSearch index, Redis, RabbitMQ and MinIO store it, and which systems receive exports. Auditors use these diagrams to check residency claims and third-party exposure. Mark every point where data leaves your boundary, including any sharing with partners or other MISP instances.
Backup and restore test records
Store dated records showing that OpenCTI's database, search index and object storage were backed up, and that a restore was tested into a separate environment. Note which components were restored, the time taken, and any gaps found. Because the platform depends on several stores, a backup that restores only one of them does not prove recoverability. Ask whether Recorded Future data can be re-pulled after a restore.
Upgrade change records
Each OpenCTI upgrade should have a change record listing the version moved from and to, the reason, the test results and the approver. OpenCTI releases are date-based, with regular releases shipping from daily to weekly and LTS releases every six months, so the cadence drives how many records you will produce. For LTS releases, record the license key status as well, since LTS builds require a specific key.
What does it cost and take to run OpenCTI with Recorded Future data?
What does it cost to run OpenCTI with Recorded Future data?
The cost has five components: your Recorded Future subscription, the infrastructure that hosts OpenCTI, connector upkeep, analyst time, and any Enterprise Edition licensing you choose. OpenCTI Community Edition is licensed under Apache 2.0, so the software itself carries no license fee. The subscription stays with Recorded Future and remains a recurring cost. Infrastructure, connector maintenance and analyst time are recurring too. Ask for each component separately in any quote so you can see which ones your own team already pays for.
Does OpenCTI Enterprise Edition add a license cost?
Only if you need its features. OpenCTI Enterprise Edition is licensed under the proprietary OpenCTI Enterprise Edition License and adds audit logs, playbooks, organization-based segregation, full text indexing, AI insights and SSO options for OpenID, LDAP, SAML, certificate and header authentication. Community Edition covers the core platform. Confirm with Filigran, the company that designs and develops OpenCTI, what Enterprise licensing costs and whether your segregation or audit requirements need it, using the OpenCTI Enterprise Edition documentation as the starting point.
What infrastructure does a self-hosted OpenCTI deployment need?
OpenCTI needs several components running together: the platform, Python workers, connectors, Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage such as MinIO. 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, with at least one platform node for every 3 workers. Actual sizing depends on how much Recorded Future data you ingest and how long you retain it, so test with a representative volume before you commit to hardware or cloud spend.
How long does it take to get Recorded Future data into OpenCTI?
The timeline depends on the environment, the number of connectors and how much mapping work your data needs, and no fixed duration applies to every team. The steps are standing up the dependencies, deploying the platform, configuring the Recorded Future connectors with a token, and validating what lands in the knowledge graph. Ask any implementation partner for a timeline in a fixed-scope quote that lists these stages, the environment assumptions and the acceptance checks for the first ingestion.
What does my team need to provide for this work?
You need a cloud account, data center or air-gapped environment where OpenCTI can run, plus owners for identity, network access, secrets and the Recorded Future API token. Your threat intelligence team should define which Recorded Future data matters, how it maps to your workflows and who reviews enrichment output. Your platform team handles backups, upgrades and monitoring. Confirm these responsibilities in writing before work starts, since they determine how much of the operation stays with you after handover.
Can our own team run OpenCTI with Recorded Future without outside help?
A team with container, search engine and message queue experience can deploy OpenCTI from the documentation, but the work is more than installation. Ongoing tasks include tracking LTS and regular releases, since OpenCTI LTS releases require a specific license key and receive only critical bug and security fixes after stabilization, plus updating connectors and keeping backups tested. Assess whether your staff can own those tasks for the life of the deployment. Support, upgrades and continuous testing can also be covered by a retainer.
What should I ask for in a fixed-scope quote for this work?
Ask for a written scope that names the Recorded Future connectors and data types in use, the target infrastructure, the Enterprise or Community Edition decision, and the handover documentation. Require separate line items for deployment, connector configuration, token handling, testing, backup setup and training. Ask which items are one-time and which recur, such as retainers, upgrades and connector maintenance. Confirm the acceptance criteria, the list of deliverables and what happens to the work if the Recorded Future subscription changes.
Where the work ends and your team takes over
Your team keeps the Recorded Future subscription, the analyst decisions and the API token. The contract, the feed entitlements and the portal account stay with your organization, so the connector only ever acts on data your subscription already allows you to pull. Whoever holds the token should be named in writing, and the token should be stored in your own secrets tooling rather than in connector configuration files that engineers can copy. Decisions about what becomes a detection, what gets blocked and what is escalated to an incident also stay with your analysts, because no connector makes those calls.
DeployOpen plans, deploys, hardens, documents and supports the OpenCTI platform and its connectors inside your infrastructure, under a written fixed scope that names the components, environments, roles and deliverables before work starts. In practice that covers the platform, its Elasticsearch or OpenSearch, Redis, RabbitMQ and object storage dependencies, the Recorded Future connectors, access controls and backup design. Before signing, ask for the exact list of connectors in scope, who performs token rotation, and which handover documents you receive.
Upgrades and ongoing operation are a separate decision. OpenCTI releases arrive as regular builds and as LTS lines that require a specific license key, so ask whether your scope includes applying them and who holds that key. Ongoing support, upgrades and continuous testing are available as retainers, which are priced separately from the initial implementation. Confirm the response expectations in the retainer itself, since none are assumed here, and plan an internal owner for the platform for the periods between engagements.
How DeployOpen deploys OpenCTI under your data constraints
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Recorded Future feed flowing into OpenCTI, that means agreeing in writing which data leaves the Recorded Future portal, where API tokens are stored and rotated, and where the OpenCTI platform and its dependencies run.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which Recorded Future data types feed OpenCTI and which stay in the Recorded Future portal.
- We confirm your Recorded Future entitlements and whether the Enrichment and Recorded Future connectors fit your subscription terms.
How we build
- We deploy the OpenCTI platform with its Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage dependencies in your environment.
- API tokens are stored in your chosen secrets handling, with access limited to the connector services that need them.
- We test connector imports, enrichment behavior and access controls, including single sign-on, before anything goes live.
How we hand over
- You receive architecture, configuration and connector runbooks written for your own operations staff.
- Documentation records the Community or Enterprise Edition choice, the LTS or regular release track and the license key requirements.
- We walk your team through token rotation, connector upgrades and what remains in the Recorded Future portal.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Upgrades follow the OpenCTI release or LTS cadence you choose, tested in a staging copy first.
- Security testing of the OpenCTI deployment and its connectors can be scoped as a separate engagement.
