---
title: TMF Intent Security Ontology Overview
url: https://www.emergentmind.com/topics/tm-forum-tmf-intent-security-ontology
type: topic
---

# TMF Intent Security Ontology Overview

The TM Forum (TMF) Intent Security Ontology denotes a TMF-aligned semantic approach to expressing, validating, and operationalizing security-related intents in autonomous telecommunications networks. In the current literature, the term does not refer to a single universally fixed artifact. The directly named standard artifact is the **TM Forum TR292I Security Ontology**, presented as an extension of the **TM Forum Intent Common Model (ICM)** for security-domain semantics, while adjacent work addresses the broader **TMF Intent Ontology (TIO)**, SHACL-based validation, semantic catalog grounding, and security-oriented extensions for differentiated secure connectivity [2605.27743][2604.27359][2606.28348][2509.25462].

## 1. Terminological scope and standard position

The most precise usage in the literature identifies the ontology as **“TM Forum TR292I Security Ontology”**, including references to **TR292I Security Ontology v4.0.0** in one source and **TR292I TM Forum Security Ontology (TIO) v3.7.0** in another. This already indicates that the phrase “TMF Intent Security Ontology” functions partly as an umbrella label for related TMF security-intent work rather than as a single stable bibliographic title across all sources [2605.27743][2509.25462].

A second distinction is between the **security ontology** and the **general intent ontology substrate**. The 2026 orchestration work uses the **TMF Intent Ontology / Intent Common Model (TIO)** for RDF intent representation and SHACL validation, but explicitly states that it does **not** define a distinct “TMF Intent Security Ontology.” In that work, security relevance is indirect: the same TIO, SHACL, and capability-grounding pipeline could process security intents if security properties were exposed as modeled capabilities [2606.28348]. The same boundary appears in **TIO-SHACL**, which validates the full TIO but does not introduce confidentiality, integrity, isolation, or access-control semantics of its own [2604.27359].

| Artifact | Role in the literature | Security relation |
|---|---|---|
| **TR290 / TIO / ICM** | General TMF intent substrate | Provides intent, expectation, target, logical, quantity, and lifecycle semantics |
| **TR292I Security Ontology** | Security-domain extension | Adds assets, attack surfaces, security expectations, capabilities, and resource-impact modeling |
| **TIO-SHACL** | Validation framework | Validates TIO structure and semantics before admission |
| **Differentiated secure connectivity extension** | Security-intent proposal | Adds protection requirements, security performance requirements, and differentiated levels |

A common misconception is therefore to treat TMF intent security work as equivalent to the base TIO. The literature supports a sharper distinction: **TIO/ICM** supplies the generic intent grammar, whereas **TR292I** and related proposals supply security-domain vocabulary and security-specific expectation semantics [2605.27743][2606.28348].

## 2. Ontological foundation and core semantics

The ontology is described as inheriting from the **TM Forum Intent Common Model (ICM)**. More specifically, TR292I provides **RDFS vocabularies** that “directly inherit from and extend the foundational TM Forum Intent Common Model (ICM),” cited as **TR290 Intent Common Model (ICM) Intent Expression v3.7.0**. The modeling choice is explicitly lightweight: TR292I v4.0.0 is said to be built “strictly around RDFS vocabularies,” rather than heavyweight OWL reasoning, in order to reduce latency and avoid “state-explosion bottlenecks” in runtime edge loops [2605.27743].

Its core hierarchy is centered on expectations, assets, attack surfaces, and capabilities. In the paper’s extracted subsumption structure,

$$
sec:SecurityExpectation \sqsubseteq icm:Expectation
$$

with two subclasses,

$$
sec:ProtectionExpectation \sqsubseteq sec:SecurityExpectation
$$

and

$$
sec:PerformanceExpectation \sqsubseteq sec:SecurityExpectation.
$$

The ontology also places

$$
sec:Asset \sqsubseteq icm:Target
$$

and

$$
sec:AttackSurface \sqsubseteq rdfs:Container.
$$

This means the security ontology is not separate from intent semantics; it is an explicit specialization of the TMF intent model [2605.27743].

The main concepts named in the paper are structurally specific. **`sec:Asset`** denotes any high-value logical, software-defined, or physical resource with explicit security requirements. **`sec:AttackSurface`** represents exposure vectors or grouped entry points sharing vulnerabilities, linked to assets by **`sec:attackSurface`**. **`sec:ProtectionExpectation`** expresses functional security goals and is linked via **`sec:satisfies`** to a **`sec:SecurityAttribute`**, for which the figure gives **`sec:Confidentiality`**, **`sec:Integrity`**, and **`sec:Availability`** as examples. **`sec:PerformanceExpectation`** expresses non-functional, quantifiable, bound parameters and is linked via **`sec:measuredBy`** to a telemetry metric [2605.27743].

The implementation-side abstraction is **`sec:SecurityCapability`**, with subclasses **`sec:PreventiveCapability`**, **`sec:DetectionCapability`**, and **`sec:MitigationCapability`**. Capability selection depends on properties such as **`sec:mitigates`**, **`sec:impactOnResource`**, **`sec:impactValue`**, and **`sec:performanceMetric`**. The paper’s central interpretation is that TR292I “decouples the high-level, functional security goals from technical enforcement capabilities while concurrently mapping deployment costs via the `sec:impactOnResource` property” [2605.27743].

A further precision is important: the paper does **not** define a formal class such as `sec:Intent`. Instead, a security intent is modeled through **expectations plus conditions**, grounded in ICM. In the DDoS example, what is colloquially called the intent is an instance of **`sec:PerformanceExpectation`** with a target asset, a measured metric, and one or more **`icm:Condition`** constraints. This suggests that, in TMF security semantics, “intent” is often realized as a structured expectation-bearing graph rather than as a security-specific top-level class [2605.27743].

## 3. Security expectations, measurable requirements, and differentiated levels

Across the literature, the dominant semantic split is between **functional security expectations** and **non-functional measurable security expectations**. In TR292I this appears as the distinction between **`sec:ProtectionExpectation`** and **`sec:PerformanceExpectation`**. In the differentiated secure connectivity proposal, the corresponding terms are **Protection Requirements** and **Security Performance Requirements** [2605.27743][2509.25462].

The differentiated secure connectivity paper argues that “current standards do not yet provide formal definitions for either qualitative and quantitative expectations and metrics for the security domain that could be expressed as intents.” Its extension therefore uses the TMF ontology family—**Intent Ontology**, **Logical Operators Ontology**, **Quantity Ontology**, and **Security Ontology**—to represent both qualitative and quantitative security semantics in RDF. The paper proposes that service intents may carry qualitative expectations, while operations intents may carry quantitative expectations, and that decomposition maps between them [2509.25462].

The key qualitative notion is **Protection Coverage**, with differentiated levels **`ProtectionCoverage-Basic`**, **`ProtectionCoverage-Enhanced`**, and **`ProtectionCoverage-Advanced`**. These levels are not treated as final implementation choices. Rather, the model states that differentiated protection levels can be hybrid, meaning they can have a qualitative level mapped to a quantitative value. The quantitative side is then expressed through metrics such as **Attack Surface Coverage** and **Security Control Coverage**, along with thresholded examples such as `Segmentation level ≥ 40%`, `Radio Robustness level ≥ 60%`, and `Mean-time-to-Detect Radio Attacks ≤ 200 ms` [2509.25462].

This distinction is significant because the paper explicitly criticizes capability-centric and policy-over-specified approaches. A security capability should belong to the **solution space**, not to the requirement itself. The same paper also emphasizes differentiated security across services, slices, domains, network functions, and attack surfaces, including examples in which **enhanced protection on the radio interface** means suitable security features to ensure confidentiality and integrity on the radio control plane, while **advanced protection level** extends that scope to the radio user plane as well [2509.25462].

Taken together, these sources support a two-layer interpretation of TMF intent security semantics. First, the ontology must represent **what security state is expected**. Second, it must support a measurable mapping from that expectation to observability, fulfillment evaluation, and downstream realization. This does not yet amount to a single finished standard profile, and the differentiated secure connectivity paper explicitly presents itself as an extension proposal rather than a complete finalized ontology specification [2509.25462].

## 4. Structural validation, semantic grounding, and decomposition

A major development in TMF intent ontology work is the introduction of explicit machine-checkable validation. **TIO-SHACL** is presented as “the first comprehensive SHACL validation framework for the TMF Intent Ontology,” with **56 node shapes** and **69 property shapes** across all **15 tio v3.6.0 ontology modules**, a reusable constraint library with **25 parameterized SPARQL-based constraint components**, and **100% vocabulary coverage (87 classes, 109 properties, 72 functions)**. It validates recursive logical operators, quantity-based constraints, cross-expectation relationships, function arity and typing, and undeclared vocabulary usage, and it reports validation accuracy on **133 test cases** with cross-implementation agreement across **pySHACL 0.31.0**, **TopBraid SHACL 1.4.3**, and **Apache Jena 5.2.0** [2604.27359].

For TMF intent security, the immediate implication is that structurally valid intent graphs are treated as a prerequisite for admission. The 2026 intent-driven orchestration paper operationalizes this directly. In that system, intents are expressed as **RDF graphs over the TIO**, which is “specified across **15 ontology modules** covering intent structure, logical composition, quantity constraints, metrics, and lifecycle management.” Validation then proceeds in two layers: **SHACL** checks “required fields, correct types, and cardinality,” while a separate **RequirementCapability** layer checks semantic feasibility against a TMF SID-aligned semantic service catalog [2606.28348].

The formal decomposition used there is explicit. For customer-facing service specification selection, the chosen profile minimizes cost subject to satisfying every extracted requirement:

$$
p^* = \arg\min_{p \in P}\; \mathit{cost}(p) \;\;\text{s.t.}\;\; \forall\, r \in R,\; \exists\, c \in C(p)\!: \operatorname{Sat}(c, r).
$$

For infrastructure decomposition, the selected resource-facing profile set solves a weighted set cover problem:

$$
S^* = \arg\min_{S \subseteq Q}\; \sum_{q \in S} w(q) \;\;\text{s.t.}\;\; \bigcup_{q \in S} C(q) \supseteq R_{\text{cfss}}.
$$

The paper characterizes the first as a **constraint-satisfaction problem** and the second as **weighted set cover**, solved with a **greedy heuristic** with **\(O(\ln n)\)** approximation and compared against **CP-SAT** [2606.28348].

The same paper is explicit that this is not yet a security ontology profile. It names metrics such as latency, jitter, throughput, bandwidth, packet loss, availability, slice type, and 3GPP 5QI, and states that it does **not** explicitly model confidentiality, integrity, encryption, authentication, authorization/access control, compliance, trust, isolation, threat protection, or secure connectivity. Its relevance to security is therefore infrastructural: if a TMF-aligned security ontology or service catalog exposed security properties in `req:provides`, then the same workflow could translate, SHACL-validate, ground, and decompose them [2606.28348].

## 5. Closed-loop security management and runtime decision-making

The most direct operational account of the TMF security ontology is the **Intent Management Function (IMF)** pipeline built on TR292I. The architecture is described as a closed loop in which an operator expresses the desired security state declaratively, the IMF reads real-time operational context of the topology, a **`sec:DetectionCapability`** identifies active threats, the IMF queries the ontology-backed graph for candidate capabilities, constraints are solved, the best feasible capability is chosen, and enforcement is validated through telemetry and expectation compliance [2605.27743].

The paper’s DDoS mitigation walkthrough on a disaggregated gNB slice makes the ontology operationally concrete. The protected asset is **`ex:gNB01 a sec:Asset`**, the attack surface is **`ex:ControlPlaneSurface a sec:AttackSurface`**, and the active threat is **`ex:RadioDdosThreat`**. The operator specifies two conditions: the threat must be neutralized within **50 ms**, and mitigation must not add more than **20 ms** end-to-end latency. The “intent” is represented as a **`sec:PerformanceExpectation`** measured by **`ex:MeanTimeToMitigate`** and constrained by two **`icm:Condition`** instances using **`quan:atMost`** [2605.27743].

Two candidate **`sec:MitigationCapability`** instances are then compared. **Candidate A (`ex:DpiCapability`)** mitigates quickly, with mean time to mitigate **10 ms**, but imposes **35 ms** of latency impact and therefore violates the ceiling. **Candidate B (`ex:ThrottlingCapability`)** is slower, with mean time to mitigate **30 ms**, but imposes only **15 ms** of latency impact and therefore satisfies both conditions. The IMF consequently selects **dynamic edge request throttling**, invokes the control protocol, neutralizes the signaling storm, and preserves SLA integrity [2605.27743].

This is not described as soft multi-objective optimization. The paper explicitly says the model uses **hard constraints**—mitigation time must remain below the maximum and impact on each monitored resource must stay below ceiling—and then minimizes mitigation time among feasible candidates. The value of the ontology here is not only representational. It supplies the graph-query substrate through which conflict resolution is implemented as semantic candidate filtering plus constrained optimization [2605.27743].

A plausible implication is that this same pattern generalizes beyond DDoS mitigation. The ontology already distinguishes functional protection expectations from measurable performance expectations, and it already represents resource-impact side effects. That combination makes it suitable for security automation scenarios in which the fastest protective action is not necessarily the admissible one.

## 6. Empirical status, limitations, and research directions

The empirical basis for TMF intent-security work is uneven but increasingly concrete. On the validation side, **TIO-SHACL** achieves full vocabulary coverage of the base TIO and passes all **133** expected test outcomes, with **100% agreement** across three SHACL engines after interoperability adjustments [2604.27359]. On the orchestration side, the TMF-aligned grounded-intent pipeline reports **930 benchmark runs**, **97% success** in Builder mode, **90%** average success in natural-language scenarios, and **100% correct rejection** of infeasible requests. It also reports that grounding LLM context in catalog capability metadata improves adversarial success from **61%** to **87%**, a **+26 percentage point** gain [2606.28348].

At the same time, several limitations recur across the literature. The general TIO papers do not define a dedicated TMF security module or security-specific SHACL shapes for encryption, authentication, confidentiality, integrity, isolation, compliance, or trust [2606.28348][2604.27359]. The TR292I paper presents a **formal semantic walkthrough**, not a full deployment benchmark, and explicitly notes that multi-intent arbitration remains future work [2605.27743]. The differentiated secure connectivity paper argues that there is still “no standardized method for formalizing security intents and translating them into measurable service characteristics,” and that current standards do not yet provide the needed formal qualitative and quantitative security expectations [2509.25462].

The literature also exposes a versioning and scope ambiguity. One source centers on **TR292I Security Ontology v4.0.0**, while another references **TR292I TM Forum Security Ontology (TIO) v3.7.0** [2605.27743][2509.25462]. More fundamentally, “TMF Intent Security Ontology” may refer to the standardized TR292I vocabulary, to TIO-based security-intent processing infrastructure, or to proposed extensions for differentiated secure connectivity. Treating these as interchangeable obscures important semantic boundaries.

Adjacent TMF-aligned work on intent co-creation and test-driven assurance suggests a further direction. Those papers do not define a security ontology, but they do introduce **canonical intent**, **explicit user confirmation**, **Intents Inventory**, **Service Test Specifications**, **Service Test Results**, and strict separation between cognitive reasoning and deterministic execution. This suggests that future TMF security ontologies may need first-class treatment of provenance, approval, evidence, and guardrails in addition to security expectations and capabilities [2604.23285][2604.23288].

Outside TMF, threat-centric security-intent work defines an alert-driven intent tuple,

$$
I_{AL} \triangleq (OT, MD, DAT, DT),
$$

linking offensive technique, metadata, digital artifact, and defensive technique. A plausible implication is that TMF security-intent research may eventually converge with such threat-centric structures, using TMF expectations and targets for service-level semantics while importing richer attack and response models for runtime cyber defense [2507.12061].

In its present state, the TMF Intent Security Ontology is best understood as an emerging stack rather than a finished singular object: a security-domain extension of the TMF intent model, a validation and admission-control substrate for TIO graphs, a growing body of measurable security-intent proposals, and a closed-loop operational pattern for selecting admissible mitigations under explicit resource constraints.

Source: https://www.emergentmind.com/topics/tm-forum-tmf-intent-security-ontology