When teams publish OpenCTI feeds through TAXII, streams or CSV
A security team that curates intelligence in OpenCTI often has to share part of it with partners, sector groups or downstream tools, and the right export depends on who receives it and what they do with it. OpenCTI can publish intelligence through TAXII 2.1 collections, live streams and CSV feeds, and each of these outputs suits a different consumer. The exact capabilities of each output, and which license edition unlocks them, must be confirmed against the OpenCTI documentation for the version you run, because publishing features change between releases and between the Community and Enterprise Editions.
TAXII 2.1 collections are a pull model. A partner platform or a sector sharing service polls a collection and retrieves the STIX objects it is allowed to see, which suits organizations that already run TAXII clients. Live streams are aimed at consumers that need updates as they happen, such as a detection platform that should ingest new indicators within minutes of their creation. CSV feeds are the simplest option: a flat file that spreadsheets, scripts and lightweight firewall or proxy tools can read without STIX knowledge, at the cost of losing most of the relationships and context that STIX carries. Confirm for each option whether the consumer needs STIX objects, flat indicators or both.
Before you choose, list every consumer and record three things: the format it can parse, how often it must refresh, and whether it is inside or outside your trust boundary. Ask the OpenCTI documentation for your version how collections and streams are created, how filters are applied, and whether public access is available or restricted to authenticated consumers. Also confirm which of these publishing controls require the Enterprise Edition, since authentication strategies and several governance features are restricted to that license.
The rest of this page covers how each output is configured, how filters and visibility controls shape what leaves the platform, how public and authenticated access differ, and what to verify before you give a partner an endpoint. Work through the consumer list first, because it determines which outputs you need and which controls you must test.
Which output format fits each partner or tool
This table compares TAXII 2.1 collections, live streams and CSV feeds by who typically consumes them, how data reaches them, how filtering works and what the publisher must keep running. Read each row against the consumer's pull or push pattern, then confirm filter and field options in the documentation for your OpenCTI version before committing. The main takeaway is that the consumer's ingestion model, not the data itself, usually decides the format.
| Format | Typical consumer | How data reaches the consumer | Filtering approach | What the publisher must operate afterwards |
|---|---|---|---|---|
| TAXII 2.1 collection | A partner platform or threat intelligence tool that polls on its own schedule and keeps its own read position | The consumer requests objects from the collection over HTTPS, usually on a recurring poll | Filters are applied to the request, so the consumer narrows results per poll; confirm supported filter fields in your version's documentation | A reachable TAXII endpoint, access credentials per consumer, and monitoring of polling errors and response times |
| Live stream | A SIEM or tool that expects near-real-time delivery of new or changed intelligence | The platform publishes each matching change as it happens, and the consumer stays connected to receive it | Filters are defined on the stream itself, so the publisher decides what each stream carries; confirm the filter options available in your version | A persistent connection path through network controls, stream health checks, and handling of consumers that disconnect or fall behind |
| CSV feed | A team or tool that loads flat indicator lists into blocklists, spreadsheets or simple scripts | The consumer downloads a file that is regenerated on the publisher's schedule or on demand | Filtering is applied when the file is generated, so each feed reflects one fixed selection of fields and records | Scheduled generation, file hosting and access control, and a check that column layouts still match what consumers parse |
| Access model | Partners outside your organization versus internal tools that already hold accounts | External consumers need credentials or a granted path; internal tools usually reuse existing service access | Access and visibility rules decide what a consumer can see, regardless of the output format chosen | Credential issuance and rotation, visibility reviews as sharing agreements change, and records of who accessed what |
| Change handling | Consumers that must track updates, revocations and deletions reliably | Collections and streams carry changes as they occur, while a CSV file shows only the state at generation time | Deleted or revoked items need an explicit handling rule in each consumer, so test removal behavior with each one | A tested process for revoked indicators, plus clear communication to consumers about how removals appear |
| Operational effort | Teams weighing how much infrastructure a partner or internal tool expects the publisher to run | Polling collections place the load on consumer schedules, streams need persistent connections, and CSV feeds need scheduled jobs | Filter complexity adds testing effort for every format, since each consumer's selection must be checked separately | Uptime expectations, on-call coverage for streams, and capacity planning for the platform and its workers, sized against the deployment |
| Consumer verification | Teams that must confirm what a partner actually receives before sharing production data | Test with a non-production consumer that mirrors the partner's polling or connection pattern | Compare received object counts and fields against the agreed filter, using illustrative test cases | A repeatable test script for each consumer and a record of the agreed format, filters and fields |
How the OpenCTI platform, workers and connectors carry published intelligence
Every published feed depends on the path that gets intelligence into OpenCTI in the first place, so start by mapping the components. The documented deployment consists of three parts: the platform, which provides the web application and GraphQL API; Python workers that consume RabbitMQ messages to carry out asynchronous writes; and connectors, which handle import, enrichment, file extraction, export and stream consumption. The platform also depends on Elasticsearch or OpenSearch, Redis 7.1 or later, RabbitMQ 3.11 or later and S3-compatible storage such as MinIO. Your architecture review should name the host, cloud service or container that runs each of these and who operates it, because a feed inherits the availability of every part it depends on.
The harder question is which component serves or pushes each output. TAXII 2.1 collections, live streams and CSV feeds do not necessarily follow the same route, and the deployment overview describes connector categories rather than a single publishing path for each output. Before you commit to a design, confirm in the vendor documentation for your exact version whether a TAXII request is answered by the platform, whether a stream event is pushed by a connector or a platform process, and which component generates each CSV file and where it is written. Record the answer for each output. The decision you need to make is whether the publishing component sits inside the same access controls and gateway as the platform or runs as a separate service with its own credentials and network path.
A feed is only as current as the writes that feed it. Partners receive whatever the platform holds at the moment they request data, so a worker that stops consuming RabbitMQ messages delays every output without producing an error on the partner side. Watch three signals: queue depth in RabbitMQ, which shows writes waiting to be applied; the number of active worker consumers; and the time between a connector import and the object appearing in the outputs you publish. The documented sizing recommends at least one platform node for every three workers. Treat that as a starting point for capacity planning and validate it against your own volume. Alert on sustained queue growth, and on Elasticsearch or OpenSearch and Redis health, since both sit in the same write path.
Plan for the failure modes that stay quiet. A connector can run on schedule while importing nothing, a stream consumer can fall behind the live output, and a CSV export can be regenerated from stale data and still look valid. Define a freshness expectation for each feed and agree it with partners in writing before go-live. Then test it: add a known test indicator, record when it first appears in each output, and repeat the check after a worker restart and a RabbitMQ failover in a non-production environment. Keep a runbook that names the owner of each connector, worker pool and feed so that a backlog reaches the team able to clear it, and confirm version-specific behavior in the vendor documentation before you rely on it in production.
Setting up a TAXII feed and checking what partners receive
This sequence takes a sharing request from stated purpose to a verified feed. It ends with evidence that a test consumer receives the agreed objects, markings and organizations, and that withdrawn items stop appearing. Menu paths and field names vary by OpenCTI version, so check them against your deployed release before you start.
Define the sharing purpose and audience
Write down why the feed exists, who will consume it (for example, a partner's threat intelligence team or an internal detection tool), and what they will do with the data. Name one owner who approves scope changes. This step is done when the purpose, audience and owner are recorded in a short document that the data owner has approved in writing. Later scope decisions are tested against this document.
Decide the data scope and markings
Choose which object types may leave the platform, which marking definitions they must carry, and which author organizations are included. Map each marking to what the consumer is allowed to see. Check the in-scope objects for the markings you expect, because an unmarked object is easy to overlook. This step is done when the scope is a written list that you can compare against the feed output in the verification step.
Create the collection or stream
In the OpenCTI interface, create a TAXII 2.1 collection, a live stream or a CSV feed, depending on how the consumer pulls data. Apply the filters from the scope list to object type, marking and organization, and record the filter expression and feed identifier. Run a sample query and confirm it returns only in-scope objects. Confirm which feed types your version offers and how it writes filters, since these details change between releases.
Choose the access model
Decide whether the feed is public, restricted to named consumers, or limited by organization and marking, and whether each consumer gets its own credential. Confirm which access controls your edition supports, since organization-based data segregation is an Enterprise Edition capability. Record who holds each credential and how it is rotated. This step is done when each consumer's credential opens only the feed agreed in the first step, and a request without credentials is refused.
Connect a non-production consumer
Set up a test consumer outside production, such as a staging TAXII client or a copy of the partner's ingestion script, pointed at the feed. Use test credentials and the same scope list. Let it poll or subscribe for the period agreed with the audience. This step is done when the consumer has completed at least one successful poll or stream session and its logs show the request, the response and any errors.
Compare records and markings with the source
Run the same filter in OpenCTI and at the consumer, then compare object counts by type, the marking labels on sample objects and the author organization. Compare identifiers for a sample of objects so you know the same objects arrived, not only the same number. Investigate any gap before you widen the scope. This step is done when counts match for each object type and every sampled object carries the same markings on both sides.
Confirm removed and revoked items stop appearing
Pick a test object in scope, remove it from the feed or revoke it through your agreed process, then poll again from the test consumer. Revoke a test credential and confirm that access is refused. Check whether the consumer keeps a local copy, and document how the partner should handle it. Confirm how your version represents revoked objects in responses. This step is done when the removed object and revoked credential no longer produce results and the behavior is written into the runbook.
Public access and visibility controls before anything leaves the platform
Every TAXII collection, live stream and CSV feed is an outbound channel, so access decisions come before the first export. The six cards cover who can read each feed, what data it can contain, how consumers authenticate, and how requests reach the endpoint. Work through them in order before any feed is shared outside your organization.
Decide public or authenticated access
Start by deciding, for each feed, whether anyone may read it or whether every consumer must authenticate. A public feed is effectively a publication decision, so it should carry only content your organization already accepts for open release. Authenticated feeds let you tie each consumer to a named credential and revoke that access without changing the data. Record the decision for every collection and stream before configuration begins, and confirm with the feed owner who approved it.
Scope filters to approved markings and types
Each collection, stream or CSV export should use filters that pass only the marking definitions and STIX object types named in your sharing agreement. Filters are the main control against accidental exposure of observables, reports or relationships that were never meant to leave the platform. Test each filter with sample data on a non-production instance, and check that objects added later with a new marking or type are excluded by default. Document the filter logic so reviewers can compare it directly with the agreement.
Review sensitive context in outgoing data
Descriptions, labels, notes, external references and linked entities can reveal internal investigations, customer names or victim details, even when the core indicator is harmless. Review a sample of the exported content from each feed against the fields it will contain, including CSV columns that combine several attributes into one. Confirm with legal or your information-sharing lead which fields are safe to publish, and repeat the review when enrichment connectors begin adding new data.
Protect consumer credentials and tokens
Consumers of authenticated TAXII collections and live streams hold credentials that grant read access to your data, so treat them as secrets. Issue a separate credential to each consumer, store it in that consumer's secret manager, and set a documented rotation and revocation process. Check whether your OpenCTI version lets you revoke one consumer without affecting the others, and confirm how tokens are generated, displayed and replaced if lost.
Place the endpoint behind existing controls
Publishing endpoints are external services, so they should pass through the same controls your organization applies to other partner-facing APIs. That usually means a reverse proxy or API gateway with TLS termination, rate limiting, IP allowlisting where partners have fixed addresses, and logging at the edge. Confirm that the gateway forwards the authentication headers the feed requires, and test that unauthenticated and malformed requests are refused before they reach the platform.
Log who accessed each feed
Knowing which consumer pulled which feed, and when, supports incident response and partner disputes. Whether OpenCTI records feed access in audit logs depends on the edition you run. The supplied OpenCTI Enterprise Edition documentation lists activity monitoring and audit logs as Enterprise Edition features, so confirm with Filigran for your version before relying on them. If audit logs are unavailable, capture access at the gateway or reverse proxy, keep those logs for the period your policy sets, and test that each entry identifies the consumer.
Which parts of feed publishing need the Enterprise Edition license
Decide the edition before you design feed access, because the licensing split determines which controls you can rely on when you publish intelligence to partners and tools. OpenCTI Community Edition is licensed under the Apache License 2.0. The Enterprise Edition is licensed under the proprietary OpenCTI Enterprise Edition License and adds features to the platform. The Enterprise Edition documentation lists activity monitoring and audit logs, playbooks, organization-based data segregation, authorized members, full-text document indexing, AI features, priority intelligence requirements and SSO configuration. Several of these bear directly on shared feeds, so raise the edition question in your first design review, before any feed goes live.
Each feature matters for a shared feed for a different reason. Activity monitoring and audit logs should show who changed a collection, a filter or a stream, which matters when a partner questions what they received. Organization-based data segregation keeps information attributed to one partner or sharing group out of feeds built for another. Authorized members determine who can administer publishing settings, and SSO configuration determines how people sign in to the platform. Playbooks and priority intelligence requirements can also shape what enters a feed. The sibling topic on playbooks covers that in detail. Map each feature to a specific control in your feed design so you can show a reviewer exactly where it applies.
The documentation supplied for this topic does not confirm which TAXII collection, live stream, CSV feed or visibility function is Enterprise-only. Do not assume that a feed capability is available in the Community Edition, and do not assume that every feed capability requires a license. Confirm each capability you plan to use against the version you intend to run, either with Filigran or in the Enterprise Edition documentation at the time of design. Ask for the answer in writing, listing each function, its edition and the release it applies to. OpenCTI uses date-based version numbers, and behavior can change between releases, so record the version you tested.
SSO for feed consumers depends on your authentication strategy rules, which sit outside the feed configuration. OpenCTI supports local users and LDAP, plus SAML, OpenID Connect and other strategies. Since 7.260224.0, defining and using authentication strategies, including SSO, is an Enterprise Edition feature. If partner analysts or tools must authenticate through your identity provider, confirm that your edition allows the strategy you need. Also confirm how non-interactive consumers, such as TAXII clients, authenticate, because that path may differ from browser sign-in. Filigran offers the Enterprise Edition on premises or as SaaS, so ask for license terms, renewal conditions and what happens to consumer access if a license lapses.
What to confirm about TAXII, streams and CSV in your environment
Publishing OpenCTI intelligence to partners and tools touches protocols, filters, limits and upgrade behavior, and each one shapes what your consumers actually receive. The cards below list the points to confirm with the OpenCTI documentation, your Filigran contact or your own platform team before you commit to a feed design.
TAXII version and protocol exposure
Confirm which TAXII version your OpenCTI release exposes and whether TAXII 2.1 is the only protocol offered for collections. Ask whether any legacy endpoints or alternative transports are enabled by default, and whether they can be switched off. Your partners' client libraries must match the exposed version, so verify this against the release you plan to run in production.
Filter syntax and object-type coverage
Ask which filter expressions the collections accept, how they combine labels, marking definitions and object types, and which STIX object types can be included or excluded. Test each filter against a sample dataset to see whether indicators, observables, relationships and reports behave as your partners expect. Record the results so that a later change to the filter syntax is easy to spot.
Scope parity across streams and CSV
Confirm whether live streams and CSV exports accept the same scoping rules as TAXII collections, or whether each channel applies its own filters. A mismatch means a partner could receive different data from the stream than from the file export. Ask the vendor to document any differences and decide, before launch, which channel is authoritative for each audience.
Rate, size and pagination limits
Ask for the documented request rate limits, maximum page sizes, export size ceilings and any timeouts for TAXII polling and CSV generation. These limits determine how often a consumer can poll and how large a single feed can grow before it is split or truncated. Run a load test with a realistic consumer profile in your own environment, because limits set by the defaults may not fit your volume.
Behavior when a consumer falls behind
Find out how live streams buffer messages, how long they retain them and what happens when a consumer reconnects after a long gap. Ask whether a lagging consumer can miss updates silently, how the platform signals the gap, and whether the consumer can resume from a known position. Your partner runbook should describe the recovery steps for each case.
Deletion and revocation propagation
Confirm how a deleted or revoked object appears to TAXII clients, streams and CSV consumers, and whether revocation markers are sent as separate records or simply disappear from the feed. Ask how long a removed object can remain in a consumer's cache and whether a full resynchronization can be forced. Partners who act on indicators need a clear answer before you promise them removal within a set time.
Feed behavior across version upgrades
Ask whether collection identifiers, filter semantics, stream positions and CSV column layouts change between regular releases and LTS lines. Check the upgrade notes for each target version and confirm whether a database migration can alter feed output. Plan a staging test that compares feed output before and after each upgrade, since consumers may break silently if the format shifts.
Running published feeds through OpenCTI upgrades and capacity changes
Every OpenCTI upgrade or capacity change can alter what a TAXII collection, live stream or CSV feed returns, so the feed should be treated as a dependency to re-test each time the platform moves. Start by knowing which release line you run. OpenCTI uses date-based version numbers: regular releases follow the pattern x.YYMMDD.z, and LTS releases follow x.YYMMDD.z-lts.n, where the date is the release or LTS branching date. Non-LTS releases ship when ready, from daily to weekly, so a team that tracks them will upgrade often. LTS releases arrive every 6 months and each is supported for one year, which gives a 6-month overlap between consecutive LTS versions. Choosing the line is a decision about how often your partners' consumers must be re-validated, not only about new features.
Plan a feed regression check as part of every upgrade window. Before the change, record the expected output of each published collection and feed: object counts for a known filter, the STIX bundle structure returned by a TAXII request, the header and column layout of a CSV export, and the behavior of a live stream consumer that reconnects after a restart. Run the same checks on a staging copy of the platform, then again in production after the cutover. Confirm that marking, filters, and public or restricted access still behave as configured. Give downstream partners a window and a contact point, since a schema or field change can break a parser on their side even when OpenCTI itself is healthy.
LTS releases carry a licensing and support condition that affects how you plan. OpenCTI LTS releases are distributed as container images, but they require a specific LTS license key to use. After a one-month stabilization period, they receive only critical bug and security fixes, so feature changes that your feeds depend on will not arrive on that line. Ask the vendor or Filigran to confirm current license terms, the key issuance process and whether your edition covers the LTS line you intend to run. OpenCTI 7.260309.0 is the LTS line referenced in the researched release history, and its hotfix numbering (lts.n) shows how often fixes arrive. Track those hotfixes, but schedule the full re-test before adopting each one.
Capacity changes affect how current published data stays. The documented dependencies are 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. Worker throughput depends on RabbitMQ, and the documented sizing recommends at least one platform node for every three workers. When feeds lag behind the data a team has just imported, the cause is often a backlog in the worker queues or a search index that cannot keep up with writes, not the feed itself. Before adding workers or moving to a larger index tier, confirm the sizing in the deployment overview against your own volumes, and ask your implementation partner to model the effect on feed freshness.
What buyers ask before publishing OpenCTI feeds to partners
How much effort does an OpenCTI feed project take?
Effort depends mainly on how many partners consume the feed, how complex the filters are, and how much agreement sits behind each feed. One internal TAXII collection with a single consumer is a small job. Each additional partner adds a filter definition, a test cycle, a credential, and a named contact to maintain. The drivers to price are the number of consumers, filter complexity, the edition and license decisions, the data-sharing agreements, and the testing each partner requires. Ask for the effort split by these drivers in the written scope. DeployOpen works to a fixed scope agreed in writing before work starts, so changes to the number of consumers or filters should be handled as scope changes.
What does an OpenCTI feed project cost, and what recurs?
The cost is the sum of licensing, infrastructure, implementation labor and any ongoing support. DeployOpen does not publish a price list, and a quote follows from the written scope. One-time costs usually include scoping, configuration, partner testing, and handover. Recurring costs include the Enterprise Edition license if your chosen features need it (confirm current terms with Filigran), hosting for the platform dependencies such as Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, upgrades that follow the release cadence, and optional retainer support. Ask the quote to itemize who is paid for each line, which items are one-time, and which renew annually or monthly.
What does the client need to provide for a feed project?
The work needs decisions from your side that no implementer can make for you. You need data owners who decide which indicators, observables and reports may leave the organization. You need a written marking policy that the filters can follow, such as which TLP levels or organizational labels are shareable. You need named technical and business contacts at each partner, and change windows agreed with your operations team for config changes and credential rotation. You also need access to the OpenCTI instance and its hosting environment, and a decision on who approves credentials for each consumer. Without a marking policy, filters become guesses, and partner testing takes longer.
Can our own team build and run OpenCTI feeds alone?
A team with platform engineering skills and threat intelligence knowledge can build and run feeds alone, but it should plan for ownership before starting. The work involves deploying the platform and its dependencies, understanding the STIX2-based knowledge schema, configuring access and filters, and keeping up with releases. Teams that need SSO or organization-based segregation must also account for Enterprise Edition features. A common split is a partner for scoping, configuration and handover documentation, while your team operates the feeds day to day. Ask any provider for written handover material and a test plan so that your engineers can maintain the feeds without the original builders.
Can TAXII, live streams and CSV feeds be published without Enterprise Edition?
Confirm this for your exact OpenCTI version before you commit to a design. The Community Edition is licensed under Apache License 2.0, while the Enterprise Edition is covered by a proprietary license. Filigran's Enterprise Edition documentation lists features such as SSO configuration, audit logs, playbooks, and organization-based data segregation, and the authentication documentation states that defining and using authentication strategies, including SSO, is an Enterprise Edition feature since 7.260224.0. Whether a specific publishing method is available in a given edition is a version-specific question, so check the current release notes and Filigran's documentation, and test the exact feed type during scoping.
Which OpenCTI release line should a feed project target?
Choose between regular releases and an LTS line based on how stable the consumer contract must be. Regular releases ship from daily to weekly, with version numbers in the form x.YYMMDD.z. LTS releases occur about every six months, are supported for one year, and use the form x.YYMMDD.z-lts.n. An LTS release requires a specific LTS license key, and after a one-month stabilization period it receives only critical bug and security fixes. For partners who depend on stable behavior, an LTS line reduces the frequency of changes. Confirm that the features your feeds need are present in the chosen line, and plan upgrades on the line's support end date.
How do we test a partner feed before it goes live?
Test each feed against the partner's own client before any production credential is issued. Illustrative test plan: load a sample set of objects with known markings, confirm the filter includes and excludes each one as the marking policy requires, check that the partner's tool parses the output, and verify that revoking a credential stops access. Repeat the test after each platform upgrade and after any filter change. Record each test result, the version tested, and the person who approved it. Ask the provider for the test plan and acceptance criteria in writing, and agree with the partner on who signs off before go-live.
How DeployOpen scopes, delivers and supports OpenCTI feed publishing
DeployOpen plans, builds, documents and supports the feed publishing layer of a self-hosted OpenCTI platform in infrastructure you control. We scope which TAXII collections, live streams and CSV feeds your partners and tools need, then build them with the filters, public access settings and visibility controls your data policy requires.
How we scope
- Inventory which partners, tools and teams consume intelligence and what each one is allowed to receive.
- Define each TAXII 2.1 collection, live stream and CSV feed, including its filters and its audience.
- Record public access and visibility decisions in the written scope before any configuration starts.
- Confirm which OpenCTI features your chosen edition supports, since some access controls depend on the Enterprise Edition license.
How we build
- Configure collections, streams and CSV exports in a test instance before they reach production consumers.
- Test each filter against sample data to confirm that only the intended objects are published.
- Check that consumers can authenticate, poll or subscribe, and parse the output in their own tools.
- Set up the connectors and workers that move data to feeds, and confirm their sizing against the documented dependencies.
How we hand over
- Document every collection, stream and CSV feed with its purpose, filters, audience and access settings.
- Provide a consumer guide that explains how each partner or tool connects, polls and handles updates.
- Record test results, configuration exports and the approval trail for each published feed.
- Walk through operational runbooks for adding, changing or retiring a feed without exposing unintended data.
How we support
- Review feed scope and access settings when partners, tools or data policies change.
- Plan OpenCTI upgrades around the release and LTS lines, and retest feeds after each upgrade.
- Monitor feed consumption and connector health, and respond to issues under the agreed support terms.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
