22 Definition Entries for "Threat" — On One NIST Page

Source: NIST CSRC Glossary: Cyber Threat
Visit this page yourself. Count the definition blocks. Then ask: how can we build a risk-based security program on terminology this unstable?

The Glossary Page That Explains Everything

If anyone ever asks me why cybersecurity has a "language problem," I now have a single URL to share.

The National Institute of Standards and Technology — the organization that defines cybersecurity standards for the United States government — cannot agree with itself on what "threat" means.

On one glossary page, they list 22 separate definition entries for "cyber threat" or "threat" across their publications. Some are near-duplicates sourced from different documents. Others are fundamentally different conceptual definitions.

The Definitional Chaos

Here's a sample of what you'll find:

Definition 1 (NIST SP 800-160v1r1):
"Potential cause of unacceptable asset loss..."

Definition 2 (NISTIR 7435):
"the likelihood or frequency of a harmful event occurring"

Definition 3 (NIST SP 800-28):
"A possible danger to a computer system..."

Definition 4 (NISTIR 8053):
"potential cause of an unwanted incident..."

Definition 5 (NIST SP 800-221):
"Any circumstance or event with the potential to adversely impact organizational operations."

And seventeen more variations.

"But It's Just an Aggregation"

NIST's glossary includes a disclaimer: definitions are extracted from multiple publications and should not necessarily be viewed as "official" or "preferred" definitions.

This doesn't weaken the critique — it explains why the page looks like this, and sharpens the real problem:

• This is the page people cite as "the NIST definition."
• When a CISO needs to define "threat" for a board presentation, when a vendor writes a compliance mapping, when an auditor checks terminology — they come to this glossary. The disclaimer doesn't appear in the documents that reference these definitions. The chaos propagates.

Why This Matters

Notice something critical: NISTIR 7435 defines threat as a probability measure ("likelihood or frequency"). Meanwhile, SP 800-160v1r1 defines it as a cause ("Potential cause of unacceptable asset loss").

These aren't the same category of thing. One is an ontological entity (a cause). The other is a mathematical property (a probability).

When "threat" sometimes means cause/event and sometimes means frequency/likelihood, teams build incompatible risk models and talk past each other.

Consider: NIST risk publications typically frame risk in terms of likelihood × impact, with "threat" feeding into the likelihood assessment. But if one team treats "threat" as the thing that attacks (an entity to be characterized), while another team treats "threat" as how often attacks occur (a frequency to be measured), their risk assessments become incommensurable — even when both teams claim to follow "NIST guidance."

This isn't pedantry. It's why security teams and business leadership consistently fail to communicate about risk.

The Scope Creep Problem

Beyond the conceptual confusion, there's inconsistent scope:

When the same organization can't maintain consistent scope in their definitions, how can we expect alignment across an industry that includes vendors, regulators, insurers, and practitioners — each with their own definitional preferences?

The Uncomfortable Question

NIST provides the definitional foundation for:

• Federal cybersecurity requirements
• NIST Cybersecurity Framework (adopted globally)
• FedRAMP, FISMA, and countless compliance regimes
• Private sector security programs built on NIST guidance

And their own glossary demonstrates they haven't settled on what the most fundamental term in the field actually means — 22 entries worth of unsettled.

This isn't a criticism of NIST specifically. They're documenting a field-wide reality: cybersecurity has never established paradigmatic consensus on its core concepts. We're still pre-Newtonian — a field with competing schools, incompatible vocabularies, and no shared foundation.

What Would Precision Look Like?

A rigorous definition of "threat" should:

1. Distinguish cause from consequence — Threats are not the damage they produce
2. Separate probability from entity — "Threat" is what attacks; "likelihood" is how often
3. Identify the mechanism — What generic vulnerability does this threat exploit?
4. Enable control mapping — If you can't connect threats to specific control types, the definition is operationally useless

The 22 definition entries on that NIST page serve none of these functions consistently.

The Path Forward

The TLCTC framework exists precisely because this problem needed solving. By classifying threats according to their root cause — the generic vulnerability they exploit — rather than their outcomes, labels, or arbitrary taxonomic decisions, we can:

• Map any specific threat to exactly one of 10 clusters
• Connect those clusters to specific control families
• Create a shared vocabulary that doesn't drift based on which document you're reading
• Build risk models that don't double-count probability

The NIST glossary page isn't evidence of institutional failure. It's evidence of a field that outgrew its vocabulary. The question is whether we keep building on definitional quicksand, or establish the semantic foundation that precision security requires.

See the source for yourself: https://csrc.nist.gov/glossary/term/cyber_threat