Tech Deep Dive

Cyber-security for 5G/6G autonomous networks

5G/6G, network slicing and edge computing security: risks, zero-trust defenses, sample code and roadmap for CISO and telcos.

Cyber-security

27 January 2026

Table of contents

  • From 4G to 6G: architectures and differences that matter for security
  • Autonomous networks: intent-based, self-organizing and where risks hide
  • Emerging attack surfaces: edge, massive IoT, slicing and MITM “in the corridors”
  • Practical defenses: Zero Trust for mobile, segmentation and anomaly detection
  • Lab: two slices, one attack and three countermeasures
  • Strong authentication and identity protection: EU, devices, network functions
  • Compliance and governance: telcos, vendors and public/private collaboration
  • Operational roadmap for CISOs and architects
  • From “remote connectivity” to enterprise architecture: a paradigm shift
  • Use case: manufacturing with URLLC and eMBB slices

From 4G to 5G/6G everything changes: SBA, edge, Open RAN, network slicing and autonomous networks move security onto APIs, workload identity and slice isolation. Here we explain risks, Zero Trust, anomaly detection and provide code to simulate attacks and countermeasures.

Next-generation mobile networks are not just “faster”: they are more software-defined, distributed and autonomous. The leap from 4G to 5G and, soon, to 6G introduces Service-Based Architecture (SBA), cloud-native network functions, Open RAN, edge computing (MEC) and, above all, network slicing, the ability to carve “virtual networks” with different requirements over the same physical infrastructure. This power also expands the attack surface: massive IoT (mMTC), mission-critical URLLC traffic, APIs exposed in core and edge, devices with zero-touch provisioning, and orchestrators that automate everything (and therefore can automate mistakes too).


In this article, aimed at CISOs, SOC teams, telco cloud architects and OT/IoT managers, we analyze (operationally) what changes, which threats emerge and what mitigations to apply: segmentation, strong authentication, anomaly detection, Zero Trust for mobile networks, hardening of SBA APIs and strict isolation of slices. You will also find practical examples (in Python, Bash and Kubernetes YAML) to simulate a network slice, inject an attack, detect it and mitigate it.

From 4G to 6G: architectures and differences that matter for security

4G introduced virtualization (NFV) but with a relatively centralized core. 5G accelerates:

  • Cloud-native core with microservices (SBA) and APIs (typically HTTP/2 + TLS) among functions such as AMF, SMF, UPF, PCF, AUSF, etc. Security is no longer only “Diameter/IPsec”: it’s mTLS, certificate management, API gateways, rate limiting and fine-grained authz.
  • Strong separation of control/data (CUPS): the UPF close to the edge shortens latency but exposes inspection and policy enforcement points in distributed locations.
  • Open RAN: disaggregates RAN components (RU/DU/CU) with open interfaces. Innovation gains come with new surfaces: supply chain, RIC controllers (near-RT/non-RT) and unverified xApps/rApps.
  • Edge computing / MEC: core functions and vertical applications (e.g., robotics, OT) move to the edge cloud. Security posture shifts from “clean” data center to “distributed site”: physically accessible and often multi-tenant.
  • Network slicing: logical slices (for eMBB, URLLC, mMTC, verticals/OT) with resource isolation and dedicated SLAs. Isolation becomes a security requirement, not only a QoS one.

Moving toward 6G, these themes intensify: autonomic/intent-based networks, AI/ML for control and defense, integrated sensing, RIS (Reconfigurable Intelligent Surfaces), and integration of non-terrestrial networks (NTN). Each adds attack vectors (for example, compromising the AI models that govern closed-loop control).

Practical implication: security shifts from “perimeter + APN” to security-by-design within the SBA, API hardening, Zero Trust at every hop, rich telemetry and policy-driven controls on the data plane (UPF) and control plane (AMF/SMF).

Autonomous networks: intent-based, self-organizing and where risks hide

Autonomous networks promise self-configuration, self-optimization and self-healing using AI/ML. The operator or enterprise expresses an intent (“ensure 5 ms latency for this URLLC slice”) and the orchestrator implements policies, scaling and optimal paths.

Security critical points:

  • Orchestrators and controllers (core, RAN, RIC) become high-privilege “brains.” A MITM or compromise at these planes can propagate in seconds across thousands of edges.
  • AI/ML models: data poisoning, model stealing, undetected drift ⇒ incorrect decisions about slicing, routing, QoS and UE admission.
  • Zero-touch provisioning of devices and edge sites: supply chain, bootstrap credentials, PKI.
  • APIs northbound/southbound to OSS/BSS, partners and third parties: more ecosystem, more surfaces.

Countermeasures: model and data governance, hardware attestation (TPM, TEE), signed xApps/rApps, policy guardrails (limits on automation actions), and canary slices to test configuration changes before full rollout.

Emerging attack surfaces: edge, massive IoT, slicing and MITM “in the corridors”

In 5G the attacker no longer needs to “break into the core”: they can strike at the edges, where infrastructure is more distributed and multi-tenant.

  • Edge/MEC
    • Physical access and side-channels (USB, consoles, boot).
    • Multi-tenancy between third-party workloads and telco functions.
    • Local transit of telemetry and PII to reduce latency.
  • Massive IoT / mMTC
    • Low-cost devices with weak authentication and unpatched firmware.
    • Misconfigured zero-touch = exposed bootstrap credentials and pivoting to the edge.
    • Internal distributed DoS from telemetry storms.
  • Network slicing
    • Incomplete logical isolation (misconfigured policies on **UPF/**SMF, shared namespaces in Kubernetes, unconstrained SDN).
    • Intra-slice MITM: malicious actor inserts itself into a slice corridor (compromised proxy, compromised service mesh, ARP/NDP spoofing in MEC L2/L3 domains).
    • Noisy neighbor: resource saturation of shared components degrading URLLC or exfiltrating data via timing side channels.
  • Open RAN
    • Unverified xApps/rApps → manipulation of scheduling, power control, handover.
    • O-fronthaul and midhaul interfaces: encryption and component authentication for gNB (RU/DU/CU).
  • SBA / APIs
    • APIs exposed without mTLS, missing JWT checks and least-privilege authorizations.
    • No rate limiting → signaling DoS (UE registrations, PDU sessions).
    • Insufficient logging → inability to perform effective threat hunting.

Practical defenses: Zero Trust for mobile, segmentation and anomaly detection

Zero Trust for 5G/6G means “never trust, always verify,” even between network functions, slices, edge and vertical applications.

Control plane (SBA) measures:

  • mTLS mandatory among NFs with a robust internal PKI, automatic certificate rotation and short-lived certs.
  • API gateway with authn/authz (OPA/Rego), rate limiting, schema validation and a WAF for JSON payloads.
  • Segregation between domains (core vs edge) and among slices at routing, service mesh (mTLS with SPIFFE/SPIRE), and namespace level.

Data plane (UPF) measures:

  • Policies for slices (SDF templates) and micro-segmentation down to the flow level (5-tuple + DSCP/QFI).
  • Selective inspection (mirroring N3/N9) to IDS/IPS probes that understand 5G; use eBPF/XDP for low-overhead telemetry.
  • Rate policing and flood protection within slices.

Edge/MEC and Kubernetes:

  • NetworkPolicy “deny-all by default”, minimal RBAC, PodSecurity (or Pod Security Standards), signed images, and node/VM attestation.
  • Secrets in KMS/HSM, TOTP or FIDO2 for human access, disabling SSH where possible.
  • Runtime policy (Falco/eBPF) to detect anomalous processes.

IoT / mMTC:

  • Strong authentication (EAP-TLS, DTLS, device certificates), firmware attestation, SBOM.
  • Fleet management with patching, inventory and credential revocation.
  • Gateways using mTLS toward the edge, QoS and rate limiting to avoid telemetry storms.

Anomaly detection:

  • Multi-layer features: signaling (UE registrations, SM/AM events), data plane (flows and QFI), RAN KPIs(handover failures, PRB usage), edge (syscalls via eBPF).
  • Use unsupervised models (Isolation Forest, z-score, autoencoders) with minimal explainability (feature importance) for SOC use.

Lab: two slices, one attack and three countermeasures

Below is a practical example to create a test MEC environment with two “application slices” isolated at Kubernetes level (two namespaces) and a service mesh with mTLS. We then inject a simple MITM/proxy and show how to detect and block it using NetworkPolicy and OPA controls.

Example
It does not replicate a full 5G core, but the patterns of isolation, telemetry and mitigation are transferable.

1) Define the two slices (namespaces + label)

# Slice eMBB “video-analytics”
kubectl create ns slice-embb
kubectl label ns slice-embb slice=embb env=lab

# Slice URLLC “robotics-control”
kubectl create ns slice-urllc
kubectl label ns slice-urllc slice=urllc env=lab

2) Network policies: deny-all and allow only intra-slice

# base-deny.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: slice-embb
spec:
  podSelector: {}
  policyTypes: ["Ingress","Egress"]

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: slice-urllc
spec:
  podSelector: {}
  policyTypes: ["Ingress","Egress"]

# allow-intra-slice.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-intra-slice
  namespace: slice-embb
spec:
  podSelector: {}
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              slice: embb
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              slice: embb
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-intra-slice
  namespace: slice-urllc
spec:
  podSelector: {}
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              slice: urllc
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              slice: urllc

Apply:
kubectl apply -f base-deny.yaml
kubectl apply -f allow-intra-slice.yaml

3) Service mesh with mTLS and SPIFFE identity

With Istio (or Linkerd) enable mTLS strict per namespace:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: mtls-strict
  namespace: slice-embb
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: mtls-strict
  namespace: slice-urllc
spec:
  mtls:
    mode: STRICT

Use AuthorizationPolicy to further separate service accounts by role.

4) A “simple attack”: malicious proxy trying to bridge slices

Create an “attacker” Pod in the slice-embb namespace that attempts to call services in slice-urllc:

apiVersion: v1
kind: Pod
metadata:
  name: attacker
  namespace: slice-embb
spec:
  containers:
    - name: curl
      image: curlimages/curl:8.8.0
      command: ["sleep","infinity"]

Test (it should fail thanks to NetworkPolicy):

kubectl exec -n slice-embb attacker -- \
  curl -sS http://svc-urllc.slice-urllc.svc.cluster.local:8080/health
# Expected: timeout / connection refused

If someone relaxes policies or the mesh is misconfigured, the call could succeed: that is our lab “intra-slice MITM”.

5) Telemetry and anomaly detection (Python)

Suppose we export counts of cross-namespace calls (via eBPF or mesh metrics). A simple z-score can highlight deviations:

import numpy as np

# historical baseline (cross-slice calls per minute)
baseline = np.array([0,0,0,1,0,0,0,1,0,0,0,0,1,0,0], dtype=float)
mu, sigma = baseline.mean(), baseline.std(ddof=1) or 1.0

# current window (under attack)
current = np.array([0,0,0,5,6,7,8,9,10], dtype=float)

z_scores = (current - mu) / sigma
threshold = 3.0
anomalies = np.where(z_scores > threshold)[0]

print("mu=%.2f sigma=%.2f" % (mu, sigma))
print("z-scores:", np.round(z_scores,2))
print("anomaly indices:", anomalies.tolist())

Automatic actions (SOAR): if anomalies is non-empty → block cross-slice routes (reapply NetworkPolicy), quarantine the attacker Pod, open a SOC ticket and create targeted PCAP.

6) Immediate block via “circuit-breaker” NetworkPolicy

In real scenarios you’d use a GitOps controller or a SOAR playbook. Here’s an emergency snippet:

# Totally isolate the affected namespace
kubectl label ns slice-embb quarantine=true --overwrite

cat <<'YAML' | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: quarantine-all
  namespace: slice-embb
spec:
  podSelector: {}
  policyTypes: ["Ingress","Egress"]
  ingress: []   # total block
  egress: []    # total block
YAML

7) OPA/Envoy control on SBA APIs

For SBA functions (or edge services), place OPA as Envoy’s ext_authz. Example Rego policy (simple) that forbids cross-slice calls:

package sba.authz

default allow = false

# Allow only if token claim 'slice' matches the destination namespace
allow {
  input.parsed_token.claims.slice == input.request.http.headers["x-dest-namespace"]
}

With this logic, even if NetworkPolicy were temporarily weakened, the API gateway would block illegitimate requests.

Strong authentication

Strong authentication and identity protection: EU, devices, network functions

5G AKA and SUCI improve UE identity privacy. But at the edge and between NFs additional rigor is required:

  • mTLS with SPIFFE IDs (e.g., spiffe://telco.local/ns/slice-urllc/sa/robotics-controller).
  • Automatic secret rotation, workload identity (avoiding static secrets).
  • For IoT, prefer EAP-TLS/DTLS with unique device certificates (factory enrollment + first-boot attestation zero-touch).
  • JTI (JWT ID) to prevent replay, restricted audience, and short TTLs.
  • Harden AUSF/UDM: least-privilege access, HSM for master keys.

Open RAN and RIC: how to curb “creative” xApps

  • Supply chain
    Sign and verify xApps/rApps, publish SBOMs, and run CVE scans at build time.
  • Sandboxing
    Run xApps in environments with quotas/limits and policy guardrails (limit their scope).
  • Kill switch
    Enable rapid rollback and disabling of a faulty xApp.
  • Monitoring
    Map anomalous RAN KPIs (handover rates, PRB use, BLER) to responsible xApps (observability by design).

Compliance and governance: telcos, vendors and public/private collaboration

The regulatory mosaic affects telcos and organizations deploying private 5G:

  • NIS2: obligations for risk management, incident reporting and supply chain oversight; clear roles (CISO vs Operations) and penalties for non-compliance.
  • Cyber Resilience Act (CRA): responsibilities for digital products (including IoT devices and edge software), timely patching and vulnerability disclosure.
  • GSMA NESAS/3GPP SCAS
    Security schemes for NFs and RAN equipment.
  • ETSI MEC: guidelines for securing edge services.
  • Data governance & sovereignty
    Where data resides (edge, core, public cloud), tamper-proof logging for audits, and retention rules per vertical (healthcare, industry).

Public/private collaboration: sharing IoCs, vertical-specific CTI (energy, healthcare, manufacturing), and joint exercises and tabletops on URLLC/OT scenarios (e.g., robots

Operational roadmap for CISOs and architects

0–30 days (Assessment and minimum guardrails)

  • Map assets: NFs, edge sites, UPF, gNB, RIC, IoT.
  • Verify mTLS enforced on all SBA APIs; enable rate limiting and schema validation.
  • Set NetworkPolicy “deny-all by default” and service mesh mTLS across namespaces for slices.
  • Turn on telemetry (flow, signaling, eBPF), centralize logs in a SIEM.
  • Create SOAR playbooks for quarantining slices/namespaces and rotating edge credentials.

30–90 days (Isolation, identity and detection)

  • Deploy SPIFFE/SPIRE for workload identity, OPA in front of critical APIs.
  • IoT fleet: certificate enrollment, EAP-TLS, SBOM and patching policy.
  • Model governance for automations (datasets, drift monitoring).
  • Establish traffic baselines per slice and unsupervised detection models (Isolation Forest / z-score) with alerts that are explainable.

3–12 months (Resilience and reality tests)

  • Red team exercises on edge/MEC and RIC; API fuzzing for SBA.
  • Chaos engineering for autonomous networks (controlled faults, verify automatic rollback).
  • Supply chain: signed images/containers, SLSA level 2–3, SBOM verification.
  • SLAs that include security isolation metrics between slices (not only latency and throughput).

From “remote connectivity” to enterprise architecture: a paradigm shift

For many companies, mobile was traditionally “remote access” (APN, VPN). With 5G/6G, it becomes an integral part of the application architecture: edge analytics, connected OT, autonomous vehicles, factory AR. Accordingly:

  • Mobile security must integrate with IAM, DevSecOps, data governance and OT security.
  • SLAs among IT/OT/Telco include isolation and forensic criteria.
  • The SOC must “speak 5G”: signaling, QFI, SMF/UPF logs, and RAN KPIs.
  • Business continuity treats edges as mini data centers: spare parts, remote wipe, and fallback 4G/5G strategies.

Additional code examples and configurations

Selective traffic mirroring (iptables/eBPF)

Note: in production prefer native probes and telemetry brokers. Below is a minimal idea.

# Mirror connections to the critical service of the URLLC slice
IF=edge0
MON=10.10.10.50 # IDS probe
sudo iptables -t mangle -A PREROUTING -i $IF -p tcp --dport 443 \
  -j TEE --gateway $MON

Simple noisy-neighbor detection (Python)

import numpy as np

# CPU/latency usage percentiles for 2 slices
embb = np.array([50,52,49,51,80,85,90,88,87])    # suspicious spikes
urllc = np.array([10,11,9,10,10,11,9,10,10])

def spike_idx(x, win=4, k=3.5):
    m = np.convolve(x, np.ones(win)/win, mode='valid')
    s = np.sqrt(np.convolve((x[:len(m)]-m)**2, np.ones(1), mode='same') + 1e-6)
    z = (x[:len(m)]-m)/ (s + 1e-3)
    return np.where(z>k)[0]

print("embb spikes:", spike_idx(embb).tolist())
print("urllc spikes:", spike_idx(urllc).tolist())

Hardening SBA APIs (Envoy filter snippet)

# Envoy: rate limit + header constraints per SBA API
http_filters:
- name: envoy.filters.http.ratelimit
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.http.ratelimit.v3.RateLimit
    domain: sba-nf
    timeout: 0.1s
- name: envoy.filters.http.header_to_metadata
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.http.header_to_metadata.v3.Config
    request_rules:
      - header: x-slice
        on_header_present:
          metadata_namespace: envoy.lb
          key: slice
          value: "%REQ(x-slice)%"
        on_header_missing:
          value: "unknown"

CI/CD policy gate for xApps/RAN (GitHub Actions)

- name: Run SBOM scan
  uses: anchore/scan-action@v3
  with:
    path: .
- name: OPA Policy Gate
  uses: open-policy-agent/setup-opa@v3
- run: |
    opa eval --format=pretty \
      -i artifact.json -d policies rego.allow

Use case: manufacturing with URLLC and eMBB slices

An automotive company deploys a private 5G. Two slices:

  • URLLC for robotics (5 ms, minimal jitter, local edge, end-to-end Zero Trust).
  • eMBB for video analytics and AR (high throughput, buffering tolerated).

Observed risk: during a sprint, a team temporarily enabled a proxy for AR testing and inadvertently opened cross-slice routes. Robots experienced micro interruptions (jitter).
Remediations applied:

  • NetworkPolicy deny-all + mTLS mesh with SPIFFE.
  • OPA on SBA gateway and edge services.
  • Anomaly detection on jitter and cross-namespace calls with a SOAR playbook for automatic quarantine.
    Outcome: the subsequent incident was detected in 30 seconds and contained in <1 minute; no production line stoppage.

Conclusions

The move to 5G/6G and autonomous networks is not a simple throughput upgrade: it is an architectural and organizational transformation. Network slicing, edge computing, Open RAN and SBA bring flexibility but also new threats: intra-slice MITM, supply chain for xApps, exposed APIs, and massive IoT. The winning response combines Zero Trust, precise data-plane segmentation, strong authentication for devices and NFs, API hardening and deep-telemetry anomaly detection.

For CISOs and telco cloud operators, mobile security is no longer “remote access” but a native component of enterprise architecture, intertwined with DevSecOps, OT security and data governance. Adopting guardrail controls, telemetry and safe automation now enables scaling innovation without leaving the door open to attackers.

Questions and answers

  1. What is network slicing in a few words?
    It is the creation of logical slices “virtual” networks with dedicated resources, policies and SLAs that coexist on the same 5G/6G infrastructure. Each slice is isolated and optimized for a use case (eMBB, URLLC, mMTC, industrial vertical).
  2. Why is 5G more exposed than 4G?
    Because it introduces SBA with microservices and web APIs, distributed edge/MEC and Open RAN. The number of entry points increases and Zero Trust is needed at every hop.
  3. What’s the most underestimated attack?
    The intra-slice or cross-slice man-in-the-middle via misconfigurations (mesh, NetworkPolicy, UPF). It’s quiet but degrades URLLC and opens exfiltration channels.
  4. How to apply Zero Trust to a mobile network?
    Enforce mTLS everywhere, adopt workload identity (e.g., SPIFFE), use authz with OPA, set default deny-all, apply micro-segmentation on the data plane (UPF) and a service mesh; validate SBA APIs and use rate limiting.
  5. Edge/MEC: what are defense priorities?
    Physical and logical hardening, signed images, node attestation, KMS/HSM for secrets, restrictive NetworkPolicy, eBPF telemetry and tenant isolation.
  6. How to protect millions of IoT devices?
    Strong authentication (EAP-TLS/DTLS), device certificate management and revocation, SBOMs and patching, gateways with mTLS and rate limiting, anomaly detection for device behavior.
  7. Is Open RAN riskier?
    It’s more open, therefore it needs strict governance: sign/verify xApps/rApps, sandboxes and a kill switch, protected RIC, and continuous regression testing.
  8. What telemetry does the SOC need?
    SBA events (AMF/SMF/PCF), data plane QFI/5-tuple, RAN KPIs, eBPF on edge, and API metrics (latency, error rate). Without telemetry, reliable anomaly detection is impossible.
  9. Which regulations to watch in Europe?
    NIS2 for risk & incident management, Cyber Resilience Act for products/patching, GSMA NESAS/3GPP SCAS, and ETSI MEC for edge guidance.
  10. A concrete first step for a non-telco company?
    If you use (or will use) private 5G: define slices for critical functions, set deny-all + mTLS + OPA; integrate telemetry into your SIEM and write a SOAR playbook for slice quarantine.
2
To top