TMF Intent Security Ontology Overview

• TMF Intent Security Ontology is a semantic framework that extends the TMF Intent Common Model by incorporating security-specific vocabulary and measurable expectations.
• It operationalizes security intents by differentiating functional protection expectations from quantifiable performance metrics using lightweight RDFS vocabularies and SHACL validation.
• The ontology supports closed-loop security management by enabling dynamic threat mitigation, capability selection, and runtime decision-making within autonomous telecom networks.

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 (Abdelrazek, 26 May 2026, Martins et al., 30 Apr 2026, Martins et al., 3 Jun 2026, Abdelrazek et al., 29 Sep 2025).

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 (Abdelrazek, 26 May 2026, Abdelrazek et al., 29 Sep 2025).

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 (Martins et al., 3 Jun 2026). 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 (Martins et al., 30 Apr 2026).

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 (Abdelrazek, 26 May 2026, Martins et al., 3 Jun 2026).

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 (Abdelrazek, 26 May 2026).

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 (Abdelrazek, 26 May 2026).

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 (Abdelrazek, 26 May 2026).

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” (Abdelrazek, 26 May 2026).

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 (Abdelrazek, 26 May 2026).

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 (Abdelrazek, 26 May 2026, Abdelrazek et al., 29 Sep 2025).

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 (Abdelrazek et al., 29 Sep 2025).

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 (Abdelrazek et al., 29 Sep 2025).

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 (Abdelrazek et al., 29 Sep 2025).

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 (Abdelrazek et al., 29 Sep 2025).

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 (Martins et al., 30 Apr 2026).

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 (Martins et al., 3 Jun 2026).

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 (Martins et al., 3 Jun 2026).

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 (Martins et al., 3 Jun 2026).

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 (Abdelrazek, 26 May 2026).

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 (Abdelrazek, 26 May 2026).

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 (Abdelrazek, 26 May 2026).

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 (Abdelrazek, 26 May 2026).

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 (Martins et al., 30 Apr 2026). 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 (Martins et al., 3 Jun 2026).

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 (Martins et al., 3 Jun 2026, Martins et al., 30 Apr 2026). The TR292I paper presents a formal semantic walkthrough, not a full deployment benchmark, and explicitly notes that multi-intent arbitration remains future work (Abdelrazek, 26 May 2026). 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 (Abdelrazek et al., 29 Sep 2025).

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 (Abdelrazek, 26 May 2026, Abdelrazek et al., 29 Sep 2025). 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 (Tranoris et al., 25 Apr 2026, Trantzas et al., 25 Apr 2026).

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 (Huang et al., 16 Jul 2025).

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.