You know how your phone's app store checks that an app hasn't been tampered with before it installs — but never checks again while it's running? Imagine that same app controls cell towers serving millions of people. That's the gap this paper addresses in O-RAN, the open telecom architecture that's replacing proprietary base stations with modular, multi-vendor software components. The core claim: O-RAN specs lock down onboarding, authentication, and secure communication, but provide no mechanism to verify that rApps and xApps — the software brains running on the RAN Intelligent Controllers — haven't been modified after deployment. The authors propose "rApp/xApp attestation" as a formal RIC-native security use case, mapping it to existing O-RAN working groups (WG1, WG2, WG3, WG11) and defining the architectural plumbing needed: attestation modules, attestation agents, RIC application interfaces, and SMO-driven policy coordination. This isn't a new cryptographic protocol — it's an integration architecture that assembles known integrity verification techniques into the O-RAN stack. The prototype is deliberately minimal: a hash-based attestation agent running on the Near-RT RIC platform, testing SHA-256, SHA-384, SHA-512, and BLAKE2b against deployed xApp binaries. Attestation latencies came in below 40 milliseconds across all hash functions, with the authors arguing this is well within acceptable bounds for periodic runtime checks that don't interfere with the RIC's time-sensitive control loops (which operate on the order of 10ms–1s for Near-RT RIC decisions). The ladder context matters here. There is no direct prior work that implements runtime attestation specifically for O-RAN rApps/xApps — the authors are essentially proposing a new category of O-RAN security function rather than beating an existing implementation. The closest analogues are Trusted Platform Module (TPM) remote attestation in cloud computing and Intel SGX-style enclave verification, but neither has been mapped to O-RAN's specific architecture with its SMO/RIC/A1/E2 interface topology. The paper's novelty is architectural integration, not cryptographic innovation. The integrity picture is mixed. The prototype demonstrates feasibility — hash computation is fast, unsurprisingly — but doesn't tackle the hard problems the authors themselves identify: establishing trusted known-good reference states, handling dynamic runtime environments where app memory changes legitimately, scaling attestation across hundreds of xApps, and defining what actually happens when attestation fails. The experimental validation proves that hashing a binary takes less than 40ms, which is not a surprising result. The real engineering challenges are all in the 'future work' section. What makes this paper matter isn't the prototype but the standardization mapping. O-RAN is being deployed now by major operators (AT&T, Deutsche Telekom, Rakuten), and the security gap the authors identify is real. If a compromised xApp runs on a Near-RT RIC making sub-second radio resource management decisions, the blast radius is significant — potential eavesdropping, denial of service, or manipulation of network slicing policies. The paper's value is naming the problem precisely and showing the O-RAN Alliance where to put the fix. The successor question is telling: the authors didn't test with hardware-rooted trust (TPM, TEE) or with adversarial scenarios where an attacker actively tries to evade attestation. The honest read is (a) — the prototype was scoped to demonstrate timing feasibility on a software-only platform, and hardware trust integration requires vendor cooperation and physical infrastructure they likely didn't have. The more interesting experiment they didn't run is attestation under load: what happens to those <40ms latencies when the RIC is processing thousands of E2 messages per second while simultaneously attesting 50 xApps?
