Appearance
O-RAN WG11 Compliance
The O-RAN Alliance WG11 Security Working Group defines security requirements and threat models for disaggregated RAN deployments. Telovix maps runtime detections, process ownership evidence, and protocol observations directly to the WG11 control set, producing a continuously updated compliance posture rather than a point-in-time assessment.
Requires: Telecom sensor flavor and
telecomConsole vertical. WG11 controls only appear in the Console when the telecom vertical is active.
In the Console, go to Compliance > O-RAN WG11. Each control in the report links to the specific runtime evidence that supports or contradicts it, including alert kinds, sensor IDs, and timestamps.
The seven WG11 controls
The sensor evaluates seven WG11 controls sourced from the compliance_oran.rs module. Each control maps to one or more protocol interfaces, process behaviors, and alert kinds.
| Control ID | Description |
|---|---|
ORAN_O1 | O1 management interface security |
ORAN_O2 | O2 infrastructure interface security |
ORAN_E2 | E2 interface peer verification |
ORAN_TIMING | Timing and synchronization integrity |
ORAN_MGMT | Management plane access control |
ORAN_CUDU | CU/DU F1 and E1 interface boundary |
ORAN_XAPP | xApp and rApp API security |
ORAN_O1: O1 management interface security
The O1 interface uses NETCONF over SSH (RFC 6241) on port 830 for management and orchestration of O-RAN components from the SMO. The sensor monitors NETCONF sessions and YANG model interactions from the oran_o1_report heartbeat field.
Detections contributing to this control:
| Alert kind | Condition |
|---|---|
k2_o1_new_peer | New NETCONF peer not seen during the learning window |
k2_o1_public_management_peer | NETCONF connection from a public internet IP; critical severity |
k2_o1_wrong_process | A process other than the expected management agent opened the NETCONF connection |
Anomalies tracked:
- Unexpected YANG model version change (firmware upgrade without change notification)
- Configuration rollback (potential unauthorized configuration change)
- Hardware failure not reported through O1 (monitoring bypass)
Evidence required for passing control: O1 connections originate only from known internal SMO addresses, the correct management process owns the NETCONF socket, and no YANG model version anomalies are recorded.
ORAN_O2: O2 infrastructure interface security
The O2 interface uses a REST API (typically port 8080) to expose O-Cloud resource management to the SMO. The sensor monitors O2 REST connections and resource lifecycle operations from the oran_o2_report heartbeat field.
Detections contributing to this control:
| Alert kind | Condition |
|---|---|
k3_o2_public_peer | O2 API called from a public internet IP |
k3_o2_new_caller | New caller process or IP not seen during the learning window |
k3_o2_destructive_operation | A non-SMO process attempts a container lifecycle control operation |
Anomalies tracked:
- Resource exhaustion (CPU or memory limit hit on DU, CU-CP, or CU-UP)
- Unallocated resource requests (requests exceed available capacity)
- Orphaned containers (allocated via O2 with no corresponding E2 or O1 update)
Evidence required for passing control: O2 API calls originate from authorized SMO addresses only, resource allocation patterns are consistent with the known topology, and no destructive operations are initiated from unclassified processes.
ORAN_E2: E2 interface peer verification
The E2 interface connects E2 agents (gNB components) to the Near-RT RIC over SCTP port 36421. xApps connect via SCTP port 36422. The sensor monitors all E2 connections from the e2ap_report heartbeat field and the xApp baseline.
Detections contributing to this control:
| Alert kind | Condition |
|---|---|
oran_e2_public_peer | E2 connection to or from a public internet IP; RIC compromise risk |
oran_e2_wrong_process | Non-RAN process connecting on the E2 interface |
NewRicPeer | xApp connected to an unknown RIC after the learning window |
PublicRicPeer | RIC peer IP is a public internet address; critical severity |
RicPeerChanged | RIC IP changed after the baseline was established |
MultipleRicPeers | Multiple distinct RIC IPs observed for one xApp |
NonStandardE2Port | E2 connection to a port other than 36421 |
UnclassifiedE2Agent | Unclassified process present on the E2 interface |
Evidence required for passing control: All E2 connections use port 36421, E2 agents connect only to known internal RIC instances, and no unclassified or non-RAN processes are present on the E2 interface.
ORAN_TIMING: Timing and synchronization integrity
O-RAN components require precise timing synchronization (PTP, IEEE 1588). The sensor monitors PTP processes (ptp4l, phc2sys) on nodes where they run, tracking process integrity and behavior from the timing_report heartbeat field.
What is evaluated:
- Whether PTP processes (
ptp4l,phc2sys) show unexpected binary modifications - Whether PTP processes have unexpected parent processes
- Whether privilege anomalies occur on PTP processes
- Whether unexpected processes attempt to write to timing configuration paths
Why this matters for O-RAN: Fronthaul-connected O-DU nodes require sub-microsecond timing accuracy. A compromised or modified timing process can desynchronize the O-DU from the O-RU, causing radio failures that are indistinguishable from hardware faults.
Evidence required for passing control: PTP processes run with expected binary hashes, expected parent processes (systemd or equivalent), and no privilege anomalies have been recorded.
ORAN_MGMT: Management plane access control
The management plane covers all interfaces and processes used for configuration, orchestration, and monitoring of O-RAN components. This control evaluates whether management-plane access follows expected patterns.
What is evaluated:
- Whether processes with management-plane access (NETCONF, O2 REST, SSH) show unexpected network connections
- Whether new listeners appear on management ports (830, 8080, 22) outside the learned baseline
- Whether management credentials (SSH keys, API tokens) are stored in expected paths
- Whether any process makes unexpected modifications to management configuration files
Evidence required for passing control: Management interfaces are owned by expected processes, no new management listeners have appeared outside baseline, and management configuration paths show no unauthorized modifications.
ORAN_CUDU: CU/DU F1 and E1 interface boundary
The CU/DU split introduces an architectural boundary between gNB-CU-CP, gNB-CU-UP, and gNB-DU. This control evaluates whether the F1 (SCTP 38472) and E1 (SCTP 38462) interfaces are used only by the processes that should own them.
What is evaluated:
- Whether F1AP connections are owned by the correct CU-CP and DU processes
- Whether E1AP connections are owned by the correct CU-CP and CU-UP processes
- Whether TLS is in use on F1 and E1 connections
- Whether F1SetupFailure rates exceed threshold
- Whether unauthorized processes attempt to use F1 or E1 ports
Alert kind: oran_api_f1e1_boundary fires when a process outside the learned CU/DU role set opens a connection on F1 or E1 ports.
Evidence required for passing control: F1 and E1 connections are owned by correctly classified gNB components, setup failure rates are within baseline, and no unauthorized processes appear on these interfaces.
ORAN_XAPP: xApp and rApp API security
xApps connect to the Near-RT RIC via SCTP port 36422 (E42 interface). This control evaluates whether xApp behavior conforms to the expected access pattern.
What is evaluated:
- xApp RIC peer baseline (established over 3 heartbeats, 90 seconds)
- Whether xApps connect only to known internal RIC instances
- Whether xApp processes run with expected UID and binary
- Whether A1 policy interface calls originate from authorized callers
- Whether KPM (Key Performance Metric) data consumers are authorized
- Whether route modification requests come from expected sources
Detections contributing to this control:
| Alert kind | Condition |
|---|---|
oran_api_a1_policy | A1 policy call from a non-authorized caller |
oran_api_kpm_caller_violation | KPM data accessed by an unexpected caller |
oran_api_route_modification | Route modification requested by an unexpected process |
NewRicPeer | xApp connected to unknown RIC |
PublicRicPeer | xApp RIC peer is a public IP address |
WrongProcessOnE2 | Non-RAN process using the E2 interface |
Evidence required for passing control: All xApps connect to known internal RIC instances, A1 and KPM interfaces are accessed only by authorized callers, and no non-RAN processes appear on the xApp interface.
Compliance views
WG11 report
In the Console, go to Compliance > O-RAN WG11. The page shows the current WG11 compliance posture: per-control status (passing, failing, partial), evidence counts, last evaluation timestamp, and linked alert IDs for each failing finding.
Generate an evidence bundle
For certification or audit purposes, in the Console go to Compliance > O-RAN WG11, then click Generate Evidence Bundle. The bundle covers all seven WG11 controls and can be downloaded as a ZIP archive for use in O-RAN Alliance certification packages or internal security review records.
Heartbeat fields that feed WG11 controls
| Heartbeat field | Controls it informs |
|---|---|
oran_o1_report | ORAN_O1 |
oran_o2_report | ORAN_O2 |
e2ap_report, oran_report | ORAN_E2, ORAN_XAPP |
timing_report | ORAN_TIMING |
ran_net_report, ran_integrity_report | ORAN_MGMT, ORAN_CUDU |
tls_inventory_report | ORAN_E2, ORAN_O1, ORAN_XAPP |
Validating controls with threat exercises
Passing WG11 controls requires confirmed detection, not just deployed rules. The Threat Exercises page provides a structured workflow for producing explicit validation evidence per control. The expected alert kinds for each exercise are:
| Exercise | Expected alert kind | Control validated |
|---|---|---|
| Unauthorized O1 peer | k2_o1_public_management_peer | ORAN_O1 |
| Destructive O2 operation | k3_o2_destructive_operation | ORAN_O2 |
| E2 peer spoofing | oran_e2_wrong_process | ORAN_E2 |
| A1 policy injection | oran_api_a1_policy | ORAN_XAPP |
| KPM caller violation | oran_api_kpm_caller_violation | ORAN_XAPP |
| F1/E1 boundary violation | oran_api_f1e1_boundary | ORAN_CUDU |
Run exercises in a controlled window and attach the resulting investigation or alert ID to your WG11 compliance record. See Threat Exercises for the full procedure.
Operational guidance
Role accuracy is a prerequisite: WG11 controls rely on correct NF role classification. A gNB-DU classified as generic_linux will not contribute to ORAN_CUDU or ORAN_E2 evidence. Declare roles explicitly during enrollment before reviewing WG11 posture.
Learning windows and initial state: All peer-based controls (ORAN_O1, ORAN_O2, ORAN_E2, ORAN_XAPP) use a learning window to establish the baseline before raising alerts. During the learning period (3 heartbeats for xApps, longer for management interfaces), the control will show partial evidence. Allow sensors to reach steady state before treating a partial status as a finding.
Timing control on non-O-DU nodes: The ORAN_TIMING control only applies to nodes where PTP processes are running. On nodes without ptp4l or phc2sys, this control will show no evidence rather than failing. This is expected for CU-CP, CU-UP, and Near-RT RIC nodes that do not directly handle fronthaul timing.
Evidence bundles for certification: WG11 evidence bundles include alert records, event timestamps, sensor IDs, and control evaluation results. They are designed to be attached directly to O-RAN Alliance certification packages or internal security review records. Generate a fresh bundle at the end of each compliance assessment cycle; bundles reflect the state at generation time.
Further reading
- O-RAN Architecture (DU / CU / RIC)
- Threat Exercises
- TLS Visibility
- Compliance (CIS / NIS2 / ETSI)
- Guardian Profiles and Policies
- RAN Signaling (NGAP / F1AP / E2AP)
- O-RAN WG11 - Security Workgroup Specifications
- O-RAN Alliance - Security Protocols Specifications (O-RAN.WG11)
- 3GPP TS 33.501 - Security architecture and procedures for 5G system