Threat intelligence and incident details only get shared if the people sending them trust that recipients will respect the limits, and the Traffic Light Protocol (TLP) is the shared language for those limits. TLP 2.0, published by FIRST and authoritative since August 2022, uses five labels to tell recipients how far they may pass information on. This guide covers what each label permits, what changed from TLP 1.0, how to mark email, documents, chat and machine-readable feeds, how to build TLP handling into intelligence platforms and incident workflows, and where TLP stops and law or contract takes over. It is for threat intelligence analysts, incident responders, ISAC members and anyone who receives or sends advisories marked with TLP.
Key takeaways
- Five labels, one direction. TLP:RED, TLP:AMBER+STRICT, TLP:AMBER, TLP:GREEN and TLP:CLEAR describe how widely a recipient may share, from named individuals only to the world.
- TLP 2.0 renamed WHITE to CLEAR and added AMBER+STRICT. AMBER now includes the recipient's clients by default; AMBER+STRICT keeps information inside the recipient organisation.
- The source sets the label and can add restrictions. Recipients who need to share more widely must get explicit permission from the source; they do not relabel.
- TLP is not classification or law. FIRST states it is not a formal classification scheme, and CISA's user guide says it is not legally binding and does not override legal obligations.
- Automation must carry the label. MISP taxonomies and a STIX 2.1 extension express TLP 2.0 so platforms can enforce sharing boundaries instead of relying on people reading headers.
What TLP is and who maintains it
FIRST (the Forum of Incident Response and Security Teams) maintains TLP through a special interest group. FIRST describes TLP as created to facilitate greater sharing of potentially sensitive information and more effective collaboration, and as optimised for ease of adoption, human readability and person-to-person sharing. Information flows from a source to one or more recipients, and the label tells the recipients the sharing boundary to apply.
TLP 1.0 was the authoritative FIRST version from 2017 until August 2022, and FIRST allowed it to remain in use until 31 December 2022. TLP 2.0 is the current version. In the United States, CISA moved to TLP 2.0 on 1 November 2022 and published a TLP 2.0 user guide; its alert at the time said its Automated Indicator Sharing capability would follow in March 2023.
For where TLP sits within a wider intelligence programme (requirements, collection, analysis and dissemination), see the Threat Intelligence Guide. This page goes deep on the labels and their handling.
The five TLP 2.0 labels
| Label | Who may receive it | When a source uses it | Typical content |
|---|---|---|---|
| TLP:RED | The individual recipients only; in a meeting, only those present | Information cannot be acted on without significant risk to the privacy, reputation or operations of the organisations involved | Victim names in an active incident, an unpatched vulnerability under coordinated disclosure, law enforcement operations |
| TLP:AMBER+STRICT | Members of the recipient's own organisation, need-to-know | Information needs support to act on, but carries risk if shared outside the organisations involved, and clients must not receive it | Detailed incident timelines shared between two peers, intelligence a vendor or MSSP may use internally but not push to its customers |
| TLP:AMBER | The recipient's organisation and its clients, need-to-know | As above, where clients need it to protect themselves | Indicators an MSSP or national CSIRT should push to the organisations it serves |
| TLP:GREEN | Peers and partner organisations within the recipient's community, not via public channels | Information is useful to raise awareness in the wider community | Sector-wide campaign summaries, ISAC member bulletins |
| TLP:CLEAR | Anyone; subject to standard copyright rules | Minimal or no foreseeable risk of misuse, in line with rules for public release | Published advisories, public detection rules |
Definitions that decide most disputes
- Community: FIRST defines it as a group who share common goals, practices and informal trust relationships. When the community is not defined, FIRST says to assume the cybersecurity or defence community. If you send TLP:GREEN, name the community.
- Organisation: a group sharing a common affiliation by formal membership and bound by common policies. For a group of companies this is a real question: decide whether "organisation" means the legal entity or the group and say so in your sharing agreement.
- Clients: included by default in TLP:AMBER so recipients can share further downstream. CISA's user guide describes clients as those receiving cybersecurity services from an organisation, including the stakeholders and constituents of teams with national responsibility.
What changed from TLP 1.0 to TLP 2.0
| Area | TLP 1.0 | TLP 2.0 | What to update |
|---|---|---|---|
| Public label | TLP:WHITE | TLP:CLEAR | Templates, mail rules, feed mappings; treat legacy WHITE as CLEAR |
| Organisation-only label | Not defined | TLP:AMBER+STRICT | Add the label to platforms and handling policy |
| AMBER scope | Recipient organisations, and clients or customers who need it | Recipient organisation and its clients, need-to-know, clients included by default | Check whether your AMBER outputs should now be AMBER+STRICT |
| RED wording | Not for disclosure, restricted to participants only | For the eyes and ears of individual recipients only, no further disclosure | Brief staff that RED does not extend to their team |
| Formatting | Colour scheme defined | Labels in capitals, no spaces, original form even in other languages; updated colour values | Document and slide templates |
FIRST publishes colour values for TLP 2.0: RED #FF2B2B, AMBER #FFC000, GREEN #33FF00 and CLEAR #FFFFFF, with the specification setting how label and background colours combine. AMBER+STRICT uses the AMBER colour. Copy the exact values and layout from the FIRST page into your templates rather than approximating them.
How to mark information
- Email: FIRST says TLP-labelled messaging must indicate the label and the label should be in the subject line. CISA's guide asks that the subject begins with the label and that any caveat appears in the subject or at the start of the message. Put the label directly before the information as well, because subject lines are lost when messages are forwarded or quoted.
- Documents: the label goes in the header and footer of every page, right-justified, in 12-point type or larger for readers with low vision. Repeat it on slides, spreadsheets (in a header row and the sheet name if needed) and exported PDFs.
- Mixed content: where parts of a document carry different labels, CISA advises marking the beginning and the end of the text each label applies to. Default the document label to the most restrictive part, or split the document.
- Chat and collaboration channels: state the label before the information. CISA notes that a standing channel can set a default level in a pinned message or rules document; individual messages can still be more restrictive.
- Meetings and calls: the speaker states the label and any caveat at the start. A conference programme can set a default for its sessions.
- Additional restrictions: FIRST says the source may specify additional sharing restrictions, which recipients must follow. Write caveats in plain words next to the label, for example "TLP:AMBER, do not share with law enforcement without asking us first".
- Format rules: write labels exactly as defined, in capitals with no spaces: TLP:AMBER+STRICT, not "TLP: Amber strict".
Receiving TLP information
- Read the label and caveats before acting. Record them with the data in your intelligence platform or case.
- Apply need-to-know. AMBER and AMBER+STRICT allow sharing only with those who need it to protect the organisation; they are not permission to copy a whole distribution list.
- Keep the label on derivatives. Detection rules, blocklists and reports built from labelled data inherit its restrictions unless the source agrees otherwise. Separate a public indicator (a domain already in open reporting) from the restricted context around it.
- Ask before widening. FIRST requires explicit permission from the source to share more widely. CISA's guide lists options: ask the originator, set up a formal agreement, or request that a caveat be added.
- Do not downgrade, and do not upgrade without telling the source. Recipients do not change labels. If you think a label is wrong, raise it with the source.
- Handle unlabelled information by your own policy. Decide a default for unlabelled material received through each channel, and ask the sender when it matters.
TLP in automated sharing
Most intelligence now moves between machines, so labels must travel in a field the platforms understand. CISA's guide explicitly says exchange designers that built on TLP 1.0 should upgrade their exchanges to TLP 2.0.
| Format or platform | How TLP 2.0 is expressed | Points to check |
|---|---|---|
| MISP | The tlp taxonomy: tags tlp:red, tlp:amber, tlp:amber+strict, tlp:green, tlp:clear (exclusive, so one per event); tlp:white kept for backward compatibility | Sync filters and distribution levels should match the tag; legacy tlp:white events need a decision |
| STIX 2.1 | marking-definition objects using the TLP 2.0 property extension published in the OASIS cti-stix-common-objects repository (extension-definition--60a3c5c5-0d10-413e-aab3-9e08dde9e88d, property tlp_2_0 with values such as amber+strict) | The STIX 2.1 core markings are TLP 1.0; confirm which your TAXII server and consumers expect |
| Ticketing and case tools | A required field with the five labels | Export and notification rules should block AMBER and above from leaving the tenant |
| Email gateways and DLP | Subject and body pattern matching on TLP:RED and TLP:AMBER+STRICT | Alert or block external forwarding of restricted labels |
See the MISP Threat Sharing Guide and the STIX and TAXII Guide for platform configuration. Where your platform cannot represent AMBER+STRICT, store it as AMBER with an organisation-only caveat and restrict distribution manually, and record that as a known gap.
Where TLP stops: law, contract and classification
- Not a classification scheme: FIRST states TLP is not a formal classification scheme and was not designed to handle licensing terms, information handling or encryption rules. Government classified material follows its own system, and your internal data classification still applies to TLP content.
- Not legally binding: CISA's user guide says TLP is not legally binding and does not override legal restrictions or obligations, and is not intended to affect freedom of information or sunshine laws. Mandatory incident reporting, regulator requests and court orders are not blocked by a label. If you need enforceable limits, use a non-disclosure or information sharing agreement and reference TLP in it.
- Not the Chatham House Rule: FIRST notes TLP is distinct from the Chatham House Rule, which protects the identity of speakers, though the two can be used together. MISP's taxonomy includes a separate tag for it.
- Not encryption: a TLP:RED label on a plaintext email to a personal address is still a plaintext email. Choose transport security that matches the label.
Where identity fits
TLP is often applied to the most sensitive identity material a defender ever handles: lists of compromised accounts, leaked API keys and tokens, session cookies from infostealer logs, and details of which service principals an attacker used. Two practical rules follow:
- Act on credentials without leaking them: a recipient can revoke or rotate a leaked key under TLP:AMBER+STRICT without sending the key value to anyone outside the organisation. Share hashes or key identifiers rather than secrets whenever possible.
- Limit access by identity in platforms: enforce label-based access through roles and groups in your intelligence platform, and treat the API keys used by sharing integrations as privileged machine identities. See the Threat Intelligence for Identity and NHI Guide and the API Key Management Guide.
Implementing TLP handling in your organisation
- Write a short handling standard. Define your organisation, your clients and your communities, defaults for unlabelled information, who may approve requests to widen sharing, and where TLP:RED material may be stored.
- Update templates and tooling. Replace TLP:WHITE with TLP:CLEAR in document templates, mail signatures, MISP and STIX mappings, and add AMBER+STRICT everywhere you offer AMBER.
- Train by scenario. Brief analysts, responders and executives with worked examples: an ISAC AMBER bulletin, a peer's AMBER+STRICT timeline, a RED call. Executives who forward advisories are a common leak.
- Pilot controls in alert mode. Turn on DLP and gateway rules that detect labelled content leaving the tenant, review hits for a month, then move TLP:RED and TLP:AMBER+STRICT to block with an approval path.
- Agree terms with partners. For MSSPs, incident response retainers and sharing communities, record in the agreement how TLP is applied and what counts as a client or community.
- Review and roll back safely. If blocking rules disrupt legitimate sharing, return them to alert mode, adjust patterns, and keep the handling standard unchanged.
Small and large organisations: a small team can implement TLP with templates, a one-page standard and mail rules. A large organisation or an MSSP needs label fields enforced in its intelligence platform, client-facing distribution workflows that distinguish AMBER from AMBER+STRICT, and periodic audits of who received RED material.
Detection and measurement
- Label coverage: percentage of outbound intelligence products and incident communications carrying a TLP label.
- Legacy labels: count of new items still tagged TLP:WHITE or using TLP 1.0 markings in STIX feeds; the target is zero.
- Restricted label egress: DLP or gateway hits for TLP:RED and TLP:AMBER+STRICT content sent outside the organisation, and the share confirmed as violations.
- Permission requests: number of requests to widen sharing and median time for the source to answer; a long delay pushes people to ignore labels.
- Derivative tracking: percentage of detection rules and blocklist entries whose source label is recorded.
Framework mapping
| Framework | Reference | TLP relevance |
|---|---|---|
| NIST CSF 2.0 | ID.RA-02 Cyber threat intelligence is received from information sharing forums and sources | Labelled intelligence from ISACs and CERTs |
| NIST CSF 2.0 | RS.CO-03 Information is shared with designated internal and external stakeholders | Labels define who the stakeholders are for each item |
| NIST SP 800-53 Rev. 5 | AC-21 Information Sharing | Authorised users decide whether a partner's access matches the information's restrictions |
| NIST SP 800-53 Rev. 5 | PM-15 Security and Privacy Groups and Associations; PM-16 Threat Awareness Program; SI-5 Security Alerts, Advisories, and Directives | Participation in sharing communities and handling of received advisories |
| NIST SP 800-53 Rev. 5 | MP-3 Media Marking | Marking of distribution limitations on outputs |
| ISO/IEC 27001:2022 | Annex A 5.7 Threat intelligence, 5.13 Labelling of information, 5.14 Information transfer | TLP as a labelling and transfer rule for intelligence |
Common failure patterns
- Treating RED as "my team": a recipient forwards a TLP:RED briefing to colleagues who were not on the call. RED is for the named recipients only.
- AMBER pushed to every customer: an MSSP forwards AMBER+STRICT material to clients because its platform only knows AMBER, breaking the source's trust.
- Labels lost in automation: indicators imported from a restricted feed are exported to a public blocklist or a vendor's cloud lookup without the label.
- Undefined community: TLP:GREEN sent with no community named, so each recipient applies their own definition and the content ends up in a public forum.
- Relying on TLP instead of contract or law: a source assumes a label prevents disclosure under a regulator request or freedom of information law; CISA's guide is clear that it does not.
- Stale TLP 1.0 tooling: templates and feeds still emit TLP:WHITE and lack AMBER+STRICT years after the change.
Practitioner checklist
- Adopt TLP 2.0 definitions word for word from FIRST in your handling standard.
- Define your organisation, clients and communities in writing and in partner agreements.
- Replace TLP:WHITE with TLP:CLEAR and add TLP:AMBER+STRICT in every template and tool.
- Put labels in email subjects, directly before the information, and in document headers and footers.
- Carry labels in MISP tags or STIX 2.1 TLP 2.0 marking definitions, and test export filters.
- Record the source label on every derived detection rule and blocklist entry.
- Route requests to widen sharing to the source and track response times.
- Run DLP rules for restricted labels in alert mode, then block with an approval path.
- Share key identifiers or hashes, not secret values, when warning others about leaked credentials.
Standards and references
- FIRST: Traffic Light Protocol (TLP) version 2.0
- FIRST: Traffic Light Protocol version 1.0
- CISA: Traffic Light Protocol 2.0 User Guide
- CISA: CISA Publishes User Guide to Prepare for Nov 1 Move to TLP 2.0
- OASIS CTI TC: STIX 2.1 TLP 2.0 marking definition extension
- MISP Project: TLP taxonomy
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Threat Intelligence Guide · MISP Threat Sharing Guide · STIX and TAXII Guide · Threat Intelligence Platform Buyer's Guide · Threat Intelligence for Identity and NHI Guide