Migrate from Recorded Future to MISP

Migrate from Recorded Future to MISP: what the move involves

If your renewal, licensing change, residency requirement or lock-in concern is pushing you toward self-hosting, the first thing to settle is scope. MISP replaces the platform that stores, correlates and shares indicators, not Recorded Future's own collection. Recorded Future's analysts, proprietary sensors and finished reporting do not move into MISP, so the migration is about where your indicators live, how they are matched against your telemetry, and how you exchange them with peers. Decide early which Recorded Future outputs you actually consume (risk lists, API enrichment, reports, alerts) and which of those you will replace with open feeds, keep as a commercial feed, or stop using. The work is usually led by security engineering, with threat intelligence analysts defining the indicator workflow and a platform team owning the hosting. Many organizations bring in an implementation partner for the initial build, hardening and integration with SIEM and firewall blocklists, while keeping curation and sharing decisions in-house. Your own team will need to confirm the supported install path for the MISP release you select, since the project's download page recommends a specific Ubuntu release and lists Docker, RPM, Ansible and Puppet options, and the current release notes should be checked before you commit to one.

For effort and risk, the honest short answer is that the platform installation is the smaller part. The larger effort is rebuilding the feed and tagging model: deciding how Recorded Future risk scores map to MISP attributes, which warning lists and taxonomies you enable, and who reviews indicators before they reach blocking controls. Plan a parallel run in which both sources feed your detections, then compare false positive rates and coverage before you switch enforcement. The main risks are blocking on stale or unvetted indicators, losing confidence scores and context that analysts relied on, and underestimating the ongoing analyst time needed to curate community and open feeds. Ask any implementation partner for a written scope that names the feeds, integrations, data mappings and acceptance tests, and confirm your own retention and sharing obligations before any indicators leave your environment.

Which Recorded Future capabilities map to MISP, and which need rework

This table maps the main Recorded Future capabilities that a migration to MISP would touch. Read each row as a fit check: clean means MISP covers the need with built-in features, needs rework means the output requires mapping, scripting or process change, and gap means MISP does not provide it. Proprietary collection and analyst reporting remain gaps, so plan how to cover them before ending the subscription.

Capability	MISP equivalent	Status
Indicator storage	Events and attributes with type, value, tags, comments and distribution level	Clean
Risk list ingestion	CSV or STIX risk lists load through import or custom feeds, but risk scores and fields need mapping to MISP attribute types and tags	Needs rework
Correlation	Exact matches plus advanced patterns, including fuzzy hashes and CIDR overlaps, with granular controls	Clean
Sharing with partners	Distribution levels, sharing groups and instance synchronization, down to individual attributes; partners need MISP or STIX exports	Clean
STIX and CSV export	STIX 1 and 2, MISP JSON and CSV exports are built in; confirm field mapping with each consumer	Clean
API access	REST API described in OpenAPI, restSearch and the PyMISP library; token and automation design is your responsibility	Clean
SIEM and firewall outputs	Suricata, Snort, Zeek, RPZ and text exports exist, but SIEM pushes and firewall blocklists need scripts or connectors	Needs rework
Proprietary collection	MISP does not replace Recorded Future's own collection; it brings community and default feeds instead	Gap
Analyst reporting	MISP does not provide finished intelligence reports; teams need another tool or process for analyst write-ups	Gap

What data moves out of Recorded Future and what to rebuild

Recorded Future data leaves through a small set of documented paths: risk list downloads in CSV and STIX, and TAXII collections. Each path lands indicators in MISP as events and attributes, but the rules, pushes and agreements around that data do not come with it. The cards below separate what can be exported from what has to be rebuilt in your own environment.

Risk list downloads in CSV and STIX

Risk lists are the simplest export: a point-in-time set of indicators such as IP addresses, domains, URLs and hashes, with risk scores attached. Export them in CSV or STIX and import into MISP as an event, with each indicator as an attribute and the source recorded in the event info field. Check which fields your export includes, especially risk scores and first-seen dates, because MISP needs them mapped to attribute comments or tags to remain useful. Confirm the export format and any row limits with your Recorded Future account team before you plan the cadence.

TAXII collections as a feed

TAXII collections deliver STIX objects on a repeating schedule rather than as a one-off file. Map each collection to a MISP feed or a scripted pull through the MISP REST API, then decide whether objects are imported as events or kept as a separate pool for correlation. Ask which collections your subscription includes, how often they update, and whether deleted or revoked objects are signaled, since stale indicators left in MISP will keep generating matches.

Event and attribute structure

Recorded Future indicators carry context such as associated actors, malware families and evidence links that a flat export may not preserve. Plan how that context becomes MISP tags, galaxies or object relationships, and decide which fields are worth keeping. Document the mapping once so analysts can tell which attributes came from Recorded Future and which came from community feeds. Keep the original source identifiers so you can trace any indicator back to its origin when a sharing partner asks.

Alert rules and analyst workflows

Alert rules, saved searches and watchlists inside the Recorded Future portal do not move. Rebuild the equivalent as MISP warning lists, correlation views and scheduled searches using the restSearch API, and assign ownership for each rule. Expect the rebuilt rules to differ in precision, so run both in parallel for a period and compare hit rates before retiring the old alerts. Confirm which alert types your team actually relies on before you rebuild them.

SIEM and firewall pushes

Integrations that push Recorded Future indicators into a SIEM, firewall or proxy blocklist are configured on the consumer side and must be repointed. MISP can export Suricata, Snort, Zeek and RPZ formats, and its REST API can feed custom blocklist generators. Test each downstream system with a known indicator, confirm expiry and removal handling, and record who approves changes to blocking policy. Blocklists that are not pruned will accumulate stale entries.

API consumers and sharing agreements

Scripts, dashboards and partner arrangements that call the Recorded Future API or receive its data depend on credentials and terms tied to your subscription. Inventory every consumer, then rebuild each against MISP's API key model and sharing groups. Review data-use terms for any shared intelligence before it goes to peers, since those terms belong to the subscription, not to the data itself. Ask legal or procurement to confirm what you may still share after the subscription ends.

How the migration runs in five steps

The sequence moves indicator handling from Recorded Future to MISP in controlled stages, so every consumer is mapped, the new platform is proven on a bounded data set, and the old feed is retired only after the new one has matched it. Each step ends with a named output that the next step depends on.

Inventory indicators, sources and consumers
Your team lists every Recorded Future input in use: risk list downloads, TAXII collections, API queries and alerts. For each one, record the indicator types, the update cadence and the owner. Then list every consumer that acts on that data, such as the SIEM, firewall blocklists, EDR, ticketing and any partner you share with. The output is a source and consumer register that names what each consumer depends on. The step is done when the security lead and the platform owner have both signed off on the register and no consumer is unassigned.
Build a pilot MISP instance
DeployOpen or your internal platform team installs MISP 2.5 on Ubuntu 24.04 using the project's provided installer, which the MISP download page recommends for MISP 2.5. Docker images, Ansible roles and RPM packages are alternatives if they match your standards. Load a bounded data set from the register, such as one risk list and one TAXII collection, and confirm that correlation, distribution levels and the REST API behave as expected. The output is a pilot instance with documented configuration, authentication settings and a tested import path. Confirm the authentication method with your identity team before any analyst account is created.
Run the parallel feed comparison
Keep Recorded Future fully live while MISP ingests the same bounded sources. Compare the indicators each platform holds for the same period, and record gaps, duplicates and format differences, including any loss in confidence, expiry or context fields during import. Export a sample from MISP into the formats your consumers need, such as CSV blocklists or Suricata rules, and check them against the live Recorded Future output. The output is a written comparison report with a list of accepted differences and a list of defects to fix. Do not cut over until the report is reviewed and each defect has an owner.
Cut over consumers to MISP exports
Move one consumer at a time from Recorded Future to MISP-fed output. Typical targets are SIEM lookup tables, firewall or proxy blocklists and EDR watchlists, each updated by a scheduled export or API pull from MISP. Keep the Recorded Future path available as a documented fallback for each consumer until its cutover has run cleanly for an agreed period that you set. The output is a cutover log for each consumer showing the date, the change, the test performed and the rollback path. Confirm that every blocklist change still passes through your existing change control.
Decommission the Recorded Future integrations
Once every consumer runs on MISP output and the fallback is no longer needed, remove the Recorded Future API tokens, scheduled downloads and TAXII subscriptions that are no longer used. Revoke service accounts, update the register and archive exported data according to your retention policy. If you keep any commercial feed, record it as a separate, named source with its own owner. The output is a closed integration inventory and a decommission record that auditors and your contract team can review. Confirm the subscription end date and any data return or deletion terms with Mastercard's Recorded Future team before you stop access.

How to build the MISP instance so it can hold and share indicators

Start by choosing the release line, because it decides everything else. Deploy MISP 2.5 for any new instance. The project lists 2.5 as the recommended version for new deployments and states that 2.4 is end of life with security fixes only, so the project strongly advises against installing new 2.4 instances. Check the current 2.5 point release on the MISP download page before you build, since the project's release history moves quickly (the project website lists 2.5.47, released September 17, 2026, as the latest release at the time of research, and it introduced a new database migration system with PostgreSQL support). The download page recommends Ubuntu 24.04 with the provided installer. Docker images, RPM packages, an Ansible role and a Puppet module are the other documented routes, and your team's configuration management standard should pick one. Confirm with your platform team whether PostgreSQL is an approved database for your environment, because the default stack is still PHP with CakePHP, MySQL or MariaDB, and Redis, and changing the database engine later is a migration project of its own.

Sharing controls are set up before the first import, not after. Taxonomies and galaxies ship under licenses separate from the AGPL software license: the download page notes CC0 1.0 Universal or the 2-clause BSD license for that data, so have your legal team record that position for your internal documentation. Enable the taxonomies your analysts will use for tagging, such as TLP markings, and review the galaxies covering threat actors, malware, ransomware, tools and MITRE ATT&CK, since they shape how indicators are classified and searched. Next, define sharing groups and distribution levels for each internal team and each external partner. Distribution levels and sharing groups can be applied down to individual attributes, so decide the default distribution for imported Recorded Future data now, because a permissive default leaks intelligence you are not licensed to redistribute. Finally, document who may create sharing groups and who approves a new synchronization partner, and confirm with your legal and contract owners whether any Recorded Future terms restrict redistribution of exported risk list data before you enable any sync.

How the migration changes by team size and starting point

A SOC that mainly pulls indicators from Recorded Future into a SIEM or firewall usually has a small, one-directional workflow. The main work is to stand up a MISP instance that holds the indicators, decides which ones are actionable, and exports them to the detection stack. Sharing is often limited, so the instance can start with a single administrator group and no synchronization partners.

Fewer integrations: Expect a handful of consumers, such as a SIEM, a firewall blocklist and a ticketing tool, rather than a web of partner connections.
Export focus: Plan around MISP exports for Suricata, Snort, Zeek, CSV and RPZ, depending on which enforcement points you run.
Feed replacement: Identify which open or community feeds cover the indicator types you actually block, and measure the gap before cutting the subscription.
Lower sharing risk: With no outbound sharing, you can defer decisions on distribution levels and sharing groups until later.
Analyst curation: The most time-consuming work is usually tuning false positives, not the platform itself.

Before you cut over, confirm with your SIEM and firewall vendors which formats and import methods they accept, and run both sources in parallel for a defined period.

How to run both platforms in parallel and cut over safely

Agree the cutover criteria in writing before any MISP instance receives production data, and make them measurable. Compare the two systems on three measures: indicator counts by type and source, match rates against your own telemetry (the same sample of SIEM alerts and firewall hits run through both), and false positive handling, meaning how many indicators each side flags that analysts later reverse. Record the baseline from Recorded Future exports for the same window so that differences trace to a feed or a rule, not to a timing gap. Define who signs off each threshold, how long the comparison runs, and what happens if a measure misses. These are decisions for your security operations and threat intelligence leads, and a parallel run that has no written pass mark tends to end with an argument rather than a cutover.

Switch consumers in order of how easily they can be reversed. Start with read-only uses such as analyst enrichment and reporting, where a wrong answer costs time, then move SIEM correlation rules that alert but do not block, and only then move blocklists that push to firewalls or DNS resolvers. Keep MISP's export paths in mind here: the Suricata, Snort, Zeek and RPZ formats cover the sensor and resolver consumers, and the restSearch API with PyMISP covers scripted pulls, so confirm each consumer's current input format and its owner before you change its source. Set the rollback point as the last known-good configuration of each consumer, including the Recorded Future connector or export job that it reads from, and keep that job disabled, not deleted, until the agreed observation window closes. Confirm with your Recorded Future account team how long the subscription and export access remain available during the overlap, since a rollback path that depends on a lapsed contract is not a rollback path.

What drives the cost and duration of this migration

This table breaks the migration from Recorded Future to MISP into cost components, showing who is paid for each, whether it is one-time or recurring, and what drives it up. Use it to build a quote request, since the MISP software itself carries no license fee under AGPL-3.0, so most of the spend is in people, infrastructure and feed curation.

Cost component	Who is paid, and for what	One-time or recurring	What drives it, and what to ask for in a quote
Discovery	Internal team or implementation partner maps current Recorded Future use: risk lists, API consumers, TAXII collections and alert routing	One-time	Number of integrations and downstream consumers. Ask for a written inventory deliverable and a list of assumptions
MISP build and hardening	Partner or internal engineers install MISP 2.5 on your own servers, configure authentication and backups, and harden the host	One-time, with periodic reviews	Hosting model, HA requirements and authentication choice. Ask which MISP install method is proposed and how hardening is evidenced
Data mapping	Engineers map Recorded Future fields and indicator types to MISP attributes, objects, tags and sharing levels	One-time, plus changes when feeds change	Volume of indicator types and custom fields. Ask how mapping is tested and who signs off on it
SIEM and firewall integration	Engineers or SIEM and firewall vendor services connect MISP outputs to detection rules and blocklists	One-time, plus ongoing rule upkeep	Number of SIEM and firewall platforms and whether exports are automated. Ask for the export formats and push method
Analyst time to curate open feeds	Your analysts, or contracted analysts, select, tune and retire community and default feeds to replace Recorded Future coverage	Recurring	Feed count, false-positive rate and expected coverage gaps. Ask which feeds are in scope and how curation effort is tracked
Parallel run	Your analysts run both platforms side by side to compare alerts, detections and blocklist hits before cutover	One-time, but extends the Recorded Future subscription	Length of overlap and subscription terms. Confirm the notice period and whether the subscription can be shortened
Ongoing maintenance	Patching MISP, its database and dependencies, certificate and key rotation, sync partner management and backup testing	Recurring	Upgrade cadence, sync peers and staff capacity. Ask for a written support scope and response expectations
Infrastructure	Your cloud or data center costs for compute, storage, database, backups and network paths to SIEM and firewalls	Recurring	Indicator volume, retention period and redundancy. Ask the partner to size the environment from your data, not a template

What usually goes wrong in a Recorded Future to MISP migration

Most failed transitions do not fail on installation. They fail on assumptions about what MISP does, how data is mapped and shared, and who depends on the output. The cards below cover the risks we see most often and a concrete check for each, so the cutover plan addresses them before the subscription ends.

Assuming MISP replaces collection

MISP stores, correlates and shares indicators. It does not collect telemetry or produce Recorded Future's proprietary analyst reporting. Teams that cancel first and then discover missing coverage lose visibility during the gap. Before cutover, list every Recorded Future source your analysts use, and mark each one as replaced by a community or open feed, kept as a commercial feed, or accepted as lost. Confirm that decision in writing with the intelligence lead.

Losing context in attribute mapping

Risk list entries carry risk scores, evidence and timestamps that do not map one to one onto MISP attributes. When a CSV or STIX export is imported with default settings, confidence, first seen and last seen values can be dropped or flattened. Map each source field to a MISP attribute type, category and comment before bulk import, and sample a few hundred records to confirm the context survived the round trip.

Sharing groups set too broadly or narrowly

Distribution levels that are too open expose internal indicators to partners who should not see them. Settings that are too closed stop useful intelligence from reaching the consumers who need it. Define distribution and sharing groups before the first import, assign a default for imported data, and review which synchronization partners receive each group. Ask the sharing community or trusted partners to confirm what they will accept.

Unmaintained feed ingestion

Feeds that are enabled once and never checked fail quietly. Upstream URLs change, licences change, and pulls stop returning new data while the dashboard still shows old counts. Assign an owner to each feed, record its update cadence, and set an alert for feeds that have not produced new events within the expected window. Review feed health on a fixed schedule.

Stale or false positive blocklists

Exporting an indicator list to a firewall or SIEM without an expiry rule keeps retired infrastructure blocked and can disrupt legitimate services that share an IP address. Set decay or expiry on attributes, filter by confidence and to_ids flags before export, and exclude shared hosting ranges and known good domains. Run a sample of the blocklist against recent traffic logs before enabling enforcement.

Missing consumers at cutover

The MISP instance can be healthy while the SIEM rules, firewall policies, ticketing enrichments and analyst dashboards still point at the Recorded Future API. Inventory every system that reads Recorded Future output, including scheduled exports and automated enrichment, and assign each one a replacement and a test. Keep the old feed running in parallel until each consumer has been confirmed on the new source. Confirm the list with the platform and SOC owners before the subscription end date.

Questions buyers ask before moving from Recorded Future to MISP

What does it cost to move from Recorded Future to MISP?

MISP has no license fee, so the cost is the work and infrastructure around it. One-time costs include planning, building the instance, importing data, connecting SIEM and firewall outputs, and testing. Recurring costs include servers or cloud capacity, patching and upgrades, feed curation time for analysts, and any commercial feed you keep. Costs go up with the number of sources, sharing partners and blocklist targets. Ask any implementer for a quote built from a written scope, and ask your Recorded Future account team what export rights and renewal terms apply to the data you plan to move.

How long does a Recorded Future to MISP migration take?

No duration is fixed by the project, so the timeline depends on your scope. The main drivers are how many feeds and indicator sets you import, how many SIEM, firewall or sharing integrations you build, whether Recorded Future stays in parallel during transition, and how much validation your analysts need before blocklists go live. Run the cutover in stages: stand up MISP, import one source, verify correlation and exports, then add the rest. Ask for milestones and acceptance criteria in writing before work starts, and confirm the installer steps against the MISP download page.

What skills does our internal team need to run MISP?

Your team needs Linux administration for the server, familiarity with the MISP installer or a container or configuration-management deployment, and database and cache operations, since MISP runs on PHP with CakePHP, MySQL or MariaDB and Redis. Recent releases also add PostgreSQL support, so check which database your team will operate. Integration work needs someone comfortable with the REST API and PyMISP for scripting exports to SIEM and firewall tools. Analysts must own feed selection, tagging, and sharing-group decisions, which is an ongoing operational role.

Can we run the migration in-house without an implementation partner?

Yes, if your team has the skills listed above and time to build, test and document the platform. An in-house project is most likely to succeed when one owner controls the scope, the integrations and the acceptance tests. An implementation partner adds value when the team lacks that capacity or needs hardening, backup and documentation done to a defined standard. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure, usually under a fixed scope agreed in writing, with ongoing support available as a retainer. DeployOpen does not publish a price list.

Can MISP replace Recorded Future analyst reporting?

No. MISP stores, correlates and shares indicators, events and attributes, and it provides taxonomies, warning lists and galaxies covering threat actors, malware, ransomware, tools and MITRE ATT&CK. It does not produce the proprietary collection or finished analyst reports that a commercial intelligence service sells. Teams usually keep that capability in a commercial source, an internal analysis function, or a sharing community, and use MISP as the system where those outputs are recorded and distributed. Confirm the exact feature set with the MISP project before you plan reporting workflows.

Does the AGPL-3.0 license affect how we use MISP?

For most internal use, the AGPL-3.0 license does not require you to publish your own code, but the terms depend on how you use and change the software. MISP is licensed under the GNU AGPL version 3, and the AGPL adds obligations when you modify MISP and let users interact with the modified version over a network. Taxonomies and galaxy data carry separate licenses, CC0 1.0 Universal or the 2-clause BSD license. The MISP repository explains that interlocked contributor copyright prevents a single entity from changing the license model. Have your legal team review your deployment and any custom code before rollout.

How do we keep a commercial feed alongside MISP?

Keep the commercial feed as an input, and have MISP import it on a schedule so your correlation and blocklist outputs draw from one place. Typical options are a documented export such as CSV or STIX, a TAXII collection, or an API pull into MISP. Before you build the flow, check your contract for three points: whether you may store the data in your own infrastructure, whether you may share derived indicators with partners or sharing communities, and what happens to the data at renewal. Set a review date for each feed so that unused sources are removed rather than kept by default.

How DeployOpen scopes and runs a MISP migration

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For a move from Recorded Future to MISP, the work starts with a written scope that names the intelligence you hold, the systems that consume it and the sharing communities you need to reach.

How we scope

Inventory the Recorded Future feeds, risk lists and API or TAXII collections your teams actually use today.
Map which indicator types go to SIEM, firewall blocklists and sharing groups, and who owns each consumer.
Agree in writing which community and open feeds replace each commercial source, and which sources stay.

How we build

Deploy MISP in your cloud account, data center or air-gapped network, using the installer or packaging you approve.
Configure authentication, sharing groups and distribution levels to match your data handling and partner agreements.
Build import jobs for risk list exports or TAXII collections during transition, and test correlation against sample events.

How we hand over

Document the architecture, backup and restore steps, feed schedules and export paths to your SIEM and firewalls.
Test indicator push to SIEM and blocklists end to end, and record the results as evidence for your team.
Run a knowledge transfer with the operators who will maintain the instance, feeds and synchronization after handover.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Upgrades, feed maintenance and continuous testing are available as a retainer after handover.
Ask any provider to confirm the MISP release, database option and feed licenses they will deploy, and what they cover.

Migrate from Recorded Future to MISP