Traffic Light Protocol Guide: Using TLP 2.0 Labels Correctly in Sharing

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

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

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

1. Read the label and caveats before acting. Record them with the data in your intelligence platform or case.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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

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