NIST IR 8625: Zero Trust Checklist for O-RAN RIC Security

ZERO TRUST / O-RAN / NIST IR 8625

NIST has published a final report that turns an abstract zero trust goal into concrete design questions for the software controlling an Open Radio Access Network. NIST IR 8625, published September 24 and announced October 8, examines security for the Near-Real Time RAN Intelligent Controller, its xApps and rApps, and the interfaces that let those components influence live radio behavior. The practical message is simple: an authenticated workload is not automatically an authorized workload.

For mobile operators and platform teams, this is not a patch bulletin or a claim that every O-RAN deployment is vulnerable. It is an architecture review guide. The report highlights identity stability, narrow authorization, service-to-service protection, comprehensive telemetry, software supply chain controls, and the tradeoff between controls built into an application and controls supplied by the underlying cloud platform.

What NIST IR 8625 covers

O-RAN disaggregates radio access network functions and exposes standardized interfaces so components from multiple vendors can work together. The RAN Intelligent Controller, or RIC, gives operators a platform for software that observes and changes network behavior. An xApp operates in the Near-RT RIC for time-sensitive control, while an rApp operates in the Non-RT RIC for broader analysis and policy. The A1 interface links the Non-RT and Near-RT RICs; the E2 interface connects the Near-RT RIC to controlled RAN functions.

That flexibility increases the number of identities, APIs, certificates, tokens, deployment pipelines, and policy decisions that defenders must manage. NIST maps the resulting threat space with STRIDE: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. The report also calls out supply chain compromise and a legitimate but overprivileged application as distinct risks. An approved xApp can still make a request that falls outside its intended workflow.

The useful security boundary is not simply “inside the RIC.” It is every request between a named workload and a named resource, evaluated against an explicit policy.

Five engineering decisions that matter

1. Give every workload a durable identity

NIST notes that the Near-RT RIC uses UUID-based workload identities encoded in certificates, while cloud-native environments may use SPIFFE identities. A random runtime identifier can be unique yet difficult to connect to a stable service owner, policy, and historical log record. A scoped URI such as spiffe://operator.example/ric/xapp/traffic-steering carries administrative context and can persist across restarts.

• Inventory every RIC platform service, xApp, rApp, gateway, message broker, and authorization service.
• Map each runtime identity to an owner, software artifact, environment, and approved workflow.
• Rotate short-lived credentials automatically and alert on issuance outside the expected deployment path.
• Retain an identity-to-instance mapping long enough to support incident reconstruction.

2. Separate authentication from authorization

Mutual TLS can prove which workload established a connection and protect the channel, but it does not express every action that workload may perform. NIST describes OAuth 2.0 access tokens for service-to-service authorization, where a signed token carries privileges that a resource validates. Engineers should define scopes around actual operations, resources, and interfaces. A broad scope such as ric:* defeats least privilege even when the token is valid.

3. Deny communication that policy does not name

NIST recommends explicit approval of communication paths and logging of all activity, including traffic that is not specific to RAN protocols. This matters because a compromised application may contact an external command server or exfiltrate telemetry through an ordinary cloud endpoint. Start with observed flows in a staging environment, assign an owner to each dependency, then convert the approved set into network policy and service-mesh authorization. Do not copy a sample allowlist into production without validating DNS behavior, failover paths, certificate services, update services, and observability collectors.

4. Decide where each control is enforced

A Kubernetes service mesh can provide workload certificates, mutual TLS, and coarse service authorization below the application layer. An API gateway or the application may still need to validate OAuth scopes, message fields, subscriber context, or the requested policy operation. NIST explicitly cautions that alternative cloud-native technologies discussed in the report are considerations, not prescribed O-RAN implementations. Document control ownership so a platform team and application vendor do not each assume the other validates the same request.

5. Plan for object security and cryptographic agility

Channel security protects a direct connection. It may not protect an object after a proxy, gateway, or broker terminates that channel. For high-impact policy objects or telemetry that crosses intermediaries, assess whether signatures or object-level encryption are needed. The report also recommends planning for post-quantum migration across certificates, key generation, monitoring, and operational tooling, not merely swapping a TLS algorithm. This is inventory and dependency work today, not a reason to improvise unsupported production cryptography.

Hands-on lab: audit a synthetic RIC application inventory

This offline lab is a policy-review exercise. It does not deploy O-RAN software and does not claim conformance with an O-RAN specification. Use it to demonstrate how an inventory can reveal shared identities, missing mutual TLS, wildcard scopes, and unapproved external egress before those patterns reach a real environment.

Prerequisites and isolation

• Python 3.9 or newer.
• An empty local directory with no production configuration or credentials.
• No network access is required.

Create ric-services.json with three synthetic services. One intentionally violates the review rules:

[
  {
    "name": "traffic-steering-xapp",
    "identity": "spiffe://lab.example/ric/xapp/traffic-steering",
    "mtls": true,
    "scopes": ["e2:read:kpm", "e2:write:policy"],
    "egress": ["e2-gateway.ric.svc.cluster.local"]
  },
  {
    "name": "energy-saver-xapp",
    "identity": "shared-xapp-account",
    "mtls": false,
    "scopes": ["*"],
    "egress": ["e2-gateway.ric.svc.cluster.local", "telemetry.example.net"]
  },
  {
    "name": "policy-rapp",
    "identity": "spiffe://lab.example/ric/rapp/policy",
    "mtls": true,
    "scopes": ["a1:read:policy", "a1:write:policy"],
    "egress": ["a1-gateway.ric.svc.cluster.local"]
  }
]

Save the following as audit_ric_inventory.py:

#!/usr/bin/env python3
import json, sys
from pathlib import Path

def audit(service):
    findings = []
    if not service.get("identity", "").startswith("spiffe://"):
        findings.append("identity is not a scoped SPIFFE URI")
    if service.get("mtls") is not True:
        findings.append("mTLS is not required")
    if not service.get("scopes") or "*" in service["scopes"]:
        findings.append("authorization scope is empty or wildcard")
    for destination in service.get("egress", []):
        if not destination.endswith(".svc.cluster.local"):
            findings.append(f"external egress destination: {destination}")
    return findings

services = json.loads(Path(sys.argv[1]).read_text())
total = 0
for service in services:
    findings = audit(service)
    print(("FAIL" if findings else "PASS"), service["name"])
    for finding in findings:
        print("  -", finding)
    total += len(findings)
print(f"SUMMARY services={len(services)} findings={total}")
raise SystemExit(1 if total else 0)

Run the audit:

python3 audit_ric_inventory.py ric-services.json

Expected output:

PASS traffic-steering-xapp
FAIL energy-saver-xapp
  - identity is not a scoped SPIFFE URI
  - mTLS is not required
  - authorization scope is empty or wildcard
  - external egress destination: telemetry.example.net
PASS policy-rapp
SUMMARY services=3 findings=4

The script exits with status 1 when it finds a violation, so it can act as a simple CI quality gate. In a real engineering workflow, replace the synthetic inventory with exported policy data, replace the hard-coded naming assumptions with your trust-domain and destination registry, and require an approved exception record for any external egress. Never feed secrets, tokens, private keys, or production configuration into an unreviewed script.

Troubleshooting and cleanup

• If Python reports a JSON error, validate commas and quotation marks in ric-services.json.
• If every service fails identity validation, update the expected trust domain only after confirming your organization’s identity convention.
• Delete the lab directory when finished. It contains only synthetic data and creates no background process or network resource.

Operational detection checklist

1. Log identity and decision context. Record the authenticated workload, token issuer, audience, scopes, resource, action, decision, and policy version.
2. Baseline denied requests. Alert on repeated scope failures, requests to unused APIs, and traffic from a valid identity to a resource it has never contacted.
3. Watch credential behavior. Detect unusual certificate issuance, failed rotation, long-lived tokens, unknown signing keys, and token use outside the intended audience.
4. Monitor application behavior. Track policy deletion, abrupt configuration churn, unexpected A1 or E2 request volume, and resource exhaustion that may indicate abuse or a faulty app.
5. Correlate layers. Join service-mesh telemetry, Kubernetes audit logs, authorization-server events, application logs, and RAN operational data under the same workload identity.
6. Test failure modes. Confirm that an unavailable identity or policy service fails closed where safety permits, and document any availability-driven exception.

Teams developing these controls can pair this checklist with our overview of Zero Trust Security Architecture. For adjacent 5G radio threats, see the practical analysis of NIST’s false base station test guidance.

What to do next

Start with a request-level data flow diagram for the RIC, not a product list. Name each workload, interface, resource, action, credential authority, policy enforcement point, and log destination. Then compare the deployed behavior with the approved workflow. The highest-value early fixes are usually eliminating shared identities, reducing wildcard privileges, denying unexplained egress, and preserving enough context to explain every authorization decision.

NIST IR 8625 does not remove the need for vendor-specific testing, O-RAN conformance work, or operational risk analysis. It gives security architects a sharper question: if an xApp, rApp, platform component, or token is compromised, which exact requests can it make, which data can it reach, and how quickly will defenders know? A credible zero trust design should answer that before the network carries production traffic.

Primary references

• NIST IR 8625: Open Radio Access Network Near-Real Time RAN Intelligent Controller Security, final report published September 24, 2026.
• NIST announcement: Reports on O-RAN Security, released October 8, 2026.
• O-RAN ALLIANCE specifications portal and development process.
• O-RAN ALLIANCE certification and badging program.