What is TAXII (Trusted Automated Exchange of Intelligence Information)?

TAXII (Trusted Automated Exchange of Intelligence Information) is an open, application-layer protocol for exchanging cyber threat intelligence (CTI) over HTTPS. In practical terms, TAXII is the transport: it defines a RESTful API and requirements for clients and servers so that organizations can send, receive, request, and manage threat intelligence in an automated, standardized way. TAXII is almost always mentioned alongside STIX, but the two do different jobs. STIX is the language that structures the intelligence (the "what"); TAXII is the protocol that moves it between systems (the "how"). TAXII was designed specifically to carry STIX, and support for exchanging STIX 2.1 is mandatory to implement, but it can also transport other formats.

Key takeaways

TAXII is the transport, not the language. It moves cyber threat intelligence between systems; STIX is the format that intelligence is written in.
It's an HTTPS-based RESTful API. TAXII defines services and requirements for clients and servers communicating over HTTPS.
Two services: Collections and Channels. Collections use a request-response (pull) model; Channels use a publish-subscribe (push) model.
STIX and TAXII are independent. STIX can be shared without TAXII, and TAXII can carry non-STIX data, though STIX 2.1 support is mandatory.
It enables automated, vendor-neutral sharing. TAXII lets SOCs, ISACs, and CERTs exchange intelligence at scale with minimal manual effort.

TAXII vs STIX: The transport, not the language

Because so many resources merge the two, it's worth being precise about the boundary. STIX defines how a threat is described: structured, machine-readable objects and relationships. TAXII defines how that description travels from a producer to a consumer. Think of STIX as the content of the letter; TAXII is the postal service that delivers it.

The two were developed together and a TAXII server must be able to handle STIX, yet they remain independent standards. You can share STIX intelligence by other means, through email, a file, or your own API, and a TAXII server can move data in formats other than STIX. What TAXII adds is a common, secure, automated delivery mechanism, so tools from different vendors can exchange intelligence without custom integration for every connection.

How TAXII works

TAXII operates on a client-server model over HTTPS. A TAXII server stores, manages, and distributes CTI; a TAXII client connects to a server to send or retrieve it. All communication runs over HTTPS, with access typically controlled through OAuth 2.0 or API keys. Rather than inventing new plumbing, TAXII deliberately builds on existing protocols to keep adoption simple.

Servers are discovered via DNS Service (SRV) records or a dedicated Discovery Endpoint, and the API itself is RESTful: each interaction is an endpoint, defined by a URL and an HTTP method with specified behavior.

The two TAXII services: Collections and Channels

TAXII defines two primary services to support the common ways organizations share intelligence.

	Collections	Channels
Model	Request-response (pull)	Publish-subscribe (push)
How it works	A producer hosts a set of CTI; consumers request it and the server responds.	A producer pushes data to many subscribed consumers, who receive it as it is published.
Direction	Consumer initiates (client pulls from server)	Producer initiates (server pushes to subscribers)
Good for	On-demand access to a maintained repository of intelligence	Distribution of new intelligence to many consumers

A Collection is an interface to a logical repository of CTI objects: the consumer asks, the server responds. A Channel flips the direction: the producer publishes and many subscribers receive. Together they cover the two fundamental sharing patterns, pull and push.

Note: in some versions of the specification, Channel keywords are reserved rather than fully defined, with Collections being the primary implemented service.

Core TAXII components

TAXII server: hosts, manages, and distributes CTI to clients.
TAXII client: connects to a server to request or submit CTI.
API Root: a logical grouping of Collections and Channels, effectively one instance of the TAXII API at a specific URL. A single server can host multiple API Roots, for example one per trust group.
Collection: a logical group of CTI objects that clients can request (pull).
Channel: a publish-subscribe stream for pushing CTI to many consumers.
Endpoint: a URL plus an HTTP method with defined behavior, the building block of the RESTful API.
Discovery: how clients find a server and learn what it offers, via DNS SRV records or a Discovery Endpoint.

Sharing models TAXII supports

TAXII was built to fit how organizations already share, not to force a single topology. It minimizes operational change and integrates with existing sharing agreements. The three supported models are hub-and-spoke (a central hub distributes to and collects from members), peer-to-peer (organizations exchange directly), and source-subscriber (one producer feeds many consumers). Collections and Channels, grouped under API Roots, let a single deployment serve all three across different trust groups simultaneously.

TAXII 2.0 vs TAXII 2.1

TAXII is maintained by the OASIS Cyber Threat Intelligence (CTI) Technical Committee, having originated at MITRE with US Department of Homeland Security support. The current version, TAXII 2.1, was released as an OASIS standard alongside STIX 2.1. Compared with 2.0, version 2.1 made targeted refinements: the DNS SRV discovery record changed from taxii to taxii2; the discovery URL path changed from /taxii/ to /taxii2/; and the Manifest resource was updated to represent individual versions of an object rather than an object with all its versions. Same transport model, cleaner delivery.

What TAXII is used for

TAXII exists to make threat intelligence sharing automated, secure, and interoperable. Common uses include:

Automated CTI ingestion: SOCs use TAXII to automatically pull threat data into their tools, so intelligence flows in without manual downloads.
Feeding a security stack: a TAXII feed can deliver indicators directly into SIEMs, threat intelligence platforms, and detection systems.
Community and sector sharing: ISACs, CERTs, and trust groups host TAXII servers so members can subscribe to and contribute intelligence.
Government-scale programs: CISA's Automated Indicator Sharing (AIS) uses a bidirectional TAXII connection so participants can both send and receive machine-readable STIX indicators at scale.

Expert insight: A feed is only as good as what happens after ingestion

TAXII solves the delivery problem cleanly: it gets intelligence from a producer into your environment automatically and securely. But delivery is the beginning. A TAXII feed pointed at a system that can't correlate, prioritize, and act on what arrives just produces a faster firehose. The value comes when ingested intelligence is matched against your own telemetry, deduplicated, aged appropriately, and turned into detection.

Native support matters in both directions. Sekoia Intelligence is built on native STIX 2.1 and supports TAXII, acting as both a consumer (pulling in external feeds from ISACs, CERTs, and partners) and as a producer (exposing its own intelligence for others to consume). On the Sekoia AI SOC platform, intelligence arriving over TAXII doesn't just sit in a repository: it's correlated against customer telemetry, feeds detection, and new indicators can be retro-hunted across historical data rather than only watched going forward. As a European vendor with a data-sovereignty posture, Sekoia suits the public-sector bodies, national CERTs, and sector communities that rely on TAXII to share at scale. Choose the right transport; back it with a platform that can operationalize what the feed delivers.

‍