5G and Open RAN – More Open, More Secure? Or Just More Exposed?

Introduction: Openness vs. Exposure in the 5G Era

The telecom industry is embracing openness like never before. From monolithic vendor stacks to modular network functions, from black-box hardware to software-defined everything, openness is the new orthodoxy.

At the centre of this transformation is Open RAN—a framework for disaggregated, interoperable radio access networks (RAN). Touted as a driver of innovation, cost efficiency, and vendor diversity, Open RAN is being adopted by operators worldwide as a core pillar of 5G strategy.

But with disaggregation comes complexity. With open interfaces come more integration points. And with more players come more risk. This raises a fundamental question:

Does Open RAN make 5G networks more secure—or more exposed?

Understanding Open RAN: The Basics

Traditional RAN architectures are typically provided by a single vendor (e.g., Ericsson, Nokia, Huawei) in a vertically integrated stack comprising:

• Radio Unit (RU)

• Distributed Unit (DU)

• Centralised Unit (CU)

• Management and orchestration layer

Open RAN, by contrast, separates these functions and defines open interfaces between them, allowing operators to mix and match components from different vendors.

Key elements include:

• Open Fronthaul: Connects RUs to DUs

• O-RAN Software Architecture: Standardises interfaces and APIs

• RAN Intelligent Controller (RIC): Enables real-time optimisation via apps

• Cloud-Native Functions: Deployed on commercial off-the-shelf (COTS) hardware using Kubernetes and containers

The result is a flexible, scalable, software-driven RAN architecture—but also one with many more moving parts.

Security Promises: What Open RAN Advocates Claim

1. Vendor Diversity Reduces Concentrated RiskBreaking up the vendor stack avoids single points of failure or control.

2. Greater TransparencyOpen-source elements and interface standardisation improve auditability.

3. Programmability Enables ResilienceIntelligent RAN apps can detect and respond to anomalies in real time.

4. Encourages Independent VerificationOperators and governments can inspect individual modules more easily than monolithic black-box solutions.

These are genuine benefits—but only if security is embedded from day one. Unfortunately, reality doesn’t always align with intention.

The Security Challenges of Open RAN

1. Increased Attack Surface

Every interface is a potential point of compromise. In Open RAN, key interfaces include:

• E2 (between RIC and DU/CU)

• A1 (between non-real-time and near-real-time RIC)

• Open Fronthaul (between DU and RU)

• O1/O2 (management and orchestration interfaces)

Each must be secured, authenticated, and monitored continuously.

2. Multi-Vendor Complexity

Disaggregated systems increase the difficulty of unified security management. Operators must ensure consistent:

• Authentication mechanisms

• Patch management

• Logging and forensics

• Incident response across heterogeneous systems

3. Untrusted or Inexperienced Vendors

Open RAN invites participation from small, new entrants. While this spurs innovation, it may also introduce immature security practices or insufficient testing.

4. Cloud-Native Infrastructure Risks

Containerised network functions (CNFs) running on cloud platforms introduce:

• Resource misconfiguration risks

• Supply chain risks in container images

• Orchestration layer vulnerabilities (e.g. Kubernetes RBAC mismanagement)

• Shared infrastructure concerns in public clouds

5. RIC-Specific Threats

The RAN Intelligent Controller opens new security vectors:

• Malicious xApps or rApps could compromise performance or privacy

• Insecure APIs may be exploited to manipulate RAN behaviour

• App stores or CI/CD pipelines could become malware delivery mechanisms

Case Study: Rakuten Mobile – Pioneering and Under Pressure

Japan’s Rakuten Mobile was among the first to deploy a fully virtualised, Open RAN-based 4G/5G network at scale. While it demonstrated cost and deployment advantages, it also highlighted operational challenges:

• Integration complexity across vendors including Altiostar (now Mavenir), NEC, and Red Hat

• Continuous tuning needed for performance parity with traditional vendors

• Persistent concerns from critics about long-term security governance across components

Rakuten’s experience shows Open RAN is viable—but not easy, and not automatically secure.

What National Security Agencies Are Saying

Governments and intelligence communities are taking a cautious stance:

• NCSC (UK): Has flagged the need for end-to-end assurance in disaggregated RAN environments.

• CISA (US): Warns about Open RAN’s increased complexity and need for comprehensive security strategies.

• EU ENISA: Highlights lack of maturity in RIC security and risks from new vendor entrants.

• India’s DoT: Initially championed Open RAN, but now seeks tighter certification of modules.

The consensus: Open RAN is not inherently insecure—but it is inherently harder to secure.

Open RAN Supply Chain Risk: Who Makes What?

Disaggregation exposes operators to a wider and more opaque supply chain:

Component	Typical Vendors	Risk
RU (Radio Unit)	NEC, Fujitsu, Comba, MTI	Hardware backdoors, firmware vulnerabilities
DU/CU	Mavenir, Parallel Wireless, Altiostar	Virtualisation layer compromise
xApps/rApps	Multiple start-ups, open-source developers	App store poisoning, unauthorised logic
Cloud Platforms	Red Hat, VMware, AWS, Azure	Multi-tenant exposure, orchestration risks
System Integration	Various consultancies or internal teams	Integration flaws, config drift

Vendor due diligence becomes more challenging—and more critical.

Key Security Actions for Operators Embracing Open RAN

1. Adopt a Zero Trust Architecture (ZTA)

• Treat every interface and component as untrusted until proven otherwise

• Require mutual TLS authentication, signed binaries, and endpoint verification

2. Mandate Secure-by-Design in Procurement

• Build security requirements into RFPs, not as bolt-ons

• Demand secure update processes, attestation mechanisms, and auditability

3. Secure the RIC Environment

• Vet all xApps/rApps for permissions, functionality, and source

• Enforce sandboxing and isolation policies

• Monitor app performance for anomalous or malicious behaviour

4. Harden Orchestration Layers

• Lock down Kubernetes and container registries

• Apply automated policy enforcement (e.g. OPA/Gatekeeper)

• Use runtime security tools to detect privilege escalation or API abuse

5. Demand Supply Chain Transparency

• Trace component origins and software provenance

• Use Software Bills of Materials (SBOMs)

• Implement continuous vulnerability scanning and threat intelligence sharing

6. Ensure Interoperability Doesn’t Undermine Security

• Harmonise logging, identity management, and patching across vendors

• Perform full-stack penetration tests with simulated attack scenarios

A Board-Level Imperative: Openness Without Blindness

Board members and executive teams must resist the temptation to view Open RAN as simply a cost-saving or innovation play.

Open RAN requires:

• Strategic vendor curation

• Rigorous integration governance

• Security investment commensurate with risk

Open RAN is not a product—it is an architectural transformation. It touches everything from procurement and operations to compliance and reputation. It must be owned at the top.

Conclusion: Freedom and Fragility in the Open RAN Era

Open RAN opens doors. To innovation. To cost savings. To a diversified ecosystem.

But every door that opens must be locked, monitored, and reinforced. If not, we risk building the next generation of telecom networks on a wider, flatter, and more fragile attack surface.

The question is not whether Open RAN is secure. The question is whether we will make it secure—before those with hostile intent find the keys to the new kingdom.