How to export your data from Recorded Future before the contract ends
If your team faces a renewal, a pricing change or a decision to leave, the first question is what you can take with you. Recorded Future documents API-based exports of domain risk lists and STIX or TAXII collections, and those files can be loaded into self-hosted OpenCTI or MISP. The platform's own analyst reporting, its proprietary collection and the enrichment that happens inside the portal are not part of those exports. Plan on keeping a record of what you export, but do not expect the reasoning behind a score to travel with the data in the same form.
The domain risk list endpoint, /domain/risklist, returns CSV by default and can also return STIX 1.1.1, STIX 1.2 or STIX 2.1, optionally gzip compressed. Requests authenticate with an X-RFToken header, so confirm which API token your contract grants, whether it covers bulk export, and how long your access continues after notice. Each CSV row carries the domain, a risk score from 0 to 99, the ratio of triggered rules and JSON evidence for each triggered rule. Ask Recorded Future to confirm, in writing, the export rights, retention terms and any rate limits that apply to your plan, since these vary by contract. The Recorded Future domain risk list reference is the starting point for the parameters your engineers will use.
For STIX content, Recorded Future offers TAXII 1.x named collections and TAXII 2.1 API roots, and it documents a dedicated opencti API root that flattens nested structures and caps collections at 1,000 objects. Collections are generated live at request time, so run exports in a window that avoids peak load, and reduce page size with the limit parameter for collections larger than 100,000 records. Sequence the work: export the risk lists and collections first, load them into a test OpenCTI or MISP instance, verify counts and sample records, then cut over before the access ends. The TAXII collections reference explains the endpoints you will need to test.
Which Recorded Future data you can export and how
This table lists each documented way to pull Recorded Future data out, the format it arrives in, and what limits apply. Read it as a menu: pick the path that matches your target platform, then check the row notes for the constraints that will shape your import job.
| Export path | Format and authentication | Limits and behavior | Best fit |
|---|---|---|---|
| Domain risk list (/domain/risklist) | CSV/Splunk by default; STIX 1.1.1, STIX 1.2 or STIX 2.1 on request; optional gzip; X-RFToken header | Returns domain risk scores; CSV is the default format and the simplest to parse | Bulk domain blocklists and scoring for SIEM or firewall loads |
| CSV row fields | Domain, risk score (0 to 99), ratio of triggered rules, JSON-encoded evidence per triggered rule | Evidence is a JSON string inside a CSV cell, so parsers must handle nested quoting | Mapping risk scores to MISP attributes or OpenCTI indicator scores |
| STIX 2.1 and STIX 1.x downloads | STIX content from the risk list endpoint in the formats above | STIX 1.x is older and less expressive; STIX 2.1 aligns better with OpenCTI's STIX 2 schema | Loading structured objects into OpenCTI; STIX 1 when the importer requires it |
| TAXII 1.x named collections | STIX content served over TAXII 1.x named collections | Collections are generated live at request time, so results can change between pulls | Legacy pull clients that only speak TAXII 1.x |
| TAXII 2.1 API roots | STIX content over TAXII 2.1 API roots | Use the limit parameter to reduce page size for collections over 100,000 records | Scheduled pulls into MISP or OpenCTI connectors |
| Dedicated opencti API root | TAXII 2.1 root built for OpenCTI | Flattens nested structures and caps each collection at 1,000 objects, so expect many paged requests | OpenCTI ingestion where nested objects would otherwise fail to import |
| What is not in these exports | Portal-only analyst reports, collection methods and proprietary context | Confirm with Recorded Future which fields and historical data each path includes and whether your contract permits storing them after the subscription ends | Scoping what must be rebuilt or sourced elsewhere |
What stays behind when you leave Recorded Future
The documented interfaces move indicators and risk scores, but much of what makes a Recorded Future subscription useful is produced inside its portal or only exists at query time. Each card below names one category that the exports do not hand over, a workable path for it, and what to confirm with Recorded Future in writing before you cancel.
Analyst-written reports
Finished intelligence reports, finished-intelligence write-ups and analyst assessments are authored and stored in the Recorded Future portal. The risk list CSV and STIX collections carry objects and scores, not the narrative that explains them. Plan to re-write the reports you still rely on as internal reports in OpenCTI reports or MISP events, and archive PDFs or copies you are licensed to keep. Ask Recorded Future in writing what rights you hold to retained report content after termination.
Proprietary collection and sources
Recorded Future's own collection, including sources it gathers and processes internally, does not leave with your data. Exports only reflect what it has already published into risk lists or TAXII collections. Expect the coverage of open feeds in MISP or OpenCTI to differ. Map the sources behind your highest-value indicators, then decide whether a commercial feed or community feed replaces each one. Confirm with Recorded Future which collection content may be stored outside its service.
Portal saved searches and alerts
Saved searches, alert rules, watchlists and notification routing live in the portal configuration. A CSV export contains results, not the queries that produced them. Export each saved query as text, record its purpose and owner, and rebuild the important ones as MISP warning lists, OpenCTI feeds or SIEM rules. Also record which alerts go to which teams, since that routing is lost when the subscription ends.
Live enrichment and lookups
Context such as the current risk score, the rules triggered now, and the evidence behind a lookup is computed when you query. A stored export is a snapshot from one moment. When you move enrichment to a connector or a local feed, the scores will reflect the export time, not today. Decide which workflows need live lookups, keep a read-only or pay-per-query arrangement for them if you can, and confirm the terms for querying after cancellation.
Users, roles and audit history
Portal accounts, role assignments, activity logs and access history are kept by the Recorded Future tenant and are not part of the intelligence export. OpenCTI and MISP each need their own accounts, group mapping and logging from day one. Export a list of who used the service and in which team, then recreate that access model through your identity provider. Ask Recorded Future what usage records it will provide for your audit file.
The export sequence and how to verify each step
This sequence moves Recorded Future data into a staging OpenCTI or MISP instance in an order that lets you check each stage before the next one starts. Each step ends with a check you can record, so you know what was exported, what arrived and whether it still matches the source.
Inventory every feed and API root in use
Before any export, list each Recorded Future product you pay for and each integration that reads from it: domain risk lists, TAXII 1.x named collections, TAXII 2.1 API roots, and any dedicated opencti root. Record which team owns each feed, which downstream systems consume it and how often. The output is a written inventory that becomes your checklist, and it is done when every consumer has been matched to a feed or marked as retired.
Request a token and confirm its scope
Ask your Recorded Future administrator for an API token that authenticates with the X-RFToken header, and confirm with the vendor which entitlements that token carries. Store the token in a secrets manager rather than in scripts or shell history. Verify the token by making a single read-only request to a small endpoint and checking for a successful response with the expected data. Record the token's owner, creation date and the entitlements you confirmed.
Pull a STIX 2.1 risk list and a CSV sample
Request the domain risk list from the /domain/risklist endpoint in STIX 2.1 format, and separately pull a CSV sample, which is the default format. The CSV rows carry the domain, a risk score from 0 to 99, the ratio of triggered rules and JSON-encoded evidence for each rule. Confirm that the row count is plausible, spot-check several domains against the portal, and check that the evidence field parses as JSON. Compute a checksum for each file and record it with the export date and API version.
Page through a TAXII collection with limit
Request a TAXII collection through the appropriate API root and set the limit parameter to control page size. Recorded Future advises reducing page size for collections over 100,000 records, and generates collections live at request time, so two requests can differ. Walk every page, keep the page count and object count, and compare the total with the count the collection reports. Store each page with its checksum so a failed run can resume without re-pulling earlier pages.
Land the data in a staging instance
Load the exported STIX bundles into a staging OpenCTI or MISP instance that is not connected to production consumers. For OpenCTI, the dedicated opencti TAXII root flattens nested structures and caps collections at 1,000 objects, so expect more pages and check counts per page. Confirm that object totals match the exported totals, that relationships resolved, and that a sample of scores and evidence fields matches the source records. Keep the import logs as evidence of the load.
Document the run and confirm the baseline
Write a short run record that lists the export date, the API version used, the endpoints called, the token owner, file checksums, object counts and any rows that failed validation. Have a second person repeat one sample export and compare checksums or counts to confirm the process is repeatable. The run is complete when the record is stored with the exported files and a named owner has signed off on it.
How to land the exported data in OpenCTI or MISP
Start by matching each export format to the platform that will read it, because the path into OpenCTI and the path into MISP are different. The opencti TAXII API root is the Recorded Future collection designed for OpenCTI ingestion. It flattens nested structures and caps each collection at 1,000 objects, so the load is paged rather than bulk. OpenCTI structures its data on the STIX 2 knowledge schema and exposes a GraphQL API, so the imported objects become indicators, observables and relationships that you can query through the web application or the API. Confirm in the OpenCTI documentation for your chosen version how the STIX 2.1 objects from the risk list and collections are mapped to its entity types, and whether any Recorded Future fields are dropped or stored as custom properties.
MISP takes a different route. It accepts STIX 1 and 2, CSV and its own MISP JSON through its import tooling, and the REST API and the bundled PyMISP library can create events and attributes programmatically. Domain risk lists in CSV carry the risk score and the JSON-encoded evidence in separate columns, so decide early whether the score becomes a tag, a comment or part of an attribute and whether the evidence is kept at all. Before any full load, pull a small sample, import it into a non-production instance, and check that domains, scores, timestamps and distribution settings arrive as you expect. Repeat the test for each format and each platform version you run, since import behavior can change between releases.
Plan the full load as a repeatable job, not a one-time import. Record which collection, format and date range each batch came from, so you can re-run or roll back a batch that loaded incorrectly. Keep the Recorded Future API token in your secrets store, and confirm the request limits and page size guidance in the Recorded Future API documentation before you schedule recurring pulls. Decide who reviews imported objects before they reach downstream blocklists, because a load that looks complete can still contain stale or mis-scored indicators. Your sample results and import logs are the evidence you will need if the migration is reviewed later.
What to plan before the renewal or termination date
Most of the risk in leaving Recorded Future sits in the weeks before the contract ends, not after. The cards below cover the decisions to settle, the order to settle them in, and what the contract, rather than this guide, will tell you about notice and retention.
Confirm data rights in writing
Ask Recorded Future, in writing, what you may keep after termination, including exported risk lists, STIX objects pulled through TAXII, and any derived data stored in your SIEM or blocklists. Ask how long they retain your query logs and API usage records, and whether deletion requests are confirmed in writing. Check whether internal sharing with partners or ISAC members is permitted. The answers decide what you can carry into MISP or OpenCTI and what must be purged.
Schedule the final full export
Run the last full pull while API access is still active. Domain risk lists are available in CSV, STIX 1.1.1, STIX 1.2 and STIX 2.1, and TAXII collections are generated at request time, so a large collection may need several paged requests. Record the export date, format, row counts and checksums for each file. Keep the export on your own storage and confirm it opens in the target platform before access ends.
Decide on a reduced subscription
Decide whether you need any Recorded Future access after cutover, such as enrichment lookups for analysts or a narrower feed for a specific sector. Ask the vendor for a quote covering a reduced tier, the API call allowance it includes, and whether it can run alongside self-hosted platforms. Also confirm whether the contract allows a short overlap period for parallel running. If you decide to drop the subscription entirely, plan the enrichment gap explicitly.
Set up hosting for the new platform
Provision the target platform before the export is needed. OpenCTI requires Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage such as MinIO, plus platform and worker nodes sized to the documented minimums. MISP runs on Ubuntu 24.04 with the provided installer or as Docker images. Choose the release line deliberately: OpenCTI LTS releases need a specific license key, and MISP 2.4 is end of life. Test restores before go-live.
Retire integrations in order
Remove dependencies in a defined sequence. First repoint consumers to the new source, such as SIEM correlation rules or firewall blocklists fed from MISP or OpenCTI exports. Then confirm those feeds have run cleanly for a full cycle. Only after that, disable the Recorded Future connectors and revoke the X-RFToken API keys. Remove stored tokens from scripts, secrets managers and CI variables, and record each step in your change log.
Read the contract for notice dates
Notice periods, auto-renewal windows, data return obligations and deletion timelines are set by your agreement with Recorded Future, not by this guide. Locate the notice clause and calculate the deadline with your legal and procurement teams, allowing time for written correspondence. Confirm which party bears responsibility for data handling after termination and whether a certificate of deletion is provided on request.
What drives the effort of an export
The effort of an export comes from three cost components: staff time, infrastructure, and connector upkeep. Staff time is the largest and least visible item. Someone has to inventory which Recorded Future outputs you actually use (domain risk lists, TAXII collections, or both), decide which fields map to which OpenCTI or MISP objects, and build and test the pipeline that moves them. That work is largely one-time, but it is paid for in people, whether your own engineers or an implementation partner working to a written scope. Ask any quote to separate build effort from the ongoing run effort.
Infrastructure is the second component, and the documented OpenCTI baseline is the place to start sizing. The deployment overview lists 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, with the platform needing 2 cores and at least 8 GB RAM, the search tier 2 cores, 8 GB RAM and 16 GB SSD, and at least one platform node for every 3 workers. Those figures are minimums for planning, not a capacity guarantee. MISP has a different footprint built on PHP, MySQL or MariaDB and Redis, and its install options and current release should be confirmed against the MISP download page before you size hosts.
Connector upkeep is the recurring component. Each Recorded Future output you pull, and each OpenCTI connector you run, needs monitoring, token rotation, version alignment with the platform, and a check after each upgrade. OpenCTI's non-LTS releases ship from daily to weekly, while LTS releases need a specific license key and receive only critical and security fixes after stabilization, so the upkeep schedule depends on which track you choose. The three main drivers are data volume, the number of feeds, and the amount of custom mapping. Higher volume raises search and storage needs, more feeds multiply connector work, and heavy mapping increases both build time and the cost of every later change. Ask vendors and partners to price these three drivers separately.
Questions teams ask before exporting from Recorded Future
Can we export our Recorded Future data in-house without a partner?
Yes, most teams can pull the data themselves, because the export runs through documented interfaces. Recorded Future's Connect API serves domain risk lists from the /domain/risklist endpoint in CSV, STIX 1.1.1, STIX 1.2 or STIX 2.1 format, authenticated with an X-RFToken header. TAXII collections are available as well. The harder part is not the download but the mapping: deciding which fields become MISP attributes or OpenCTI observables, how scores and rule ratios are kept, and how the load is scheduled. Teams with a security engineer who knows the API, a Linux host and a clear data owner can do this in-house. Teams without those skills often bring in help for the mapping and the loader.
How much staff effort does an export need, and what drives it?
Effort depends on how many data types you export and how much mapping they need. A single domain risk list is simpler than a set of TAXII collections covering several object types. The main drivers are: the number of Recorded Future data sets in scope, the target platform (MISP or OpenCTI each have their own data model), the amount of deduplication and enrichment you want on load, the number of consumers downstream such as SIEM or firewall blocklists, and whether you need repeatable scheduled runs or a one-time archive. Ask any provider for a written breakdown by data set, target platform and recurring run, and ask which parts are one-time build work and which are ongoing upkeep.
How long does the export take, and what sets the timeline?
No duration can be stated here without your environment and scope. The timeline is set by the size of the collections, the number of data sets, the target platform setup and the time needed for review. Recorded Future's documentation notes that TAXII collections are generated live at request time and recommends reducing page size with the limit parameter for collections over 100,000 records, so large pulls need careful pacing. An OpenCTI deployment also has its own dependencies, including Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, and those must be ready before data lands. Ask for a timeline tied to named milestones in the written scope.
What does the work need from our team?
The export needs three things from your side. First, a named owner for the Recorded Future API token, since the token ties every pull to a subscription and must be stored in a secrets manager rather than in scripts. Second, a host or cluster for the target platform, whether MISP, which can be installed on Ubuntu 24.04 with the provided installer or deployed with Docker, or OpenCTI, which needs its own set of services and sizing. Third, a data owner who signs off on which intelligence may be copied, retained and shared, because some Recorded Future content carries licensing terms that govern redistribution. Confirm those terms against your agreement before loading data into a sharing community.
Is a partner worth bringing in, and what does a fixed-scope engagement cover?
A partner is worth considering when the export has to be repeatable, audited or tied to a renewal date, or when the team lacks capacity. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A typical written scope for this work should list the data sets to export, the target platform and version, the mapping rules, the scheduled jobs, the handover documentation and any ongoing support as a separate retainer. DeployOpen does not publish a price list, so ask for a quote that follows from that written scope.
Does exported data keep its risk scores and evidence?
It depends on the format you choose. The CSV format of a domain risk list carries each domain, a risk score from 0 to 99, the ratio of triggered rules and JSON-encoded evidence for every triggered risk rule. STIX exports carry the intelligence in a standard structure, but how a platform stores scores and evidence varies. OpenCTI structures data on the STIX 2 standard, and MISP supports STIX 1 and 2 as well as its own JSON format. Recorded Future also documents a dedicated opencti TAXII API root that flattens nested structures and caps collections at 1,000 objects, which can change what arrives. Test a sample of each format on a non-production instance and compare score and evidence fields field by field before relying on them.
Can we keep the exported data after the subscription ends?
Data you have already copied into your own platform remains in your platform, but the licensing terms of the source govern whether you may keep, use and share it after the subscription ends. Check the agreement with Recorded Future before you archive or redistribute content, and ask your legal or procurement team to confirm the position in writing. Also confirm which fields come along in each format, since live enrichment, portal-only views and API access stop when the subscription does. Plan the archive so that the record of what was exported, when and from which endpoint is kept as part of your evidence trail.
How to confirm the export is complete and defensible
Treat the export as evidence from the first pull, not as a file copy. Record the exact endpoints you called, such as the /domain/risklist endpoint of the Connect API or the TAXII collections and API roots you read, along with the output format (CSV, STIX 1.1.1, STIX 1.2 or STIX 2.1), every query parameter, including the limit value used for large collections, whether gzip compression was requested, and the date and time of each request. Store the API token under your secrets management policy and log its owner and rotation date, but never write the token itself into the export record. The recorded parameters are what an auditor or internal risk owner will compare against the subscription terms and the scope you agreed.
Reconcile counts before you accept any import. For each collection, compare the number of records or objects the source returned with the number the import created in OpenCTI or MISP, and explain every difference, such as duplicates merged on import, rows rejected by the parser, or objects the platform does not map. Note that Recorded Future's opencti TAXII root flattens nested structures and caps collections at 1,000 objects, so a count that stops at that ceiling is a paging problem, not a complete export. Generate SHA-256 checksums for every file at the moment it lands, and record them in the same log as the request parameters. Ask your team to confirm that the checksum tool and the hashing method meet your own policy.
Retain the raw source files, not only the imported data, for the period your retention policy sets for threat intelligence and security records. Keep the request log, checksums, reconciliation sheets and a short note on who ran each pull and who approved it. Several of these records may contain third-party data, so confirm with your legal or contract owner that the Recorded Future license permits you to store the exported content after the subscription ends. DeployOpen can prepare this evidence set and map it to the controls your assessment covers, but DeployOpen does not issue audit reports or attestations. Independent auditors decide whether your evidence is adequate for their purposes.
How DeployOpen scopes and delivers a Recorded Future exit
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a Recorded Future export, that means agreeing in writing which risk lists, TAXII collections and retention needs move, then building the landing path into OpenCTI or MISP in your environment.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which domain risk lists, STIX collections and output formats are in the export.
- We confirm which Recorded Future API tokens, endpoints and TAXII roots your team holds and can use.
- The scope names the target platform, OpenCTI or MISP, and the hosting environment, including any air-gapped segment.
How we build
- We set up the ingestion path into OpenCTI or MISP inside your cloud accounts, data centers or air-gapped network.
- Pipelines are tested against sample exports so field mapping and row counts can be checked before cutover.
- Connectors, credentials and API token handling are configured so secrets stay under your access controls.
- Hardening, backup and sharing-group settings are implemented as agreed in the written scope.
How we hand over
- Deliverables include documentation of each export job, its schedule, source endpoint and destination.
- Your team receives a record of what was exported, what was not, and the known gaps versus live Recorded Future enrichment.
- We document restore steps and the runbook for re-running exports if an export fails or is incomplete.
- Handover includes a checklist for what remains in the Recorded Future portal after the subscription ends.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover connector updates and platform upgrades, including checks against OpenCTI or MISP release notes.
- Compliance readiness work, where needed, prepares systems and evidence; independent auditors issue any assessment outcome.
- Ask us to confirm support terms, response expectations and retainer scope in the written quote.
