STIX and TAXII Explained: How Threat Intelligence Actually Moves Between Systems

STIX (Structured Threat Information eXpression) is a standardised language for describing cyber threat intelligence. TAXII (Trusted Automated eXchange of Intelligence Information) is the protocol for transporting it. STIX is the content; TAXII is the delivery. Both are maintained as open standards by OASIS, and together they are the reason threat intelligence can move between tools from different vendors without custom integration work.

Before these standards, sharing intelligence meant emailing spreadsheets of IP addresses. The information was real but unusable at machine speed, and the context — who the actor was, what campaign it belonged to, why the indicator mattered — was lost in translation.

What STIX actually describes

The most common misconception is that STIX is a list of indicators. It is considerably richer than that. STIX 2.1 models the whole threat landscape as objects and the relationships between them.

STIX Domain Objects (SDOs) represent concepts. The ones you will encounter most:

Object	Represents
indicator	A detectable pattern — a hash, domain, IP, or a pattern expression
malware	A malicious program or family
threat-actor	An individual or group behind activity
intrusion-set	A grouped set of behaviours attributed to one operation
campaign	A series of activities against particular targets
attack-pattern	A technique, typically mapped to MITRE ATT&CK
vulnerability	A weakness, usually referencing a CVE
course-of-action	A mitigation or response step
identity	An organisation, sector or individual — victim or reporter
observed-data	Something actually seen, as opposed to something suspected

STIX Relationship Objects (SROs) are what make it intelligence rather than a list. A relationship object connects two SDOs with a verb: this indicator indicates that malware; that malware is used by this threat actor; that actor targets this sector. A sighting records that a specific indicator was actually observed, by whom, and how many times.

STIX Cyber-observable Objects (SCOs) describe the raw artefacts themselves — a file with its hashes, an IPv4 address, a domain name, a network traffic record, a Windows registry key.

The practical payoff: when an indicator fires in your environment, you can traverse the graph to answer "what is this, who uses it, what are they after, and what should we do?" — without leaving your console.

A concrete example

A STIX indicator object looks roughly like this:

{
  "type": "indicator",
  "spec_version": "2.1",
  "id": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",
  "created": "2026-03-14T09:12:00.000Z",
  "modified": "2026-03-14T09:12:00.000Z",
  "name": "Known C2 domain",
  "indicator_types": ["malicious-activity"],
  "pattern": "[domain-name:value = 'malicious-example.test']",
  "pattern_type": "stix",
  "valid_from": "2026-03-14T09:12:00.000Z"
}

Note the pattern field. STIX patterning is its own expression language, capable of far more than single values — it can express conjunctions, time windows and multi-observable conditions, so one indicator can describe a compound behaviour rather than a single artefact.

Note also valid_from. Indicators are supposed to expire. An IP address that hosted a command-and-control server two years ago may now be an innocent shared host, and blocking it generates false positives forever. Intelligence has a shelf life, and STIX has fields to express it — feeds that omit them are lower quality.

How TAXII moves it

TAXII 2.1 is a straightforward REST API over HTTPS, deliberately simple so that any platform can implement a client.

Its structure:

• Server — the host offering intelligence
• API root — a logical grouping of content, allowing one server to offer several distinct sets
• Collection — a bundle of related STIX objects that clients can read from or write to
• Objects endpoint — where clients retrieve the STIX content itself

TAXII supports two interaction models. In collections, the client polls the server and asks for what is new — the model most consumers use. In channels, the server pushes to subscribers, which suits time-critical distribution.

A typical consumer configuration needs: the server's discovery URL, credentials, the collection ID to subscribe to, and a polling interval. Most teams poll every fifteen to sixty minutes, using the added_after filter so each poll retrieves only new objects rather than the whole collection.

Where the intelligence comes from

Common sources that speak STIX and TAXII natively:

• MISP — the widely deployed open-source threat intelligence platform, which can export STIX and act as a TAXII server. Many national CERTs and sector ISACs distribute through MISP instances.
• AlienVault OTX — a large open community feed.
• Sector ISACs — financial services, healthcare and energy sharing bodies, often the highest-quality intelligence available because it is contextual to your industry.
• National CERTs — several publish TAXII collections for their constituencies.
• Commercial providers — most enterprise threat intelligence vendors offer TAXII delivery.

A word of caution on volume. It is tempting to subscribe to every free feed available. The result is usually hundreds of thousands of indicators of mixed quality, a rise in false positives, and analysts who stop trusting intelligence alerts. Two well-curated feeds relevant to your sector and region outperform twenty generic ones.

Using STIX without a live connection

This is where the standard earns its place in regulated and air-gapped environments.

Because STIX is a self-contained JSON document format, intelligence does not require a live TAXII connection to be useful. A STIX bundle is simply a file containing a set of objects. It can be downloaded on a connected machine, transferred across an air gap by approved media, and imported into an isolated platform.

This means a classified or fully disconnected network can still consume current threat intelligence on a controlled schedule — daily, weekly, or whatever the security policy permits. The platform's detection logic works identically whether the bundle arrived over TAXII or on removable media.

For defence, government and critical national infrastructure operators, this property is often the deciding factor. Any platform whose threat intelligence only works with live outbound connectivity is unusable in those environments.

What good looks like in practice

A well-implemented STIX/TAXII pipeline should:

1. Deduplicate across feeds. The same indicator will arrive from several sources. It should appear once, with all sources recorded.
2. Respect expiry. Indicators past valid_until should stop matching automatically, not linger indefinitely.
3. Preserve relationships. A match should surface the associated malware, actor and ATT&CK technique — not just the bare indicator.
4. Support allowlisting. Public feeds periodically include major CDN addresses, DNS resolvers or your own infrastructure. You need a way to suppress those permanently.
5. Record sightings. When an indicator matches, that observation is itself intelligence, and mature programmes contribute it back to their sharing community.
6. Retain provenance. Every indicator should carry which feed supplied it, so a feed that produces persistent noise can be identified and dropped.

---

Configuration details for STIX 2.1 and TAXII 2.1 ingestion, including offline bundle import for air-gapped deployments, are in the nPro documentation.