A 5G network is not a faster 4G network with the same security model. The specification fixed several long-standing weaknesses of mobile telephony and, in the same move, replaced dedicated telecom hardware with software running on general-purpose infrastructure. The protections improved. The surface they protect moved.
Quick Overview
Discussions of 5G security tend to collapse into one of two positions: the standard is stronger than what came before, or the network is more exposed than what came before. Both are accurate, and holding only one of them produces bad decisions. The radio layer and the identity layer genuinely improved. The core, meanwhile, stopped being a set of purpose-built boxes speaking fixed interfaces and became a set of services speaking over APIs, deployed on virtualised infrastructure, orchestrated by software, and assembled from a supply chain nobody controls end to end.
That is the whole subject of this article, and it is deliberately narrow. Building security into the way software is written — requirements, design, code, testing — belongs to the development lifecycle and is treated separately; what follows is about the surface a deployed network exposes and who can reach it. It is also not a competency map: the question of which skills a telecommunications organisation has to hire or build for this environment is answered in IT training for telecommunications, and this text assumes those skills exist and asks what they have to be pointed at.
The short version: identity got better, the core got softer, isolation became a configuration property, the device population became somebody else’s problem that is nonetheless yours, and the regulator responded to the part that technology cannot fix.
What Changed in the Design Goals, and Why That Moves Security
The generation was specified around higher throughput, latency low enough for control-loop applications, and connection density far beyond what earlier generations were built to carry. Those goals are not security properties, but each of them relocates a security problem.
Higher throughput means a compromised endpoint can move more data before anyone notices, and it means traffic inspection at line rate stops being a solved problem — the analysis budget per packet shrinks as the link gets faster, so detection either moves to sampling, to behavioural models, or to the edge.
Latency targets in the range that industrial control and vehicle applications require force processing toward the edge of the network, which multiplies the number of physical locations holding network functions. A core function running in a data centre with controlled access is a different risk object from the same function running in a cabinet at the base of a mast. Physical security, which telecommunications organisations had largely solved by concentrating the interesting equipment in few places, becomes a distributed problem again — and the tamper-evidence measures that make sense for a sprawl of unstaffed sites are not the ones that made sense for a small number of guarded buildings.
Connection density brings a device population that is heterogeneous, long-lived and frequently unpatchable. Each of those goals was chosen for what it enables commercially; each of them arrives with a security consequence that no protocol improvement cancels. The 5G System Overview published by 3GPP describes the architecture that carries these goals, and reading it as an operator rather than as an engineer makes the pattern obvious: nearly every capability that makes the network flexible also makes it reachable from somewhere new. Anyone assessing that surface has to be able to read the architecture first, which is the ground covered by 5G network architecture: foundations of the next generation.
Identity: From a Permanent Identifier to a Concealed One
The clearest security win of the generation is the treatment of subscriber identity. In earlier generations a permanent subscriber identifier travelled over the radio interface in circumstances where it could be captured, which is the mechanism behind passive subscriber tracking and the equipment built to exploit it.
The 5G design separates the permanent identifier, SUPI, from what actually crosses the air interface. The device encrypts the permanent identifier using the home network’s public key and transmits the result — the concealed identifier, SUCI — so a passive listener sees a value that changes and cannot be linked back to a subscriber without the home network’s private key. Passive identity capture stops being a matter of listening and becomes a matter of key compromise, which is a different and much harder attack.
The improvement is real and it is also bounded, and the boundary matters more than the mechanism. Concealment protects the identifier in transit; it does not protect a subscriber from an operator, from lawful interception, or from correlation attacks built on traffic patterns rather than identifiers. Nor does it apply where legacy interworking is in play: a network operating in non-standalone mode still leans on a 4G core for parts of the procedure, and the properties of that core are the ones that apply. Deployments described as 5G differ enormously in whether they have this protection at all, and the answer depends on architecture, not on the logo in the status bar. The full catalogue of what the specifications mandate and what they leave optional is set out in Security in 5G Specifications - Controls in 3GPP, and the gap between mandated and optional is where most real-world variation lives.
Authentication and Encryption Between Generations
Authentication in 5G is mutual: the device authenticates the network as well as the reverse. That closes the family of attacks in which a rogue base station persuades a handset to attach to it, which earlier generations mitigated inconsistently. Session keys derived from a successful authentication protect both signalling and user traffic, and the specification supports modern symmetric algorithms with key lengths in the range current practice expects — AES-128 and AES-256 among them, as catalogued in Security in 5G Specifications - Controls in 3GPP.
Integrity protection is the change that gets least attention and deserves more. Encryption without integrity protection stops an eavesdropper reading traffic but does not stop an attacker modifying it in flight. Extending integrity protection to the user plane, not only to signalling, removes a class of manipulation attacks rather than a single instance of one.
None of this makes the transport layer the interesting part of a modern attack. It makes it the boring part, which is the point of good cryptographic engineering. An attacker who cannot read the radio interface goes somewhere else — to the core, to the management plane, to the orchestration layer, or to a device that will hand over its credentials without being asked twice. Cryptography moved the fight; it did not end it.
There is a second-order effect worth naming, because it catches organisations that read only the good news. Strong transport protection reduces what network-layer monitoring can see. Traffic that is encrypted end to end and integrity-protected is traffic a passive sensor cannot inspect, which means detection has to work on metadata, on volumes, on timing and on behaviour rather than on content. Security teams accustomed to deep packet inspection as their primary instrument find that instrument progressively less useful, and the replacement is not a product but a different analytical practice. An operator that improves its cryptography without rebuilding its detection approach has made the network harder to attack and harder to observe at the same time, and the second half of that trade is easy to discover late.
The Core Became Software, and Software Has an API Surface
The architectural change with the largest security consequence is the least visible to a subscriber. A 4G core was built from network elements with defined roles, connected by defined interfaces, largely running on vendor hardware. A 5G core is a service-based architecture: network functions are software services that discover one another and communicate over HTTP-based APIs.
Everything an application-security practitioner knows about APIs now applies to the middle of a telephone network. Each network function must authenticate and authorise before it can consume another function’s service, and the specification leans on established web mechanisms — token-based authorisation of the OAuth 2.0 family — rather than on the implicit trust of a closed interface. That is the right design. It also means the core inherits the failure modes of API estates everywhere: an authorisation check that is present in one function and absent in another, a token whose scope is wider than the call needs, a service exposed to a management network that was assumed to be trusted, an endpoint left reachable after a migration.
The register of what can go wrong here is not speculative. ENISA threat landscape for 5G Networks enumerates the threat classes for exactly this architecture — signalling manipulation, abuse of exposed interfaces, attacks against the management and orchestration layers — and it reads, for anyone who has secured a microservice estate, like a familiar document with unfamiliar acronyms. The controls that apply are the ones that apply to any service mesh: authenticate every call, scope every token, gateway every external interface, and keep an inventory that matches what is actually deployed rather than what was designed. The general principles underneath those controls are set out in what computer network security is and how it works; the 5G-specific part is that they now apply inside the telephone network rather than around it.
Network Slicing: Isolation as a Configuration Decision
Slicing is the capability operators sell and the one most often described inaccurately. A slice is a logically isolated virtual network carved out of shared physical infrastructure, with its own policies, its own resource guarantees and, in principle, its own security posture. A critical-infrastructure customer gets a slice with strict guarantees; a consumer broadband service gets another.
The security claim attached to slicing is that a compromise in one slice does not reach another. That claim is true to the extent the isolation is actually implemented, and the phrase carrying the weight is to the extent. Slices share physical resources. Isolation is delivered by configuration of the virtualisation and orchestration layers, by resource scheduling, and in the strongest cases by dedicating separate instances of core functions to a single slice rather than sharing them. Where the isolation is logical only, a defect in the shared substrate is a defect in every slice above it.
This is the difference between a security property and a security promise. A slice whose isolation was verified — separate instances for the sensitive functions, monitored inter-slice paths, tested failure behaviour — is a genuine control. A slice that exists because a template was applied is a label. Distinguishing the two requires looking at the deployment, not at the service description, and it is the single most useful question a critical-infrastructure customer can ask an operator.
Virtualised Infrastructure Inherits the IT Threat Model
Underneath the service-based core sits virtualised infrastructure: network functions as software workloads, a hypervisor or container runtime beneath them, and a management-and-orchestration layer above that decides what runs where. Every layer of that stack is a target, and the orchestration layer is the highest-value one in the network — an attacker who controls what gets deployed controls the network without ever attacking a protocol.
The consequence is that a telecommunications operator now has to be competent at things that were not previously telecommunications problems. Image provenance and signing. Runtime hardening. Configuration drift between what the orchestrator believes is deployed and what is running. Patch cadence for a software estate whose components come from several vendors on different release trains. NFV Security in 5G - Challenges and Best Practices collects these into a set of practices, and the striking thing about that document is how little of it is telecom-specific: the guidance would be at home in any cloud-platform security programme.
The organisational failure this produces is predictable. Network engineering owns the protocol layer, IT security owns the platform layer, and the orchestration layer sits between them owned by neither. Closing that gap is partly a matter of skills — the automation and orchestration practices taught in ONAP in telecommunications systems and operations automation sit precisely on this boundary — and partly a matter of deciding, in writing, who is accountable when an orchestrator misbehaves.
The Device Population Is the Part You Do Not Control
Connection density was a design goal, and it delivered a population of connected devices with security properties that range from adequate to absent. Constrained devices often cannot run current cryptography, ship with credentials that are never changed, and receive firmware updates for a period far shorter than their service life — if at all.
For an operator this population amplifies risk in both directions. Outward, a botnet assembled from these devices sits on connections fast enough to generate traffic volumes that make volumetric attacks cheaper to mount than they used to be. Inward, a compromised device is an authenticated participant in the network, and a network that assumes attached devices are benign will treat its traffic as legitimate.
The mitigations available to an operator are structural rather than device-level, because the devices are somebody else’s. Dedicated slices for device traffic, so that a compromised population is contained by design. Behavioural analysis at the edge, where a device that has changed its traffic pattern can be identified before its volume matters. Rate limiting and anomaly detection applied to categories of subscriber rather than to individuals. The uncomfortable conclusion is that device security is a supplier and regulatory problem, and an operator’s job is to build a network that stays usable when a portion of what is attached to it is hostile.
Detecting Anything in This Environment
Monitoring a 5G network is not monitoring a 4G network with more sensors. The telemetry arrives from layers that used to be separate operational worlds: radio access, the service-based core, the virtualisation platform, the orchestration layer, and the applications running in edge locations. Correlating an event across those layers is the whole problem, and no single tool sees all of them.
The instruments themselves are recognisable. Log collection and correlation across the estate. Behavioural analysis of network traffic, which becomes the primary detection surface as content inspection loses ground to encryption. Posture management for the cloud platforms hosting network functions, because misconfiguration is a more common entry point than exploitation. Automated response for the classes of incident where the correct action is mechanical and the volume is too high for a human queue. None of that is exotic; the difficulty is that it has to work over a distributed, elastic estate whose composition changes when the orchestrator decides it should.
Machine learning gets deployed here for a specific and defensible reason: the volume of telemetry exceeds what analysts can review, and anomaly detection over baselines is a genuine fit for that shape of problem. It is also where the marketing claims outrun the mechanism. A model trained on a baseline captured before a slice was reconfigured will flag the reconfiguration; a model tuned to suppress that noise will suppress a probe that resembles it. Detection engineering in this environment is mostly the work of deciding what normal means for a network that changes shape on purpose, and that decision is not one a model makes on an operator’s behalf.
The failure mode to watch for is a monitoring programme sized by tooling budget rather than by analytical capacity. Signal that nobody reads is not detection. It is storage.
The Supply Chain and the European Regulatory Answer
The risk that no protocol addresses is the origin of the equipment and software the network is built from. A network function is a compiled artefact from a vendor, running on hardware from another vendor, orchestrated by software from a third. A defect introduced anywhere along that path is present in the deployed network, and the operator has limited means of detecting it.
The European response treats this as a governance problem rather than a technical one. Cybersecurity of 5G networks - EU Toolbox of risk mitigating measures sets out the strategic and technical measures member states agreed on: strengthening requirements placed on operators, assessing the risk profile of suppliers, applying restrictions to suppliers assessed as high risk in sensitive parts of the network, and avoiding dependency on any single supplier. Member states, Poland among them, implement these through national law and regulatory guidance.
Two features of that framework matter for anyone planning a deployment. The first is that supplier risk is assessed on non-technical criteria as well as technical ones — legal environment, ownership, the ability of a third country to compel a vendor — which means a procurement decision can become non-compliant without anything about the product changing. The second is that diversification is itself a control: an operator running one supplier’s equipment end to end has a cheaper network and a single point of failure that no amount of configuration will remove. General cybersecurity and data-protection obligations sit on top of this and apply regardless, which is why supply-chain decisions in this sector are made by legal, procurement and engineering together or made badly.
What Post-Quantum Means for a Network Built Now
The public-key cryptography that protects key exchange today, including the concealment of subscriber identity, rests on mathematical problems a sufficiently capable quantum computer would solve. Standardisation of replacements is under way and partly complete: the Module-Lattice-Based Key-Encapsulation Mechanism Standard is a finalised specification for key establishment resistant to that class of attack.
For a network being deployed now, the practical question is not whether to switch algorithms today but whether the design permits switching later. Cryptographic agility — the ability to change algorithms without re-architecting the systems that use them — is a design property, and it is far cheaper to build in than to retrofit into an estate of network functions, subscriber modules and management systems that hard-coded a choice.
The other consideration is retention. Traffic captured today and stored can be decrypted later, once the capability exists, which makes long-lived confidentiality a present-tense problem for any traffic whose sensitivity outlasts the current generation of cryptography. That argument applies to a narrow slice of telecommunications traffic, but for that slice it applies now rather than at some future announcement.
What an Operator Actually Has to Staff
The competency profile this environment demands is not the one telecommunications organisations were built around. Protocol expertise remains necessary and stops being sufficient: the same organisation now needs cloud-platform security, API security, identity and access management for machine-to-machine traffic, and detection engineering capable of operating over telemetry from a distributed estate.
The recurring staffing mistake is to buy the tooling first. Monitoring and orchestration platforms produce signal at a volume that is worthless without people who can interpret it, and a security operations function that cannot read the difference between a slice rebalancing and a slice being probed will either miss the second or drown in the first.
The most useful sequence starts with a description of the deployed network that is actually accurate, moves to explicit ownership of every layer including the orchestration layer nobody claims, and only then adds instrumentation. Teams building that competence usually need the wireless and transport-layer grounding covered in security of wireless and telecommunications networks before the cloud-native material means anything, because the failure modes of a radio access network are not deducible from platform engineering alone.
Frequently Asked Questions
Is 5G more secure than 4G?
The protocol mechanisms are stronger — concealed subscriber identity, mutual authentication, integrity protection extended to user traffic. The network as deployed is more exposed, because the core became software reachable over APIs, running on virtualised infrastructure assembled from a multi-vendor supply chain. Both statements are true, and treating either as the whole answer produces the wrong investment.
Does network slicing guarantee that one customer cannot affect another?
No. Slicing makes isolation possible; configuration decides whether it exists. Slices share physical resources, and isolation delivered purely as a logical construct fails when the shared substrate fails. Ask whether sensitive slices run on dedicated instances of core functions, and whether the isolation has been tested rather than assumed.
What does the EU Toolbox actually require of an operator?
It is a coordinated set of risk-mitigating measures, implemented through national law rather than applying directly. In practice it drives strengthened security requirements on operators, formal assessment of supplier risk on technical and non-technical criteria, restrictions on high-risk suppliers in sensitive network parts, and pressure toward supplier diversification.
Our organisation is a customer of an operator, not an operator. What should we ask?
Ask which architecture the service runs on, because a non-standalone deployment inherits the properties of a 4G core. Ask whether your traffic sits on a dedicated slice and how that isolation is implemented. Ask who owns the orchestration layer and how changes to it are authorised. Those questions produce answers that differ between providers; questions about encryption strength generally do not.
Do we need to act on post-quantum cryptography now?
Design for it now, migrate on the published timetable. Cryptographic agility built in at design time costs a fraction of a later retrofit across network functions, subscriber modules and management systems. Traffic whose confidentiality must outlast the current generation of public-key cryptography is the exception that needs attention immediately.