FIRST Traffic Light Protocol (TLP) 2.0, explained

TLP (Traffic Light Protocol) 2.0 is the current, FIRST-maintained standard for labeling how far a piece of potentially sensitive security information is allowed to travel once it leaves its source. Four labels — TLP:RED, TLP:AMBER (with an AMBER+STRICT variant), TLP:GREEN and TLP:CLEAR — tell a recipient, in plain language, who they may pass information on to. Published by FIRST's TLP Special Interest Group in August 2022 after a three-year, 50-plus-expert consultation, version 2.0 replaced the 2016-era TLP 1.0 and is now the baseline nearly every PSIRT, CSIRT and information-sharing community — including SoftWSP's own PSIRT-setup guidance — builds its sharing rules on top of.

Where TLP came from

TLP did not start as a FIRST product. According to FIRST's own history, as recounted in its version 2.0 release announcement, the protocol was "established in 1999 by the National Infrastructure Security Co-ordination Center (NISCC)" — a UK government body — to let analysts share threat information with industry without it leaking further than intended. It "gradually became well-known globally," and in 2015 "FIRST took the lead in unifying and standardizing the TLP." That unification work produced TLP 1.0, announced by FIRST on 31 August 2016, which the announcement says had "achieved 'de facto' international standard status" even before formal standardization, already in use by "various types of CSIRTs, operational trust communities, information sharing analysis organizations, government agencies, and private researchers."

TLP 1.0 stood for six years. In 2019, over 50 security incident-response professionals reconvened as the FIRST TLP Special Interest Group (TLP-SIG) specifically to improve "content, language, supporting materials, and accessibility." The resulting TLP 2.0 was finalized and released on 5 August 2022, with FIRST stating it is "authoritative from August 2022 onwards" and that TLP 1.0 is correspondingly marked "Deprecated August 2022" on FIRST's own download page.

The four labels, verbatim

TLP's §3 defines each label with both a one-line meaning and operational guidance for sources and recipients:

Label	Meaning (verbatim)	Who it's for
TLP:RED	"For the eyes and ears of individual recipients only, no further disclosure."	Information that "cannot be effectively acted upon without significant risk for the privacy, reputation, or operations of the organizations involved." In a meeting, RED is limited to those present.
TLP:AMBER	"Limited disclosure, recipients can only spread this on a need-to-know basis within their organization and its clients."	Information needing support to act on, but risky if shared outside the organizations involved. "Clients" are, by TLP's own definition, people or entities receiving cybersecurity services from the organization — included by default so they can act to protect themselves.
TLP:AMBER+STRICT	A restriction on AMBER: "if the source wants to restrict sharing to the organization only, they must specify TLP:AMBER+STRICT."	Same risk profile as AMBER, but the source does not want the organization's clients included.
TLP:GREEN	"Limited disclosure, recipients can spread this within their community."	Information useful for wider community awareness, shareable with "peers and partner organizations... but not via publicly accessible channels." Default community, if undefined, is "the cybersecurity/defense community."
TLP:CLEAR	"Recipients can spread this to the world, there is no limit on disclosure."	Information with "minimal or no foreseeable risk of misuse," shareable "without restriction," subject to ordinary copyright rules.

Two label-writing rules apply across the board, per §1.b: labels "MUST not contain spaces and SHOULD be in capitals," and they "MUST remain in their original form, even when used in other languages" — a document can be translated, but TLP:AMBER stays TLP:AMBER regardless of the surrounding language.

What changed from TLP 1.0

FIRST's own release announcement lists the changes it considers most significant, and two of them are visible the moment you look at a label:

1. TLP:WHITE became TLP:CLEAR. The old "WHITE" label (public, no restriction) was retired in favor of "CLEAR" — same meaning, different word.
2. TLP:AMBER+STRICT was added, to let a source restrict AMBER-level information to "the recipient's organization only," closing a gap where AMBER's default client-inclusion wasn't always what the source wanted.

Beyond the two label changes, FIRST states it: "Removed synonyms and colloquialisms to improve accessibility for non-native English speakers and ease of translation"; added formal Community, Organization and Clients definitions it had never spelled out before; and added an RGB/CMYK/Hex color table so TLP's familiar red/amber/green/clear visual scheme renders consistently across tools and print. FIRST TLP-SIG co-chair Don Stikvoort framed the goal directly in the release: "We need systems that are easy to use, simple to understand, and straightforward enough that translation does not impact the meaning." CISA — the US Cybersecurity and Infrastructure Security Agency — committed to a hard cutover date in its own fact sheet, stating it "will officially move from TLP 1.0 to TLP 2.0 on November 1, 2022," while FIRST's broader target was worldwide adoption "by January 2023."

Using TLP correctly: messages, documents, automated exchanges

TLP 2.0's §2 sets explicit MUST/SHOULD rules, using the RFC-2119 convention the standard cites directly, for three distinct channels:

• Messaging (email, chat): the TLP label "MUST" appear "directly prior to the information itself," and "SHOULD" be in the email subject line. Where the labeled content doesn't run to the end of the message, the sender should also mark where it ends.
• Documents: the label "MUST" appear "in the header and footer of each page," "SHOULD" be at least 12-point type "for users with low vision," and right-justification "is recommended" — all choices the standard frames explicitly around accessibility.
• Automated information exchanges (e.g. MISP, IEP): TLP 2.0 deliberately does not define the mechanism — "this is left to the designers of such exchanges, but MUST be in accordance with this standard." CISA's own TLP 2.0 materials add that automated-exchange designers who built against TLP 1.0 "should ensure they upgrade their exchanges to TLP 2.0."

CISA's fact sheet also documents a convention the FIRST standard itself doesn't spell out: for verbal discussions and conference talks, "participants should assume information is TLP:CLEAR if the speaker does not provide a designation" — a sensible default given TLP:CLEAR's own definition of "no limit on disclosure."

What TLP is explicitly not

The standard is unusually direct about its own limits, in §1.c: "TLP is not a formal classification scheme. TLP was not designed to handle licensing terms, nor information handling or encryption rules. TLP labels and their definitions are not intended to have any effect on freedom of information or 'sunshine' laws in any jurisdiction." CISA's plain-language fact sheet puts the same point to a general audience: "Unlike formal classification systems, TLP is not legally binding." The standard also separately notes, in §1.e, that TLP "is distinct from the Chatham House Rule, but may be used in conjunction when appropriate" — the two solve different problems (Chatham House governs attribution of statements, not redistribution of documents) and are not substitutes for each other.

Responsibility under TLP sits with the source, not an external authority: §1.f-h state the source "is responsible for ensuring that recipients of TLP-labeled information understand and can follow TLP sharing guidance," may add further restrictions recipients "must" adhere to, and that a recipient wanting to share more widely than a label allows "must obtain explicit permission from the source" first. There is no TLP governing body that adjudicates violations the way a formal classification authority would — compliance runs on trust between source and recipient, which is why FIRST calls TLP "optimized for ease of adoption, human readability and person-to-person sharing" rather than a security-clearance-style control.

A workable starting point

1. Use the five current labels, not the six you might remember. If your organization's templates, playbooks or ISAC agreements still reference TLP:WHITE, update them — it was retired in 2022, and FIRST's own standard calls TLP 1.0 "Deprecated."
2. Decide your default for client-facing AMBER information up front. TLP:AMBER includes an organization's clients by default; if a given advisory or report should stop at your own staff, label it TLP:AMBER+STRICT explicitly rather than assuming recipients will infer the narrower scope.
3. Put the label where the rules say it goes — subject line for email, header and footer for documents — rather than only in a cover note; a recipient who forwards just the body text should still see the label.
4. Don't treat TLP as a substitute for a real access-control or NDA regime. The standard itself disclaims any legal force; if information genuinely needs enforceable confidentiality, pair TLP with a contractual or regulatory control, not instead of one.
5. If you're building or consuming automated advisory feeds (CSAF/VEX, MISP, custom APIs), confirm explicitly how TLP labels map onto your schema — the standard leaves this undefined by design, so two systems' "TLP 2.0 support" can still disagree without a shared convention.

Most CRA, NIS2 and PSIRT vulnerability-handling obligations assume a working information-sharing discipline underneath them — see the CVD process explained and CSAF/VEX for device makers for the surrounding machinery. SoftWSP's PSIRT setup work builds TLP-aware intake and advisory-sharing workflows into a device maker's disclosure program from day one: see PSIRT services.

This guide quotes FIRST's own published TLP 2.0 standard text (Introduction, Usage, and Definitions sections), FIRST's official TLP 2.0 and TLP 1.0 release announcements, and CISA's September 2022 TLP 2.0 fact sheet; it is not a substitute for the full standard at first.org/tlp, and does not constitute legal advice. FIRST's TLP 2.0 standard document is copyrighted material (© 2015—2026 Forum of Incident Response and Security Teams, Inc.) — the short excerpts quoted here are reproduced for commentary and identification, not as a substitute for reading the source.