Top Level Cyber Threat Clusters (TLCTC)

Version 2.5 · CC BY 4.0 · · tlctc.net · Core Paper (citable) · White Paper

A cause-oriented, axiomatic cyber threat taxonomy. We are aware of no prior framework that classifies threats by the generic vulnerability exploited rather than by outcome or actor.

TLCTC provides the missing semantic foundation for cybersecurity: a stable, non-overlapping classification of cyber threats based on why compromise happens — the generic vulnerability exploited — rather than what happens afterwards (outcomes like "data breach," "ransomware," or "denial of service").

A cyber threat is defined by the generic vulnerability it exploits, not by who performs it and not by what consequence follows.

---

Framework Documents

TLCTC v2.5 is the current citable baseline: the v2.3 consolidation freeze of the finalized v2.1 framework, plus the v2.4 interaction-model clarification and the v2.5 disambiguation rules R-CHANNEL and R-SUBSTRATE (see tlctc-traceability.md). The documents form a deliberate hierarchy:

Document	Role
Core Paper (PDF)	The canonical, citable definition of the framework: derivation, 10 clusters, 10 axioms, 18 classification rules, attack-path notation, glossary, references. Cite this.
Application Paper (PDF)	Companion for putting the taxonomy to work: classification procedure, worked examples, NIST CSF mapping, controls, KRI/KCI/KPI. Takes the core as given.
White Paper (web)	The extended practitioner handbook: full notation grammar (§11), boundary catalogs, decision procedures, anti-patterns, and worked detail beyond the core. Conforms to the core; filename kept for link stability.
Operational Enumeration (JSON)	The evolving TLCTC-XX.YY sub-cluster catalogue. The strategic layer (10 clusters) is frozen; the operational layer grows by contribution.

Machine-readable twin of the core: json-schemas/layer-1/tlctc-framework.v2.5.json. The v2.3 and v2.4 dictionaries are retained unchanged as frozen records for classifications made under those versions.

---

The Problem: Semantic Diffusion

Cybersecurity suffers from a persistent language problem. "Threat" is used interchangeably for actors, vulnerabilities, control failures, incidents, and outcomes. Even authoritative sources maintain conflicting definitions — NIST alone carries over 20 different definitions of "cyber threat" across its publications. This semantic blur makes it impossible to compare incidents, aggregate intelligence, design targeted controls, or communicate risk consistently between leadership, risk functions, and technical teams.

TLCTC solves this by anchoring analysis in causality and enforcing strict separation through formal axioms.

Core Architecture

The Bow-Tie Anchor

TLCTC is structurally anchored in the Bow-Tie risk model, which enforces the separation between causes and effects:

   CAUSE SIDE                    RISK EVENT                 CONSEQUENCE SIDE
┌──────────────────┐     ┌─────────────────────┐     ┌──────────────────────┐
│  Threat Clusters  │     │  Loss of Control /  │     │   Data Risk Events   │
│  (#1 – #10)      │────▶│  System Compromise  │────▶│   (C, I, A)          │
│  Generic Vulns    │     │     [DETECT]        │     │   Business Impact    │
│                   │     │                     │     │                      │
│  IDENTIFY/PROTECT │     └─────────────────────┘     │  RESPOND/RECOVER     │
└──────────────────┘                                   └──────────────────────┘

Threat clusters live exclusively on the cause side. Outcomes such as Loss of Confidentiality, Loss of Integrity, or Loss of Availability/Accessibility are recorded separately as Data Risk Events (DREs) — never as threat categories.

The Two-Tiered Approach

TLCTC strictly separates two layers that must align without collapsing into each other:

Layer	Focus	Stability	Audience
Strategic Management	10 clusters, generic vulnerabilities, risk governance, control mapping	Stable	CISO, Risk, Board
Operational Security	Specific CVEs, CWEs, MITRE ATT&CK TTPs, detection rules	Dynamic	SOC, Engineering, DevSec

This separation ensures that strategic risk discussions remain comparable across technologies, environments, and organizations — while operational teams retain full granularity.

---

The 10 Top Level Cyber Threat Clusters

Each cluster is defined by exactly one generic vulnerability (Axiom VI). Each attack step maps to exactly one cluster. No overlaps, no gaps.

#	Cluster	Generic Vulnerability	Topology
#1	Abuse of Functions	The inherent trust, scope, and complexity designed into software functionality and configuration	Internal
#2	Exploiting Server	Server-side implementation flaws enable unintended behavior	Internal
#3	Exploiting Client	Client-side implementation flaws enable unintended behavior	Internal
#4	Identity Theft	Insufficient binding, at the point of authentication, between a presented credential and the authentic holder of the identity it claims	Internal
#5	Man in the Middle	The lack of sufficient control over the communication path	Internal
#6	Flooding Attack	Finite capacity limitations inherent in any system component	Internal
#7	Malware	The software environment's designed capability to execute potentially untrusted foreign code	Internal
#8	Physical Attack	Physical accessibility of infrastructure and the exploitability of physical-layer properties	Bridge
#9	Social Engineering	Humans can be influenced into unsafe actions or decisions	Bridge
#10	Supply Chain Attack	Trust in third-party components and update channels can be subverted	Bridge

Cluster Scope (operational)

The generic-vulnerability strings above are reproduced verbatim from the canonical framework dictionary (json-schemas/layer-1/tlctc-framework.v2.5.json), which also carries the canonical one-line Definition and Attacker's View per cluster. The scope descriptions below are the operational elaborations from the white paper §4.1.

• #1 Abuse of Functions — Manipulation of legitimate software capabilities — features, APIs, configurations, administrative settings, workflows — through standard interfaces using built-in input types and valid sequences of actions. The step achieves an attacker advantage without requiring an implementation flaw.

• #2 Exploiting Server — Triggering an implementation flaw in server-role software using exploit code, exploiting coding mistakes in how the server processes requests, handles data, enforces logic, or manages resources. This forces an unintended data→code transition.

• #3 Exploiting Client — Triggering an implementation flaw in client-role software through crafted content, responses, or state, exploiting coding mistakes in parsing, rendering, state management, or response handling.

• #4 Identity Theft — Presentation or use of credentials, tokens, keys, session artifacts, or other identity representations to authenticate and act as an identity different from the presenter's own. This cluster focuses on the use of credentials — acquisition maps to the enabling cluster (see Credential Dual Nature below).

• #5 Man in the Middle (MitM) — Exploitation of a controlled position on a communication path through interception, observation, modification, injection, replay, or protocol downgrade/stripping.

• #6 Flooding Attack — Exhaustion of finite system resources (bandwidth, CPU, memory, storage, quotas, pools) through volume or intensity that exceeds capacity limits, causing disruption, degradation, or denial of service.

• #7 Malware — Execution of Foreign Executable Content (FEC) through the environment's designed execution capabilities (binaries, scripts, macros, modules, or attacker-controlled commands fed into interpreters), including dual-use tooling when it executes attacker-controlled FEC.

• #8 Physical Attack — Unauthorized physical interaction with or interference to hardware, facilities, media, interfaces (including removable media), or signals — via direct contact or exploitation of physical phenomena/emanations.

• #9 Social Engineering — Psychological manipulation that causes a human to perform an action counter to security interests — disclosing information, granting access, executing content, modifying configuration, or bypassing procedures.

• #10 Supply Chain Attack — Exploitation of an organization's third-party trust link such that the organization accepts third-party-originating artifacts or decisions as authoritative within its domain, enabling unauthorized action or compromise. Placed at the Trust Acceptance Event (TAE).

---

Key Concepts

Data→Code Transitions and R-EXEC

The execution distinction is the sharpest analytical tool in the framework. Four data paths exist:

Path	Mechanism	Cluster
Data → Data	Pure data manipulation, no code execution	#1 only
Data → Function → Foreign Code	Function abuse enables code execution	#1 → #7
Data → Code via Implementation Flaw	Unintended transition (exploit code triggers bug)	#2 or #3
Data → Code via Designed Capability	Intended execution (malware code uses execution engine)	#7

R-EXEC Rule (Normative): Whenever Foreign Executable Content (FEC) is executed, a #7 step MUST be recorded at the moment of execution, independent of how execution was enabled. Analysts must not "absorb" execution into the enabling cluster.

Common execution patterns: #1 → #7 · #2 → #7 · #3 → #7 · #8 → #7 · #9 → #7 · #10 → #7

Credential Dual Nature (Axiom X)

Credentials have two distinct operational phases, and they must be classified separately:

Phase	Classification	Example
Acquisition	Maps to the enabling cluster (the generic vulnerability that exposed the credential)	#2 (SQLi dumps passwords), #5 (MitM intercepts token), #9 (phishing captures password)
Application	#4 — regardless of how the credential was obtained, provided the identity claimed is not the presenter's own (a system-issued self-enrolled identity used as self is not #4; out-of-scope enrolment is #1, per R-CRED)	Attacker logs in using stolen credentials → #4

Attack Velocity (Δt) and Velocity Classes

Attack Velocity is the time interval between two adjacent attack steps. It is the most accurate predictor of which control types are structurally viable — a detection that alerts in hours is structurally insufficient if Δt between steps is minutes.

Class	Time Range	Defender's Feasible Response Mode
VC-1	Days → Months	Strategic: Log retention, threat hunting, strategic monitoring
VC-2	Hours	Tactical: SIEM alerting, analyst triage, guided response
VC-3	Minutes	Operational: Automation (SOAR/EDR), rapid containment, prebuilt playbooks
VC-4	Seconds → Milliseconds	Real-Time: Architecture & circuit breakers, rate-limits, hardening, automatic isolation

---

Attack Path Notation

Complex attacks are not single events — they are sequences. TLCTC provides a standardized notation to map multi-step attack paths with full temporal and topological context.

Notation Elements

Element	Syntax	Purpose
Sequential step	→	Links cause-side steps in order
Parallel steps	(#X + #Y)	Concurrent exploitation of distinct generic vulnerabilities
Velocity annotation	→[Δt=value]→	Time interval between steps (e.g., →[Δt=15m]→, →[Δt=~2h]→)
Domain boundary	||[context][@Source→@Target]||	Marks where attack crosses responsibility spheres
Transit boundary	||[context][@Source⇒@Carrier→@Target]||	Marks intermediate carrier/relay spheres (⇒ = transit)
Intra-system boundary	|[type][@from→@to]|	Within-host boundary crossing (sandbox, privilege, process, hypervisor)
Unresolved step	? / …	Forensic uncertainty — step exists but cluster cannot yet be determined
Data Risk Event	+ [DRE: C, I, A]	Annotates consequences (never a step itself)

Boundary Operators

TLCTC provides three boundary operators — all are observability annotations that increase analytical precision without changing cluster classification.

Domain Boundary Operator (||...||)

Marks where an attack crosses between responsibility spheres (inter-organizational boundaries):

||[context][@Source→@Target]||

Transit Boundary Operator (⇒)

Identifies intermediate responsibility spheres that relay an attack without being its source or target:

||[context][@Source⇒@Carrier→@Target]||          # single transit party
||[context][@Source⇒@CarrierB⇒@CarrierA→@Target]||  # chained transit (right-to-left relay)

Example: SMS-based phishing where the SMS gateway relays the malicious link:

#9 ||[messaging][@Attacker⇒@SMSProvider→@Victim]||

Transit ≠ Supply Chain (#10). Transit marks a relay/carrier that passes the attack through. #10 marks a Trust Acceptance Event — the moment a trust artifact becomes authoritative inside the target domain. An SMS provider relaying a phishing link is transit; a compromised npm package installed by the target is #10.

Intra-System Boundary Operator (|[type][@from→@to]|)

Annotates boundary crossings within a single host or system — as opposed to domain boundaries (||...||) which cross between responsibility spheres.

Type	Description	Example
sandbox	Escape from application sandbox to host OS or less-restricted context	Browser renderer sandbox escape, container breakout
privilege	Elevation from lower to higher privilege level	User-to-root, unprivileged to kernel mode
process	Crossing from one process's security context to another	Process injection, DLL hijacking
hypervisor	Escape from VM to hypervisor or another VM	VM escape, hyperjacking

#3 |[sandbox][@renderer→@os]|    # browser exploit escaping renderer sandbox
#2 |[privilege][@user→@root]|    # local privilege escalation via server-side flaw

Boundary Classification Rules

Rule	Statement
R-TRANSIT-3	Vendor code running on the target device is NOT transit. Safari on the victim's phone is the attack surface (classify by R-ROLE as #3), not a transit party.
R-INTRA-7	Intra-system boundaries never change cluster classification. They are observability annotations, not classification inputs.
R-INTRA-9	The memory boundary type is explicitly deferred and MUST NOT be used.

Boundary Context Vocabulary

The context vocabulary is extensible. The baseline profile defines 16 context types:

messaging · email · cdn · cloud · network · signaling · auth · media · browser · exploit · dev · update · physical · human · legal · admin

Unresolved-Step Operators (?, …)

Incident analysis is iterative — evidence arrives over time and CTI must flow before classification is complete. Paths support two operators for forensic uncertainty:

Operator	Name	Meaning
?	Single Unresolved Step	Exactly one step occurred at this position, but its cluster cannot yet be determined
…	Unresolved Gap	At least one step occurred in this region; both count and clusters are unknown

Example: #3 →[Δt=0s] #7 →[Δt=4h] ? →[Δt=<10m] #4 → #1

Key rules:

• ? and … are epistemic annotations, not clusters — they have no generic vulnerability (R-UNRES-2)
• DRE tags MUST NOT be appended to ?/… (R-UNRES-5)
• Boundary operators MAY appear adjacent to ?/… — boundaries are independently observable (R-UNRES-6)
• Every ?/… MUST carry a prose notes annotation explaining what is unresolved and why (R-UNRES-8)

Epistemic State Hierarchy

The notation carries four distinct epistemic states for a step:

State	Syntax	Use when
Classified	#X	Cluster assigned, evidence supports it
Low-confidence	#X [conf=low]	Best-supported cluster with explicit caveat
Inferred	#X [inferred]	Not directly observed but logically required
Unresolved	? or …	No cluster can be defended on available evidence

If any cluster can be defended — even weakly — use #X [conf=low], not ?. Reserve unresolved operators for genuine "we know something happened, we don't know what" situations.

Example: Deconstructing "Ransomware"

"Ransomware" is not a threat — it's an outcome label that obscures the actual attack sequence. Here is what a typical ransomware campaign looks like in TLCTC:

Scenario: Phishing email delivers a malicious macro. The malware steals credentials. The attacker uses the credentials to abuse Active Directory while simultaneously deploying an encryption payload.

TLCTC Attack Path:

#9 ||[human][@External→@Org]|| →[Δt=24h] #7 →[Δt=5m] #4 →[Δt=15m] #1 → #7 + [DRE: Ac]

Reading this notation:

1. #9 — Social engineering (phishing email) crosses from external to organization domain
2. →[Δt=24h] — 24 hours until victim opens attachment
3. #7 — Malware executes (malicious macro runs via designed execution capability)
4. →[Δt=5m] — 5 minutes later, credentials are exfiltrated
5. #4 — Stolen credentials are used (identity theft — credential application)
6. →[Δt=15m] — 15 minutes of lateral movement
7. #1 → #7 — AD function abuse deploys/pushes the encryption payload (#1), then the payload executes (#7); per R-EXEC, #7 is recorded at the execution moment — after its enabler. The order is known, so this is sequential, not parallel (see White Paper §11.2.2)
8. + [DRE: Ac] — Consequence: Loss of Accessibility (data exists but is unusable)

Note: The consequence is Loss of Accessibility (data present but encrypted/unusable), not Loss of Availability (data gone or infrastructure unreachable). This distinction matters for incident response.

More Path Examples

Supply chain trusted update (SolarWinds-style):

#10 ||[update][@Vendor→@Org]|| →[Δt=0s] #7 →[Δt=hours] #4 →[Δt=days] #1 + [DRE: C]

Physical access to interception:

#8 ||[physical][@Facilities→@IT]|| → #5 → #4

Federated access abuse:

#4 → #10 ||[auth][@Vendor(IdP)→@Org(SP)]|| → #1

SMS phishing with transit carrier:

#9 ||[messaging][@Attacker⇒@SMSProvider→@Victim]|| →[Δt=1h] #7 →[Δt=5m] #4 + [DRE: C]

Browser exploit with sandbox escape:

#3 |[sandbox][@renderer→@os]| →[Δt=0s] #7 |[privilege][@user→@system]| →[Δt=2m] #4 + [DRE: C, I]

Watering hole via compromised CDN with chained transit:

#9 ||[browser][@Attacker⇒@CDN⇒@AdNetwork→@Victim]|| →[Δt=0s] #3 |[sandbox][@renderer→@os]| →[Δt=0s] #7 + [DRE: C]

---

The Rosetta Stone: Translating Other Frameworks

TLCTC acts as the strategic translation layer — a shared semantic backbone that connects operational frameworks without replacing them.

CVEs and CWEs → TLCTC

Every specific CVE is an instance of a generic vulnerability and maps to a primary TLCTC cluster. The hierarchy flows: Weakness (CWE) → Specific Vulnerability (CVE) → Generic Vulnerability → Threat Cluster (#1–#10).

Example: An RCE vulnerability in Apache Struts (CVE-2017-5638) is a server-side implementation flaw → #2 Exploiting Server. If the exploit leads to code execution → #2 → #7.

The mappings/mitre-cwe/ directory contains the mapping of 985 CWE weaknesses to TLCTC clusters, including rationale, confidence verdicts, CVE references, and a decision tree methodology. Because CWE defines the flaw while TLCTC defines the exploit vector, the same CWE can map to different clusters depending on context (e.g., server-side vs. client-side). See the CWE mapping README for notation and the decision tree for classification methodology.

Note: The CWE mapping was generated with AI assistance and is marked experimental.

MITRE ATT&CK → TLCTC

Operational techniques map to strategic clusters based on the generic vulnerability exploited. The mappings/mitre-attack-enterprise/ directory contains the complete mapping of 698 ATT&CK Enterprise techniques to TLCTC clusters, including detailed rationale for each classification and a decision tree methodology.

Quick examples:

• T1566.001 "Spearphishing Attachment" → #9 Social Engineering (the phishing step; the payload execution is a separate #7 step)
• T1059 "Command and Scripting Interpreter" → #7 Malware (or #1 → #7 when legitimate tools execute attacker-controlled content)
• T1078 "Valid Accounts" → #4 Identity Theft (credential application)

See the mapping README for notation conventions, the decision tree for classification methodology, and the SOC-to-risk walkthrough for a worked example.

Sigma Detection Rules → TLCTC

Detection rules carry the strategic cluster their logic defends. The mappings/sigma/ directory contains a per-rule TLCTC derivation of 3,132 SigmaHQ detection rules, generated mechanically from each rule's attack.t* tags joined against the ATT&CK→TLCTC mapping. This lets a SOC cross-walk its detection coverage against the ten clusters — which causes are well-instrumented, and which are blind spots.

Each rule resolves to one of three states: ok (a single concrete cluster), ambiguous (the rule spans multiple clusters or an alternation), or unmapped (no usable ATT&CK technique tag). No rule detection bodies are reproduced — only titles, GUIDs, log sources, and the derived clusters (license-safe). The committed snapshot is rebuilt by a deterministic, dependency-free generator (primaryCluster is the lowest-numbered cluster in the resolved set).

See the mapping README for the record schema and regeneration recipe, and the decision tree for the resolution algorithm.

Note: Like the ATT&CK and CWE mappings, the Sigma derivation inherits the experimental, AI-generated ATT&CK→TLCTC mapping.

SARIF Scanner Findings → TLCTC

Any scanner that emits SARIF 2.1.0 (Semgrep, CodeQL, Trivy, Grype, Bandit, gosec) can be cluster-classified without a per-tool adapter. The integrations/sarif/ pack is a standalone, stdlib-only Python CLI that mines CWE/CVE identifiers from any SARIF file, classifies CWE-first against the canonical CWE→TLCTC mapping with a CVE→KEV fallback, resolves ambiguous #2 | #3 findings by file-path role (R-ROLE), and emits JSON, Markdown, or TLCTC-enriched SARIF. A --fail-on-cluster gate turns it into a CI check. See the pack README and deploy guide.

NIST CSF 2.0 → TLCTC

Controls are organized in a cluster × function matrix. NIST CSF 2.0 defines 6 functions: GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER. GOVERN operates as the overarching strategic governance layer providing assurance controls, while the remaining 5 map directly to Bow-Tie positions:

Bow-Tie Position	NIST CSF 2.0 Functions	Purpose
Strategic Oversight	GOVERN	Risk appetite, policies, roles — assurance controls
Cause Side (Prevention)	IDENTIFY, PROTECT	Reduce likelihood of cluster steps reaching the central event
Central Event	DETECT	Recognize when loss of control occurs
Consequence Side (Mitigation)	RESPOND, RECOVER	Contain impact, restore operations after compromise

---

JSON Architecture

The TLCTC JSON architecture enables machine-readable threat intelligence sharing through a three-layer design that separates stable definitions from dynamic incident data.

Three-Layer Structure

Layer	Purpose	Artifact	Scope	Update Frequency
Layer 1 — Framework Definition	Immutable "dictionary": clusters, axioms, rule IDs, topology types	tlctc-framework.schema.json / tlctc-framework.v2.5.json	Universal	Rarely (framework evolution)
Layer 2 — Reference Registry	Reusable reference objects: responsibility spheres, boundary contexts, intra-system boundary types	tlctc-reference.schema.json / @Org-registry.vX.Y.Z.json	Organization-specific	Occasionally (org changes)
Layer 3 — Attack Path Instances	Specific incidents: sequences, parallel groups, Δt, boundary annotations, DREs	tlctc-attack-path.schema.json / incident-<id>.json	Per-incident	Constantly (new incidents)

Layer 4 — Risk Quantification (optional extension, proposed): a FAIR bridge that quantifies financial risk over a Layer 3 attack path (Sequence Complexity Factor, Compound Threat Multipliers, Velocity-Weighted Control Effectiveness, Path Variance Analysis). It sits on top of the three core layers and is not required to use them. Schema: json-schemas/layer-4/tlctc-fair-risk.schema.json; rationale: documentation/tlctc-fair-integration-proposal.md.

Design Principles

• Separation of meaning from measurement — Layer 1 defines what a cluster is; Layer 3 records what happened. Incident records must not redefine clusters.
• Strict validation — Schemas use additionalProperties: false. Non-standard fields go in extensions objects.
• Linear + parallel modeling — Attack paths are ordered sequences of attack_step and parallel_group entries.
• R-EXEC enforcement — Steps carry fec_executed and fec_recorded_in_step_id fields to ensure FEC execution is always recorded.

---

Agent-Consumable Knowledge: the OKF Bundle

The okf/ directory packages the entire taxonomy as an Open Knowledge Format bundle (OKF v0.1) — a tree of markdown files with YAML frontmatter, built so LLM agents and RAG pipelines can consume TLCTC directly. It is a rendered view generated from the canonical JSON schemas, whitepaper, and tools; those remain the single source of truth.

• 412 concept documents: clusters (the six-field whitepaper definitions), axioms, rules, Layer-2 spheres/contexts, 247 glossary terms, 51 attack paths (notation + step tables), and ATT&CK/CWE/Sigma mappings grouped by cluster.
• Governance controls section: pairs the NIST CSF control objectives with the full 60-cell ISO 27001:2022 Annex A control matrix (every cluster × function, local + umbrella), the CDE → COE → ECR effectiveness model with the Detection Coverage Score, and the KRI/KCI/KPI indicator hierarchy.
• Regenerate & validate: npm run validate chains validate-framework → build-okf → validate-okf (SPEC conformance). The rebuild is deterministic. See okf/README.md.

Note: The ISO 27001 Annex A control placements and the CWE mapping carry starter / AI-assisted provenance notes — guidance, not certified control sets.

---

Axioms

TLCTC relies on 10 non-negotiable axioms organized into four groups. These prevent the category errors that plague cybersecurity language.

#	Axiom	Group	Core Statement
I	No System-Type Differentiation	Scope	Generic IT assets; sector labels (SCADA, IoT, cloud) don't create new threat classes
II	Client–Server Model	Scope	All networked interaction can be modeled as client–server at one or more layers
III	Causes, Not Outcomes	Separation	Threats ≠ data risk events. "Data breach" is never a threat category
IV	Not Threat Actors	Separation	Threats ≠ actor identity. "APT" is not a cluster
V	Not Control Failure	Separation	Control-risk ≠ threat category. A missing patch is not a threat
VI	Single-Cluster Rule	Classification	One step = one generic vulnerability = one cluster (non-overlap)
VII	Initial-Vulnerability Rule	Classification	Each attack vector is defined by the generic vulnerability it initially targets
VIII	Strategic–Operational Layering	Classification	Clusters have sub-threats (strategic → operational decomposition)
IX	Sequence + Velocity	Sequences	Clusters chain into attack paths; Δt measures velocity between steps
X	Credential Duality	Sequences	Credential acquisition and application are distinct steps with distinct classifications

---

Repository Contents

tlctc/
├── mappings/
│   ├── mitre-attack-enterprise/              # MITRE ATT&CK Enterprise → TLCTC
│   │   ├── README.md                         # Mapping documentation & notation
│   │   ├── tlctc-enterprise-attack.json      # 698 technique mappings with rationale
│   │   ├── decision-tree.md                  # Classification methodology
│   │   └── examples/
│   │       └── soc-to-risk-walkthrough.md    # Worked example: SOC → risk register
│   ├── mitre-cwe/                            # MITRE CWE → TLCTC (experimental)
│   │   ├── README.md                         # Mapping documentation & verdict system
│   │   ├── tlctc-cwe.json                    # 985 CWE mappings with rationale & CVE refs
│   │   ├── decision-tree.md                  # Classification methodology
│   │   └── examples/
│   │       └── cwe-to-control-walkthrough.md # Worked example: vuln findings → controls
│   ├── npm-supply-chain/                     # npm supply chain patterns → TLCTC
│   │   ├── README.md                         # Pattern documentation & methodology
│   │   ├── tlctc-npm-patterns.json           # Supply chain attack patterns mapping
│   │   └── examples/
│   │       └── incident-to-control-walkthrough.md # Worked example: incident → controls
│   ├── cloudflare-2026-patterns/             # Cloudflare 2026 attack patterns → TLCTC
│   │   ├── README.md                         # Pattern documentation & methodology
│   │   └── tlctc-cloudflare-2026-patterns.json # Cloudflare 2026 threat report pattern mapping
│   ├── cisa-kev/                             # CISA Known Exploited Vulnerabilities → TLCTC
│   │   ├── README.md                         # Mapping documentation & caveats
│   │   ├── generate-kev-mapping.py           # Deterministic ETL generator
│   │   ├── tlctc-kev.json                    # 1,568 per-CVE derivations
│   │   ├── tlctc-kev-stats.json              # Cluster counts, ransomware, vendor & monthly stats
│   │   ├── product-role-heuristic.json       # R-ROLE (#2 | #3) disambiguation rules
│   │   ├── decision-tree.md                  # Derivation algorithm
│   │   ├── input/                            # Pinned KEV snapshot (reproducibility)
│   │   └── examples/
│   │       └── cluster-exposure-walkthrough.md # Worked example: vendor stack → exposure
│   ├── mandiant-2026/                        # Mandiant M-Trends 2026 ATT&CK → TLCTC
│   │   └── tlctc-mandiant-2026-attck-mapping.json # Mandiant 2026 technique mapping
│   ├── splunk-cisco/                         # Splunk/Cisco Top-50 comparison
│   │   └── splunk-top50-tlctc-comparison.html # Interactive Splunk Top-50 vs TLCTC view
│   └── sigma/                                # SigmaHQ detection rules → TLCTC
│       ├── README.md                         # Mapping documentation & caveats
│       ├── generate-sigma-mapping.py         # Deterministic ETL generator (PyYAML)
│       ├── tlctc-sigma.json                  # 3,132 per-rule derivations
│       ├── tlctc-sigma-stats.json            # Cluster distribution & status counts
│       ├── decision-tree.md                  # Derivation algorithm
│       └── tests/                            # Generator unit tests
├── json-schemas/
│   ├── layer-1/                              # Framework Definition (Static)
│   │   ├── tlctc-framework.schema.json       # Schema for framework packages
│   │   ├── tlctc-framework.v2.3.json         # V2.3 frozen record (retained for 2.3.x classifications)
│   │   └── tlctc-framework.v2.5.json         # V2.5 citable baseline: clusters, axioms, 18 rules
│   ├── layer-2/                              # Reference Registry (Context)
│   │   ├── tlctc-reference.schema.json       # Schema for reference registries
│   │   └── example-registry.json             # Example org-specific registry
│   ├── layer-3/                              # Attack Path Instances (Dynamic)
│   │   ├── tlctc-attack-path.schema.json     # Schema for attack path instances
│   │   └── examples/
│   │       ├── solarwinds-2020.json          # SolarWinds supply chain incident
│   │       ├── chalk-debug-2025.json         # npm phishing campaign incident
│   │       ├── midnight-blizzard-microsoft-2024.json # Midnight Blizzard → Microsoft OAuth pivot
│   │       └── unresolved-step-example-2026.json # Unresolved-step operators (?/…) reference
│   ├── layer-4/                              # FAIR Risk Quantification (Risk)
│   │   ├── tlctc-fair-risk.schema.json       # Schema for FAIR risk assessment instances
│   │   └── examples/
│   │       └── scattered-spider-2024-fair.json # SCATTERED SPIDER FAIR risk assessment
│   └── operational/                          # Operational sub-cluster enumeration (evolving)
│       ├── tlctc-operational-enumeration.schema.json # Schema for the enumeration
│       └── tlctc-operational-enumeration.json # TLCTC-XX.YY catalogue (JSON twin of the md)
├── grammar/                                  # Standalone ABNF grammar for path notation
│   ├── README.md                             # Grammar documentation & tooling notes
│   └── tlctc-attack-path.abnf                # ABNF grammar for TLCTC attack-path syntax
├── scripts/                                  # Build & validation tooling (Node.js)
│   ├── build-pdf.js                          # markdown → text PDF (marked + puppeteer)
│   ├── validate-framework.js                 # ajv JSON Schema validator
│   ├── build-okf.js                          # canonical sources → OKF bundle (okf/)
│   └── validate-okf.js                       # OKF SPEC conformance checker
├── okf/                                      # Open Knowledge Format bundle (agent-consumable; generated by scripts/build-okf.js)
│   ├── README.md                             # Bundle provenance & regeneration recipe
│   ├── index.md / log.md                     # OKF reserved navigation & changelog
│   ├── clusters/ axioms/ rules/              # Framework dictionary (one markdown doc per concept)
│   ├── spheres/ contexts/                    # Layer-2 registry (responsibility spheres, boundary contexts)
│   ├── glossary/                             # 247 term docs
│   ├── attack-paths/                         # 59 incident path docs (notation + step tables)
│   ├── controls/                             # NIST CSF × ISO 27001 matrix, effectiveness model, indicators
│   └── mappings/                             # ATT&CK / CWE / Sigma grouped by cluster
├── documentation/
│   ├── tlctc-v2.5-core.md                    # ⭐ Citable core paper (v2.5) — canonical definition
│   ├── tlctc-v2.5-core.pdf                   # PDF of the core paper (citation target)
│   ├── tlctc-v2.5-application.md             # Application & governance companion (v2.5)
│   ├── tlctc-v2.5-application.pdf            # PDF of the application paper
│   ├── tlctc-traceability.md            # consolidation & version traceability (v2.1 → v2.5)
│   ├── tlctc-operational-enumeration.md      # Evolving TLCTC-XX.YY sub-cluster catalogue
│   ├── tlctc-v2.0-whitepaper.md              # Extended practitioner handbook (v2.1 content; filename kept for link stability)
│   ├── tlctc-v2.0-whitepaper.pdf             # PDF export of the white paper
│   ├── tlctc-glossary.md                     # Comprehensive definitions
│   ├── tlctc-glossary.pdf                    # PDF export of the glossary
│   ├── tlctc-ti-sharing-profile.md           # TI Sharing — Extension Profile (companion)
│   ├── tlctc-fair-integration-proposal.md    # FAIR integration proposal (Layer 4 spec)
│   ├── tlctc-cve-extension-proposal.md       # CVE extension proposal
│   ├── tlctc-replication-notation-proposal.md # Replication notation (×N fan-out / ×* self-propagation) — conceptual proposal (v0.1)
│   ├── tlctc-plus-ncsc-proposal.md           # TLCTC+ national reporting extension — policy proposal (v0.1)
│   ├── tlctc-plus-specification.md           # TLCTC+ implementation specification (v0.3) — grammar, conformance, catalogues
│   ├── propagated-controls.md                # Managing controls over event chains — generalizes Propagated PR to BCM, contractual, and policy sources
│   ├── npm-supply-chain-blog-final.md        # npm supply chain threat analysis
│   ├── Why Exactly Ten_ — TLCTC Framework Architecture.pdf # Framework architecture rationale
│   └── images/                               # Diagrams and visual assets
│       ├── tlctc-bowtie-anchor-diagram.svg
│       ├── tlctc-consequence-chain.svg
│       ├── tlctc-cyber-bow-tie.svg
│       ├── tlctc-dual-layer-bowtie-overview.svg
│       └── tlctc-dual-layer-naming.svg
├── tools/
│   ├── README.md                             # Tool index & JSON format reference
│   ├── threat-modeling.html                  # SDLC threat modeling & architecture analysis
│   ├── attack-path-architect.html            # Incident attack path documentation & CTI exchange
│   ├── actor-profile-designer.html           # Threat actor capability profiling & comparison (573 actors: 59 expert-scored + 514 ETDA heuristic-scored)
│   ├── actor-story-designer.html             # Threat intelligence story/narrative builder
│   ├── radar-tlctc-app.html                  # Interactive threat radar visualization & assessment
│   ├── tech-enablers-radar.html              # Technology enabler radar for emerging threat vectors
│   ├── control-matrix.html                   # NIST CSF 2.0 × TLCTC control matrix with maturity scoring
│   ├── attck-explorer.html                   # MITRE ATT&CK technique explorer with TLCTC mapping
│   ├── attck-phase-heatmap.html              # ATT&CK phase heatmap visualization
│   ├── cwe-explorer.html                     # CWE weakness explorer with TLCTC mapping
│   ├── cbp-app.html                          # Cluster-based prioritization application
│   ├── cbp-starter.json                      # Cluster-based prioritization starter dataset
│   ├── control-matrix-starter.json           # NIST CSF control-matrix starter
│   ├── control-matrix-starter-iso27001.json  # ISO 27001 control-matrix starter
│   ├── control-matrix-starter-cloudflare-2026.json # Cloudflare-2026 control-matrix starter
│   ├── score_etda.py                         # ETDA→TLCTC scoring engine: tool arsenal + description mining, calibrated against expert data
│   ├── generate-cs2026-report.js             # CrowdStrike-2026 report generator
│   ├── generate-iso27001-starter.py          # ISO 27001 control-matrix starter generator
│   ├── replace-cdn.sh                        # CDN link rewrite helper
│   └── examples/                             # Starter templates & real-world example datasets
│       ├── template-threat-model.json        # Blank threat model starter
│       ├── template-attack-path.json         # Blank attack path starter
│       ├── template-actor-profile.json       # Blank actor profile starter
│       ├── CTA-CrowdStrike2025.json          # CrowdStrike 2025 Global Threat Report actors
│       ├── CTA-CrowdStrike2026.json          # CrowdStrike 2026 Global Threat Report actors
│       ├── CTA-Cloudflare-2026.json          # Cloudflare 2026 threat actors
│       ├── CTA-Mandiant-2026.json            # Mandiant M-Trends 2026 threat actors
│       ├── CTA-Google-APT-Groups.json        # Google APT group profiles
│       ├── CTA-NCSC-SituationRadar-2024-2025.json  # NCSC Situation Radar threat data
│       ├── CTA-NCSC-TAC-Profiles.json        # NCSC threat actor capability profiles
│       ├── radar-cloudflare-2026.json        # Cloudflare 2026 radar dataset
│       ├── radar-crowdstrike-2026.json       # CrowdStrike 2026 radar dataset
│       ├── radar-mandiant-2026.json          # Mandiant 2026 radar dataset
│       ├── radar-mandiant-2026-industries.json # Mandiant 2026 industry-specific radar
│       ├── stories-cloudflare-2026.json      # Cloudflare 2026 threat narratives
│       ├── stories-crowdstrike-2026.json     # CrowdStrike 2026 threat narratives
│       ├── stories-mandiant-2026.json        # Mandiant 2026 threat narratives
│       ├── control-matrix-cloudflare-2026.json # Cloudflare 2026 control matrix
│       ├── control-matrix-crowdstrike-2026.json # CrowdStrike 2026 control matrix
│       ├── control-matrix-mandiant-2026.json # Mandiant 2026 control matrix
│       ├── tech-enablers-horizon-2026.json   # Technology enablers horizon scan 2026
│       ├── tech-enablers-agentic-focus-2026.json # Agentic AI technology enablers 2026
│       ├── ncsc-google-2024-JB-bericht*.json # NCSC/Google 2024 annual report datasets (5 files)
│       └── npm-*.json                        # npm supply chain incident examples (3 files)
├── integrations/                             # External-tool deployments (operational)
│   ├── README.md                             # Index of available integration packs
│   ├── cortex-xsoar/                         # Cortex XSOAR 6.2.x per-object YAML/JSON pack
│   ├── cortex-xsoar-8/                       # Cortex XSOAR 8.x / XSIAM Marketplace Content Pack
│   ├── sonarqube/                            # SonarQube & SonarCloud sidecar (Python CLI + declarative starter)
│   └── sarif/                                # Generic SARIF 2.1.0 classifier (Python CLI, stdlib only)
├── glossary/
│   ├── tlctc-glossary.schema.json            # Schema for universal cyber security glossary
│   └── tlctc-glossary.json                   # 72 terms: clusters, axioms, rules, notation, architecture, boundary operators
├── agentic-ai/                               # Analysis of AI semantics in Cyber Threats
│   ├── README.md                             # Overview and methodology
│   ├── agentic-consequence-chains.json       # Consequence chain examples
│   ├── agentic-tool-profiles.json            # 5 tool category risk profiles
│   ├── agentic-irreversibility-matrix.json   # Irreversibility windows per consequence type
│   └── attack-paths/                         # 10 individual agentic AI attack paths (A–J)
│       ├── path-A-direct-prompt-injection.json
│       ├── path-B-indirect-prompt-injection.json
│       ├── path-C-social-engineering-operator.json
│       ├── path-D-credential-access.json
│       ├── path-E-agent-as-lolbin.json
│       ├── path-F-runtime-exploit.json
│       ├── path-G-rogue-agent-install.json
│       ├── path-H-supply-chain-marketplace.json
│       ├── path-I-apt-in-a-box.json
│       └── path-J-llm-weaponization-supply-chain.json
├── attack-paths/                             # Community-contributed incident analyses (51 incidents, 58 path files)
│   ├── CONTRIBUTING.md
│   ├── # Canonical pattern reference
│   ├── ad-domain-admin-cascade-2025.json     # Active Directory Domain-Admin → ransomware #1-cascade (composite pattern: Lynx, Storm-2603, Storm-0300/Akira)
│   ├── # Historical incidents (2008–2024)
│   ├── agent-btz-usb-2008.json               # USB worm (2008)
│   ├── watering-hole-iphonedevsdk-2013.json   # Watering hole (2013)
│   ├── darkhotel-wifi-2014.json               # Hotel Wi-Fi (2014)
│   ├── ubiquiti-bec-2015.json                 # BEC wire fraud (2015)
│   ├── ukraine-power-grid-2015.json           # ICS power grid (2015)
│   ├── uber-breach-2016.json                  # Credential stuffing (2016)
│   ├── mirai-botnet-2016.json                 # IoT botnet (2016)
│   ├── capital-one-2019.json                  # SSRF cloud (2019)
│   ├── credential-stuffing-2020.json          # Credential stuffing (2020)
│   ├── twitter-hack-2020.json                 # Social engineering (2020)
│   ├── colonial-pipeline-2021.json            # Ransomware (2021)
│   ├── pegasus-forcedentry-2021.json          # Zero-click exploit (2021)
│   ├── okta-lapsus-2022.json                  # Supply chain (2022)
│   ├── lockbit-byovd-2023.json                # BYOVD ransomware (2023)
│   ├── cloudflare-http-ddos-2023.json         # HTTP/2 DDoS (2023)
│   ├── tesla-insider-2023.json                # Insider threat (2023)
│   ├── tesla-k8s-cryptojacking-2018.json      # K8s cryptojacking (2018)
│   ├── lojax-uefi-2018.json                   # UEFI rootkit (2018)
│   ├── change-healthcare-2024.json            # Healthcare ransomware (2024)
│   ├── # Cloudflare 2026 Threat Report sourced (13 incidents)
│   ├── grub1-saas-pivot-2025.json             # GRUB1 Salesloft/Drift SaaS pivot
│   ├── opencode-exploit-chain-2025.json       # OpenCode AI IDE RCE chain
│   ├── frumpytoad-toughprogress-2025.json     # FrumpyToad ToughProgress phishing
│   ├── nastyshrew-ukraine-2025.json           # NastyShrew Ukraine espionage
│   ├── rottenshrew-signal-2025.json           # RottenShrew Signal device linking
│   ├── clumsytoad-snakedisk-2025.json         # ClumsyToad SnakeDisk USB wiper
│   ├── punytoad-f5-bigip-2025.json            # PunyToad F5 BIG-IP exploitation
│   ├── nk-it-worker-infiltration-2025.json    # DPRK IT worker infiltration scheme
│   ├── infostealer-ransomware-pipeline-2025.json # Infostealer → IAB → ransomware pipeline
│   ├── aisuru-ddos-2025.json                  # Aisuru botnet DDoS-for-hire
│   ├── authorized-insider-extortion-2025.json # Authorized insider extortion
│   ├── bot-chain-lifecycle-2025.json          # Bot chain lifecycle (IoT → proxy)
│   ├── raccoon-phaas-aitm-2025.json          # Raccoon PhaaS AiTM credential theft
│   ├── # Mandiant M-Trends 2026 sourced (6 incidents)
│   ├── mandiant-handoff-ransomware-2025.json  # Infostealer → IAB → ransomware hand-off
│   ├── mandiant-multi-year-espionage-2025.json # Multi-year espionage campaign
│   ├── mandiant-saas-cascade-2025.json        # SaaS token cascade
│   ├── mandiant-edge-device-exploitation-2025.json # Edge device exploitation
│   ├── mandiant-esxi-virtualization-2025.json # ESXi VMDK-mount credential dump
│   ├── mandiant-recovery-denial-2025.json     # Recovery denial ransomware
│   ├── # CrowdStrike 2026 Global Threat Report sourced (8 incidents)
│   ├── scattered-spider-unmanaged-vm-2025.json # SCATTERED SPIDER unmanaged VM credential dump
│   ├── pressure-chollima-bybit-2025.json      # PRESSURE CHOLLIMA Bybit $1.46B supply chain
│   ├── fancy-bear-lamehug-2025.json           # FANCY BEAR LAMEHUG LLM-enabled malware
│   ├── blockade-spider-embargo-2025.json      # BLOCKADE SPIDER cross-domain Embargo ransomware
│   ├── cozy-bear-oauth-ngo-2025.json          # COZY BEAR multi-day OAuth phishing
│   ├── chatty-spider-lawfirm-2025.json        # CHATTY SPIDER 4-minute law firm intrusion
│   ├── punk-spider-smb-encryption-2025.json   # PUNK SPIDER remote SMB encryption via IoT
│   ├── famous-chollima-beavertail-2025.json   # FAMOUS CHOLLIMA fake recruiter npm + BeaverTail
│   ├── # npm ecosystem sourced (3 incidents)
│   ├── s1ngularity-nx-2025.json               # S1ngularity NX npm campaign
│   ├── chalk-debug-phishing-2025.json         # chalk-debug npm phishing
│   ├── shai-hulud-worm-2025.json              # ShaiHulud self-propagating npm worm
│   ├── # OpenAI – Hugging Face incident, July 2026 (1 incident, 8 paths, TLCTC v2.5)
│   ├── openai-hf-artifactory-2026.json         # AP-1 covert channel, first egress, Artifactory takeover (@OAI-Research)
│   ├── openai-hf-precursor-spaces-2026.json    # Precursor branch, HF Spaces proxy (explicitly non-causal)
│   ├── openai-hf-sandbox-escape-2026.json      # AP-2 re-establishment and eval sandbox escape
│   ├── openai-hf-relay-estate-2026.json        # AP-3 third-party relay estate (@Modal-Cust, @Org1, screenshot service)
│   ├── openai-hf-huggingface-2026.json         # AP-4 Hugging Face production compromise (29 steps)
│   ├── openai-hf-package-plane-2026.json       # AP-5 image cache poisoning + RubyGems deserialisation (#10 twice)
│   ├── openai-hf-cloud-escalation-2026.json    # AP-6 kernel exploit → cloud control plane (956 secrets)
│   └── openai-hf-observability-2026.json       # AP-7 tool-call transcript spoofing (v2.6 [DRE: Im] test case)
└── LICENSE                                   # CC BY 4.0

Getting Started

1. Read the core paper — documentation/tlctc-v2.5-core.md is the canonical, citable definition: derivation, clusters, axioms, rules, and notation in one self-contained paper.
2. Read the axioms — They are the non-negotiable foundation. If you skip them, you'll misclassify.
3. Understand the Bow-Tie — Threats are causes, outcomes are consequences. Never confuse them.
4. Practice with attack paths — Take any recent incident report and decompose it into TLCTC notation. The Application Paper walks the procedure end-to-end.
5. Use the JSON schemas — Validate your attack path instances against Layer 3 schema.
6. Explore the ATT&CK mapping — See mappings/mitre-attack-enterprise/ to understand how operational techniques translate to strategic clusters.
7. Explore the CWE mapping — See mappings/mitre-cwe/ to connect vulnerability findings to threat clusters.
8. Track active exploitation — See mappings/cisa-kev/ for a TLCTC-cluster view of the CISA Known Exploited Vulnerabilities catalog (1,568 CVEs, weekly-refreshable, deterministically derived).
9. Audit your detection coverage — See mappings/sigma/ for a per-rule TLCTC cluster derivation of 3,132 SigmaHQ detection rules — cross-walk your SOC ruleset against the strategic cluster model.
10. Use the glossary — See glossary/ for precise, machine-readable definitions of all TLCTC terms and cyber security vocabulary.
11. Learn the boundary and epistemic operators — The White Paper covers transit boundaries, intra-system boundaries, unresolved-step operators, and the epistemic state hierarchy.
12. Read the extension proposals — TLCTC+ has two paired documents: tlctc-plus-ncsc-proposal.md (v0.1 policy proposal — the why) and tlctc-plus-specification.md (v0.3 implementation spec — the how: grammar, conformance, BRE/PATTERN/IMPACT/REPORT catalogues, JSON formats). For other framework extensions, see tlctc-cve-extension-proposal.md (CVE enrichment), tlctc-fair-integration-proposal.md (FAIR risk quantification), and tlctc-replication-notation-proposal.md (replication notation — ×N fan-out / ×* self-propagation, conceptual).
13. Deploy an integration — See integrations/ to operationalise TLCTC inside the tools your team already runs. Available packs: Cortex XSOAR 6.2.x and 8.x / XSIAM (incident triage + Layer 3 emission), SonarQube + SonarCloud (SAST findings → cluster tags via a Python sidecar against the canonical CWE→TLCTC mapping), and the generic SARIF classifier (any SARIF 2.1.0 producer → TLCTC clusters; CWE-first with CVE→KEV fallback; stdlib-only).
14. Feed an LLM agent — Point a RAG pipeline or agent at the okf/ Open Knowledge Format bundle (markdown + YAML frontmatter) rendering the whole taxonomy — clusters, axioms, rules, glossary, attack paths, controls, and mappings — for machine consumption. Regenerate with npm run validate.

Contributing

We welcome community contributions, particularly:

• Attack path mappings of real-world incidents using TLCTC notation
• Framework integration examples (MITRE ATT&CK mappings, NIST CSF control matrices)
• Tooling that consumes or produces TLCTC JSON (see tools/ for existing standalone apps)
• Integrations that operationalise TLCTC inside vendor platforms (see integrations/ for the Cortex XSOAR and SonarQube packs as reference shapes)
• Glossary terms — propose new terms or refine definitions for the universal cyber security glossary

See attack-paths/CONTRIBUTING.md for guidelines.

Resources

Resource	Description
Core Paper v2.5 (PDF)	The canonical, citable definition of the framework
Application Paper v2.5 (PDF)	Classification in practice, governance, controls, and indicators
tlctc.net	Official TLCTC website with documentation, visuals, and tools
White Paper	Extended practitioner handbook: boundary logic, epistemic operators, and complete notation specification
barnes.ch	Author's site with foundational analysis on cybersecurity's language problem

How to Cite

Kreinz, B. (2026). A Cause-Oriented Cyber Threat Taxonomy: The Top Level Cyber Threat Clusters Framework (Version 2.5) [Preprint]. Zenodo. https://doi.org/10.5281/zenodo.20633176

@misc{kreinz2026tlctc,
  author    = {Kreinz, Bernhard},
  title     = {A Cause-Oriented Cyber Threat Taxonomy: The Top Level
               Cyber Threat Clusters Framework},
  year      = {2026},
  version   = {2.5},
  publisher = {Zenodo},
  doi       = {10.5281/zenodo.20633176},
  url       = {https://doi.org/10.5281/zenodo.20633176}
}

The DOI above is the concept DOI: it always resolves to the most recent published version of the paper. To cite a specific release instead, use that version's own DOI from the Zenodo record.

License

All TLCTC framework definitions, notations, axioms, and JSON architectures are licensed under Creative Commons Attribution 4.0 International (CC BY 4.0).

You are free to share and adapt this material for any purpose, including commercial use, provided you give appropriate attribution.

---

TLCTC was created by Bernhard Kreinz to solve cybersecurity's fundamental language problem — because you cannot manage what you cannot consistently name.