Consultation outcome

Proposals for new telecoms security regulations and code of practice - government response to public consultation

Updated 30 August 2022

Ministerial foreword

This government has been clear in its ambition to make the United Kingdom a world leader in digital connectivity. Over 69% of the country has access to gigabit-capable broadband, and the government’s ambition for the majority of the population to have access to a 5G signal by 2027 has been delivered five years early. But we know that today the security and resilience of our communications networks and services is more important than ever. From heightened geopolitical threats through to malicious cyber criminals exploiting network vulnerabilities, global events have shown the importance of providing world-leading security for our networks and services.

That’s why the creation of a new telecoms security framework via the Telecommunications (Security) Act 2021 was so important. With the help of the telecoms industry, we’ve now been able to move that framework forwards.

In March 2022 we launched a ten-week public consultation on drafts of the Electronic Communications (Security Measures) Regulations and Telecommunications Security Code of Practice that will form the central part of the new security framework. The consultation enabled individuals and organisations to share their views on the drafts with us. It has also enabled the government to finalise the drafts, taking into account those views, to create a security framework to identify and address risks to the UK’s public telecoms networks and services both today and in the future.

This government response sets out the changes we have made to the draft regulations and code of practice to ensure they are appropriate and proportionate ahead of the planned commencement of the new framework in October 2022. I want to thank all of those who responded to the consultation for sharing their views and insights, drawing upon their extensive knowledge and experience. We have taken into account the range of views provided by respondents, which have been vital in developing the documents. Now is the right time to put those final parts of the security framework in place, and defend the public networks and services that we all rely on.

Matt Warman MP

Minister of State for Digital, Culture, Media and Sport

Executive summary

The UK is becoming ever more dependent on public telecoms networks and services. The increased reliance of the economy, society and critical national infrastructure (CNI) on such networks and services means it is important to have confidence in their security. As the value of our connectivity increases, it becomes a more attractive target for attackers. It is important to make sure that our networks and services are secure in this evolving threat landscape.

To protect the UK’s public telecoms networks and services against security compromises, the government introduced the Telecommunications (Security) Act 2021. It provides the government with new powers to make regulations that place specific security obligations on the providers of public telecoms networks and services. The Act also enables the government to issue codes of practice containing guidance on how to meet those obligations.

The government held a public consultation on the draft Electronic Communications (Security Measures) Regulations and a draft code of practice between 1 March and 10 May 2022. We sought views on the security requirements set out in the draft regulations and the guidance measures within the draft code of practice. We also asked for views on a proposed system of ‘tiering’ and implementation timeframes, which are intended to help ensure the measures are implemented appropriately and proportionately depending on the nature of the provider. Finally, we sought views on the security measures that should be applied to legacy equipment within telecoms networks.

There were 38 responses to the consultation, from public telecoms providers, industry trade bodies, telecoms suppliers, and interested stakeholders from the wider telecoms and technology industry. The responses have all been recorded and analysed by the government. A significant number of the responses focussed on the approach to phasing-in new measures in the draft code of practice, with many suggesting that implementation timeframes should be pushed back for larger (‘Tier 1’) providers to align with smaller (‘Tier 2’) providers. Other responses focussed on specific measures in the draft regulations and draft code of practice, including those related to privileged access workstations, national resilience, legacy networks and relationships with suppliers.

This document sets out the government’s response to the views raised in the consultation. It explains how we have considered those views, and where appropriate, taken them into account to revise the draft regulations and draft code of practice. For example, in light of the feedback we received, we have altered the implementation timeframes for Tier 1 providers. We have also made changes to those security measures relating to national resilience, legacy networks and the supply chain.

The government will shortly lay the Electronic Communications (Security Measures) Regulations 2022 and accompanying draft Telecommunications Security Code of Practice in Parliament. These versions will reflect changes made by the government in light of the consultation responses it received.

Introduction

Context

The UK’s future prosperity rests on the security and resilience of the public electronic communications networks and services that connect us. Yet as technologies evolve, new threats to those networks and services are emerging. Cyber hackers are now capable of threatening communications worldwide, as the cost barriers to mass-scale disruption continue to fall. Countering state threats is a high priority, with greater competition and aggression in cyberspace by countries such as Russia, China, Iran and North Korea. Actors may seek to exploit weaknesses in telecoms equipment, network architecture and/or operational practices, in order to compromise security.

We are becoming ever more dependent on telecoms as the speed and scale of networks and services develop. The increased reliance of our economy, society and critical national infrastructure (CNI) on telecoms means we need to have confidence in its security. Without effective telecoms security, disruption due to cyber attacks will continue to grow, including the potential for connectivity compromises and outages that could be catastrophic.

The Telecommunications (Security) Act 2021 amends the Communications Act 2003 (‘the Act’) to introduce new duties on providers of public electronic communications networks and services (hereafter referred to as ‘providers’) to identify and reduce the risk of security compromises, and prepare for the possibility of their occurrence (s.105A). The Act also places duties on providers to prevent, remedy or mitigate any adverse effects of security compromises (s.105C). These overarching security duties are intended to provide an effective and enduring basis for protecting UK public telecoms networks and services.

In addition, the Act provides the government with new powers to make regulations (s.105B and 105D) and issue codes of practice (s.105E). The regulations set out specific security measures in secondary legislation, indicating where providers must focus their efforts to secure their public networks and services. Codes of practice provide detailed technical guidance measures to demonstrate how providers can meet their legal obligations.

The Electronic Communications (Security) Measures Regulations 2022 (‘the regulations’) and the associated Telecommunications Security Code of Practice will be the first use of these powers. Their development has been informed by advice provided by the National Cyber Security Centre (NCSC), Ofcom and industry. Draft versions of the regulations and code have been subject to public consultation to ensure that the measures they contain to improve the security of public networks and services are appropriate and proportionate to implement.

Ofcom will take on new responsibilities for monitoring and enforcing compliance with the Act and the regulations. In doing so, it will take into account the guidance measures within the code of practice. How Ofcom intends to meet its new duties and exercise its powers and functions are set out in Ofcom’s draft procedural guidance, which has also been subject to consultation. The government and Ofcom recognise that improving the security of UK networks and services is a shared endeavour, and Ofcom will seek to work closely with public telecoms providers to meet the objectives of the new security framework.

The consultation

The public consultation on the draft Electronic Communications (Security Measures) Regulations and the associated draft code of practice took place from 1 March to 10 May 2022, and sought views on the following four areas in particular:

• the government’s proposed approach to securing public electronic communications networks and services as set out in the draft regulations and guidance measures in the draft code of practice
• the tiering system set out in Section 1 of the draft code of practice, which was proposed to ensure the guidance measures are implemented appropriately and proportionately depending on the nature of the provider
• the approach to phasing-in new measures in the draft code of practice, so that the recommended implementation timeframes for individual measures set out in the code account for both security imperatives and proportionate delivery
• the ways in which measures in the draft code of practice and the draft regulations account for legacy equipment due to be phased out, so that investment in security improvements is distributed appropriately

There were 38 responses to the consultation, including from public telecoms providers, industry trade bodies, and telecoms suppliers. A list of the organisations that responded can be found in Annex B. All responses to the consultation we received have been considered by the government. This document sets out:

• the views expressed in those responses, drawing out common themes and points of particular concern to respondents
• the government’s response to those views, including the changes it has subsequently made to the regulations and draft code of practice, as well as its justification for not making some of the changes that were proposed
• next steps that will be taken to finalise the regulations and code of practice

Responses

The consultation on the draft regulations and draft code of practice received responses from public telecoms providers, their suppliers, industry trade bodies, and interested stakeholders from the wider telecoms and technology industry. A greater proportion of responses were received from larger providers, with relatively few from smaller providers.

Most respondents either answered the specific questions contained within the consultation document, or expressed views in relation to the four areas upon which those questions focused. This section is therefore structured in a similar manner:

• Part 1 focuses on responses to proposals in the draft regulations and code of practice for securing networks and services
• Part 2 focuses on responses to the government’s proposed approach in the code of practice to determining the tiering of providers
• Part 3 focuses on responses to the government’s proposed implementation timeframes for measures set out in the draft code of practice
• Part 4 focuses on responses to the government’s proposed approach in the code for securing legacy networks and services in the draft code of practice

In each Part, context is provided on the government’s specific proposals in the draft regulations and code of practice, information is provided on the views we received from respondents, and the government’s response to those views is set out.

Part 1: Securing networks and services

Context

The draft Electronic Communications (Security Measures) Regulations proposed specific measures that providers, with the exception of micro-entities, must implement. The draft regulations are based around different network or service features, or around the objectives they seek to achieve. They are structured as follows:

Regulation 1 - Citation, extent and commencement

Regulation 2 - Interpretation

Regulation 3 - Network architecture

Regulation 4 - Protection of data and network functions

Regulation 5 - Protection of certain tools enabling monitoring or analysis

Regulation 6 - Monitoring and analysis

Regulation 7 - Supply chain

Regulation 8 - Prevention of unauthorised access or interference

Regulation 9 - Preparing for remediation and recovery

Regulation 10 - Governance

Regulation 11 - Reviews

Regulation 12 - Patches and updates

Regulation 13 - Competency

Regulation 14 - Testing

Regulation 15 - Assistance

Regulation 16 - Exemption for micro-entities

The draft code of practice, which accompanies the regulations, contains technical guidance demonstrating how providers can meet their legal obligations, as set out in the overarching duties in the Act and the regulations. It is divided into three parts. The first part explains the purpose of the draft code of practice and its position within the new framework. The second part follows the structure of the regulations. It explains the key concepts underpinning them, to help providers carry out the technical measures associated with particular legal requirements in the regulations. The third part of the draft code of practice sets out specific technical guidance measures, as a series of actions that could be taken by providers to demonstrate compliance with their legal obligations. These specific technical guidance measures are linked to the regulation(s) to which they are applicable.

Together, the overarching security duties in the Act, the security measures in the regulations (referred to here as ‘security requirements’) and the technical guidance measures in the code of practice form the new telecoms security framework. They are intended to balance the need for effective security with the need for objectives and actions to be proportionate to the risks they are intended to address.

Views received and government responses

In the consultation document we asked the following question regarding the draft regulations and draft code of practice:

Question 1 - Do you agree that the requirements set out in the draft regulations and the guidance measures set out in the draft code of practice are an appropriate and proportionate response to address the risks of a security compromise to public telecoms networks and services under the new duties (s.105A and 105C) in the Act? If no, please set out why, specifically referencing the particular risk of a security compromise, requirements in the draft regulations, guidance measures in the draft code of practice, and objectives of each section.

A summary of the answers we received, and our responses to those answers, is provided below.

Interpretation

Several respondents requested that the code of practice include more detailed definitions of certain terms, including ‘security critical functions’ used within the regulations, and ‘network oversight functions’ and ‘operational support systems’ used within the code. They suggested more detailed definitions would help providers to determine more precisely where new security protections should be applied, and enable them to better understand the magnitude of the changes required.

A small number of respondents also commented that more information needed to be provided on the scope of public electronic communications networks and services (PECN and PECS). Some respondents wanted this clarity to further understand the boundary between public and private networks, whilst others were more interested in which organisations would be defined as providers of such networks and services (e.g. whether cloud providers or resellers would be in or out of scope).

Government response

The government has carefully reviewed the definitions of certain terms used in the draft regulations and code of practice, in light of the consultation responses we received. We have provided further clarification in the draft code of practice on certain definitions, including the relationship between ‘security critical functions’, ‘network oversight functions’ and ‘operational support systems’. This is intended to help providers determine how the security measures apply to different parts of their networks and services.

The definition of ‘security critical functions’ in the draft regulations represents a concept, rather than an exhaustive set of highly specific network and service functions. We consider that it needs to be flexible enough to apply to the different technical set-ups and operational models used across a diverse telecoms sector, which will evolve over time. Similarly, the definition of what might constitute a ‘material impact’ or ‘material part’ of a network with respect to a security critical function will necessarily vary across providers. For these reasons, we have not altered the definition of ‘security critical functions’ used in the regulations.

The definitions of PECN and PECS are contained within section 151 of the Communications Act 2003. Providers of PECN and PECS will include companies with a very diverse range of business models, technologies and delivery approaches. As part of a technology agnostic regulatory framework, the regulations and draft code of practice do not specify subsets of PECN and PECS providers who should take, or be exempt from, specific actions. Nor have they specified that particular business models are out of scope. As with the existing regulatory framework, providers will need to continue to make their own judgments as to whether they are providing a PECN or PECS, or a private network^{[footnote 1]}.

Network architecture - measures relating to national resilience

Multiple respondents provided views on the measures contained within the draft regulations and draft code of practice that seek to mitigate risks posed by public telecoms providers offshoring network security functions and capabilities. These included concerns that the proposed measures could impact some existing business models in which offshore centres collect and analyse network security data to address vulnerabilities.

Some respondents suggested removing the measures in the draft regulations^{[footnote 2]} that seek to ensure providers are able to assess security compromise risks to UK networks and, where necessary, operate UK networks, without reliance on overseas staff, equipment or data. As an alternative, it was suggested that providers should rely on resilience measures within the Civil Contingencies Act 2004. Some respondents requested clarification in the code of practice on the type of services that providers should be expected to run from within the UK in the event of a loss of international connectivity^{[footnote 3]}. Respondents suggested that it would be infeasible to maintain 100% of normal service connectivity for a period of one month, as proposed in the draft code of practice. They also asked for an indication in the code of practice of the risk scenarios that would result in loss of international connectivity, and so would make such action necessary.

Respondents also queried the proportionality of the proposed national resilience measures. For example, it was suggested that the measures should vary depending on a telecoms provider’s size, with greater expectations placed on larger companies. Others suggested that certain types of provider, such as those operating telecoms networks across multiple countries, should be exempt from the measures.

Government response

Dependence of providers on security capabilities based overseas could lead to the inability to effectively assess and mitigate security risks to UK networks, if those capabilities become inaccessible.

We understand respondents’ concerns regarding the national resilience measures, including those in the draft code of practice^{[footnote 4]}. We have been clear that the final requirements and guidance will provide a proportionate and targeted approach. At the same time, the international geopolitical context requires us to have confidence in providers’ ability to continue providing connectivity to UK end-users in the event of a range of geographic risks. To mitigate such risks, the government believes that specific national resilience requirements should be placed on providers of PECN, beyond the more general resilience measures required under the Civil Contingencies Act 2004. We therefore consider it would not be appropriate to remove the proposed regulations relating to national resilience. However, we have amended the wording in the regulations to clarify that public network providers must only take appropriate and proportionate measures to achieve these aims.

We agree that further clarity on the national resilience measures should be provided in the draft code of practice. We have updated the draft code of practice to explain the types of risk scenarios that could necessitate a reduced reliance on certain non-UK security capabilities. In addition, we acknowledge that public telecoms network providers may be unable to maintain 100% of normal services in the event of a loss of international connectivity. We have therefore amended the draft code to explain that if it becomes necessary to do so in an emergency in which the UK lost international connectivity, public telecoms network providers shall have the ability to maintain within the UK (as relevant, where they provide such forms of connectivity prior to the event) fixed and mobile data connectivity to UK peering points, mobile voice services, and text-based mobile messaging.

The relevant measures in the draft code of practice and the risks they are designed to mitigate are applicable to network providers (not service providers) providing PECNs in the UK regardless of whether they operate telecoms networks across multiple countries. The code of practice therefore does not exempt providers that choose to operate networks across multiple countries from national resilience measures.

Network architecture - measures relating to existing networks

Respondents commented on requirements in the draft regulations to secure existing parts of networks^{[footnote 5]}. One respondent suggested these requirements should be extended to cover existing network designs, to allow growth of these networks without creating a disproportionate requirement to refresh all parts of existing networks at the same time. Other respondents provided further comments on how definitions of existing networks might impact security protections for older, ‘legacy’, networks.

Government response

The draft regulations include requirements for providers to protect existing parts of networks that are relied on today by millions of end-users. Under the requirements, providers need to take appropriate and proportionate steps to redesign and develop existing parts of networks in a manner which reduces the risks of a security compromise occurring. Were an existing network design to be considered an existing part of a network, it would therefore still need to be redesigned and developed in such a manner. The draft regulations were also clear that an ‘existing’ part of a network is a part that was brought into operation before the coming into force of the regulations. This would include any equipment that had updates applied to it, where that equipment was in operation before the regulations were brought into force.

Network architecture - measures relating to the management plane

Four respondents commented on the measures in the code of practice relating to security of the ‘management plane’^{[footnote 6]}. One respondent suggested that there was a tension in the draft guidance between recommending that second authentication factors should not be generated from a management device, and recommending that the second factor should be locally generated and not transmitted^{[footnote 7]}. Another asked that the government consider amending the proposal that would segregate the management plane so that disruption of one plane will only affect a single UK region, suggesting this could prove disproportionate in certain instances^{[footnote 8]}. The respondents requested that such segregation only apply to national-scale full fibre networks and 5G access networks.

Government response

The government has provided further clarity in the draft code of practice on the role of the management plane in securing the network or service. However, we consider that the wording in the draft code of practice on multi-factor authentication did not need to change. This is because it is possible for a user to generate a second factor on a separate device in their immediate vicinity without that device also being used to make changes to management networks (for example, a mobile phone could operate as a second factor device, as long as that factor isn’t via public messaging such as SMS).

We also recognise that redesigning networks to segregate management planes for multiple UK regions may prove extremely challenging and costly for providers where they do not offer national-scale networks. The aim of such measures in the draft code of practice is to ensure that a compromise in one segment of the management plane does not severely disrupt connectivity across the whole network. We have therefore clarified in the draft code of practice that providers have the flexibility to achieve this aim in a manner that allows the use of the latest technologies and helps ensure providers are able to adopt an appropriate and proportionate approach.

Network architecture - measures relating to virtualisation

Several respondents commented on measures in the draft code of practice relating to network virtualisation^{[footnote 9]}. One organisation noted that the draft security measures are framed on the assumption of a unified ownership model of the virtualisation fabric. They commented that, in practice, ownership is shared between providers and their third party suppliers, including public cloud service providers. They were therefore concerned that providers would not be able to implement specific guidance measures in the draft code of practice^{[footnote 10]}.

Another respondent suggested that virtualisation measures should be based around more general and less specific principles. They expressed concern that the current approach could place public telecoms providers at a competitive disadvantage to other companies that are not regulated under the new security framework and may use network infrastructure to provide connectivity services. Some respondents also commented on a guidance measure^{[footnote 11]} that stipulates that providers should use physically separated ports to segregate internal and external network traffic, requesting clarity on how ‘external’ and ‘internal’ are defined in this context.

Government response

Virtualisation of certain network functions will provide various security benefits, for example allowing better inspection of system behaviour, and allowing security updates and improvements to be implemented more quickly. We know that in some instances, some of these functions will make increased use of cloud services including (for example) those offered by platforms such as Amazon Web Services, Microsoft or Google. The regulations and draft code of practice are designed to be technology agnostic. They are also designed to ensure that providers are responsible for the security of their networks and services. Where certain functions are contracted with third party suppliers (including cloud services) providers must take appropriate and proportionate steps to hold those third parties accountable in line with measures in regulation 7 concerning supply chains, regardless of the type of technology chosen for delivery of services^{[footnote 12]}. We have changed the relevant guidance measures in section 3 of the draft code of practice to address this point.

The status of the draft code of practice as guidance, including the virtualisation measures, already provides a degree of flexibility to public telecoms providers in how they choose to meet their security duties as they modernise their networks and services. Providers may choose an alternative approach to meet those obligations, which they would need to justify to Ofcom. Those companies with ambitions to deliver end-to-end connectivity within the UK will need to consider whether their networks and/or services could be considered PECN or PECS. Ofcom oversight and monitoring of PECN and PECS provision within the UK applies equally to different business models.

We have provided further clarification in the draft code of practice that measures in section 3 concerning the use of physically separated ports relate to internal and external ‘interface’ network traffic.

Protection of data and network functions - privileged access workstations

Multiple respondents provided similar comments and suggestions concerning the measures in the draft code of practice relating to privileged access workstations (PAWs)^{[footnote 13]}. These respondents suggested that the measures, as drafted, would be challenging to implement. Respondents were concerned that the proposed approach in the draft code of practice would mean their suppliers may not be able to remotely connect to their networks to make necessary changes. They also suggested that those suppliers, who serve multiple networks, may need to carry multiple devices. Respondents also argued that preventing internet exposure on PAWs would hamper their ability to easily update the devices to the latest and most efficient software used to make changes to network security.

As part of the responses, we received a paper produced by a group of providers, which proposed an alternative security model for PAWs to that presented within the draft code of practice. The paper suggested a number of changes to the text in the code in order to allow the following:

• a virtual PAW to accept an inbound connection over an insecure network from an approved virtual desktop infrastructure (VDI) application with compensating controls to mitigate the risks introduced
• browse up to a virtual PAW from a VDI application with compensating controls to mitigate risks introduced and
• browsing from a third party physical PAW to a virtual PAW within a provider environment.

Government response

We believe that proposed guidance in the draft code of practice, describing how providers can secure their PAWs, is more appropriate to addressing security risks than the alternative technical solution suggested by some consultation respondents. The proposal in the draft code of practice does not prevent providers (or their suppliers) remotely accessing networks. We proposed that secure remote connections could be used as long as additional protections are in place. The draft code of practice has been updated to clarify that a single device can also connect to multiple networks where providers have granted relevant permissions.

The technical solution proposed in the draft code is only one way for providers to ensure compliance. However, it achieves optimal security outcomes so should be considered best practice. The solution proposed by respondents does not achieve these security outcomes, primarily because it would not prevent PAWs from being compromised by attackers over the internet. However, we recognise the benefit in providers implementing a common technical solution for both security baselines and for interactions between companies. The government therefore encourages further engagement by the NCSC with industry to provide further clarity on how PAWs solutions can be built in line with the proposal in the draft code of practice.

Protection of data and network functions - encryption

In responding to the consultation, two respondents raised a potential concern regarding a requirement in regulation 4 for network providers to encrypt network signals^{[footnote 14]}. It was suggested that, due to the broad definition of ‘network provider’ in the regulations, an internet exchange point provider would have to apply encryption to signals received at the ingress point, then decrypt and egress. They commented that this could result in increasing latency and packet loss, and slow transition of data.

Government response

The regulations and code of practice will apply to providers of PECN and PECS. As noted above, companies will need to make their own determinations as to whether their activities meet the definitions of PECN or PECS provision.

Neither the draft regulations nor the draft code of practice sought to make an internet exchange encrypt data from providers that has already undergone encryption before being transmitted. Signals received by the exchange should be encrypted by the provider before being transmitted to safeguard against security compromises. We agree that further encryption by an internet exchange will likely lead to an unacceptable level of latency being introduced to the signals on the network.

We consider that the encryption of signals remains appropriate for ensuring the security of PECN and PECS. The regulations and the draft code of practice have therefore not been amended to reduce the need for applying encryption to signals.

Protection of data and network functions - signalling

Four respondents expressed concerns about a specific measure^{[footnote 15]} in the draft code of practice that stipulates providers shall reconstruct valid incoming signalling messages, rather than copy them, when forwarding such messages to core nodes within their networks. In their consultation responses, they suggested the technical solution which would be needed to implement this measure is currently unavailable. The responses also added that such a solution could prevent the normal operation of services that rely on the integrity of signalling messages being verified through cryptographic signatures. One respondent also commented that another signalling measure^{[footnote 16]} in the draft code is also not currently technically achievable. The measure states that only ‘hub’ signalling addresses shall be exposed externally, and that this should be done in such a way that internal signalling addresses of critical core nodes are not shared or exposed externally.

Another respondent commented that the draft code of practice does not define ‘outbound signalling’ despite there being measures contained within the code suggesting that providers should take action in regards to ‘outbound traffic’^{[footnote 17]}. The respondent suggested a lack of clarity could create disproportionate cost burdens on providers, if they applied the widest possible interpretation of the definition when implementing the measures.

Government response

Malicious signalling messages can lead to network data being put at risk, so we proposed that providers should assume incoming messages are untrustworthy and act accordingly. Reconstruction of incoming signalling is one route to deploying effective security barriers to prevent compromise of networks via the signalling plane. While some technical solutions in today’s market deliver the ability to reconstruct and route incoming signals before they traverse the network, we acknowledge that further technology development may be required before such a measure becomes reasonably practicable in all cases. We have therefore removed the proposed measure to reconstruct incoming signalling messages from the draft code of practice. Instead, we have clarified the security intent behind message reconstruction - ensuring that providers make their critical core and signalling security systems highly resilient to signalling attacks. This allows providers the option of implementing message reconstruction to protect their networks, without excluding other solutions. In relation to exposure of signalling addresses externally, we understand that for SS7^{[footnote 18]} and GTP-C^{[footnote 19]} signalling protocols, network topology information is used as an important part of existing security solutions. The draft code of practice has therefore been amended to clarify that, where measures are taken to prevent external networks from being able to connect to non-‘hub’ signalling addresses^{[footnote 20]}, those measures will not apply to SS7 and GTP-C protocols.

Section 2 of the draft code of practice contained detailed guidance on the types of protocols, signalling messages and risks for providers to consider when meeting their security duties with respect to signalling protections. We have changed the draft code of practice to clarify that such guidance is equally applicable to ‘outgoing signalling traffic’ as it is to signalling traffic arriving from untrusted signalling networks and to signalling arriving from other networks which are not within the scope of the security framework, in order to avoid misinterpretation or confusion.

Protection of data and network functions - Customer Premises Equipment (CPE)

Three respondents expressed concerns about a measure^{[footnote 21]} in the draft code of practice that stipulated that providers shall offer their customers a no-additional-cost replacement of customer premises equipment (CPE)^{[footnote 22]} supplied by that provider, once that equipment had gone out of third party support. Concerns included the costs to providers if the measures extended to business customers and whether such costs would be proportionate to the need to address associated security risks. It was suggested that, as an alternative, lifespans for the support and operation of CPE could be defined and shared with customers so they would know that beyond a certain point in time they could either opt out of support, or be required to procure or recontract for new equipment.

One respondent requested that a definition of CPE be included in the regulations that avoided placing all types of CPE in scope of the regulations. They also asked for text to be added to the draft code of practice to clarify that CPE measures only apply when CPE is supplied as part of the PECN/S, and that they do not apply to endpoint devices or customer Local-Area-Network (LAN) connected devices beyond this.

Government response

Providers who supply CPE to customers that is used, or intended to be used, as part of the network or service should ensure that risks arising from it are appropriately mitigated. We recognise that providers cannot control customer behaviour but nevertheless effort should be made to ensure CPE is kept up to date and secure. We have amended the draft code of practice to remove the suggestion that providers should replace CPE at no extra cost to the customer, recognising that the potential costs to providers of replacing out-of-support CPE could be significant. As CPE supplied to customers differs considerably, depending upon the specific provider and their business models, we do not believe it is appropriate to narrowly define CPE within the regulations.

Protection of data and network functions - SIMs

One respondent suggested an inconsistency between a specific measure^{[footnote 23]} in the draft code of practice relating to the updating of SIM card profiles, and the flexibility allowing for use of alternative solutions elsewhere in the draft code. They also suggested that SIM cards do not generally allow for the encryption key to be changed as the measure necessitates. As an alternative to the measure, it was suggested that if a provider is unable to update SIM cards they should provide replacement cards in the event of the SIM card supplier being compromised. Another respondent requested the measures allow for use of a managed service contract with the SIM card manufacturer so they fully manage the profile-modifiable SIM instead of the provider. One respondent suggested that regulation 4, concerning the protection of data and network functions, should include a requirement to use data that identifies devices and their users to determine where risks to SIM cards might arise.

Government response

The measures in the draft code of practice are intended to keep pace with evolving technologies, including SIMs. We recognise that not every SIM card will allow alteration of encryption keys, and we have changed the measures in the draft code of practice to make that clear. While some providers may be able to replace all SIMs whose supplier has been compromised, what is appropriate and proportionate will depend on the particular circumstances. Therefore we do not consider it necessary to change the position in the guidance measures, and we have not changed the draft code of practice in relation to that position. We also consider it would not be appropriate to introduce regulations and guidance measures that encourage the use of identifying features of users and their devices, which is subject to strict data privacy protections under UK data law. Where SIM manufacturers act as managed service providers for SIM cards, providers will need to ensure the relevant regulations and guidance measures relating to third party suppliers are applied.

Protection of certain tools enabling monitoring or analysis

Two respondents suggested that it would be helpful to include further information in the draft code of practice on how the list of countries in the schedule^{[footnote 24]} to the regulations will be updated. They mentioned that it was important to give as much advance notice as possible to industry of any such changes. In particular, they asked for the code of practice to explain the process, criteria and implementation timeline for any changes to the schedule.

Government response

The schedule to the regulations is used to prohibit specific activities being carried out in the listed countries, due to the unmanageable security risks that would present. The government recognises that the UK’s telecoms sector benefits from the expertise of security centres worldwide outside these locations. However, providing information on the process and criteria for adding new countries to the schedules may risk inappropriately disclosing classified information and fettering future national security decisions. The draft code of practice has therefore not been amended to contain such information. Where it is appropriate to do so, we will instead seek to engage at the earliest opportunity with providers who may be impacted, in the event of any future additions to, or removals from, the schedule becoming necessary. We will also ensure that reasonable time is given to providers to adjust to such changes.

Monitoring and analysis - logging and monitoring data

A small number of respondents were concerned about requirements in the draft regulations and measures in the draft code of practice that involve the storage of logging and monitoring data^{[footnote 25]}. It was suggested that analysing such data could inadvertently reveal pattern-of-life information about customers (thereby posing data privacy risks) and its storage could pose security risks, providing a high-value target for state threat actors. The necessity and proportionality of the requirement in the regulations to store data to monitor and analyse access to security critical functions for 13 months was also questioned.

Government response

The draft regulations and draft code of practice set out how providers should monitor and log data regarding access to security critical functions. This access should be conducted by authorised personnel working for, or on behalf, of the provider. This logged data would not relate to any of the provider’s individual customers, unless a customer was making changes to security critical functions, which would constitute a security compromise in itself. Draft regulation 4 proposed that providers would be required to take appropriate and proportionate measures to protect stored data, which would include logs of access to security critical functions. While some providers may currently store data for a shorter period than 13 months, the draft code of practice explained that retaining logs for this period will capture changes to security critical functions that may only be made on a once-yearly basis. Providers can then compare year-on-year data to rapidly identify any deviations as a result of security compromises. We have therefore not amended the draft code of practice or regulations in this area.

Supply chain - proposed exemption for joint ventures and third party networks

The draft regulations include requirements for providers to include security measures in their contracts with third party suppliers.^{[footnote 26]}** Two respondents requested that joint ventures that are wholly controlled by the providers to whom the joint venture supplies services should be exempted from the definition of third party suppliers within the regulations. They suggested this should be done because existing governance exercised over such joint ventures meant they effectively operated as an extension of those providers. They suggested, therefore, that treating such joint ventures as third party suppliers would prove administratively burdensome, without improving security.

Another respondent suggested that the providers of destination networks, intermediate (transit) networks and interconnection points should be exempted from the definition of ‘third party supplier’ to maintain a clear boundary of responsibility for security at the edge of a provider’s network.

Government response

While joint ventures can offer an effective way to deliver network infrastructure, that infrastructure must be adequately protected. Ownership structures may vary, and in most cases it is likely to be appropriate to treat joint ventures as a third party supplier to ensure that security protections are in place.

The regulations and draft guidance measures concerning supply chains are intended to ensure the protection of provider’s networks and services and avoid vulnerabilities where providers contract with third party suppliers. All providers will have bespoke relationships with their suppliers depending on the nature of their networks and services. It would therefore not be appropriate to exempt certain parties who may act as suppliers, where their activities could impact a provider’s network or service. As such, the regulations and draft code of practice have not been amended to include exemptions for providers of destination networks, intermediate (transit) networks and interconnection points from the definition of ‘third party supplier’.

Supply chain - negotiating contracts

A concern from a number of respondents was that the requirements surrounding contracting with suppliers will be difficult to implement in practice^{[footnote 27]}. Smaller providers commented that they have limited buying power, and larger providers emphasised the time and complexity involved with re-contracting with multinational suppliers. It was suggested that this issue is exacerbated by the limited number of vendors in the market and the stresses on global supply chains. Five respondents asked that the government produce model contract clauses that providers could use in contract negotiations to help implement measures in draft code. Some respondents also requested further clarification be included in the code of practice on what constitutes a ‘new’ contract.

Government response

The government recognises that negotiation and renegotiation of contracts with global suppliers can be complex and takes time. In light of consultation responses, we have therefore revised implementation timeframes in the draft code of practice for larger (‘Tier 1’) providers to incorporate security measures into new and existing contracts. The government continues to advocate the benefits of adopting the security policies reflected in the regulations and draft code of practice to the governments of other countries. Many of those countries are planning to adopt telecoms security frameworks in a similar manner to the UK. The government is also establishing a UK Telecoms Lab which will be a new national capability to support supply chain diversification, as well as security and resilience of the telecoms sector. The lab will focus on supplier diversification, security research and security testing.

The creation of model security contract clauses by the government would not be appropriate here, as contracts between providers and their suppliers need to be specifically tailored to business needs, relating to their individual networks and services. However, the draft code of practice has been updated to include guidance on what constitutes a ‘new’ contract to assist providers’ engagement with their suppliers.

Supply chain - single security standards on sites

One respondent raised the concern that where sites have equipment that is used by multiple providers (e.g. cell sites), they may need to comply with multiple different sets of security requirements. They suggested that wording should be added to the code that encourages providers on the same site to work together to a set of consistent security standards.

Government response

We agree that providers who share cell sites will need to develop practical agreements on how they apply new requirements to those sites. We have added a recommendation to the draft code of practice that providers sharing the same site work together to agree security measures that will be commonly applied.

Supply chain - maintaining asset records

One respondent commented on the guidance in Section 2 of the draft code of practice that providers should not rely on third party suppliers to maintain asset records^{[footnote 28]}. They suggested that being asked to do this would go beyond what is required by the draft regulations and would also result in significant costs being incurred by providers. Another respondent suggested that, rather than having to maintain records themselves of assets supplied by others, as set out in the draft code, they should be permitted to rely on suppliers or third parties to maintain such records and be able to request information from them when necessary for security planning and incident response. The respondent suggested this would avoid imposing a disproportionate compliance burden on providers.

Government response

The retention of asset records is vital to providers developing an understanding of the risks to network and service security. Holding these records themselves will enable providers to engage effectively with internal and external parties who have access to their networks and services. In retaining such records, providers may need to work closely with their third party suppliers to collate information. We have provided clarification in the draft code of practice that public telecoms providers may collate information from suppliers and third parties as part of their own asset management records.

Prevention of unauthorised access or interference - ‘break glass’ measures

A small number of respondents expressed concern that ‘break glass’ access^{[footnote 29]} measures in the draft code of practice were disproportionate and would take a long time to implement. They also suggested that the deployment of available solutions to implement the measures could have adverse impacts on the availability and resilience of telecoms networks and services.

Government response

The draft code of practice emphasised the need to protect ‘break-glass’ access credentials so that they may only be accessed in emergencies. This is important practice for credential management, and the government’s changes to the implementation timeframes in the draft code (see below) will help to ensure providers have sufficient time to introduce the measures to avoid adverse impacts on their networks and services. We have also made changes to the draft code of practice so it clarifies that central storage for persistent credentials must be protected by hardware means, providing examples of this.

Preparing for remediation and recovery - use of offline backups

Two respondents commented that the proposed requirement in the draft regulations^{[footnote 30]} to hold offline backups of the information necessary to maintain the normal operation of the network or service in the UK would potentially create further targets for attackers, whilst proving costly to implement. It was suggested instead by one respondent that backing data up in public cloud storage outside the UK would be a more resilient approach in the face of catastrophic domestic infrastructure failure. Another respondent commented that what matters is how secure the information is, rather than where it is stored. One respondent noted that restoring backups following a cyber attack risked, in certain circumstances, exposing the network or service to the same vulnerabilities as originally exploited. Because of this, they suggested that analysis and patching of vulnerabilities needed to be carried out before restoration to avoid further exploitation.

Government response

Retaining backups of network and service rebuild data from a known good state allows rapid recovery in the event of a security compromise. The draft regulations proposed retaining an offline copy of such information so far as it is proportionate to do so. Therefore, what is proportionate will depend on the particular circumstances. The draft regulations also proposed that data which relates to the operation of the network or service must be appropriately and proportionately protected^{[footnote 31]}. This would extend to copies of information necessary to maintain the normal operation of the network or service in the UK, so would prevent additional vulnerabilities (that attackers might exploit) being unaddressed. The draft code of practice proposed guidance on offline backups, including modern technologies such as the secure use of cloud storage.

Given that UK end-users are served by networks and services that rely on at least some capabilities based within the UK, it is important that copies of rebuild data are accessible in the UK when incidents occur preventing access to data stored overseas. This would not prevent providers holding copies of such data in other countries.

Rebuilding networks should not reintroduce vulnerabilities. The draft regulations are intended to ensure that providers will be able to have access to the information necessary to ensure networks and services are resilient to security compromises, such that the impacts to end-users are kept to a minimum. In resuming normal service, providers will be required to take appropriate and proportionate measures to ensure that the use of such information would not cause any, or further, security compromises.

Patches and updates - scale of patches and difficulty of implementing them within 14 days

Ten respondents commented on measures relating to security patching^{[footnote 32]} in the draft regulations and draft code of practice. Most of the concerns related to the proposal that providers would have to implement patches within a 14-day period, or alternatively record in writing why they have not done so. One respondent suggested that the requirement to record the reasons for not implementing patches within 14 days would be overly burdensome, particularly for small providers, due to the volume of patches they apply. Some other respondents proposed a risk-based approach in which patching of the most critical vulnerabilities is prioritised. They also suggested that focusing too heavily on patching any vulnerability within 14 days risked causing network outages due to lack of proper testing of the patches.

Government response

The requirement in regulation 12 requires providers to take appropriate and proportionate measures to deploy patches based on the risk to their networks and services. Therefore, it already allows for providers to take actions that are proportionate to the circumstances in order to meet the requirement, as requested by respondents.

However, we recognise that additional clarity could be provided in the draft code of practice on how the most critical security issues may be patched. Therefore, we have updated the draft code of practice to more clearly reflect this risk-based approach by, for example, including more information on which critical vulnerabilities ought to be patched within 14 days. This should help to ensure that the patching of vulnerabilities is carefully balanced against any potential negative impact to the wider network. The additional guidance we have included in the draft code should also help providers to more easily categorise and record those patches (routine or otherwise) that may justifiably require more than 14 days to implement.

Testing - general comments on testing

We received a small number of comments from respondents regarding the testing requirements and guidance measures in the draft regulations and draft code of practice. Some of these were focussed around one particular measure in the draft code of practice, which specified that testing on externally-facing systems should normally be performed at least every two years, and in any case shortly after a significant change occurs.^{[footnote 33]} Respondents requested more information on the level of testing that is expected, including whether providers should only look to test for vulnerabilities, and asked why a period of two years is specified. One respondent suggested that customer premises equipment (CPE) should be excluded from testing on externally-facing systems, as such testing could lead to disruption to services for customers, including outages.

One respondent suggested that the testing requirements set out in draft regulation 14 should specify the requirements for such tests to be compliant with international standards, such as the 3GPP Security Assurance Specifications (SCAS) or the GSMA Network Equipment Security Assurance Scheme (NESAS).

One respondent mentioned risks associated with ‘fuzzing’^{[footnote 34]}, commenting that inserting malformed packets into network equipment could cause compromises or outages. They suggested that these risks should be passed onto suppliers and that fuzz tests of equipment should be carried out centrally within the planned UK Telecoms Lab, due to the specialised hardware and skills required to perform it.

Finally, one respondent commented that, if an intention of the measures is for network or service providers to perform tests or assessments on their cloud or shared service managed by a third party, further clarification is required on the scope of such testing.

Government response

Guidance contained in the draft code of practice that providers should carry out regular testing of externally-facing systems at least every two years will help to ensure they are secure and that providers identify and address security risks before further testing is carried out. We have changed the draft code of practice to specify that this regular testing excludes testing of CPE, to avoid potential unintended disruption to customer connectivity. Where internationally-recognised tests are applicable to certain parts of a network or service, providers can choose to apply them but what is appropriate and proportionate will depend on their particular circumstances.

The draft code of practice did not suggest that fuzz testing should be carried out on live networks and services, but providers should seek to perform fuzzing in an appropriate manner that would not lead to compromises or service disruption. Where tests are performed on third party-managed equipment and facilities, the provider will need to ensure they are satisfied that the network or service they have responsibility for is subject to adequate testing. The ways in which this is done will differ depending on specific arrangements between the provider and third party. As noted above, the UK Telecoms Lab will also support supplier diversification, security research and security testing to reduce the burden on providers.

Assistance - security of information sharing

One respondent expressed concern about the security of information which providers would need to share with others under draft regulation 15. The regulation requires providers to share information about a security compromise in relation to their networks or services with other providers if that compromise may cause a connected compromise in their networks or services. They suggested that, when shared, such information should be suitably redacted, reduced, and anonymised and once it is no longer needed it should be deleted. A small number of respondents suggested that a formal mechanism or forum for such information sharing would be welcomed to ensure it can be done securely.

Government response

Draft regulation 15 proposed that providers in receipt of information from another provider would not be able to use or disclose that information for any other purpose than addressing a security compromise, without the originating provider’s consent. This provides a high degree of protection over potentially sensitive information shared in confidence by a provider. Data privacy laws will also apply to such information. However, to avoid confusion, we have made it clear in regulation 15(2) that information should not be retained by the recipient longer than is necessary for security purposes. The government welcomes further engagement with providers regarding the proposal to create a forum for such information sharing.

Further questions we asked in our consultation on securing networks and services, the answers we received, and the government’s response to those answers are set out below.

Question 2 - Do you agree it is sufficiently clear which guidance measures in the draft code of practice relate to which regulation (or regulations) within the draft regulations? If no please explain why.

There was a mixed response as to whether or not the measures in the code of practice were clearly linked to the regulations. Nine respondents agreed that it was sufficiently clear, whereas six answered that it was not clear.

Some respondents suggested that workshops would be useful to help industry further understand the links between the measures in the draft code of practice and the draft regulations. Others suggested mapping of each of the regulations to each of the guidance measures in the code of practice would be useful. One respondent also suggested it may be helpful for industry to map the measures in the code of practice to existing technical standards.

The main concern from the negative responses was that individual guidance measures in the draft code of practice that relate to the same regulations have different implementation timeframes. It was also suggested that it was not always clear how information in Section 2 of the draft code of practice related to specific measures in Section 3 of the draft code.

Government response

Section 3 of the draft code of practice identifies which of the regulations each of the guidance measures relate to (including regulations which may be indirectly linked to the measure). This ‘mapping’ is intended to assist providers in using the code of practice to meet their security duties. It should be noted, however, that the extent to which each technical guidance measure can contribute to ensuring compliance with any specific regulation will depend on the facts of each case. The mapping of measures to regulations in Section 3 of the draft code is therefore only indicative and non-exhaustive. Therefore, workshops would not provide significant additional clarity to individual providers who may have particular circumstances that they need to take into account.

If they choose to do so, providers can simply reverse the mapping to identify which of the guidance measures relates to each regulation. However, in the interests of brevity, the government has not added such ‘reverse’ mapping to the draft code of practice. For similar reasons, we have chosen not to signpost how guidance provided in Section 2 relates to each of the individual measures in Section 3 of the code of practice. In the draft code practice, we set out the expected implementation timeframes for each of the guidance measures within the code of practice, in recognition that some measures relating to the same regulation may be more straightforward to implement than others. We agree that some providers may find it helpful to map the guidance measures in the code of practice against existing standards where those are pertinent to their particular activities and not already referenced within the draft code of practice.

Question 3 - Do you expect the draft regulations and draft code of practice to have cost impacts on your business? If yes, please respond to the separate cost survey.

All respondents who answered this question agreed that the draft regulations and draft code of practice would have cost impacts on public telecoms providers. However, one respondent, who had not yet reviewed the cost impacts on their organisation in detail, chose not to comment. Sixteen providers responded separately to the cost impact survey provided by DCMS which asked more detailed questions on the expected cost impacts on providers of implementing the draft regulations. Multiple respondents to the consultation noted that the implementation timeframes set out in the code of practice would have significant impacts on implementation costs.

Government response

We appreciate that the implementation of the new regulations and measures in the code of practice will have significant cost impacts for many providers. Through the consultation we have sought to gain a clear understanding of those impacts to inform the development of the regulations and guidance measures and ensure they are appropriate and proportionate. The changes we have made to the regulations and draft code of practice, in light of the consultation responses, seek to reduce cost burdens on providers. These include changes to the implementation timeframes within the draft code of practice, which are addressed in detail below.

The cost impact survey has informed the development of a business impact assessment, which will be published alongside the regulations when they are laid in Parliament. This assessment will include an estimate of the total cost over a ten year period plus aggregated annual cost of implementing the new regulations. The assessment sets out how the government has developed its policy approach in light of cost survey findings and consultation responses from industry, and explains the methodology behind its findings.

Part 2: Tiering

Context

We proposed that the new security framework should reflect the differences in scale and criticality of providers’ networks and services by using a system of tiering set out in the draft code of practice. Each provider would be allocated to one of three tiers. The guidance measures within the draft code of practice would apply differently to providers in each tier. We suggested that the tiering should be based on providers’ annual relevant turnover.

The government’s proposals for each tier were as follows:

• Tier 1 providers would be the largest organisations (annual relevant turnover of £1bn or more) providing public networks and services for which a security compromise would have the most widespread impact on network and service availability, and the most damaging economic or social effects.
• Tier 2 providers would be those medium-sized companies (annual relevant turnover of more than or equal to £50m but less than £1bn) providing networks and services for which security compromises would have an impact on critical national infrastructure (CNI) or regional availability with potentially significant security, economic or social effects.
• Tier 3 providers would be the smallest companies in the market (annual relevant turnover of less than £50m) that are not micro-entities. While security compromises to their networks or services could affect their customers, if those networks and services do not support CNI such compromises would not significantly affect national or regional availability.

We explained our intention that the measures in the code of practice apply in particular to the Tier 1 and Tier 2 providers. Tier 3 providers may choose to adopt the measures where these are relevant to their networks and services.

We also explained the intention for Ofcom to apply different levels of oversight to Tier 1, Tier 2 and Tier 3 public telecoms providers. Ofcom’s proposed approach to monitoring and enforcing compliance with the new regulatory regime is contained within its draft procedural guidance document^{[footnote 35]}.

Views received and government response

The questions we asked in our consultation document on tiering, the answers we received, and the government’s responses to those answers are set out below.

Question 4. Do you agree that differences between public telecoms providers should be recognised within the code of practice via a system of tiering? If no, please explain the reasons for your answer?

The majority of respondents who expressed an opinion on this topic agreed that a tiering system should be used within the code of practice. However, many respondents provided further comments on the tiering system, largely focussed around the different implementation timeframes for Tier 1 and Tier 2 providers (the comments relating to timeframes are set out in the ‘Implementation Timeframes’ section below).

Several respondents expressed concerns about draft regulation 7(4)(a)(ii), with some interpreting it as meaning that any Tier 2 or Tier 3 providers who supply to Tier 1 providers would be effectively treated as a Tier 1 provider themselves. They commented that, if this was the case, it would negate the benefit of providing different implementation timeframes for Tier 1 and Tier 2 providers and fundamentally undermine the purpose of the tiering.

Two respondents thought that the tiering system should be removed altogether and replaced with a different risk-based assessment approach to enforcement, as threats apply equally to all providers. Some respondents also requested bespoke measures be set out for resellers, who use the infrastructure of other providers. These respondents considered that resellers may be required to carry out security assessments that would duplicate those carried out by providers whose services they are reselling.

Government response

The government first published its proposal for a system of tiering in November 2020^{[footnote 36]}, when the Telecommunications (Security) Act 2021 was introduced to Parliament. The draft code of practice provided further details regarding our proposal, including the relationship between the scale of providers’ networks and services and the potential impact of those networks and services being compromised. The consultation responses we received reflect the widespread agreement with the principle of the three-tier system, which we plan to keep in the draft code of practice.

However, we recognise that some respondents expressed confusion regarding the intent of draft regulation 7(4)(a)(ii), in particular how far security protections should extend within the business of a smaller provider serving as supplier to a larger provider. The intention of the regulation was to ensure that where small providers are supplying goods, services or facilities that form part of a larger provider’s network, those specific goods, services or facilities being supplied to the larger provider should be secured to the same standard as that larger provider’s network. We have therefore clarified the regulations and the draft code of practice to make this intent clear.

The tiering system described in the draft code of practice is intended to apply to all providers of public telecoms networks and services, with the exception of micro-entities. While broadly applicable to many different types of provider, the regulations are clear that providers must take appropriate and proportionate measures in relation to security compromises. This provides the right level of flexibility to avoid disproportionate burdens being placed on certain types of provider, such as resellers. The regulations will ensure that all providers of public telecoms networks and services, with the exception of micro-entities, achieve the required security outcomes.

Question 5: Do you agree that relevant turnover should be used as the metric for determining which tier applies to a given provider? If not, are there other metrics that should be used as an alternative or in combination?

Question 6: If YES to question 5 above, do you agree that the existing definition of relevant turnover should be adopted for the purpose of the code of practice?

The majority of respondents who answered questions 5 and 6 agreed that relevant turnover is the correct metric to use for determining which tier applies to a given provider, and suggested that the existing definition of relevant turnover proposed by the government should be adopted.

A small number of respondents suggested that relevant turnover was not an appropriate metric, either when used on its own or when combined with other metrics. Some of those respondents suggested alternative metrics that could be used, including metrics based around: providers’ capabilities; market share; and number of subscribers.

Three respondents suggested a risk-based approach focused on the specific level of risk posed by a provider’s network or service, regardless of the provider’s size. However one of them acknowledged that it would be challenging to determine the security risk posed by individual networks and services. One industry trade body commented that whilst relevant turnover is appropriate and transparent now, the government could look again over time at whether a different risk-based approach would work.

Government response

As set out in the consultation, a provider’s relevant turnover reflects the relative importance of the network or service provided, and is therefore an indicator of the potential impact of such networks and services being compromised. It also reflects the ability of a provider to shoulder the financial burden of following the guidance in the final code of practice. In addition, relevant turnover is also a metric already understood by providers, with data readily available to all. It is already applied by Ofcom in the context of determining the administrative charges payable by telecoms providers (including providers of electronic communications networks and services), thus its adoption would minimise administrative burdens on providers.

Alternative metrics would not have so many benefits. Pure security risk levels and criticality of a network or service would, as suggested by one respondent, rely on sensitive security information that would not be disclosable to all providers or to investors who may consider acquisition of a provider. Security capabilities will differ significantly across providers who may run networks that support CNI, and those capabilities may shift rapidly as new technologies are trialled and deployed. Market share could act as an alternate proxy for economic scale, but it would require the size of the relevant market to be defined, with extensive new information gathering exercises to be conducted by Ofcom on a regular basis to keep such information up to date. Using the numbers of subscribers as a metric would not capture those networks and services focused on small but critical and highly valuable parts of the communications sector, and would also require a large-scale information gathering exercise to be carried out. Therefore, while the government will keep the approach to tiering under review, the draft code of practice adopts the use of a relevant turnover metric to determine a provider’s tier.

Question 7 - Do you agree that the thresholds for each tier should be as below? If no, what alternatives would be most appropriate?
- Tier 1: Annual relevant turnover >£1bn
- Tier 2: Annual relevant turnover >£50m but less than £1bn

The majority of respondents who agreed with the tiering system also agreed that the proposed tier thresholds are appropriate.

One respondent agreed with the tiering system, but thought that Tier 2 should be subdivided to add another Tier for providers with relevant turnover of between £50m and £500m, arguing that such providers presented a significantly different scale of risks to those between £500m and £1bn annual relevant turnover. Another respondent suggested that the code of practice should only apply to Tier 1 providers, with all other providers able to choose whether or not it was relevant to meeting their security duties.

Six respondents did not agree with the adoption of a tiering system and these respondents also did not agree with the thresholds.

Government response

While Tier 1 providers represent the largest national-scale providers, Tier 2 providers are those for which security compromises are likely to have an impact on critical national infrastructure (CNI) or regional availability with potentially significant security, economic or social effects. We consider it remains important that the code of practice be applicable to such providers.

The consultation set out that the distinction between Tiers 2 and 3 is critical to applying the code. We explained that this threshold must ensure that any provider that is likely to serve critical sectors is in scope, enable Ofcom to provide a degree of regulatory oversight over such providers, and avoid imposing disproportionate financial burdens on smaller providers. We consider that this distinction is still best served by applying a threshold at £50m annual relevant turnover. Further subdivisions within Tier 2 could risk providers with substantive networks and services inappropriately applying a lower level of security protections, raising the risk of a security compromise with potentially significant security, economic or social effects.

The draft code of practice therefore contains three tiers demarcated using annual relevant turnover thresholds at: £1bn and above for Tier 1; more than or equal to £50m but below £1bn for Tier 2; and below £50m for Tier 3.

Question 8 - If you would be impacted by the proposed tiers, would the tier within which you are placed impact the costs of implementing the requirements?

The majority of respondents who answered this question believed that the tiering system would affect the costs of implementing requirements. Of these respondents, most did not provide further details.

Fifteen respondents indicated that they viewed implementation timeframes as the main determinant of overall costs, as more time to implement measures would be likely to reduce costs. Several respondents reiterated their concern that Tier 2 or Tier 3 providers would have to align with Tier 1 timeframes where they act as suppliers to Tier 1 providers.

Government response

The intended purpose of a tiering system is to manage the costs placed on providers by ensuring greater responsibilities are placed on those for whom a compromise is likely to have the most damaging security, economic or social effects. As noted above, tiering by annual relevant turnover reflects the broad ability of a provider to shoulder the financial burden of following the guidance in the code of practice.

The government’s response to concerns about measures relating to providers acting as suppliers to other providers is set out in response to question 4 above, and our response to the issue of implementation timeframes is set out in questions 11-14.

Question 9 - If you would fall into Tier 3 under the proposals, do you consider it is sufficiently clear how the draft code of practice applies to you and how you would implement relevant guidance measures? If not, would you want additional guidance and if so, on what aspects of the draft regulations?

Very few respondents answered this question, which reflects the low response rate to the consultation overall from providers who would likely fall into Tier 3 within the draft code of practice. Of those who did respond, three of them answered that the guidance was sufficiently clear, two answered that it is not and one did not comment either way.

However, half of the respondents who answered this question suggested that workshops would be useful in helping Tier 3 providers to further understand what is expected of them. One industry trade body suggested they would be willing to facilitate sessions to help providers in different tiers understand their responsibilities.

Government response

The government has sought to engage with smaller providers and their representative bodies throughout the development of the draft regulations and draft code of practice. We will continue such engagement following the laying of the regulations and draft code of practice, to ensure that all providers (including those within Tier 3) are aware of the new security framework.

Question 10 - Do you agree with the proposed approach to preventing excessive fluctuation between tiers, with a tier designation applying if a provider meets either of the following criteria? If no, what alternatives would be most appropriate and why?
- a designated tier should apply until annual relevant turnover is recorded as above or below a threshold for two years
- an existing tier designation should apply until the provider is above or below their existing tier’s range by more than £10 million

Four respondents agreed with the proposed approach to preventing excessive fluctuations between tiers, but did not provide further details. However, twelve respondents did not agree with the proposed approach.

The majority of the respondents that did not agree raised concerns about the proposal to apply an existing tier designation until the provider is above or below their existing tier’s range by more than £10 million. In contrast, such respondents tended to agree with the proposal that a designated tier should apply until annual relevant turnover is recorded as above or below a threshold for two years.

The concern about the £10 million fluctuation criteria focused on the perceived negative impact this might have on merger and acquisition activity, especially between smaller telecoms providers. Respondents suggested that this criteria would disincentivise consolidation amongst smaller providers as providers would have to instantly comply with a large number of security measures if such consolidation took place.

The majority of those who expressed these concerns thought that the sole criterion for a provider moving tiers should be its annual relevant turnover being recorded as above or below a tier threshold for two years.

A small number of respondents requested the adoption of a new risk-based approach to changing tiers.

Government response

The draft code of practice proposed including two criteria to prevent excessive fluctuation of providers between tiers, on the basis that such fluctuation could result in those affected facing significant administrative burdens and lack of investment certainty. Stability for business planning will be important to providers looking to make significant changes to security. We recognise the concern that the £10m fluctuation criterion does not deliver this stability and assistance, and could have unintended negative consequences for business investment.

We have therefore removed the guidance that an existing tier designation applies until the provider is above or below their existing tier’s range by more than £10 million. The draft code of practice instead solely sets out that a designated tier should apply until a provider’s annual relevant turnover is recorded as above or below a threshold for two years.

Part 3: Implementation timeframes

Context

The technical guidance measures contained within the code of practice vary in their cost and complexity. Furthermore, not all of the guidance measures will be new, and there will be a number of measures that providers are already implementing. In order to reflect these differences, and still achieve the security outcomes intended by the new framework, the draft code of practice set out a phased approach to implementation.

The government proposed that Tier 1 providers would be expected to:

• implement the most straightforward and least resource intensive measures by 31 March 2023
• implement more complex and resource intensive measures by 31 March 2025
• implement the most complex and resource intensive measures by 31 March 2026

To account for the need to reflect differences in the relative size of public telecoms providers, the draft code of practice proposed that Tier 2 providers should be given an extra two years to implement the measures beyond each of the timeframes set out above.

In cases where providers either change tiers, or new providers enter the market, the draft code of practice proposed they would be expected to follow the existing implementation timelines of that tier, irrespective of how recently they joined the tier.

The consultation sought to gather stakeholders’ views on all aspects of the implementation timeframes. The next section summarises those views, as well as detailing the government’s response.

Views received and government response

The questions we asked in our consultation document on implementation timeframes, the answers we received, and the government’s responses to those answers are set out below.

Question 11 - Do you agree that the guidance measures set out in the draft code of practice should be completed in three phases for Tier 1 providers: by 31 March 2023, by 31 March 2025, by 31 March 2026. If NO, please set out what you consider appropriate timelines for expected implementation, making reference to the guidance measures set out in the draft code of practice.

Eleven responses to this question agreed with the three-phased approach to implementation, but disagreed with the proposed timeframes. A wide range of providers who would likely fall into Tier 1 and Tier 2, as well as trade bodies and suppliers, suggested that these timeframes are very challenging for Tier 1 providers.

Respondents raised concerns about the feasibility of achieving measures by 31 March 2023 and the risk to network security if they attempted to do so. This was due to the tight timeframe and volume of measures proposed. One respondent noted that roughly 40% of the proposed measures in the draft code of practice were due by 31 March 2023. Multiple respondents commented that implementing these measures by 31 March 2023 would not be possible without incurring very large and disproportionate costs. Several respondents suggested that moving at such a rapid pace to implement the measures would risk creating new security vulnerabilities in their networks, as there would be insufficient time to test and securely deploy new measures.

Respondents also suggested that the proposed pace of implementation timeframes risked the delivery of other government targets. They cited in particular the targets for gigabit rollout and the development of 5G services, which respondents argued could be jeopardised as a result of rapid diversion of resources to implement the security measures. Respondents also suggested that the proposed timeframes were especially challenging in the context of a difficult financial environment. Rising input costs, a tight labour market, supply chain disruptions for hardware and low margins were all cited as factors that made the proposed timeframes for Tier 1 providers extremely challenging.

Twelve respondents suggested that timeframes for Tier 1 should be aligned with those of Tier 2, using the Tier 2 timeframes of 31 March 2025, 31 March 2027 and 31 March 2028. Respondents argued this would simplify compliance for Tier 2 providers who are working with Tier 1 providers. It would also provide Tier 1 providers more time to be able to implement the first set of measures and reduce the risks outlined above.

Government response

The implementation timeframes in the code of practice must balance the need for secure and resilient networks and services against the costs incurred to make necessary changes. The timeframes also need to reflect the fact that certain measures can only be put in place once others have been implemented.

The government has always been clear that the new security framework must address the security risks to UK telecoms networks and services now, not just in the future. We are aware that providers are already beginning to take the necessary steps to do this.

However, we agree that implementation of the measures in the code of practice cannot be considered in isolation and must be viewed in light of other significant cost burdens that providers must shoulder. The regulations and code of practice must ensure that providers address pressing risks to their network security without jeopardising other strategic priorities or investment ambitions.

Based on this approach, and the consultation responses we received, we have changed the implementation timeframes for Tier 1 providers in the draft code of practice. The Tier 1 timeframes now align with the Tier 2 timeframes, with the exception of the timeframes for most straightforward and least resource intensive measures. Tier 1 providers will, therefore, now be expected to:

• implement the most straightforward and least resource intensive measures by 31 March 2024
• implement relatively low complexity and low resource intensive measures by 31 March 2025
• implement more complex and resource intensive measures by 31 March 2027
• implement the most complex and resource intensive measures by 31 March 2028

This approach will ensure that all public providers are afforded appropriate time to implement measures while preserving the need for new security measures to be introduced as soon as is feasible. Ofcom will be able to use its new powers once the new security framework comes into force ahead of the timeframes above, to ensure providers are taking appropriate and proportionate steps to secure their networks and services. The draft code of practice remains clear that, due to the existing threat environment, the quicker providers are able to implement the measures the better.

Question 12 - Do you agree that Tier 2 providers should be afforded an additional two years for each of the phases set out above? If NO please set out what you believe is an appropriate extension (if any) and why.

Respondents’ answers to this question largely depended on whether or not they would be considered a Tier 2 provider, and whether or not such Tier 2 providers expected to act as a supplier to Tier 1 providers.

Respondents who expected to be Tier 1 providers either disagreed that Tier 2 providers should be afforded an additional two years, or re-emphasised that Tier 2 implementation timeframes are fair but should apply to both Tier 1 and Tier 2 providers. It was again suggested that, in the instances where Tier 2 providers act as suppliers to Tier 1 providers, Tier 2 providers would in practice need to follow many of the Tier 1 timeframes.

Some respondents who expected to be Tier 2 providers simply agreed that they should be given an additional two years for implementation. However, others said that Tier 1 providers should also be working to the same timeframes. In this scenario, some added that if Tier 1 providers were working to Tier 2 timeframes then Tier 2 providers should have further time and flexibility to implement measures.

Government response

The draft code of practice sets out implementation timeframes for Tier 2 providers that the government considered appropriate and proportionate to the importance of these providers. Our choice of timeframes took into account the ability of Tier 2 providers to shoulder the financial burden of implementing the code of practice measures. In light of all responses, we consider that those proposed Tier 2 timeframes strike the right balance between appropriateness and proportionality and should not be moved.

The amended draft code of practice sets out that the guidance measures it contains should be completed by Tier 2 providers either by 31 March 2025, by 31 March 2027, or by 31 March 2028 (depending on how complex and resource-intensive the specific measures are). The timeframes for Tier 2 providers will therefore align to a significant degree with those of Tier 1, set out above in response to question 11. This alignment will help to ensure Tier 1 and Tier 2 providers are able to coordinate more complex and resource-intensive security improvements, including where Tier 2 providers act as suppliers to Tier 1 providers.

Question 13 - If you expect to fall into Tier 2 what impact on your incurred costs do you expect from an additional two years to implement measures?

Most respondents did not answer this question and, of those who did, few addressed the intent of the question, which was to seek the impact on costs of the proposal to give Tier 2 providers two more years than Tier 1 providers to implement measures in the code of practice.

Two respondents agreed that the provision of an extra two years would allow for a more ordered transition to implementation of measures than would otherwise be the case. It would allow them to implement changes in line with existing upgrades and contract cycles. Only one respondent took the view that the extra two years for implementation would not reduce costs for them, but would instead distribute the same costs over a longer period of time.

Government response

We agree that Tier 2 providers need sufficient time to implement the measures contained in the code of practice and that this will have a bearing on the ability to manage costs of implementation. As set out in response to question 12, we have retained the Tier 2 implementation timeframes in the draft code of practice (by 31 March 2025, by 31 March 2027, or by 31 March 2028, depending on the measure).

Question 14 - Do you agree that the draft code of practice should apply a consistent set of end dates for implementation phases across all providers in relevant tiers, regardless of entry timing to that tier? If no, please explain the reasons for your answer.

Sixteen respondents answered this question with no clear consensus in responses. Those who agreed did not provide significant detail on their reasons for agreeing. Of those who disagreed, several opposed the principle of the code of practice applying different timeframes for Tier 1 and Tier 2 providers. Others disagreed due to concern that this approach was unfair to providers who move tier and might be expected to immediately meet higher security standards. One response suggested that manpower and capital expenditure planning are typically carried out in annual cycles, so it would be very hard to expedite any in-progress compliance projects were there an in-year change in the provider’s tier.

Government response

The draft code of practice proposed applying the same implementation timeframes to all the providers within a relevant tier irrespective of a provider’s entry timing into that tier, to ensure fairness, consistency, and clarity to industry on when the measures should be implemented. All providers, as well as organisations looking to invest in a telecoms provider’s business, will be able to take the timeframes into account in their business planning and investment decisions. The draft code of practice has therefore not been amended in this area.

Part 4: Legacy networks and services

Context

Public telecommunications networks have evolved over many decades. While the UK is now transitioning to a 5G and full-fibre future, many network providers incorporate older technologies into their infrastructure. Because of this, and the need to ensure that all elements of public telecoms networks are secure, the regulations and draft code of practice included requirements and measures to ensure the provision of lifetime support to help maintain security.

However, where equipment is due to be replaced or phased out, the benefits of investing in new security processes to protect that equipment may be outweighed by the costs. For example, suppliers may have discontinued product lines, or the equipment may have been marginalised within the active network. Providers may need to weigh investment decisions carefully to account for the possibility that new security approaches may not be appropriate for certain legacy systems and equipment.

The draft regulations and draft code of practice, which we consulted on, sought to address this issue, and the feedback received from respondents to the consultation has helped to shape the final documents.

Views received and government response

The questions we asked in our consultation document on the proposed approach to securing legacy networks, the answers we received, and the government’s responses to those answers are set out below.

Question 15 - Do you agree that a blanket approach to exempting specific equipment systems as ‘legacy networks’ is not appropriate given the variation between networks? If no, please explain the reasons for your answer.

The majority of respondents who answered this question agreed that a blanket approach to exempting specific equipment systems as ‘legacy’ is not appropriate. One response suggested that any system argued to be in, or out of, scope should be carefully risk assessed.

Feedback on this question focussed on scope, including requests for greater clarity on what constitutes a ‘legacy network’ in any given context. Several respondents suggested that they would like Ofcom to work with industry on this matter.

Two respondents offered suggestions of specific criteria that could be used to clarify what is meant by a ‘legacy network’, and would be used to classify their assets to inform a risk-based approach to applying new security protections. These criteria included defining legacy networks as those networks with a clear sunset date, those for which commercial indicators show that the technology or network is in decline, and clear evidence of reduction in footprint of that technology or network. Another respondent suggested instead defining ‘non-legacy’ networks as those with continued growth in subscribers.

Respondents also provided views in response to this question on the degree to which legacy networks should be treated differently to new networks. One respondent suggested that it should be made clear that it would not be appropriate and proportionate for providers to take the same security measures in relation to legacy networks as they should for new networks. Another response concerned instances where a security upgrade or update is carried out on an existing part of a network after the new regulations and code of practice have come into force. This respondent considered that the code of practice should clarify whether such activity would mean the relevant part of the network would be considered a ‘new part’ of the network.

Government response

While older technologies such as 2G and 3G, or copper broadband, are considered ‘legacy networks’ due to phase-out plans, they are still essential to delivering connectivity today. Draft regulation 3(1)(b) proposed that public telecoms network providers take appropriate and proportionate measures to reduce risks of security compromises occurring in existing parts as well as new parts of networks.

While we recognise that de-prioritising the protection of ‘legacy networks’ would reduce cost burdens on providers, it could also create significant security risks to connectivity for end users. We are aware that, in mobile networks, older generations of 2G and 3G infrastructure currently play a role in delivering newer 4G and 5G services. Such networks must be protected through providers taking appropriate and proportionate security measures.

The draft code of practice therefore does not define ‘legacy networks’ for which implementing the regulations and guidance measures could be deprioritised. However, we have added further guidance to the code of practice. This clarifies that where there is a demonstrable plan at commencement of the regulations for the removal of specific network equipment and it would not be proportionate for that network equipment to meet specific measures within the code, providers shall be required to ensure compliance with their security duties by implementing those measures that remain proportionate, and by taking alternative measures as necessary, based on a detailed risk assessment. Providers should seek to work closely with Ofcom to ensure that applying this risk-based approach delivers the expected security outcomes.

Question 16 - Do you agree that implementation timetables for actions in the draft code of practice should align with existing change programmes such as the planned PSTN switch-off? If no, please explain the reasons for your answer.

The majority of respondents who answered this question agreed that implementation timeframes for guidance measures should align with existing change programmes.

Beyond general agreement on this question, respondents provided specific comments. Most of these suggested that implementation expectations should allow some flexibility as end-dates for certain legacy networks and services may alter. Respondents also requested that timeframes do not align with one particular change programme over others.

Most respondents also expressed a request that the code of practice recognise that networks due to be retired should not be prioritised for new security investments.

Government response

We have set out the updated implementation timeframes to be included in the code of practice in the previous section of this response. We recognise that network upgrades, contract cycles and business change programmes will mean providers are frequently seeking to sunset and retire older networks and services. The updated implementation timeframes will ensure such rolling programmes are able to take account of a phased and proportionate approach to implementing new security improvements. The code of practice will also include further guidance that providers may carry out a thorough security risk assessment of equipment that is currently in use but planned for removal, as set out in our response to question 15.

Question 17 - Do you agree with the proposals in the draft regulations and draft code of practice to address risks arising from legacy systems and equipment (such as Regulation 3(1)(b), guidance in section 2 of the draft code of practice and guidance measures including 5.07, 10.14 and 11.05)? If no, please explain the reasons for your answer.

There was not a clear consensus in the responses to this question. Multiple respondents simply agreed with the question, whilst others repeated concerns raised about the scope of what might be considered a ‘legacy network’ as they had stated in response to question 16.

One respondent who disagreed suggested that the proposals cited in the question were not appropriate nor proportionate. They argued that providers should be able to adopt a risk based approach to legacy networks, and only invest in redesign and development if a significant long-term risk is identified that cannot be mitigated and where there are no immediate plans for that equipment’s removal or upgrade. Another respondent disagreed with a specific measure^{[footnote 37]} in the draft code of practice that stipulates that providers shall ensure that deployed equipment either meets the network equipment supplier’s recommended security configuration or that any variations are recorded and then risk-assessed. They asked if (where an equipment supplier’s recommended configurations are not secure) a period of time would be allowed to mitigate the risk after it has been recorded.

Government response

As set out in the response to question 15, we have added further guidance to the draft code of practice on how providers may take a risk-based approach to securing existing parts of their networks. The regulations and draft code of practice will ensure that providers take appropriate and proportionate measures to secure their networks, and this will apply also to existing parts of their networks. We also consider that this approach would allow a provider adequate time to mitigate risks where equipment supplier configurations were found to be insecure, although what is appropriate and proportionate will depend on the particular circumstances.

Next steps

The Electronic Communications (Security Measures) Regulations will be laid in Parliament for Parliamentary scrutiny under the negative procedure. It is intended that the regulations will subsequently come into force on 1 October 2022. On the same day as the regulations, the draft Telecommunications Security Code of Practice will also be laid in Parliament, in accordance with Section 105F of the Communications Act 2003.^{[footnote 38]} If neither House resolves against the draft code of practice within 40 sitting days, it will then be issued and published in final form.

Ofcom will regulate the new framework in accordance with its new functions under the Act to seek to ensure that public telecoms providers comply with their security duties. Ofcom has a clear remit to work with public telecoms providers to improve the security of their networks and services and monitor their compliance, including the power to request information. It is expected to begin this process in advance of the first implementation timeframes in the draft code of practice, which are set for completion by 31 March 2024. Ofcom will produce its own procedural guidance on its approach to monitoring and enforcing industry’s compliance with the security duties, and has consulted publicly on a draft of this guidance^{[footnote 39]}.

Ofcom must provide its first security report to the Secretary of State under section 105Z of the Act as soon as practicable after the end of each ‘reporting period’ (this being the period of two years after ‘commencement’^{[footnote 40]}, and each successive period of 12 months). The government will use this information to keep the effectiveness of the telecoms security framework under review, and develop it further as new threats emerge.

Annex A: Consultation questions

Part 1: Securing networks and services

Q1. Do you agree that the requirements set out in the draft regulations and the guidance measures set out in the draft code of practice are an appropriate and proportionate response to address the risks of a security compromise to public telecoms networks and services under the new duties (s.105A and 105C) in the Act? If no please set out why, specifically referencing the particular risk of a security compromise, requirements in the draft regulations, guidance measures in the draft code of practice, and objectives of each section.

Q2. Do you agree it is sufficiently clear which guidance measures in the draft code of practice relate to which regulation (or regulations) within the draft regulations? If no please explain why.

Q3. Do you expect the draft regulations and draft code of practice to have cost impacts on your business? If yes, please respond to the separate cost survey.

Part 2: Tiering

Q4. Do you agree that differences between public telecoms providers should be recognised within the code of practice via a system of tiering? If no, please explain the reasons for your answer.

Q5. Do you agree that relevant turnover should be used as the metric for determining which tier applies to a given provider? If not, are there other metrics that should be used as an alternative or in combination?

Q6. If yes to question 5 above, do you agree that the existing definition of relevant turnover should be adopted for the purpose of the code of practice?

Q7. Do you agree that the thresholds for each tier should be as below? If no, what alternatives would be most appropriate?
- Tier 1: Annual relevant turnover >£1bn
- Tier 2: Annual relevant turnover >£50m but less than £1bn

Q8. If you would be impacted by the proposed tiers, would the tier within which you are placed impact the costs of implementing the requirements?

Q9. If you would fall into Tier 3 under the proposals, do you consider it is sufficiently clear how the draft code of practice applies to you and how you would implement relevant guidance measures? If not, would you want additional guidance and if so, on what aspects of the draft regulations?

Q10. Do you agree with the proposed approach to preventing excessive fluctuation between tiers, with a tier designation applying if a provider meets either of the following criteria? If no, what alternatives would be most appropriate and why?
- a designated tier should apply until annual relevant turnover is recorded as above or below a threshold for two years
- an existing tier designation should apply until the provider is above or below their existing tier’s range by more than £10 million

Part 3: Implementation timescales

Q11. Do you agree that the guidance measures set out in the draft code of practice should be completed in three phases for Tier 1 providers: by 31 March 2023: by 31 March 2025, by 31 March 2026. If no, please set out what you consider appropriate timelines for expected implementation, making reference to the guidance measures set out in the draft code of practice.

Q12. Do you agree that Tier 2 providers should be afforded an additional two years for each of the phases set out above? If no please set out what you believe is an appropriate extension (if any) and why.

Q13. If you expect to fall into Tier 2 what impact on your incurred costs do you expect from an additional two years to implement measures?

Q14. Do you agree that the draft code of practice should apply a consistent set of end dates for implementation phases across all providers in relevant tiers, regardless of entry timing to that tier? If no, please explain the reasons for your answer.

Part 4: Legacy networks and services

Q15. Do you agree that a blanket approach to exempting specific equipment systems as ‘legacy networks’ is not appropriate given the variation between networks? If no, please explain the reasons for your answer.

Q16. Do you agree that implementation timetables for actions in the draft code of practice should align with existing change programmes such as the planned PSTN switch-off? If no, please explain the reasons for your answer.

Q17. Do you agree with the proposals in the draft regulations and draft code of practice to address risks arising from legacy systems and equipment (such as Regulation 3(1)(b), guidance in section 2 of the draft code of practice and guidance measures including 5.07, 10.14 and 11.05)? If no, please explain the reasons for your answer.

Annex B: List of respondents

The following is a list of the organisations and representative bodies that responded to the consultation:

• Arqit
• Amazon Web Services
• BT Group
• Comms Council UK (CCUK)
• Cellnex
• CityFibre
• Colt
• Common Framework Ltd
• Crowdstrike
• Ericsson
• Federation of Communications Services
• Fern Trading
• Fujitsu
• Gamma
• Gigaclear
• Huawei
• Hyperoptic
• Independent Networks Cooperative Association (INCA)
• Internet Services Providers’ Association (ISPA)
• KCOM
• LINX
• Microsoft
• Neos Networks
• NICC Standards Ltd Security Task Group
• Open Fibre Networks
• Openreach
• Palo Alto Networks
• Shell Energy
• Sky
• TalkTalk
• techUK
• Three
• Verastar
• Verizon
• Virgin Media O2
• Vodafone
• Voxyonder
• WPD Telecoms

1. As clarified in the consultation, private networks are not in scope of the new security framework introduced by the Telecommunications (Security) Act 2021. ↩

2. See draft regulations 3(3)(f), 3(3)(g), and 3(3)(h) ↩

3. See paragraph 2.88 in Section 2 of the draft code of practice, and guidance measure 23.06 in Section 3 ↩

4. See in particular draft guidance measures 23.01 to 23.07 ↩

5. See draft regulation 3(1)(b): “in relation to an existing part of the public electronic communications network, that the part is redesigned and developed in a manner which reduces the risks of security compromises occurring” See also draft regulation 3(2): “For the purposes of paragraph (1), an existing part of a public electronic communications network is a part that was brought into operation before the coming into force of these Regulations.” ↩

6. The ‘management plane’ is part of a networking system or device that delivers management, monitoring and configuration services to all layers of the network stack, and other parts of the system. ↩

7. See draft guidance measure 2.03 ↩

8. See draft guidance measure 12.24 ↩

9. ‘Virtualisation’ is the process of replacing proprietary hardware functions with commodity software. Further detail on virtualisation is included in the draft code of practice - paragraphs 2.26-2.64 of Section 2 and measures 14.01-14.28, 21.01-21.07 in Section 3. ↩

10. See draft guidance measures 12.01, 14.06, and 18.13 ↩

11. Measure 14.06 in Section 3 of the draft code of practice. ↩

12. See for example, draft regulation 7(4)(a). ↩

13. A ‘privileged access workstation’ (PAW) is a device which is able to make significant changes to security critical functions. We proposed in the draft code of practice that the exposure of these administrative devices to the internet should be strictly limited to connecting to the networks they are making changes to. Further information on PAWs is contained within the code of practice - paragraphs 3.3-3.13 of Section 2 and measures 12.25-12.32 of Section 3 ↩

14. See draft regulation 4(5) ↩

15. Measure 20.01 in Section 3 of the draft code of practice ↩

16. Measure 20.03 in Section 3 of the draft code of practice ↩

17. Measures 3.05, 3.12 and 13.01 in Section 3 of the draft code of practice ↩

18. Signalling System No.7 (SS7) is a telecommunications signalling architecture traditionally used for the set up and clear down of telephone calls and services in fixed or mobile telecommunications networks. ↩

19. GPRS Tunnelling Protocol – Control plane (GTP-C) is used to establish, update and remove data sessions for transport of user traffic between cellular networks. ↩

20. ‘Hub’ signalling addresses are the parts of the network which need to communicate with other providers (e.g. for roaming or number portability). Non-’hub’ signalling addresses are therefore all other signalling addresses. ↩

21. Measure 11.02 in Section 3 of the draft code of practice. ↩

22. Customer premises equipment (CPE) in the draft code of practice referred to that provided and managed by the provider to the customer. This excludes consumer electronic devices such as mobile phones and tablets, but does include devices such as edge firewalls, SD-WAN equipment, and fixed wireless access kit. ↩

23. The measure in question is 6.10 in Section 3 of the draft code of practice, which states that: ‘For profile-modifiable SIM cards, the provider shall, within the first year of use, update with a new profile (including K/Ki, and OTA keys) that has not been provided externally, including to the SIM card manufacturer. Providers should aim to ensure that all new UICCCs can be updated with new K/Ki and OTA keys after receipt from the SIM card manufacturer.’ ↩

24. The schedule in the draft regulations listed certain high-risk locations where certain security capabilities that monitor and analyse UK networks and services must not be located. Those security capabilities must also not be accessible from those locations. The locations are China, Iran, North Korea and Russia. ↩

25. See draft Regulation 6(3)(e), paragraphs 5.30-5.31 in Section 2 of the draft code of practice and guidance measure 18.12 in Section 3 of the draft code of practice ↩

26. See draft Regulation 7 ↩

27. Guidance measures regarding contracts in the draft code of practice are contained within Section 3 - see draft measures 8.01-10.19 ↩

28. See paragraph 2.78 in Section 2 of the draft code of practice ↩

29. ‘Break glass’ access credentials in this context refers to those credentials that are designed only for use in emergencies to allow non-administrative personnel to make changes to the network or service. See draft measures 2.05, 12.03, 12.04, 12.11-12.23, 12.36 in Section 3 of the draft code of practice. ↩

30. See draft regulation 9(2)(a)(ii) ↩

31. See draft regulations 4(1)(a) and 4(2)(a) ↩

32. Patching is a process to repair a vulnerability or a flaw that is identified after the release of an application or software. See draft Regulation 12, draft code of practice measures 10.17, 12.29, 17.01 in Section 3 and paragraphs 11.13-11.15 in Section 2 ↩

33. Measure 1.02 in Section 3 of the draft code of practice ↩

34. Fuzz testing or ‘fuzzing’ is an automated software testing method that injects invalid, malformed, or unexpected inputs into a system to reveal software defects and vulnerabilities. ↩

35. Ofcom, Annex 5: Draft general statement of policy under section 105Y of the Communications Act 2003 ↩

36. See Factsheet 2: New Telecoms Security Framework ↩

37. Measure 10.14 in Section 3 of the draft code of practice ↩

38. As amended by the Telecommunications (Security) Act 2021. ↩

39. See General policy on ensuring compliance with security duties ↩

40. The day on which section 11 of the Telecommunications (Security) Act 2021 comes into force, which is expected to be 1 October 2022. ↩