5G Network Slicing Under NIS2: Securing Critical Infrastructure Slices

A hospital in northern Europe deploys a 5G URLLC slice for remote-assisted surgery. The slice is configured for sub-10ms latency with 99.999% reliability. On the same gNB, an eMBB consumer slice handles video streaming for thousands of nearby subscribers. On a Friday evening, a concert at the adjacent stadium floods the eMBB slice. Latency on the surgical slice spikes to 200ms. The surgeon reports lag. The patient is stable, but the confidence in the isolated slice is shattered.

Nobody detected the cross-slice interference until a human felt it. No alarm triggered. No KPI threshold was breached in the OSS. The isolation existed in the configuration. It did not exist in the radio.

This is the problem that 5G network slicing and NIS2 collide on: how do you prove that a virtual network dedicated to critical infrastructure is actually isolated under real-world conditions?

What 5G network slicing actually is

Network slicing is defined in 3GPP TS 23.501 (System Architecture for the 5G System). It allows a single physical 5G SA (Standalone) infrastructure to host multiple logically isolated end-to-end virtual networks, each tailored for a specific service category.

Each slice is identified by an S-NSSAI (Single Network Slice Selection Assistance Information), composed of two fields:

• SST (Slice/Service Type): an 8-bit value identifying the service category. Standardized values include SST=1 (eMBB), SST=2 (URLLC), SST=3 (mMTC). Operator-defined values range from 128 to 255.
• SD (Slice Differentiator): an optional 24-bit value that distinguishes slices sharing the same SST. For example, two URLLC slices for different enterprise customers would share SST=2 but have different SD values.

The slice selection process involves the AMF (Access and Mobility Management Function), which receives the requested S-NSSAI from the UE during Registration and routes the UE to the appropriate network slice instance. The NSSF (Network Slice Selection Function) assists the AMF in selecting the correct slice when the serving AMF cannot serve the requested S-NSSAIs.

At the core network level, each slice can have its own SMF (Session Management Function), UPF (User Plane Function), and policy rules via PCF (Policy Control Function). At the RAN level, slicing relies on the gNB scheduler to allocate radio resources per slice according to configured SLA parameters. This is where theory and practice diverge.

NIS2 and critical infrastructure obligations

The NIS2 Directive (Directive 2022/2555 of the European Parliament and of the Council, adopted December 2022) replaced the original NIS Directive and significantly expanded the scope and rigor of cybersecurity obligations across the EU.

Telecommunications operators are classified as essential entities under NIS2. This classification triggers mandatory obligations under Article 21:

• Risk-based security measures covering supply chain, incident handling, business continuity, and network security
• Incident reporting within 24 hours (early warning), 72 hours (full notification), and one month (final report) to the designated CSIRT
• Supply chain security assessments, including validation of third-party components and services
• Management body accountability: the governing board of essential entities bears direct responsibility for cybersecurity risk management

For operators deploying 5G network slicing for critical sectors (healthcare, energy, transport, public safety), NIS2 means that slice isolation is not a performance feature. It is a security obligation. If a hospital’s URLLC slice can be degraded by consumer traffic, the operator has failed to implement adequate risk management measures under Article 21.

The intersection with network slicing is direct: if an operator promises an isolated URLLC slice for a critical infrastructure customer, NIS2 requires that the isolation is demonstrable, not assumed. A configuration file showing S-NSSAI assignment is necessary. Evidence that the isolation holds under congestion, mobility, and interference conditions is what NIS2 auditors will seek.

Where slice isolation fails in practice

The 3GPP architecture for network slicing is well-defined at the core network level. Dedicated SMF and UPF instances per slice provide genuine traffic separation above the N3 interface. The problem is at the RAN level, where physical radio resources are shared.

Radio resource sharing

A gNB serves multiple slices over the same spectrum. The MAC scheduler is responsible for allocating PRBs (Physical Resource Blocks) to UEs according to their slice SLA. But the total radio capacity is finite. When the eMBB slice consumes 90% of available PRBs during a traffic spike, the URLLC slice may not receive the guaranteed minimum, depending on the scheduler implementation and the operator’s RRM (Radio Resource Management) configuration.

3GPP TS 28.541 defines the network slice subnet management model. The maxNumberOfUEs and resourceAllocationStrategy parameters are configurable per slice. But enforcement depends on the vendor’s scheduler implementation, and no standardized testing methodology exists to verify compliance under load.

QoS enforcement gaps

Each PDU session within a slice is associated with QoS flows, identified by QFI (QoS Flow Identifier). The 5QI (5G QoS Identifier) maps to standardized characteristics: packet delay budget, packet error rate, and scheduling priority. URLLC traffic typically uses 5QI=82 (delay-critical GBR, 10ms delay budget) or 5QI=83 (10ms, higher reliability).

In practice, the QoS enforcement chain has multiple failure points: the UPF may correctly mark packets, but the gNB scheduler may not honor the priority under congestion. The RAN may honor the priority for the GBR flow but allow non-GBR flows within the same slice to compete with GBR flows from another slice.

Inter-slice signaling leakage

RRC and NAS messages are not inherently slice-aware in their transport. A UE registered on multiple slices receives RRC Reconfiguration messages that may reference resources across slices. If the gNB does not properly segregate measurement reporting and cell reselection parameters per slice, a UE on a URLLC slice may be directed to measurements that optimize for an eMBB slice, degrading latency.

Slice type requirements: what the numbers demand

Each slice type has quantified performance targets that define whether the slice is functioning as specified. These targets come from 3GPP TS 22.261 (Service Requirements for the 5G System) and ITU-R M.2410.

The gap between URLLC’s 1ms / 99.999% target and eMBB’s 4ms / 99.9% target is not marginal. It is two orders of magnitude difference in reliability. Proving that a URLLC slice meets its target while coexisting with eMBB traffic on the same gNB requires measurement under congestion, not just in idle conditions.

Field validation methodology

Verifying slice isolation in the field requires capturing and analyzing Layer 3 signaling at the UE level. The following methodology provides the evidence that NIS2 compliance demands.

Step 1: PDU Session Establishment analysis

When a UE establishes a PDU session, the NAS message (PDU Session Establishment Accept, as defined in 3GPP TS 24.501) contains the S-NSSAI assigned by the network. This may differ from the S-NSSAI requested by the UE if the network’s NSSF overrides the selection.

Capture the Registration Accept message and verify that the Allowed NSSAI matches the expected slice configuration. Then capture the PDU Session Establishment Accept and verify the assigned S-NSSAI and QoS rules (including 5QI, ARP, and GBR/MBR values).

Step 2: QoS flow verification under load

With an active PDU session on the target slice, generate traffic that saturates the eMBB slice on the same cell. Monitor the URLLC slice for latency degradation, jitter increase, and packet loss. The L3 signaling will reveal whether the gNB sends RRC Reconfiguration messages that modify the URLLC UE’s scheduling parameters in response to eMBB congestion.

Step 3: Mobility with slice continuity

Perform handovers (intra-frequency and inter-frequency) while the UE is active on a specific slice. Verify that the target cell maintains the same S-NSSAI assignment after handover. The RRC Reconfiguration message during handover should carry the slice information, and the subsequent PDU session modification (if any) should preserve QoS parameters.

Step 4: Cross-slice interference detection

Use a dual-SIM or multi-UE setup to simultaneously measure performance on two different slices served by the same cell. Correlate latency spikes on the URLLC slice with throughput bursts on the eMBB slice. Time-aligned L3 captures from both UEs provide the evidence of whether isolation holds.

The critical tool for this workflow is a Layer 3 protocol decoder capable of parsing NAS and RRC messages in real time, directly from the UE chipset via Qualcomm DIAG protocol. This provides visibility into the actual signaling exchanged between the UE and the network, not the abstracted view presented by vendor OSS systems.

For 5G network testing at scale, smartphone-based field tools capture simultaneous L3 signaling and RF KPIs (RSRP, RSRQ, SS-SINR per beam) during drive tests, enabling slice validation across large coverage areas without dedicated scanner hardware.

Conclusion

5G network slicing transforms a shared physical infrastructure into dedicated virtual networks for critical sectors. The architecture is sound. The specifications are comprehensive. But configuration is not isolation, and lab validation is not field proof.

NIS2 has changed the compliance landscape. Operators serving essential entities with sliced 5G networks must now demonstrate that slice isolation holds under real-world conditions: congestion, mobility, interference, and multi-vendor integration. Article 21’s risk management obligations apply directly to the radio resource management and QoS enforcement mechanisms that determine whether a URLLC slice actually delivers 1ms latency and 99.999% reliability when it matters.

The evidence comes from the field. PDU Session Establishment messages, RRC Reconfiguration analysis, and cross-slice performance correlation provide the verifiable data that NIS2 auditors require.

As 5G SA deployments scale and critical infrastructure increasingly relies on sliced connectivity, one question defines the operator’s compliance posture: can you prove your slices are isolated, or do you just believe they are?