3GPP releases: where each security feature actually arrived

Mobile network specifications are developed continuously and frozen periodically. Each freeze is given a number, and that number becomes the reference point for everything downstream: chipsets are built to a release, networks are upgraded to a release, and a feature that exists in a later release does not exist in a network that has not reached it.

For security this matters more than it does for most features, because a protection is only as present as its weakest available alternative. A network that supports a modern protection and also still carries an older generation offers both, and a device will use whichever it ends up on. Asking whether a protection exists is therefore the wrong question; the useful questions are which release introduced it, whether the deployment has that release, and whether anything older is still reachable.

This is the reason the pages here are organised by release instead of by topic. A topic page can say that subscriber identities are concealed on 5G. Only a release view makes it obvious that the concealment arrived with the first 5G set, that the generations running beside it never had it, and that whether it is switched on was left to the operator.

The archive’s own account of the standardisation process, written from inside it while it was happening, is on the standardisation page.

A release being frozen starts a long process. The specification has to be implemented in chipsets, which then have to appear in devices, and in network equipment, which then has to be bought, installed and configured by operators whose upgrade cycles are measured in years and whose priorities are driven by capacity before security. A feature specified in one year is commonly serving subscribers four or five years later, and in some markets considerably longer.

Two consequences follow, and both come up constantly in discussions of mobile network security. The first is that the answer to whether a protection exists depends on which question is being asked: it can be specified, implemented, deployed, and switched on, and those are four different states with years between them. The second is that older generations are not decommissioned when a new one arrives. They keep carrying traffic, often for coverage in places the new radio does not reach, and a device that can use them will use them when it has to.

That is why a release-by-release account is more useful here than a list of 5G security features. A feature list invites the conclusion that the protections are in force. The release view makes visible that each one has a date, that networks reach those dates unevenly, and that the weakest generation a device can be induced onto is the one that determines its exposure. The mechanism by which that inducement works is described on the false base station page, and it is the reason a fallback to an older generation matters as much as anything in the current one.