1
rApp/xApp Attestation: A New Security Use Case for O-RAN
arXiv:2609.24296v1 [cs.CR] 21 Sep 2026
Hamed Alimohammadi∗ ID, Burcu Şahin† ID, Arda Akman† ID, Chuan Heng Foh∗ ID, Senior Member, IEEE, Periklis Chatzimisios‡ ID, Senior Member, IEEE, and Mohammad Shojafar∗ ID, Senior Member, IEEE ∗ 6GIC, Institute for Communication Systems (ICS), University of Surrey, Guildford, UK † Nokia, Sunnyvale, California, United States ‡ Department of Information and Electronic Engineering, International Hellenic University, Thessaloniki, Greece Email: {h.alimohammadi,c.foh,m.shojafar}@surrey.ac.uk, {burcu.sahin,arda.akman}@nokia.com, [email protected]
Abstract—The disaggregation and softwarization introduced by the Open Radio Access Network (O-RAN) architecture enable multi-vendor innovation but also expose the RAN Intelligent Controller (RIC) ecosystem to new runtime security risks. Existing O-RAN specifications define strong safeguards for onboarding, authentication, identity management, and secure communication; however, they do not provide a concrete mechanism for verifying whether deployed rApps and xApps remain in their intended, untampered state during operation. This paper introduces rApp/xApp attestation as a RIC-native O-RAN security use case for runtime integrity verification. Rather than proposing a new cryptographic protocol, the work defines how existing integrity verification techniques can be integrated into O-RAN through attestation modules, attestation agents, RIC application interfaces, and SMO-driven policy coordination. We map the use case to relevant O-RAN Alliance working groups, identify required standardization extensions, and demonstrate feasibility through a lightweight hash-based prototype implemented on the Near-RT RIC platform. Experimental results show attestation latencies below 40 ms across multiple cryptographic hash functions, indicating that runtime attestation can be performed without disrupting time-sensitive RIC operations when appropriately scheduled. Finally, we discuss remaining technical and standardization challenges, including trusted verification, known-good runtime states, scalability, mitigation policies, and future hybrid attestation mechanisms.
I. I NTRODUCTION The Open Radio Access Network (O-RAN) disaggregates traditionally integrated RANs into standardized Radio Units (ORUs), Distributed Units (O-DUs), and Central Units (O-CUs), with open interfaces between them. This enables multi-vendor deployment, fostering competition and innovation. A defining feature of O-RAN is the RAN Intelligent Controller (RIC), comprising the Non-Real-Time RIC (Non-RT RIC) and Near-Real-Time RIC (Near-RT RIC). The Non-RT RIC, within the Service Management and Orchestration (SMO), operates above one-second timescales and hosts rApps for longterm optimization and analytics, while the Near-RT RIC operates between 10 ms and 1 s and hosts xApps for time-sensitive
control such as traffic steering, interference management, and mobility optimization. Through A1, rApps provide policies and guidance to near-real-time xApps. While this architecture enables flexibility and innovation, it also expands the RIC control ecosystem by introducing open interfaces, multi-vendor software components, and thirdparty control applications into the RAN decision-making path. Among these new exposure points, rApps and xApps are particularly security-critical because they can influence RAN behavior at both the policy and near-real-time control layers. A compromised rApp or xApp could therefore manipulate control logic, alter operational data, or disrupt network behavior. The O-RAN Alliance recognizes these risks and has issued specifications through Working Group 11 (WG11) for onboarding, authentication, and interface protection. However, they do not ensure application integrity after deployment. The Study on Security for Application Lifecycle Management [1] identifies runtime integrity as a potential requirement but does not define a mechanism for enforcing it. Thus, runtime trust remains an open gap, summarized in Section II. Recent research has explored zero-trust security in O-RAN, most notably ZTRAN [2], which implements authentication, intrusion detection, and secure slicing through dedicated xApps in the Near-RT RIC to strengthen network-level security and access control. It also highlights the need for monitoring and anomaly detection to identify suspicious behavior in network operations and control actions, thereby acknowledging that rApps/xApps may deviate from their intended operation at runtime. However, the study primarily focuses on using xApps to secure the network rather than verifying the integrity of the xApps themselves, and thus does not establish runtime trust in rApps/xApps. In parallel, other studies have examined security challenges in O-RAN applications. For instance, [3] analyzes threats related to xApp access control and the E2 interface, highlighting vulnerabilities in control-plane interactions. Similarly, [4]
2
proposes a framework for authentication, authorization, and isolation of xApps, focusing on service-level protection and secure onboarding. While these efforts address important aspects of O-RAN security, including access control, interface protection, and service isolation, they do not address the scenario where a compromised application behaves maliciously while operating within its permitted privileges. A natural candidate for addressing this missing runtime assurance is remote attestation. Techniques developed in trusted computing, cloud, and Network Functions Virtualization (NFV) environments provide mechanisms for verifying software integrity, typically through hash- or measurement-based approaches combined with challenge–response protocols. These approaches may be supported by hardware roots of trust such as Trusted Platform Modules (TPMs) and Trusted Execution Environments (TEEs), which strengthen integrity guarantees. However, such frameworks are not designed for the servicebased, multi-vendor, and control-loop-driven nature of the ORAN RIC, nor do they define how attestation integrates with RIC workflows, interfaces, and lifecycle management. Moreover, O-RAN deployments rely on heterogeneous, commercial off-the-shelf (COTS) infrastructures where uniform hardware trust anchors cannot be assumed, limiting the direct applicability of hardware-assisted approaches. To address this gap, this paper introduces rApp/xApp attestation as an O-RAN security use case for runtime integrity verification of applications operating within the RIC. Attestation enables continuous validation of application integrity during execution, providing operators with assurance that rApps/xApps remain in their intended, untampered state. Rather than proposing a new attestation algorithm or cryptographic protocol, this work focuses on defining a RIC-native use case that integrates existing integrity verification techniques into the O-RAN architecture, aligned with its interfaces (e.g., R1 and RIC APIs), lifecycle models, and timing constraints, while identifying the standardization gaps required to support runtime trust and suggesting a roadmap for their integration into future O-RAN specifications. The main contributions of this paper are as follows: 1) rApp/xApp attestation is introduced as a new O-RAN security use case to address the lack of runtime integrity verification in current specifications. 2) A standards-aligned attestation workflow is designed and mapped to relevant O-RAN working groups and interfaces, providing a concrete integration and standardization path. 3) The feasibility of the proposed approach is demonstrated through a lightweight prototype integrated into a NearRT RIC platform, showing that runtime attestation can be performed with millisecond-scale overhead. 4) Key challenges and open issues in deploying runtime attestation in O-RAN are systematically identified, together with directions for scalable and standardized integration.
The remainder of this paper is organized as follows. Section II reviews the relevant O-RAN security specifications and identifies the runtime integrity gap. Section III presents the proposed rApp/xApp attestation use case. Section IV discusses its alignment with O-RAN working groups and related telecom security frameworks. Section V describes the prototype implementation and evaluation results. Section VI outlines remaining challenges and future directions, and Section VII concludes the paper. II. S TANDARDS C ONTEXT: BACKGROUND AND G APS The O-RAN Alliance has defined a comprehensive set of security specifications under WG11 covering O-Cloud security, application onboarding, authentication, lifecycle management, and interface protection for rApps/xApps and RIC components. These specifications collectively establish baseline security controls, including application registration, identity management, secure communication, and conformance testing. The OCloud security assessment further recommends remote attestation for establishing trust in O-Cloud components and service deployments, including VM/container measurement at launch and while in use. In addition, several study items explicitly recognize the risk of compromised rApps/xApps and highlight runtime integrity as a potential concern. Table I summarizes the scope, coverage, and limitations of the most relevant specifications, highlighting the absence of concrete mechanisms for runtime integrity verification. These specifications demonstrate that runtime integrity is a recognized concern in O-RAN security, yet no concrete RIC-native mechanism or implementation guidance exists for runtime rApp/xApp attestation. This gap motivates rApp/xApp attestation as a practical, standardizable approach to runtime security for the RIC. III. P ROPOSED U SE C ASE : R A PP / X A PP ATTESTATION To enable runtime assurance of rApps and xApps in O-RAN, we propose rApp/xApp attestation as a runtime integrity verification use case within the RIC. The key idea is that the RIC continuously or periodically verifies the integrity of deployed applications by requesting and validating runtime evidence against trusted reference measurements. This enables operators to maintain assurance over application behavior throughout their lifecycle, complementing existing onboarding and access control mechanisms. Attestation interactions cross the RIC application interfaces, using RIC APIs in the Near-RT RIC and the R1 interface in the Non-RT RIC. Fig. 1 illustrates the architecture and operational phases of the proposed attestation use case. At a high level, the attestation process follows a closed-loop interaction between the RIC, the application (rApp/xApp), and the SMO. The RIC initiates an attestation challenge, to which
3
TABLE I
S UMMARY OF RELEVANT O-RAN SECURITY SPECIFICATIONS AND IDENTIFIED GAPS . Specification WG11 SRCS TS [5]
WG11 AppLCM Security TR [1] WG11 Threat Modeling TR [6] WG11 Security Test Specs TS [7]
Focus Area Security requirements (baseline controls) Application lifecycle security (operation phase) Comprehensive threat catalog Security validation
Coverage Registration, identity management, API authorization
Gap No requirement that mandates rApp/xApp runtime integrity verification
Identifies runtime threats; proposes cryptographic hash verification as a potential requirement; discusses feasibility limits
Acknowledged issue, but no informative mechanism due to feasibility concerns
Identifies threats across O-RAN; compromised rApps/xApps highlighted as a major risk Defines onboarding, package signing and verification, OAuth 2.0 client authorization, and lifecycle tests (e.g., signature validation and secure decommissioning) for rApps/xApps Identifies security gaps and additional security controls across xApp/Near-RT RIC and rApp/Non-RT RIC ecosystems
No defined countermeasures or runtime defenses No runtime integrity verification or attestation testing
WG11 ZTA TR [8]
Zero Trust security for O-RAN
WG11 SMO Security Analysis TR [9]
SMO, Non-RT RIC, and rApp security
WG11 Near-RT RIC & xApps TR [10]
Near-RT RIC and xApps threats
Identifies rApp management and software onboarding as security-relevant; analyses threats from compromised or misbehaving rApps Identifies compromised xApps as a key security concern and recommends onboarding safeguards
WG11 O-Cloud Security TR [11]
O-Cloud security and threat assessment
Recommends remote attestation of O-Cloud components, including VM/container measurement at launch and while in use
the application responds by obtaining integrity evidence derived from its runtime state. This evidence is then verified within the RIC against trusted reference measurements. Based on the verification outcome, the RIC reports the result to the SMO, which provides policy-driven guidance for monitoring and mitigation actions. Although attestation policies are provisioned by the SMO, the operational cycle is executed within the RIC, enabling local and timely verification. The main functional roles in this architecture can be summarized as follows: RIC (Near-RT and Non-RT): acts as the verifier, realized through an internal attestation module that issues attestation challenges, validates received evidence against reference measurements, maintains attestation records, and enforces mitigation actions when required. • rApps/xApps: act as attestation targets, equipped with a lightweight attestation agent that responds to challenges by obtaining and returning integrity evidence derived from their software artifacts or runtime state. • SMO: provides attestation policies (e.g., frequency and operational thresholds for triggering mitigation actions, such as repeated verification failures or excessive response delays) and consumes attestation results for monitoring, logging, and operational control. •
A. Attestation Model and Data Abstraction The proposed use case follows an integrity-based attestation model, where measurements of software and configuration
No runtime attestation mechanism for verifying rApp/xApp integrity during operation No runtime integrity verification or attestation mechanism for rApps/xApps No runtime integrity verification or attestation mechanism for xApps after deployment No RIC-native runtime attestation procedure for rApps/xApps
states are validated against trusted reference values. Such references should correspond to an approved application version and configuration and be updated through authorized lifecycle changes, ensuring that runtime evidence is evaluated against the appropriate known-good state. This approach is lightweight, directly verifiable, and suitable for periodic runtime checking in RIC environments. The attestation process relies on three types of data: (i) reference measurements, representing trusted software and configuration baselines maintained within the RIC; (ii) runtime evidence, obtained from rApps/xApps in response to attestation challenges; and (iii) metadata and logs, including timestamps and verification outcomes used for auditing and policy enforcement. While integrity-based verification provides a practical foundation, complementary mechanisms such as behavioral evidence (e.g., system calls, execution traces, or control actions) may further enhance detection coverage. However, such approaches are more context-dependent and are therefore considered as extensions rather than core components of the proposed use case. It is discussed in more detail in Section VI B. Threat Model The attacker is assumed to compromise the software environment of a deployed rApp or xApp after successful onboarding and registration. Possible attack vectors include binary manipulation, code injection, configuration tampering, or unauthorized updates. The attacker’s goal is to alter control logic or data flows while remaining undetected by existing onboarding and interface protections.
4
RIC Attestation Module Verifier (integrity Check) • Validate evidence
Near-RT RIC
• Check integrity against
Platform
xApps xApp Under Attestation
reference measurements • Produce attestation result
Attestation Module
Attestation Agent
Reference Measurements • Approved software artefacts • Configuration baselines
Non-RT RIC rApps
Framework
Attestation Agent
Attestation Module
• Policy Management (Attestation frequency, thresholds for triggering mitigation actions, actions) • Monitoring & Logging
(verifiable states) Attestation parameters
rApp Under Attestation
SMO (Policy & Monitoring)
• Lifecycle Actions (e.g. isolate, disable, re-onboard)
Policy parameters from SMO Audit & Logging Attestation records, timestamps, results
Phase 1: Challenge The RIC (Near-RT or NonRT) sends an attestation challenge to the rApp/xApp.
Phase 2: Evidence Collection & Response The attestation agent obtains integrity evidence (e.g., measurements of software artefacts or runtime states) and returns it to the RIC.
Phase 3: Verification & Reporting
Phase 4: Policy Update & Monitoring
The RIC verifies the evidence against reference measurements and sends the attestation result to the SMO.
The SMO uses attestation results for monitoring, logging, and operational actions, and updates policies and parameters provided to the RIC.
Fig. 1. Architecture of the proposed rApp/xApp attestation use case in O-RAN. The RIC (Near-RT and Non-RT) performs runtime integrity
verification of applications through an attestation function, interacting with rApps/xApps via standard interfaces and reporting outcomes to the SMO for policy-driven monitoring and control.
Consistent with existing O-RAN security analyses, the NonRT framework and Near-RT RIC platform and their attestation module are assumed to remain trusted, with securely maintained reference measurements. The threat model also considers attempts to forge attestation responses or replay outdated evidence, requiring the attestation mechanism to detect both static and runtime modifications in a timely manner.
C. Mitigation Actions Upon detecting integrity violations, the RIC applies mitigation actions that balance network protection with service continuity. Rather than relying on a single response, mitigation can be hierarchical and policy-driven: Isolation: temporarily remove the affected rApp/xApp from control loops while keeping it under observation. • Privilege reduction: restrict access to APIs or configuration capabilities until integrity is re-established. •
Quarantine and validation: move the application to a controlled state for further inspection or re-attestation. • Controlled deactivation: disable the application via lifecycle management when necessary and notify the SMO. • Recovery and re-onboarding: restore the application after validation through standard onboarding procedures. These actions are governed by SMO-configured policies, which define how attestation outcomes are translated into mitigation decisions. Such policies may consider factors such as repeated verification failures or severity. Standardizing policydriven mitigation procedures would further enhance interoperability and consistent security enforcement across multi-vendor O-RAN deployments. •
IV. S TANDARDS A LIGNMENT AND ROADMAP The proposed rApp/xApp attestation use case complements and extends existing O-RAN specifications by addressing the absence of runtime integrity verification identified in Section II.
5
It builds on current architectural components and interfaces, enabling integration without introducing new entities. In the absence of standardization, such mechanisms are likely to be implemented in a vendor-specific manner, leading to fragmentation and reduced interoperability.
attestation outcomes into existing lifecycle workflows, operators can enforce consistent and automated responses to runtime integrity violations without introducing new management frameworks. C. Security Integration (WG11)
A. Architectural Integration within the RIC (WG1, WG2, WG3) Attestation can be realized within the Non-RT RIC framework and the Near-RT RIC platform, which host rApps and xApps, respectively, and support service-based interaction models. This aligns with WG1, where use cases are defined and integrated into the overall O-RAN system design. Extending the O-RAN Use Cases Detailed Specification [12] to include runtime attestation represents a natural evolution of existing security-related scenarios. At the interface level, the proposed approach can be realized through dedicated services, allowing both the RIC and rApps/xApps to act as either service providers or consumers. In the Non-RT RIC (WG2), attestation can be supported over the R1 interface by introducing a dedicated service in which the rApp provides integrity evidence while the RIC issues challenges and verifies responses. In the Near-RT RIC (WG3), although communication between xApps and the Near-RT RIC platform may differ across RIC implementations, the O-RAN specifications define a Near-RT RIC API framework supporting service-based interactions between xApps and the NearRT RIC platform, including API registration and discovery [13]. Accordingly, a dedicated xApp attestation service and its corresponding API can be defined within the WG3 Near-RT RIC API framework, enabling challenge–response exchange and reporting between the RIC and xApps. This provides a common standardization path while allowing implementationspecific communication mechanisms to differ across Near-RT RIC implementations. In both contexts, rApps/xApps act as service providers of attestation evidence, while the RIC acts as the service consumer responsible for initiating attestation and validating responses. As a result, attestation can be incorporated without introducing new functional entities, requiring only the definition of the corresponding attestation services and APIs. B. Lifecycle and Operational Integration (WG10 and SMO Coordination) WG10 specifies the O-RAN Operations and Maintenance Architecture [14], including SMO-driven lifecycle management via the O1 interface. Within this framework, attestation results can be reported from the RIC to the SMO, enabling their use in monitoring, fault management, and policy-driven control. SMO policies can govern key operational parameters of attestation, such as frequency, triggering conditions, thresholds for failure, and corresponding mitigation actions. By integrating
From a security perspective, WG11 specifications can be extended to include requirements for runtime integrity verification, including the provisioning of trusted reference measurements (e.g., approved software and configuration baselines) during onboarding. These references enable subsequent verification of runtime evidence obtained from rApps/xApps. In addition, WG11 can define supporting procedures and validation mechanisms for attestation, such as challenge–response verification, freshness guarantees, and reporting of outcomes, enabling consistent implementation and evaluation across vendors. Attestation extends the WG11 security framework with runtime integrity verification, complementing and operating alongside existing mechanisms for identity management, authentication, and certificate handling. Overall, this extends the O-RAN security framework from pre-deployment assurance to continuous runtime trust validation, while remaining aligned with existing architectural and operational models. Accordingly, standardization should focus on defining the attestation services and APIs, evidence and reference requirements, and validation procedures, while allowing different attestation mechanisms to realize these requirements. The remaining technical challenges for practical adoption are discussed in Section VI. D. Relation to Existing Telecom Security Frameworks Existing telecom security frameworks provide useful context but do not directly address runtime integrity of RIC applications. ETSI NFV-SOL 004, which specifies VNF package and archive requirements, includes integrity protection through package signing and verification. Similarly, 3GPP Security Assurance Specifications (SCAS), such as TS 33.117, and the GSMA Network Equipment Security Assurance Scheme (NESAS) focus primarily on security assurance and conformance testing. These approaches provide relevant foundations but require adaptation to the service-based, control-loop-driven, and heterogeneous COTS environment of O-RAN. V. P ROTOTYPE AND R ESULTS The proposed attestation use case applies to both rApps in the Non-RT RIC and xApps in the Near-RT RIC. However, these platforms operate under significantly different timing constraints. For this reason, we prioritize feasibility evaluation where requirements are most stringent. Our hypothesis is that
6
if runtime attestation introduces sufficiently low overhead to remain practical within Near-RT RIC operations, then the same approach will be inherently feasible for rApps in the Non-RT RIC, which is less time-critical. We therefore implement and evaluate the attestation mechanism only for xApps, while noting that the design and workflow generalize directly to rApps as described in Section III. This section presents both the prototype realization of the proposed attestation mechanism and its performance evaluation, providing insight into its practical deployment in the O-RAN architecture. The prototype implements a lightweight hashbased attestation mechanism, where integrity is verified through cryptographic digests of application binaries combined with challenge–response interaction. The prototype builds upon the xApp integrity check module from our prior work [15]. However, that implementation did not optimize the verification pipeline and introduced avoidable overhead. Runtime attestation requires repeated access to application binaries and reference measurements, which introduces non-negligible I/O and computation overhead. In RIC environments, excessive overhead may limit the feasibility of frequent verification. Therefore, optimizing the verification process is essential to ensure that attestation can be performed efficiently without interfering with normal operation. The most impactful improvement was redesigning the memory access routine and implementing a more efficient filereading mechanism, reducing verification overhead by ∼30%. This was achieved by eliminating repeated buffered reads and mapping the reference file directly into memory, reducing copy overhead and enabling more efficient access during hash computation. This optimization enables faster loading and hashing of the reference image, particularly for larger digests. We further extend the module to evaluate multiple cryptographic hash functions, allowing us to quantify execution cost and study how the optimized implementation scales with digest size. A. Prototype and Evaluation Setup To validate feasibility under Near-RT constraints, we implemented a proof-of-concept xApp attestation prototype on a FlexRIC-based Near-RT RIC platform, reflecting a realistic deployment where xApps operate under latency-sensitive conditions. The prototype implements a lightweight hashbased attestation mechanism, where integrity is verified through cryptographic digests of application binaries, computed over their memory-resident executable content, combined with a challenge–response interaction. The interaction workflow is illustrated in Fig. 2. A custom xApp was extended with an attestation agent that responds to challenges issued by the attestation module in the Near-RT RIC, which acts as the verifier and maintains a trusted baseline image of the xApp. Upon connection, the xApp provides its metadata
and receives an attestation challenge. The attestation agent computes a hash over its executable content combined with a challenge seed and returns the result as integrity evidence. The verifier recomputes the expected hash over the trusted reference using the same seed and compares the results to determine integrity. This seed-based challenge–response protocol ensures freshness and protects against replay attacks while remaining lightweight and suitable for periodic runtime verification. In the prototype, the attestation functionality is exposed through a dedicated API implemented for this work. For standardization, a corresponding xApp attestation service and API could be defined within the WG3 Near-RT RIC API framework, as discussed in Section IV-A. The prototype consumes a set of well-defined input data and produces corresponding outputs, summarized in Table II. This mapping also illustrates how attestation interactions integrate with existing O-RAN interfaces. We evaluated the prototype using an xApp with a binary footprint of approximately 10 MB, representative of lightweight Near-RT RIC applications. Each attestation cycle consists of challenge issuance, hash computation at the xApp, response transmission, and verification at the RIC. By structuring the evaluation around this isolated attestation cycle, the measured latency directly reflects the overhead introduced by the attestation mechanism, without being conflated with other RAN processing tasks. The xApp computes hashes over its readable-executable (r-xp) memory mappings, while the RIC recomputes the digest over a stored reference image. Writable regions are excluded because their contents may legitimately change at runtime and therefore do not provide a stable reference for direct hash comparison. Experiments were executed on an Intel(R) Core(TM) i714700 CPU @ 2.10 GHz, 32 GB RAM, running Ubuntu 24.04 (64-bit). B. Results We benchmarked attestation using SHA-256, SHA-512, SHA3-256, and BLAKE2b (512-bit), comparing classic SHA2 hashes with more manipulation-resistant designs. Each algorithm ran across 50 rounds. The first round exhibited only a modest cold-start increase of approximately 3–4 ms compared with the subsequent rounds and was excluded from the reported steady-state averages. Fig. 3 reports the latency breakdown of the attestation cycle, including xApp-side hash computation, RIC-side verification, and additional overhead, along with the total latency. The total latency corresponds to the sum of these components. The overhead component captures the noncomputational costs of attestation, including communication between the xApp and RIC, protocol handling, and scheduling effects. In this decomposition, the dominant contributors to latency are the hashing and verification steps, while the overhead
7
xApp Attestation Agent [Prototype]
Near-RT RIC Verifier [Prototype]
SMO (Reporting) [Architectural Path]
Policy Update (frequency, threshold) 1 Attestation Challenge
Includes: challenge seed and algorithm (e.g., SHA-256). 2
Compute Seeded Hash Over xApp binary Image H= Hash (binary || seed) (e.g., SHA-256) 4 3
Attestation Response (calculated hash) Send: H
1) 2) 3) 4)
Recompute Reference Hash & Compare Load trusted reference binary image H-ref = Hash (ref_binary || seed) (same algorithm) Compare H == H-ref
Match (valid)
Mismatch (Invalid)
5
Mitigation Action
6
• • •
Attestation Result Send: status (valid/invalid), timestamp
Disable xApp Quarantine / isolate Other actions per policy
Report Result via O1 (SMO path) (status, details, timestamp, etc)
Fig. 2. Sequence of the hash-based runtime attestation procedure in the implemented prototype. TABLE II
R EQUIRED I NPUT AND O UTPUT DATA FOR X A PP ATTESTATION . Type Input
Output
Interface O1 Near-RT RIC API – Future xApp attestation API O1 Near-RT RIC API – Future xApp attestation API
Source SMO
Target Near-RT platform
Near-RT RIC platform
xApp
Near-RT RIC platform
SMO Near-RT platform
xApp
remains relatively stable across algorithms. These measured components collectively represent the additional processing cost introduced by attestation relative to a baseline system without attestation. Overhead remains nearly constant across algorithms, with small growth tied to digest size. SHA-512 is roughly twice as slow as SHA-256, and SHA3-256 is the slowest despite identical output length. SHA3-256 and BLAKE2b-512 provide stronger resistance against length-extension and craftedcollision attacks, but at higher computation cost. Practically, SHA-256 remains the most suitable for frequent attestation, while SHA-512 increases digest size and collision resistance with moderate added cost. SHA3-256 and
RIC
RIC
Description Attestation parameters such as frequency, thresholds, and mitigation policies. Challenge seed ensuring freshness and preventing replay attacks. Validation results, timestamps, alerts, and escalation events. Attestation response including calculated hash.
BLAKE2b-512 offer stronger robustness at higher cost, with BLAKE2b providing a favorable balance between performance and security. All algorithms complete within millisecond-scale timing, confirming feasibility for periodic runtime attestation in Near-RT RIC. Using the same prototype and attestation procedure, we further evaluated its detection capability against selected runtime attack scenarios. As shown in Table III, these cases illustrate the detection boundary of the prototype: modifications affecting the measured executable content are detected, whereas changes outside the measured state remain beyond the coverage of hashbased attestation. Although attestation operates outside the main control loop
8
TABLE III
RUNTIME ATTACK COVERAGE . Test case Existing executable-code modification Code injection into new r-xp mapping Modification outside measured r-xp state
Result Detected Detected Not detected
of Near-RT RIC and is not subject to strict real-time constraints, it is executed periodically and introduces additional computational load on the hosting platform. Excessive delay could indirectly impact the control loop execution execution if verification interferes with ongoing xApp processing. However, the measured latencies remain in the millisecond range, which is small relative to typical RIC processing timescales, indicating that such effects are limited in practice. This impact can be further mitigated through appropriate scheduling and attestation frequency control, but their effectiveness under representative RAN workloads requires further evaluation. 35 30
xApp Comp. RIC Comp.
Non-Comp. Overhead Total Latency
35.4
28.0
26.5
Time (ms)
25 20
18.7
15 10.4
10 5 0
12.2 12.4
11.3 8.2 8.5
12.1
10.7 7.0 7.4
4.0 4.3
SHA-256
SHA-512
SHA3-256
Algorithm
BLAKE2B
Fig. 3. xApp attestation latency.
C. Implications The evaluation demonstrates that integrating runtime attestation within the RIC introduces only millisecond-scale overhead, confirming its feasibility under Near-RT constraints. The prototype shows that runtime xApp attestation is technically feasible under the evaluated Near-RT RIC conditions. By introducing only limited additional latency in the evaluated setup, the mechanism supports periodic integrity verification alongside time-sensitive control operations when appropriately scheduled. This positions attestation as a practical extension to existing O-RAN security mechanisms, while leaving room for future enhancements such as behavioral monitoring or hardwareassisted verification. VI. C HALLENGES AND F UTURE D IRECTIONS While the prototype demonstrates the feasibility of runtime xApp attestation, several challenges remain before such
mechanisms can be deployed at scale in O-RAN systems. These include concerns already highlighted in Section 6.9 of the O-RAN.WG11.TR.AppLCM-Security report [1], as well as additional issues identified in this work. Together, they outline both the limitations of current approaches and the directions required for practical deployment and standardization. Security of the monitoring entity: A monitoring entity verifying application integrity must itself remain protected, as compromise would invalidate attestation results. In the proposed mechanism, the verifier is part of the trusted NonRT framework and Near-RT RIC platform and inherits its protection mechanisms. While this aligns with existing ORAN assumptions, stronger trust anchors (e.g., TPMs or TEEs) could further enhance protection where available, although their deployment may be constrained in virtualized and COTS environments. Defining known-good runtime states: A key challenge lies in defining what constitutes an “untampered” application during runtime. In this context, a known-good state is best interpreted as a verifiable software integrity state matching trusted reference artifacts (e.g., binaries or configuration baselines), rather than application behavior or network outcomes, which are context-dependent. However, runtime memory and configuration values may evolve legitimately, particularly in AI/MLdriven xApps, making stable reference selection non-trivial. Static hashing alone may therefore be insufficient, motivating richer verification approaches that combine integrity validation with complementary runtime observations. Stealthy attacks and limitations of software-based attestation: Attackers may evade detection by leaving the measured executable state unchanged while executing malicious logic outside that state. While seed-based attestation prevents replay attacks, it cannot fully address such stealthy behavior. Hashbased approaches are lightweight and cloud-friendly but rely on weak roots of trust. Complementary mechanisms, such as timing-based heuristics or behavioral monitoring (e.g., system calls, execution traces, or control anomalies), can improve detection coverage. Hash comparison itself is deterministic; however, legitimate changes to measured state may cause mismatches if trusted references are outdated. Reference lifecycle management is therefore necessary to distinguish authorized changes from integrity violations. Hybrid attestation mechanisms: To address these limitations, hybrid approaches combining software-based attestation with hardware-assisted trust anchors (e.g., TPMs or TEEs) offer a promising direction. Hardware-assisted methods may be applied selectively to critical functions, while lightweight software attestation scales to broader deployments. Such designs improve trust guarantees but introduce challenges in deployment, interoperability, standardizability, and system complexity. Performance and scalability: Aggregate attestation load grows with the number of applications, verification frequency,
9
and per-attestation cost. Concurrent checks may therefore cause resource contention and indirectly affect Near-RT RIC processing. Staggered scheduling, application prioritization, and adaptive frequency can limit such overhead. Multi-xApp scalability and performance under heavy RAN workloads remain to be experimentally evaluated. Mitigation actions and lifecycle integration: While mitigation strategies (e.g., isolation, privilege reduction, and controlled deactivation) can be triggered upon attestation failure, their conditions and integration into lifecycle management workflows are not yet fully defined. Standardizing these mechanisms, including their coordination with SMO-driven policies, is essential to ensure consistent behavior across vendors while preserving service continuity. Expanding the scope across the O-RAN ecosystem: Although this work focuses on rApps/xApps, similar integrity challenges exist for VNFs and cloud-native workloads. Extending attestation across these layers could enable a unified trust framework for disaggregated RAN systems, forming the basis of a broader “trust fabric” aligned with O-RAN’s open and programmable architecture. Overall, these challenges and directions indicate that while runtime attestation is technically feasible, its large-scale adoption requires advances in hybrid trust models, complementary monitoring, and adaptive orchestration. Addressing these aspects will be key to transforming rApp/xApp attestation from a prototype capability into a practical and standardized feature of O-RAN systems. VII. C ONCLUSION O-RAN programmability enables flexible and intelligent RAN control, but it also creates a need to ensure that deployed rApps and xApps remain trustworthy during operation. This paper introduced rApp/xApp attestation as a RIC-native security use case for runtime integrity verification. The proposed use case complements existing onboarding, authentication, and interface protection mechanisms by extending trust assurance into the operational phase. We mapped the attestation workflow to relevant O-RAN Alliance working groups and interfaces, showing how attestation can be realized through controlled extensions to R1, RIC APIs, and SMO-based lifecycle coordination. A hashbased prototype on a Near-RT RIC platform demonstrated that runtime attestation can be performed with millisecond-scale overhead, supporting its feasibility for periodic verification in latency-sensitive environments. The remaining challenges include securing the verifier, defining stable known-good states, scaling attestation across many applications, integrating mitigation actions into lifecycle workflows, and exploring hybrid mechanisms that combine software-based checks with hardware-assisted trust where available. Addressing these issues can help transform rApp/xApp attestation from a prototype
capability into a standardized security mechanism for secure and interoperable O-RAN deployments, providing a foundation for future O-RAN Alliance standardization efforts in runtime trust assurance. ACKNOWLEDGMENT This work was supported by UKRI (UK ID: 640240), CDTI (ES), ANI (PT ID: COMPETE2030-FEDER-01602800), and TUBITAK (TR ID: 9240013) within the EUREKA CELTICNEXT project 6G-SMART, C2023/2-20. R EFERENCES [1] “Study on Security for Application Lifecycle Management,” O-RAN Alliance, Technical Report O-RAN.WG11.TR.AppLCM-Security-R004v04.00, 2025, available at: https://specifications.o-ran.org/specifications. [2] A. S. Abdalla, J. Moore, N. Adhikari, and V. Marojevic, “ZTRAN: Prototyping zero trust security xApps for open radio access network deployments,” IEEE Wireless Communications, vol. 31, no. 2, pp. 66– 73, 2024. [3] C.-F. Hung, Y.-R. Chen, C.-H. Tseng, and S.-M. Cheng, “Security Threats to xApps Access Control and E2 Interface in O-RAN,” IEEE Open Journal of the Communications Society, vol. 5, pp. 1197–1203, 2024. [4] T. O. Atalay, S. Maitra, D. Stojadinovic, A. Stavrou, and H. Wang, “An OpenRAN Security Framework for Scalable Authentication, Authorization, and Discovery of xApps With Isolated Critical Services,” IEEE Transactions on Dependable and Secure Computing, vol. 22, no. 3, pp. 2873–2890, 2025. [5] “O-RAN Security Requirements and Controls Specification,” O-RAN Alliance, Technical Specification O-RAN.WG11.TS.SRCS.0-R005-v15.00, 2026, available at: https://specifications.o-ran.org/specifications. [6] “O-RAN Security Threat Modeling and Risk Assessment,” O-RAN Alliance, Technical Report O-RAN.WG11.TR.Threat-Modeling-R005v09.00, 2026, available at: https://specifications.o-ran.org/specifications. [7] “O-RAN Security Test Specifications,” O-RAN Alliance, Technical Specification O-RAN.WG11.TS.STS-R005-v13.00, 2026, available at: https: //specifications.o-ran.org/specifications. [8] “Study on Zero Trust Architecture for O-RAN,” O-RAN Alliance, Technical Report O-RAN.WG11.TR.ZTA-R005-v06.00, 2026, available at: https://specifications.o-ran.org/specifications. [9] “Study on Security for Service Management and Orchestration (SMO),” O-RAN Alliance, Technical Report O-RAN.WG11.TR.SMO-SecurityAnalysis.0-R005-v08.00, 2026, available at: https://specifications.o-ran. org/specifications. [10] “Study on Security for Near Real Time RIC and xApps,” O-RAN Alliance, Technical Report O-RAN.WG11.Security-Near-RT-RIC-xAppsTR.0-R005-v07.00, 2026, available at: https://specifications.o-ran.org/ specifications. [11] “Study on Security for O-Cloud,” O-RAN Alliance, Technical Report ORAN.WG11.TR.O-CLOUD-Security.0-R005-v09.00, 2026, available at: https://specifications.o-ran.org/specifications. [12] “Use Cases Detailed Specification,” O-RAN Alliance, Technical Specification O-RAN.WG1.TS.Use-Cases-Detailed-Specification-R005-v20.00, 2026, available at: https://specifications.o-ran.org/specifications. [13] “Near-RT RIC APIs,” O-RAN Alliance, Technical Specification O-RAN.WG3.TS.RICAPI-R005-v03.00, 2026, available at: https:// specifications.o-ran.org/specifications. [14] “O-RAN Operations and Maintenance Architecture,” O-RAN Alliance, Technical Specification O-RAN.WG10.TS.OAM-Architecture-R005v18.00, 2026, available at: https://specifications.o-ran.org/specifications. [15] H. Alimohammadi, S. Mayhoub, S. Chatzimiltis, M. Shojafar, and M. N. M. Bhutta, “Toward a Multi-Layer Defence Framework for Securing Near-Real-Time Operations in Open RAN,” IEEE Open Journal of the Communications Society, vol. 7, pp. 480–497, 2026.
10
B IOGRAPHIES Hamed Alimohammadi is a senior research fellow in mobile networks at the University of Surrey’s 6G Innovation Centre, specializing in Open RAN self-organization and security. He previously spent nearly a decade in mobile network governance and engineering roles. He holds a PhD in Computer Engineering from Razi University, Iran. At Surrey, he has contributed to flagship research programmes including 6G-SMART and HiPer-RAN, where he was part of the team recognized with the UK Government’s Future Network “Incremental Innovative” Award in 2025. His research interests span Open RAN security, machine learning for networks, and high-performance computing. Burcu Şahin is an O-RAN architect with over 15 years of experience in research, software development, product architecture, and standardization across wireless networks. She holds BSc and MSc degrees in Computer Science from Bilkent University and a PhD in Cognitive Science from Middle East Technical University. Burcu has contributed to R&D, product and standardization roles at Turk Telekom, Argela, and Juniper Networks, and currently works at Nokia focused on RAN Intelligent Controller product management and architecture. An active O-RAN Alliance standards contributor since 2018, she serves as rapporteur of E2SM-CCC and authored more than 20 patents. Arda Akman has over 30 years of R&D expertise in wireless networks. Currently, as R&D Director at Nokia, he is leading the product management and architecture of RAN Intelligent Controller (RIC). His previous roles include Senior Director of Engineering at Juniper Networks, Argela/Netsia, Turk Telekom R&D, Ixia and Nortel Networks. A very active contributor in O-RAN Alliance since 2018, he is leading the Use Case Task Group, Network Slicing Task Group and is also the rapporteur for 5 different specifications. He holds BSc and MSc degrees in Electronics Engineering and is the author of over 30 patent applications. Chuan Heng Foh (Senior Member, IEEE) received his M.Sc. from Monash University, Australia, in 1999, and his Ph.D. from The University of Melbourne in 2002. He briefly lectured at Monash before joining Nanyang Technological University, Singapore, as an Assistant Professor in 2002. He joined the University of Surrey in 2012 and is currently an Associate Professor there. He has authored over 180 refereed publications in international journals and conferences. His research interests include protocol design, machine learning applications, IoT, vehicular, wireless LANs, mobile ad hoc networks, 5G/6G systems, and Open RAN. He has held several IEEE leadership and editorial roles. Periklis Chatzimisios (Senior Member, IEEE) is currently a Professor at the International Hellenic University, Greece, and a Research Professor at the University of New Mexico, USA. His research interests include next-generation wireless communications, standardization, the Internet of Things (IoT), legal and ethical issues of artificial intelligence (AI), security, and robotics. He is the Vice-Chair of Working Group 1 and a Board Member of the one6G Association. He is currently an IEEE Communications Society Distinguished Lecturer. He has been included in Stanford University’s list of the world’s most influential scientists from 2020 to 2025. He serves as an Associate Editor-in-Chief of IEEE Communications Standards Magazine. Mohammad Shojafar is an Associate Professor in Network Security, an Intel Innovator, a Senior IEEE member, an ACM Distinguished Speaker, and a Higher Education Academy Fellow at the 6GIC, University of Surrey. He has secured around £3M as Principal Investigator across EU and UK projects. With the Surrey team, he received the “Incremental Innovative” Future Network Award for the DSIT/UKTIN HiPer-RAN project in 2025 and a Best Paper Award at the IEEE CSNet Conference in 2023. He is also the author of three Springer books and serves as Associate Editor for IEEE TNSM, IEEE TITS, IEEE TGCN, and IEEE TCE.