Mitigating Multi-Tenant Security Risks in 5G Network Slicing

5G network slicing is a design that lets a single physical 5G network be virtually segmented into multiple independent logical networks, each tuned for a specific service or tenant. Instead of one best-effort network, an operator carves out dedicated slices with their own bandwidth, latency, quality-of-service (QoS), and security parameters, so an ultra-reliable low-latency (URLLC) slice for a factory and a massive-IoT slice for thousands of sensors can coexist on the same radio and core infrastructure. Slicing is no longer theoretical. By 2026 more than 65 operators globally had launched commercial 5G SA networks capable of end-to-end slicing, and enterprise slice products with published SLA parameters are being sold across manufacturing, healthcare, public safety, and energy. Manufacturing and industrial buyers alone accounted for the largest share of network-slice revenue in 2025, and operators such as Ericsson and Telstra demonstrated dynamic eMBB and URLLC slicing for enterprise private networks in early 2025. The security implication deserves attention up front: slicing partitions resources and policies, but it does not, by itself, create a security boundary. CISA's Enduring Security Framework (ESF) states this directly, and the practical consequence is that every security property of a slice, including its isolation from neighbors, must be explicitly designed and enforced rather than inherited from the slicing concept.

Network slicing's real value is not raw throughput; it is the ability to deliver tailored performance and isolation guarantees for workloads with very different requirements. A healthcare network can dedicate a low-latency slice to real-time patient monitoring and remote diagnostics, while a smart city runs traffic management, emergency services, and public safety on separately prioritized slices, each with bandwidth and reliability guarantees that survive congestion elsewhere. That is why slicing is being monetized as a service. URLLC slices, typically promising sub-10 ms end-to-end latency and packet-loss rates below 0.001 percent, command the highest per-slice prices because they enable Industry 4.0 use cases such as autonomous guided vehicles, remote robotic surgery, and real-time machine-vision quality inspection that no best-effort connection can support. Tier-1 operators now expose programmable APIs so enterprises can provision and tune their own slice parameters, and hyperscaler-edge integrations let operators bundle compute and connectivity into a single per-slice tariff. The trade-off is that these commercial guarantees live on shared infrastructure. A slice's QoS promise is hollow without enforced resource isolation, and its security promise is hollow without isolation that spans the control plane, user plane, management plane, and underlying compute.

A multi-tenant 5G slicing environment is one in which multiple customers, or multiple applications of the same customer, share the physical network while each expects its slice to behave like a private network. This is the fundamental tension of the model: efficiency comes from sharing, but each tenant's confidentiality, integrity, and availability requirements differ sharply, so the operator must maintain logical separation across layers that are physically common. CISA's ESF guidance identifies four isolation layers that must each be verified per slice: control plane, user plane, management plane, and resource (compute and storage). Control-plane isolation alone is not isolation. A slice that inherits an eMBB user-plane security default, for example with user-plane integrity protection not required, may look dedicated on paper while being weak where it matters for a critical workload. Multi-tenancy also creates an operational efficiency win that operators should protect: dynamic resource allocation, scaling slices up or down from actual usage. But that same dynamism is what an attacker can abuse, so resource quotas and anti-starvation controls are not optional extras; they are the mechanism that makes coexistence safe.

The central security challenge is the gap between the promise of isolation and the reality of shared resources. Slices share CPU, memory, storage, kernels, container runtimes, network functions (NFs), and orchestration systems. CISA's ESF research ranks denial-of-service attacks on the signaling plane, misconfiguration attacks, and man-in-the-middle attacks as the threat vectors with the highest relativity to network slicing, and it emphasizes that the slice identifier itself (S-NSSAI) can leak tenant membership if transmitted or stored unprotected. Because slices have asymmetric exposure, one defense does not fit all. Public-facing eMBB slices face DDoS and resource-exhaustion pressure; enterprise and critical slices demand strict confidentiality and integrity; and IoT slices contend with large populations of weakly secured devices. 5G-Advanced (3GPP Release 18) research additionally flags network-slice side-channel attacks and inter-slice resource contention as cross-plane problems that traditional, single-domain audits miss. These realities drive the key takeaway: slice independence must be engineered through explicit controls at every layer, because shared infrastructure will find and expose the seams the moment isolation is assumed rather than enforced.

Current research and hands-on testing document several classes of attacks that directly threaten slice isolation, and they are practical rather than hypothetical. GTP tunnel-based attacks: TEID enumeration and injection enable traffic spoofing, redirection, and impersonation; nested GTP-in-GTP can crash user-plane functions or bypass policy; and GTP echo abuse reveals internal addresses and active tunnels. Control plane attacks: PFCP session hijacking lets an attacker create or modify sessions when PFCP lacks authentication; mass slice-switching (distributed slice mobility) can overload the AMF or NSSF; and NAS message fuzzing exposes parser vulnerabilities. Slice isolation breaks: UE-as-bridge attacks exploit devices registered to multiple slices to bypass isolation; resource contamination lets one slice starve others by abusing shared compute; and NSSF compromise enables incorrect slice assignments and QoS manipulation. Resource exhaustion: an authorized-but-compromised slice can inflate its reported demand to grab a disproportionate share of the resource pool, inducing cascading SLA violations. 2025 research such as the AutoGuard-Hybrid framework targets exactly this class with anomaly detection and demand purification. Container and virtualization attacks: container escapes (for example runc-related CVEs) give access to every co-located slice, and side-channel attacks on shared CPU caches infer data across boundaries. Policy and configuration attacks: slice-policy manipulation enables data extraction or privilege escalation, and compromise of a shared data store or orchestrator risks full cross-slice takeover. Recent work has also demonstrated a rogue gNodeB manipulating the slice-allocation process to tamper with a user's slice requirements during registration. These vectors confirm that slice isolation must be reinforced continuously, not assumed.

Secure multi-tenant slicing requires a multi-layer, multi-perimeter defense model, and in 2025 and 2026 that increasingly means zero trust. The first priority is removing shared single points of failure, especially shared databases: per-slice database instances with dedicated credentials dramatically reduce the blast radius of a breach. Resource isolation is the second pillar. Enforce strict CPU and memory limits and explicit resource quotas at the orchestrator and container-runtime level to block resource-contamination and starvation attacks, and enforce QoS so one slice's congestion cannot degrade another. Give each slice a per-slice security policy rather than inheriting eMBB defaults into critical slices, and use Network Slice-Specific Authentication and Authorization (NSSAA) so tenants control their own slice membership and revocation. On the control plane, enforce PFCP authentication, validate packet sources, and rate-limit slice-switching requests. On the user plane, validate TEIDs, filter and sanity-check GTP packets, and protect the S-NSSAI and SD fields as sensitive metadata. Harden the container layer with minimal privileges, prompt kernel patching, and TPM-based attestation so only trusted hosts and images run critical workloads, and use host-level monitoring plus eBPF-based resource isolation to blunt side-channel and inter-slice leakage, as recommended in Release 18 security work. Finally, observability is the safety net. Slice-aware monitoring that correlates database access, slice-switching behavior, and resource anomalies, paired with AI-driven anomaly detection, is what lets operators detect an attack mid-flight instead of in an after-action review. Deployments that prioritize observability are consistently the ones that withstand advanced cross-slice attempts.

A proactive security mindset means treating security as a continuous, evidence-based activity rather than a point-in-time audit. Static penetration tests and annual reviews miss policy drift that can appear minutes after an audit is declared, which is why 5G-Advanced (Release 18) security-assurance research pushes toward runtime, cross-domain monitoring across core, edge, and private networks, with frameworks reporting high attack-detection rates and order-of-magnitude reductions in response time on emulated 5G testbeds. Operationally, that translates into regular security drills and red-team exercises, continuous threat hunting that combines traditional telemetry with subscriber-session metadata and network-slice analytics, and ongoing staff training so everyone understands they protect their own slice. As the threat model evolves, so must the controls: adopting zero trust, keeping software patched, and revisiting slice policies as new verticals onboard are not one-time projects. A proactive mindset is what lets operators and enterprises push slicing into mission-critical applications, secure in the knowledge that isolation, resource limits, and observability will hold up under real pressure.