What is PAP, and Why Does it Matter in Cyber Threat Intelligence?

In this post

If you work with cyber threat intelligence, you already know the value of handling markings.

Most people think first about TLP, because TLP answers the sharing question:

who can this information be passed to?

That is important, but it is not the whole story.

There is a second question that matters just as much in operational CTI:

what are recipients actually allowed to do with this information?

That is where PAP comes in.

In this post I will cover:

what PAP is and where it comes from
why PAP solves a different problem to TLP
why PAP matters in practical CTI workflows
how PAP is represented in STIX 2.1 using OASIS-defined Marking Definitions
why the OASIS Extension Definition is the critical part that makes those markings interoperable

What is PAP?

PAP stands for Permissible Actions Protocol.

It was introduced in the MISP ecosystem to express how intelligence may be used, especially where a defensive action could reveal to an adversary that they have been detected or are under investigation.

That makes PAP quite different from TLP.

TLP is about distribution.

PAP is about use.

In other words:

TLP tells you who you can share something with
PAP tells you what you can safely do with it

That distinction matters because CTI is not only read by humans.

It is operationalised.

Indicators get turned into detections.

Reports get cited in products.

Findings get escalated to customers, regulators, and conference talks.

The moment intelligence leaves the analyst notebook and starts driving action, PAP becomes relevant.

The PAP levels

The PAP taxonomy is usually expressed with the following values:

PAP Level	Meaning
`PAP:CLEAR`	Information may be used without restriction.
`PAP:GREEN`	Low risk that operational use will alert an adversary.
`PAP:AMBER`	Moderate risk that operational use could expose defensive activity.
`PAP:RED`	High risk that operational use could expose sources, methods, or investigations.
`PAP:WHITE`	Legacy compatibility value retained for older MISP usage. New implementations should prefer `PAP:CLEAR`.

The exact value of PAP is not that it introduces another colour system.

The value is that it communicates intent around permissible action in a form that can move with the intelligence itself.

That is useful when:

a vendor wants to know if intelligence can be productised
a SOC wants to know if an indicator can be operationalised into detection content
a researcher wants to know if a finding can be published or publicly attributed
a downstream platform wants to preserve those restrictions when re-sharing the data

Why PAP matters in CTI

In many teams, these decisions are currently handled informally.

Someone adds a note in a report.

Someone else remembers a verbal warning.

A platform-specific tag gets added somewhere and then lost on export.

That approach does not scale.

If a consumer receives an indicator with TLP:GREEN, they know something about distribution.

But they still do not know whether turning that indicator into a public Sigma rule, a commercial detection feed, or a conference case study is acceptable.

PAP fills that gap.

It gives producers a standard way to signal operational sensitivity without burying the decision in free text.

For CTI programs that care about provenance, reuse, and downstream automation, that is a meaningful improvement.

PAP in STIX

This is the part I think is most important for STIX practitioners.

OASIS has already done the hard work of defining how PAP should be represented in STIX 2.1.

Here’s the PAP Extension Definition schema.

This means you do not need to invent your own x_pap, pap_level, or custom label scheme if your goal is STIX interoperability.

You can use the OASIS-defined objects directly.

That matters because the PAP values are not part of the STIX 2.1 core specification.

They are represented as Marking Definitions extended via an Extension Definition.

That detail is easy to overlook, but it is the key to making PAP work properly in STIX.

Why the Extension Definition matters

If you have read my earlier post on custom STIX objects and properties, this pattern will look familiar.

When STIX does not natively define a concept, the standards-aligned way to add it is not to make up a field and hope downstream tooling understands it.

The right move is to publish an Extension Definition that explains exactly what the extension means.

That is exactly what the OASIS PAP work does.

The PAP specification defines an Extension Definition with the ID:

extension-definition--f8d78575-edfd-406e-8e84-6162a8450f5b

The Marking Definitions then use that extension to declare the PAP value inside the extensions property.

So instead of a consumer seeing a generic marking-definition object with an unknown blob of custom content, it can see:

this is a PAP marking
this is the standard extension-definition used to describe PAP
this marking carries one of the expected PAP values such as clear, green, amber, red, or white

That is the interoperability win.

Without the Extension Definition, PAP would just be another custom convention.

With it, PAP becomes a documented, reusable, machine-understandable STIX pattern.

The OASIS prose spec is explicit here: because PAP 1.0 data markings are not part of STIX 2.1 core, they must be specified using the Extension Definition object, and the standard PAP Marking Definitions are the only ones that should be used for those values.

Practically, that means you should reference the canonical OASIS PAP Marking Definition objects, not generate your own local copies.

What the actual STIX objects look like

At a high level, each PAP value is a marking-definition object extended using the PAP Extension Definition.

That is an important distinction.

The PAP value is not just implied by the object name or description.

It is carried in the extensions block, keyed by the PAP Extension Definition ID.

In practice, the shape looks like this:

{
  "type": "marking-definition",
  "id": "marking-definition--...",
  "extensions": {
    "extension-definition--f8d78575-edfd-406e-8e84-6162a8450f5b": {
      "extension_type": "property-extension",
      "pap": "clear"
    }
  }
}

That is why the Extension Definition matters so much.

It tells consumers how to interpret the extra property and how to distinguish a PAP marking from some local custom convention.

The same reuse model that makes TLP markings useful in STIX applies here too.

The marking is reusable, referenceable, and separable from the object being marked through object_marking_refs.

If you want to inspect the actual objects:

Here is a simple example of a STIX report referencing the PAP:CLEAR Marking Definition:

{
  "type": "report",
  "spec_version": "2.1",
  "id": "report--2d8b8a2e-4eb0-4de9-a0c2-1f6c5af7c001",
  "created": "2026-06-15T10:00:00.000Z",
  "modified": "2026-06-15T10:00:00.000Z",
  "name": "Credential phishing activity targeting finance users",
  "report_types": [
    "threat-report"
  ],
  "published": "2026-06-15T10:00:00.000Z",
  "object_refs": [
    "indicator--11111111-1111-4111-8111-111111111111",
    "threat-actor--22222222-2222-4222-8222-222222222222"
  ],
  "object_marking_refs": [
    "marking-definition--ad15a0cd-55b6-4588-a14c-a66105329b92"
  ]
}

In this example, the report does not store the PAP value directly.

It references the PAP:CLEAR Marking Definition (marking-definition--ad15a0cd-55b6-4588-a14c-a66105329b92) through object_marking_refs, which is exactly how STIX markings are intended to be applied.

Final thought

If TLP answers “who can I share this with?”, PAP answers “what can you do with it once you have it?”.

That is a real operational distinction, and one worth preserving in structured CTI.

The good news is that if you are working in STIX 2.1, you do not need to design PAP yourself.

OASIS has already published:

the prose specification
the Extension Definition
the canonical PAP Marking Definition objects

So if you want PAP in your CTI workflows, the best path is simple: use the standard OASIS objects, reference the standard Extension Definition, and avoid inventing another custom representation for a problem that already has a clean STIX model.

We’re in the process of adopting PAP across our products, starting with Stixify.

Posted by: