Traffic Light Protocol (TLP): How to Share Sensitive Information Correctly

Anyone working in incident response, exchanging threat intelligence, or passing on vulnerability reports keeps running into the same question: who else is actually allowed to see this? An indicator of compromise from an ongoing incident can help other organizations fend off the same attack. But if it ends up on the open internet unfiltered, it also tips off the attacker. The Traffic Light Protocol (TLP) exists precisely for this tension: a deliberately simple labeling scheme that uses four levels to define how far a piece of information may be shared. It has become the de facto standard of the CSIRT world and shows up today in almost every advisory from national CERTs, in ISAC bulletins, and in coordinated vulnerability disclosures.

What the Traffic Light Protocol Is and What It Is Not

The TLP originated in the British government community of the early 2000s and is maintained today by FIRST (Forum of Incident Response and Security Teams), the international umbrella organization of incident response teams. The current edition is TLP Version 2.0, published in August 2022 and mandatory across the FIRST community since January 2023.

Getting the framing right matters: the TLP is not a classification or secrecy regime, and it replaces neither an NDA nor a formal government classification. It is an agreement between sender and recipient built on trust. The source of a piece of information decides how widely it may be distributed, and the recipient commits to respecting that boundary. Nothing is technically enforced — the TLP does not encrypt anything and carries no sanctions. Its value lies elsewhere: it creates a shared, internationally understood vocabulary that lowers the barrier to sharing sensitive information at all. Someone who knows their report will stay within TLP:AMBER is far more likely to pass it on than if the sharing rules had to be renegotiated every single time.

The Four Labels of TLP 2.0

TLP 2.0 defines four labels plus one supplementary designation. The definitions rest on three precisely defined terms: the organization (your own company), its clients (customers and constituents, for example of an MSSP), and the community (the wider security community you operate in).

• TLP:RED — For the eyes and ears of the named recipients only. The information may not be shared with anyone, not even colleagues within the recipient's own organization. Typical for highly sensitive details of an active incident or an unpatched vulnerability.
• TLP:AMBER — Sharing is limited to the recipient's own organization and its clients, and even there only on a need-to-know basis. This is the working level for most operational advisories and incident details.
• TLP:AMBER+STRICT — Like AMBER, but strictly limited to the recipient's own organization. Clients are excluded. This supplementary label was introduced with version 2.0 because the old AMBER was interpreted inconsistently in practice.
• TLP:GREEN — Sharing is permitted within the community, for example in your ISAC or among peers. Publication via publicly accessible channels is not allowed.
• TLP:CLEAR — No restriction on disclosure. The information may be distributed publicly, subject to standard copyright rules.

If a recipient needs broader distribution than the label allows, there is exactly one legitimate path: obtaining explicit permission from the source. Unilaterally downgrading a label is a breach of trust that will dry up the information flow the next time an incident hits.

What Changed With Version 2.0

The most visible change in TLP 2.0 is the renaming of TLP:WHITE to TLP:CLEAR. The reason is pragmatic: "white" renders poorly on light backgrounds and the term was ambiguous internationally. In addition, TLP:AMBER+STRICT was added, and the definitions were linguistically simplified so they can be translated unambiguously by non-native English speakers. Anyone still writing TLP:WHITE today is using an outdated standard, which regularly triggers follow-up questions in practice.

Adoption of version 2.0 is now widespread. The US agency CISA has adopted TLP 2.0, and in Germany the BSI works with it throughout: CERT-Bund advisories carry TLP labels, and participants in the UP KRITIS public-private partnership formally commit to complying with the protocol. The corresponding BSI leaflet on secure information exchange with the TLP is the authoritative German-language reference.

Applying TLP Correctly: Marking and Formalities

The standard makes concrete demands on how labels are applied, and following them pays off because automated systems and recipients rely on it. The label is always written in capital letters with no spaces — TLP:RED, not "tlp red". In emails it belongs in the subject line and in the body immediately before the labeled information. In documents it goes right-aligned in the header and footer of every page. TLP 2.0 even defines the exact color values for rendering the labels on a dark background so they look identical everywhere.

Beyond that, a few ground rules have proven themselves in practice. Information arriving without a TLP label should be treated as TLP:AMBER by default, with a follow-up question to the sender. Individual sections within one document can carry different labels, for example a TLP:CLEAR executive summary followed by TLP:AMBER details. And anyone assigning labels should resist the reflex of marking everything RED: an overly strict label prevents exactly the distribution that gives the information its value. The right question is not "what is maximally safe?" but "who needs to know this for it to be useful, and at what point does it cause harm?".

Limits of the Protocol

As useful as the TLP is, its limits need to be understood. It provides no technical protection whatsoever: a TLP:RED document in an unencrypted email remains an unencrypted document. Labeling must therefore always be accompanied by appropriate technical measures, from transport encryption to access restrictions. Legally, the TLP is non-binding unless it is backed by an explicit commitment or contract, as is the case in UP KRITIS. Where information protection has to be enforceable, there is no way around NDAs and contracts. Finally, the TLP does not override regulatory duties: statutory reporting and disclosure obligations, for example under NIS-2 or the Cyber Resilience Act, remain unaffected by a TLP label.

Conclusion

The Traffic Light Protocol solves a real problem with minimal means: four labels, clear terms, understood internationally. For organizations that receive threat intelligence, participate in ISACs, or disclose vulnerabilities in a coordinated way, clean TLP usage is simply part of the craft. The effort to adopt it is modest: train the TLP 2.0 labels internally, anchor the marking rules in email and report templates, and when in doubt ask the source instead of sharing unilaterally. Organizations that live this consistently are perceived as trustworthy partners in information exchange — and in a crisis they receive exactly the information others would withhold.