Most security frameworks ask you to inventory your assets and then apply controls according to a classification you invent. UK telecoms security regulation does something more interesting. It defines scope by asking what a thing does rather than what it is, and then it defines a second, smaller category: the systems that control the first category.
That nesting is the good idea, and it travels. You do not need to be a telecoms provider for it to change how you look at your own estate.
Table of contents
Open Table of contents
Where the definitions come from
Briefly, because the machinery matters less than the concepts.
The framework rests on the Telecommunications (Security) Act 2021, which amended the Communications Act 2003 to place security duties on providers of public electronic communications networks and services. The detail sits in the Electronic Communications (Security Measures) Regulations 2022, and the practical guidance sits in the Telecommunications Security Code of Practice, first published in December 2022 and revised to version 1.1 in July 2026.
Providers are tiered by revenue. The largest, above one billion pounds of relevant turnover, carried the earliest deadlines from March 2024, with the middle tier following roughly two years behind. Several of the harder measures now run out to 2027 and 2028, including logging and monitoring, signalling protection, trusted boot and validation of automation.
The regulator can impose penalties of up to ten per cent of qualifying turnover, with daily penalties for continuing contraventions. So this is not a framework anybody adopts voluntarily, which is part of why the definitions are drafted more carefully than the usual best practice document.
Security Critical Function
The regulations define a security critical function as any function of the network or service whose operation is likely to have a material impact on the proper operation of the entire network or service, or a material part of it.
Three details in that wording repay attention.
It is not about security functions. The name misleads almost everybody on first reading. This is not a category for firewalls and authentication systems. It is a category for anything whose failure or capture would materially degrade the service. A billing system might not qualify. A component that decides how traffic is routed almost certainly does, and it has nothing to do with security in the departmental sense.
Automation is explicitly named. The Code says that automation functionality is likely to be a security critical function, as is anything likely to materially affect the encryption used in conveying signals. That first one has consequences that I do not think are widely absorbed yet, and I come back to it below.
The burden of proof is inverted. This is the part I find most notable as a piece of drafting. If you conclude that something is not a security critical function, you are expected to be able to demonstrate that conclusion, through a risk assessment or a threat model. The default is inclusion. You do not build a list of critical things and leave everything else alone; you account for the exclusions.
That inversion quietly changes the whole exercise. Under most frameworks, scoping is where organisations shrink their obligations, and the shrinking is invisible because nobody documents what they left out. Here the exclusions are what you have to justify, which is a much harder document to write and a much more useful one to read.
Network Oversight Function
The second category is the subset that oversees and controls the first.
The Code gives a list, and says it is not exhaustive: element managers; virtualisation orchestrators; management systems such as jump boxes; security functions such as firewalls at the boundary of a security zone; root authentication and directory services; authentication services requiring more than one factor; security gateways; audit and monitoring systems, including quality monitoring of voice and data; and operational support systems.
The relationship between the two categories is asymmetric, and worth stating precisely. Every network oversight function should normally also be a security critical function. Not every security critical function is a network oversight function.
The reasoning for treating the subset differently is that these systems are both more attractive to an attacker and more damaging when captured. Compromise a routing component and you affect what it routes. Compromise the system that configures every routing component and you affect all of them, quietly, with legitimate credentials, through the channel built for exactly that purpose.
So oversight functions attract a heavier control set: hardening, faster patching with phased rollout, minimised attack surface, dedicated management functions on a segregated management plane, and enhanced monitoring that includes watching changes as they happen. The Code also says that when establishing what normal behaviour looks like for anomaly detection, providers should prioritise the behaviour of oversight functions.
Two extensions are easy to miss. The management plane should be configured so the management platforms are protected from attacks arriving upstream from the network equipment they manage, which is a nicely paranoid detail: the managed device is treated as a potential threat to its manager. And where a third party performs management on the provider’s behalf, that third party’s network is in scope, with accountability staying firmly with the provider.
Why the nesting is the right idea
Strip away the telecoms vocabulary and the claim is this: the system that administers a critical system is more critical than the system it administers, and should be protected accordingly.
Security has been circling this for years without stating it so plainly. Tiered administration models say it. Control plane and data plane separation says it. Privileged access workstations, break glass procedures and jump host architectures all say it. The idea that your directory service deserves more protection than the servers it authenticates is not new.
What the regulation does differently is make it a stated obligation with a defined boundary, rather than an architectural preference that survives until somebody needs a shortcut. Once a system is identified as an oversight function, the segregated management plane is not a debate about proportionality. It is the answer.
It also gives you a question that produces uncomfortable answers quickly. Not “is this system important” but “what can reach into this system and change it”. Follow that honestly and you usually find that the carefully protected critical component is administered by something that is patched irregularly, monitored lightly, and reachable from a laptop.
The automation problem
Here is where this collides with the rest of what I have been writing about.
Automation functionality is likely to be a security critical function. Orchestrators and operational support systems are named as oversight functions. Follow both statements to their conclusion and the automation you have built to run your network is not a supporting tool sitting outside the security boundary. It is inside it, in the more heavily protected tier.
Now consider what a modern operations platform does. It ingests telemetry from everything. It correlates and decides what matters. Increasingly it acts: restarting components, shifting traffic, scaling capacity, applying configuration. A system that can do those things across the estate oversees and controls security critical functions. That is the definition of an oversight function, arrived at by function rather than by anybody’s intention.
Which means the things I have argued for on general engineering grounds turn out to be regulatory requirements for some organisations. The automation needs its own identity with its own permissions. It needs a segregated management path. It needs enhanced monitoring, including changes watched as they happen. Its normal behaviour needs to be characterised precisely, because it is a priority for anomaly detection rather than an afterthought.
It also means that if you have connected a language model to operational data and given it the ability to act, you have added a component to an oversight function, and the untrusted input problem stops being a matter of engineering taste. The regulation’s later deadlines include validation of automation, which suggests the drafters saw this coming.
I suspect a fair number of automation platforms have been deployed as productivity tools by teams who would be surprised to learn where they sit in the classification.
Where the difficulty actually is
Not in the controls. The control expectations are demanding but legible, and a competent team can work through them.
The difficulty is classification, for three reasons.
The word “material” is doing enormous work and has no threshold attached. What proportion of a network is a material part of it? The answer is a judgement, it will be argued about, and the argument needs to be recorded because the recording is what you produce when asked.
The inverted default means the exclusions are the deliverable. Producing a defensible statement of why something is not critical requires understanding it properly, which is precisely the understanding organisations lack for their older systems. The exercise surfaces that gap rather than tolerating it.
And functions do not respect system boundaries. The definitions talk about functions, while your inventory is a list of servers, services and appliances. One function may span several systems, and one system may carry several functions of quite different criticality. Mapping between the two is genuinely hard work and it is where the effort goes.
Scope is not the point
It matters very little whether any of this binds you. Regulation of this kind is a floor rather than a target. It exists in statute because some organisations would not otherwise do the work, and being outside its scope is not the same as being outside the risk. Nobody probing your management plane checks first which tier you fall into, or whether your turnover clears a threshold.
So take the two categories as good practice that happens to have been written down unusually carefully, and treat the involvement of lawyers as evidence it was thought through rather than as a reason it belongs to somebody else. The only question that survives the compliance framing is whether the system that can reconfigure your entire estate is defended like something that can reconfigure your entire estate.
Ask which functions, not systems, would materially degrade your service if they failed or were captured. Then ask, for each one, what oversees and controls it. Then look honestly at whether the second list is better protected than the first, or worse.
In most environments it is worse, for an understandable reason. The critical system was recognised as critical and got attention. The tool that manages it was infrastructure plumbing that somebody set up years ago, and it has quietly accumulated the ability to change everything while nobody classified it as anything at all.
That gap is the finding. The regulation only makes writing it down compulsory for some people.