Open RAN Security in Europe: Why Sovereign Network Testing Matters

A European MNO’s NOC, 2 AM. An anomalous burst of RRC Reconfiguration messages lights up the monitoring dashboard on a newly deployed O-RAN site. The xApp from vendor B is triggering unexpected handovers on vendor A’s radio unit. Vendor A blames the RIC. Vendor B blames the radio configuration. The integrator points to the fronthaul timing. No single vendor owns the problem.

This is not a hypothetical scenario. It is the operational reality of multi-vendor Open RAN. And when security is at stake, the question becomes: who validates the assembled system?

The Open RAN promise and its security trade-offs

The O-RAN Alliance architecture disaggregates the traditional RAN into modular, interoperable components: O-CU (Centralized Unit), O-DU (Distributed Unit), O-RU (Radio Unit), and the RIC (RAN Intelligent Controller) with its ecosystem of xApps and rApps. The goal is vendor diversity, cost reduction, and innovation through open interfaces.

The trade-off is structural: disaggregation multiplies interfaces, and each interface is a potential attack surface. A monolithic RAN from a single vendor has internal interfaces that are proprietary and opaque. An O-RAN deployment has standardized, documented interfaces between components from different vendors. Open interfaces are easier to integrate. They are also easier to probe.

3GPP TS 33.501 defines the 5G security architecture, including authentication, key management, and user plane integrity protection. O-RAN WG11 (Security Work Group) published specifications for securing O-RAN interfaces, including the E2 interface between the RIC and the O-DU/O-CU, the A1 interface between the Non-RT RIC and the Near-RT RIC, and the O1 management interface.

But specifications are not implementations. And implementations tested in isolation are not systems tested under real-world conditions.

The orange nodes represent the interfaces where multi-vendor integration introduces the highest risk. Each one is a boundary where vendor A’s code meets vendor B’s code, with security assumptions that may not align.

Europe’s regulatory response: EU 5G Toolbox and NIS2

Europe has not ignored the risk. The regulatory framework for 5G and Open RAN security has been built progressively since 2019, with two major instruments now in force.

The EU 5G Toolbox, adopted in January 2020 and updated in 2023, defines strategic measures for Member States. It explicitly addresses the risk profile of suppliers, recommending restrictions on high-risk vendors for core network functions and sensitive RAN components. The Toolbox does not ban specific vendors by name, but the framework is designed to enable national decisions on supplier restrictions.

The NIS2 Directive (Directive 2022/2555), effective since October 2024, classifies telecommunications as an essential sector. Operators are now subject to mandatory risk management measures, incident reporting obligations (24-hour notification for significant incidents), and supply chain security requirements. Article 21 specifically requires “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.”

For Open RAN deployments, NIS2 means that operators cannot rely solely on vendor certifications. They must demonstrate that they have validated the security of their assembled multi-vendor system.

The direction is clear: European regulators are shifting from vendor-level risk assessment to system-level security validation. For operators deploying Open RAN, this means independent verification of the assembled multi-vendor chain, not just trust in individual vendor certifications.

Where Open RAN security breaks down in the field

Security specifications define what should happen. Field testing reveals what actually happens. The gap between the two is where vulnerabilities live.

Fronthaul exposure

The fronthaul link between O-DU and O-RU carries eCPRI (enhanced Common Public Radio Interface) traffic. O-RAN WG4 specifies the fronthaul plane. In some deployments, eCPRI traffic traverses the fronthaul without encryption, particularly when vendors prioritize latency over confidentiality. An attacker with physical or logical access to the fronthaul segment can intercept IQ samples, inject malformed radio frames, or disrupt timing synchronization.

RIC and xApp trust boundaries

The Near-RT RIC executes xApps that make real-time decisions about RAN behavior: traffic steering, handover optimization, load balancing. These xApps are often third-party code running with privileged access to E2 interface messages. A compromised or poorly validated xApp can trigger mass handovers, degrade service for specific subscribers, or exfiltrate signaling data through the E2 interface.

O-RAN WG11 defines security requirements for xApp onboarding, but enforcement varies across RIC implementations. The field is where xApp behavior is observed under real RF conditions, real traffic load, and real multi-vendor interactions.

Multi-vendor integration gaps

Each vendor certifies its component in its own lab environment. The O-RAN Alliance conducts plugfests and interoperability testing events. But nobody systematically tests the complete assembled chain under production conditions. This leaves integration gaps that only appear when the system is stressed by real-world variables: interference patterns, handover storms at cell boundaries, timing drift under thermal load, and unexpected xApp interactions.

The two approaches are complementary, but field testing catches the class of problems that matter most for operational security: the ones that only emerge when the full system operates under uncontrolled conditions.

Sovereign testing: why operators must own their validation

Sovereign testing is the principle that an operator must be able to independently validate the security and performance of its network, without depending on the validation results provided by its equipment vendors.

This is not a philosophical position. It is an operational and regulatory necessity.

When an operator relies exclusively on vendor-provided test results, it is trusting without verifying. Each vendor tests its own component and reports the results. But no vendor has an incentive to report problems that arise from the interaction between its component and a competitor’s. The operator is left with a collection of passing test reports and a system that may still have undetected vulnerabilities at the integration boundaries.

Independent field-level testing changes this dynamic. By capturing L3 signaling (RRC and NAS messages as defined in 3GPP TS 38.331 and TS 24.501), RF KPIs, and voice quality metrics on live O-RAN sites, operators can build their own evidence base. Smartphone-based field measurement tools enable rapid multi-site validation without the logistics of deploying dedicated scanner hardware.

L3 protocol analysis of RRC Reconfiguration messages reveals whether cell configuration parameters are consistent across vendor boundaries. Measurement events, reporting configurations, and handover thresholds that differ unexpectedly between cells from vendor A and vendor B are visible in the decoded signaling, not in vendor dashboards.

For 5G NR testing specifically, the ability to decode NR-specific signaling (SSB beam indices, MeasConfig for NR, RRC Reconfiguration with NR parameters) is critical for validating that the 5G layer of an Open RAN deployment behaves as specified under real RF conditions.

The NG-RAN architecture (3GPP TS 38.401) defines the interfaces and functional split. Field testing validates that the actual implementation matches the architectural intent.

What to look for when validating an Open RAN site

A structured validation approach for Open RAN security requires five phases, each producing measurable evidence.

Five concrete items to verify on every Open RAN site

1. SIB parameter consistency across vendors. Decode System Information Blocks from cells served by different vendors. Parameters like cellBarred, intraFreqReselection, and sIntraSearchP should be consistent within the same coverage area. Discrepancies indicate configuration misalignment that can cause unexpected cell reselection or service denial.

2. RRC Reconfiguration at vendor boundaries. Capture RRC Reconfiguration messages during handovers between cells from different vendors. Verify that measConfig, measObjectNR, and reportConfig parameters are coherent. Incoherent measurement configurations cause handover ping-pong, which is both a performance and a security issue (forced reattachments can expose subscriber identity).

3. NAS authentication sequence integrity. During initial attach and inter-vendor mobility, verify that the authentication and security mode command sequences complete correctly. Incomplete or repeated authentication sequences at vendor boundaries may indicate interoperability bugs or, in adversarial scenarios, downgrade attacks.

4. eCPRI fronthaul timing under load. While direct eCPRI measurement requires specialized probes, the effects of fronthaul timing drift are observable at L3: increased HARQ retransmissions, degraded SINR despite adequate RSRP, and throughput collapse under load. These symptoms, correlated with specific vendor combinations, point to fronthaul issues.

5. xApp-induced signaling patterns. If the RIC is deploying optimization xApps, monitor for unusual signaling patterns: rapid successive RRC Reconfigurations, unexpected measurement gap configurations, or handover commands that contradict RF conditions. These patterns may indicate xApp misbehavior, whether from bugs or from compromised code.

Conclusion

Open RAN delivers on its promise of vendor diversity and architectural flexibility. But disaggregation is not free. Every open interface is a trust boundary, and every multi-vendor integration point is a potential failure mode that no single vendor will identify or report.

The EU 5G Toolbox and NIS2 Directive have established the regulatory framework. Operators deploying Open RAN in Europe are now obligated to demonstrate that their assembled systems are secure, not merely that each component passed its vendor’s certification.

Sovereign testing capability is the mechanism that makes this possible. Independent, field-level validation of L3 signaling, RF performance, and voice quality across vendor boundaries produces the evidence that neither vendor reports nor lab certifications can provide.

As NIS2 enforcement begins and Open RAN deployments scale across Europe, which operators will lead in independent validation, and which will discover their integration gaps only when they are exploited?