Consultation outcome

Proposals to update the Telecommunications Security Code of Practice 2022: government response

Updated 1 June 2026

Executive summary

In the Telecommunications Security Code of Practice (2022), the government outlines the intention to ‘review and update the Code of Practice periodically as new threats emerge and technologies evolve’.

Following security advice provided to the government by the National Cyber Security Centre (NCSC), and feedback provided both by Ofcom and industry, the government believes that some sections of the Code of Practice now require updating. As well as reflecting new threats and emerging technologies, these updates intend to provide additional guidance and detail where it has been requested from industry.

The government held a public consultation on proposed updates to the Code of Practice from 28 August 2025 to 22 October 2025. We received 30 responses to the consultation from public telecoms providers, trade bodies, telecoms suppliers, and cyber security companies. These responses have all been recorded and analysed by the government.

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 proposed updates to the Telecommunications Security Code of Practice.

The government will lay the revised draft of the updated Telecommunications Security Code of Practice in Parliament in due course. It 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 public electronic communications networks and services (PECN and PECS) that provide our telecoms and internet connectivity. We are becoming ever more dependent on this connectivity as the data demands of our economy and society increase. Consequently, it is important to ensure that the UK’s PECN and PECS are secure and resilient.

The UK Telecoms Supply Chain Review 2019 identified the need to establish an enhanced legislative framework for telecoms security. The Telecommunications (Security) Act 2021 amended the Communications Act 2003 (the ‘2003 Act’) to establish such a framework to improve the security and resilience of UK public telecoms networks and services.

The 2003 Act, as amended, includes:

• Overarching security duties on public telecoms providers to identify and reduce the risk of security compromises occurring, prepare for the occurrence of security compromises, prevent adverse effects arising from a security compromise that has occurred, and to remedy or mitigate such adverse effects.
• Powers for the Secretary of State to make regulations setting out specific security measures to be taken by public telecoms providers.
• Powers for the Secretary of State to issue codes of practice giving guidance on the measures to be taken by public telecoms providers to meet their legal obligations.
• Provisions to ensure the telecoms regulator, Ofcom, can effectively monitor and enforce public telecoms providers’ compliance with their legal obligations under the 2003 Act.

The Electronic Communications (Security Measures) Regulations 2022 (the ‘Regulations’) and the Telecommunications Security Code of Practice (the ‘Code of Practice’) were made using the new powers in the 2003 Act. They are intended to address risks to the security of the UK’s public telecoms networks and services. They were developed in conjunction with the National Cyber Security Centre (NCSC), the UK’s national technical authority for cyber security, and Ofcom, the telecoms regulator.

The Regulations came into force on 1 October 2022. They detail the specified measures to be taken in addition to the overarching duties in the 2003 Act.

The Code of Practice was issued in December 2022. It provides detailed guidelines to large and medium-sized public telecoms providers of PECN or PECS on the government’s preferred approach to demonstrating compliance with the duties in the 2003 Act and the requirements within the Regulations.

It is important that this framework keeps pace with the scale of the threat to UK telecoms networks and services, adapting to evolving threats to network security and new innovations in telecoms technology.

NCSC’s Annual Review^{[footnote 1]} highlights how State actors continue to pose a persistent and escalating cyber threat to UK Critical National Infrastructure (CNI), including telecoms, leveraging sophisticated cyber capabilities and working closely with a growing commercial intrusion market. This threat is becoming increasingly diffuse and dangerous, with cyber-attacks a key tool in geopolitical competition. The volume of nationally significant incidents managed by the NCSC continues to grow, and we are seeing high-profile campaigns like Salt Typhoon targeting over 80 countries worldwide.

The Global System for Mobile Communications Association (GSMA)^{[footnote 2]} has highlighted that the number of cyber attacks has increased by approximately 75% over the past 5 years, and that mobile operators are an increasingly attractive target given the sector’s wide reach and economic importance. The costs to operators of attacks are significant, both in direct cost to the operators, and wider costs to the economy.

At the same time, innovations in technology are redefining both the cyber security threat and the tools available for cyber security and resilience. The growing use of AI, for example, delivers significant operational benefits for telecoms, but it also introduces new risks. Adversaries can exploit AI to automate the discovery of network vulnerabilities, and more rapidly identify high-value targets within networks. Maintaining a proactive, adaptive security posture is essential to safeguard the UK’s telecoms networks and services against these evolving and increasingly sophisticated threats.

It is important that the technical security guidance provided to industry is sufficiently detailed and clear. Government receives regular feedback on the guidance included within the Code of Practice from industry. Where possible, we have tried to reflect requests for additional guidance in our considerations regarding the updating of the Code of Practice.

The consultation

The government’s public consultation on the Code of Practice ran from 28 August 2025 to 22 October 2025. It sought views on the government’s proposed updates to the Code of Practice, intended to:

• Reflect evolving technology. Since the Code of Practice was published, use of certain technologies has increased, including eSIMs, automation tools, and Application Programming Interfaces (APIs). To ensure safe and secure adoption of such technologies, we need to ensure we are providing effective and up-to-date guidance to public telecoms providers.
• Reflect emerging security threats. Recent hostile-state-linked attacks on US telecoms networks have demonstrated the dramatic impact a cyber-attack can have. We need to ensure the Code of Practice reflects the need for public telecoms providers to take appropriate and proportionate measures to protect their networks against such threats.
• Provide further clarity. Public telecoms providers have suggested the Code of Practice is ambiguous in places and lacks specific guidance on certain measures, such as those relating to security testing and use of privileged access workstations. The proposed updates are intended to provide further guidance on these matters.
• Reemphasise the need to take a holistic, risk-based approach to the Code of Practice which encourages delivering a security approach that considers the Code of Practice in its entirety, rather than taking individual security measures in isolation.

The consultation invited thematic feedback on the proposed updates, as well as an estimate of any additional costs related to proposed amendments.  We received 30 responses to the consultation from public telecoms providers, trade bodies, telecoms suppliers, and cybersecurity companies. A full list of organisations who responded to the consultation can be found in the Annex at the end of this document.

In addition to the original consultation, we provided Tier 1^{[footnote 3]} and Tier 2^{[footnote 4]} public telecoms providers with the opportunity to fill out an additional cost survey which ran from 25 November 2025 until the 28 January 2026. We received 7 responses to this cost survey.

The responses to the consultation, and the cost survey, have all been recorded and analysed 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 draft Code of Practice
• next steps that will be taken to finalise the Code of Practice

Consultation responses

Most respondents to the consultation answered the specific questions in the government’s consultation document through the response form provided on the GOV.UK website.

The questions in the consultation document were structured in sections, mirroring those within the Code of Practice itself, including:

• Section 1 – introduction and key concepts (questions 1.1 – 1.2)
• Section 2 – key concepts (questions 2.1 – 2.3)
• Section 3 – technical guidance measures (questions 3.1 – 3.22)
• Annex A, B, and C – including the glossary, Vendor Security Assessments, and Cyber Assessment Framework (questions 5.1 – 5.3).

Respondents were able to provide cost estimates of implementing the proposed updates in response to question 4.1.

The following paragraphs also align to this structure. Within them, we have provided a summary of the changes proposed in each section of the Code of Practice, an overview of the feedback received in response to those proposed changes, and the government’s response to that feedback. While not every individual piece of consultation feedback is referred to in this response, all feedback received has been thoroughly reviewed and taken into consideration.

Section 1 – Introduction and background

Section 1 of the Code of Practice (herein referred to as the ‘Code’) provides the key context for the document, including setting out the legislative framework, roles and responsibilities of public authorities, and information to support the practical application of the Code.

We consulted on proposed changes to Section 1 of the Code that included emphasising the importance of taking a holistic, risk-based approach to security work, and encouraging providers to not delay implementing measures until the dates set out in Section 3 of the Code if they are able to implement them sooner.

We asked the following questions:

• Q1.1 - Do you agree with the proposed amendments to Section 1? If no, explain why.
• Q1.2 - Do you have any more feedback on the proposed amendments to Section 1 (Question 1.1)? If yes, provide details.

Summary of responses

Respondents were supportive of the proposed changes intended to encourage a holistic, risk-based approach to telecoms security. Some respondents indicated that they already take a holistic approach to their security work and welcomed further reinforcement of that approach in the Code.

Respondents were also supportive of the proposed amendments encouraging providers, where possible, to implement measures in advance of the implementation date as part of a proactive and risk-based security approach.

Some respondents suggested there is some tension between the holistic, risk-based approach encouraged in the proposed changes and Ofcom’s compliance monitoring approach, which they thought drove providers towards a ‘checklist’ approach to implementing the measures in the Code.

Several respondents expressed concern around the proposed addition of ‘Business Support Systems’ in paragraph 1.2, which sets out a non-exhaustive list of elements falling within the scope of the measures within the Code. In particular, it was suggested that the proposed glossary definition of the term ‘Business Support Systems’ was too broad and would, consequently, bring a wide range of IT systems into scope that are not relevant to network security.

Government response

The government is committed to working closely with the UK’s communications regulator, Ofcom, which is responsible for monitoring and enforcing public telecoms providers’ compliance with their legal obligations in the 2003 Act, as amended by the Telecommunications (Security) Act 2021.

We note respondents’ feedback suggesting a potential tension between the holistic, risk-based approach encouraged by the Code and the nature of Ofcom’s compliance monitoring process, which includes collecting information about the implementation of the Code measures in line with the phased timeframes recommended in the Code. However, we also note that in addition to informing Ofcom’s supervision approach to ensure networks are secure and resilient, this information-gathering supports Ofcom’s reporting functions, given its annual security reports must include (among other things) information about the extent to which providers have acted in accordance with the Code.^{[footnote 5]}

We also acknowledge respondents’ feedback on the proposed addition of ‘Business Support Systems’ in Section 1 of the Code, and its glossary definition.

In response to feedback, we have removed the proposed reference to Business Support Systems in paragraph 1.2, reverting the language in that paragraph to that used in the original Code. However, it is important to realise that the proposed amendment was intended as a clarification, and that some Business Support Systems could be relevant to the existing guidance in paragraph 1.2, to the extent they are ‘networks supporting the operation of the live networks, where these supporting networks can have a material impact on the proper functioning of the operational network.’

Noting that the term ‘Business Support Systems’ is also referenced elsewhere in the Code, we have retained a glossary definition of the term. In response to feedback from respondents on a more appropriate definition to the one proposed through consultation, we have changed the glossary entry for Business Support Systems to ‘corporate systems that are indirectly involved in the running of the telecoms network and/or the service provision’.

Section 2 – Key concepts

Section 2 of the Code of Practice is intended to establish a clear understanding of the terminology and principles that underpin the security measures detailed within the document.

The government proposed a range of updates throughout Section 2, including amendments to guidance in sections on: overarching key concepts; network architecture; protection of data and network functions; monitoring and analysis; supply chain; prevention of unauthorised access or interference; patching and updates; and testing.

We asked:

• Q2.1 - Do you agree with the thematic areas targeted through the proposed amendments in Section 2? If no, explain why.
• Q2.2 - Do you agree with the specific amendments proposed in Section 2? If no, explain why and propose alternative suggestions (if possible).
• Q2.3 - Do you have any more feedback on the proposed amendments to Section 2 (Question 2.1 and Question 2.2)? If yes, provide details.

Summary of responses

Respondents were broadly supportive of the thematic areas targeted through the proposed amendments in Section 2. They suggested that the new areas of guidance were largely warranted, with one respondent suggesting it was clear where the Code has evolved based on threat, based on feedback, and based on learned experience of the security regime.

Respondents provided detailed feedback on many of the proposed amendments to Section 2. The following section of this government response groups the feedback received into key thematic areas, and for each area provides information on the views we received and sets out the government’s response to those views.

Prescriptiveness of the proposed updates

In the feedback we received on the proposed amendments to Section 2, respondents expressed mixed views on the level of detail and prescription in the proposed updates. Some requested more detail, including practical examples to aid interpretation, while others felt the guidance was too detailed and overly prescriptive and asked for it to be scaled back. In several cases these contrasting views were raised on the same area of proposed new guidance, reflecting a variety of different preferences across industry.

Government response

The government is seeking to achieve the right balance between providing sufficiently detailed security guidance, and allowing organisations appropriate flexibility to achieve security outcomes in a way that best fits their operational contexts.

The consultation feedback received highlights that there is a wide range of preferences regarding the appropriate level of detail and specificity in the Code. Given this wide range of preferences, it is challenging to provide a level of detail throughout the Code that satisfies all respondents.

We have carefully considered all feedback and have made targeted amendments in specific sections of the proposed revised Code to either provide additional guidance or streamline guidance where there is a clear consensus.

It should be noted that the guidance set out in the Code is not the only way for public telecoms providers to comply with their security duties. A public telecoms provider may choose to comply with its security duties by adopting different technical solutions or approaches to those specified in the Code. When they do so, Ofcom may require the provider to explain the reasons why they are not acting in accordance with the provisions of the Code in order to assess whether they are still meeting their legal obligations under the security framework.^{[footnote 6]}

Overarching key concepts

In paragraph 1.3, additional guidance was proposed by the government - after the statutory definition of ‘Security Critical Function’ set out in The Electronic Communications (Security Measures) Regulations 2022 - to clarify that any function which is likely to have a material impact on the data encryption used in the conveyance of signals is likely to be a Security Critical Function.

A definition of ‘Security Critical Function’ was also added to the glossary. This definition mirrored the statutory definition of ‘Security Critical Function’ set out in the Electronic Communications (Security Measures) Regulations 2022 and added some examples of functions whose operation (or failure) is likely to have a material impact on the proper operation of the entire network or service, or a material part of it. Specifically, these examples concerned data encryption, small cells and automation functionality. In relation to automation functionality, it was suggested that automation functionality that has the ability to influence the confidentiality, integrity and/or availability of the network should be considered a Network Oversight Function and a Security Critical Function. 

Summary of responses

In summary, respondents expressed concerns about the examples of security critical functions added in paragraph 1.3 and in the definition of ‘Security Critical Function’ in the Glossary.       

Government response

In response to the feedback received, we have included the statutory definition of ‘Security Critical Function’ in the glossary to ensure alignment. This statutory definition is already reproduced at paragraph 1.3 of the Code.

We have also clarified in paragraph 1.3 that the following are likely to be security critical functions:

(i) small cells whose failure is likely to have a material impact on network capacity/coverage

(ii) automation functionality (especially where it can influence the confidentiality, integrity and/or availability of the network or service), and

(iii) data encryption functions, are likely to be security critical functions

We explained that this is because their operation is likely to have a material impact on the proper operation of the entire network or service, or a material part of it, which is consistent with the statutory definition of ‘security critical function’ set out in the Regulations.

The example of automation functionality is used also in paragraphs 1.6 and 2.69.

Third party administrators

The government has received numerous requests for further clarity, including from public cloud providers, on who is captured by the terminology included in this section of the current Code.

To address this, in paragraphs 2.25 – 2.27 and in paragraph 6.12, the government proposed amended guidance by explicitly adding ‘third party service providers’ and ‘third party suppliers’ – especially where these have access to administrative functions or the ability to affect the confidentiality, integrity and/or availability of the network and/or service -  to the ‘third party administrators’ in respect of whom the Code gives guidance in those paragraphs. The government proposed also to define ‘third-party service providers’ (3PSPs) or ‘third-party suppliers’ (3PSs) in the glossary.

Summary of responses

Respondents generally recognised and supported the intent of these proposals, and the aim to provide a greater degree of clarity and granularity. However, a significant number of responses suggested that the proposed introduction of 3PSPs and 3PSs could be confusing and overlapped with existing definitions including those of managed service providers (MSPs) and third-party administrators (3PAs). Respondents broadly requested more consistent and clear terminology, specifying whether cloud providers and neutral hosts should be treated as 3PAs.

Government response

In response to the feedback received, we have removed references to ‘3PSPs’ and ‘3PSs’ from the guidance in Section 2, instead using 3PA as the unified term for all relevant third-party entities. We have also removed the proposed definitions of ‘3PSPs’ and ‘3PSs’ from the glossary.

We have removed the words ‘especially where these have access to administrative functions or the ability to affect the confidentiality, integrity and/or availability of the network and/or service’ from paragraph 2.25 and 2.27.

We have changed the glossary definition of a 3PA to ‘external partners that carry out privileged access/administrative access on behalf of public telecoms providers’.

In response to feedback, we have also added a new section with guidance on cloud providers in Chapter 6 – Supply Chain.

Network automation

In paragraphs 2.66 – 2.72, new guidance was proposed on network automation that would align the Code with existing NCSC guidance, including principles for secure machine learning.

This proposed new guidance suggested that if automation tools have the ability to influence the confidentiality, integrity and/or availability of the network, it is likely they are a Network Oversight Function and/or a Security Critical Function.

Summary of responses

Respondents called for a more clearly defined scope to new guidance on automation, and improved alignment, particularly to prevent the misclassification of automation tools as Security Critical Functions or Network Oversight Functions without adequate justification.

Some respondents noted the detailed additional Section 2 guidance on automation and expressed concerns that this guidance was only accompanied by one proposed new measure in Section 3. Respondents suggested the inclusion of only a single high-level measure for automation lacks the necessary granularity to enable effective monitoring and ensure compliance with the detailed matters for consideration outlined in section 2.70.

Government response

The government must balance the perspectives of those advocating for additional measures with those favouring fewer interventions. It was determined that introducing further measures would not be appropriate or proportionate post-consultation, and government would rather providers had the flexibility to follow the proposed guidance in a way that they felt was appropriate and proportionate to their own networks.

To reflect the feedback received, we have amended paragraphs 1.3 and 1.6 (as discussed above), and also paragraph 2.69 for consistency with the ‘materiality threshold’ included in the statutory definition of ‘Security Critical Functions’. In particular, we have specified that automation functionality/tools are likely to be ‘security critical functions’ (and potentially also ‘network oversight functions’) where they are likely to affect the entire network/service or a material part of it. To avoid duplication, we have also removed the example of automation tools from the definition of ‘Network Oversight Functions’ in the glossary.

Signalling plane

The government proposed changes to paragraphs 2.76 – 2.89 of the Code of Practice to address feedback from providers and the continued targeting of the signalling plane by cyber threat actors. The changes included guidance on steps providers should take to protect against the injection of malicious signalling messages, to review number analysis reference data, and to introduce an intrusion detection system (IDS) to monitor outgoing signalling traffic.

Summary of responses

One respondent suggested that the proposed changes to paragraphs 2.78 – 2.79 (relating to the injection of malicious signalling and monitoring outgoing signalling traffic) represent a major change in posture. This was particularly highlighted regarding the proposed additions on monitoring outgoing signalling.

Several respondents provided feedback on paragraph 2.80 and the corresponding new measure that we proposed to add in Section 3 (page 129), which initially suggested number analysis reference data should be maintained regularly and reviewed frequently (ideally, at least once every 2 weeks). They argued that reviewing number analysis reference data every 2 weeks would be excessive and neither appropriate nor proportionate.

Respondents also raised concerns about the proposed amendments to paragraphs 2.88 and 2.89, and the corresponding new measure that we proposed to add in Section 3 (page 129), regarding the introduction of an intrusion detection system (IDS). They considered the introduction of an IDS to be disproportionate, given its technical complexity, cost, and significant network architecture implications.

Government response

The government notes the feedback on paragraphs 2.76 – 2.79, but does not agree that the changes represent a major shift in posture. We have therefore retained the proposed changes as drafted, noting that measure M12.01 in Section 3 of the Code already specifies that ‘incoming and outgoing signalling traffic shall be monitored’.

The proposed new text on number analysis reference data added in paragraph 2.80 was drafted using the modal verb ‘should’, instead of ‘shall’, to allow providers more flexibility to adopt a risk-based approach (see the explanation of these terms under paragraph 1.1 of the Code). However, we used ‘shall’ in the corresponding measure proposed in Section 3 of the Code.

In response to feedback from a respondent who highlighted that the proposed new measure about number analysis reference data was unclear for IP networks which are referenced in paragraph 2.80, we have updated the reference to refer to ‘GPRS Serving Node IP addresses’ in that paragraph to make it clearer. This change is also referred to later in this government response.

We are aware some providers already review number analysis data weekly, so the expectation that we initially proposed in paragraph 2.80 about the frequency of these reviews (i.e. ‘ideally at least once every 2 weeks’) was considered reasonable. However, in response to feedback, we have replaced this wording in paragraph 2.80 with ‘regularly, with an appropriate frequency commensurate to the risk’. We have also decided to use consistent wording (including the modal verb ‘should’ instead of ‘shall’) in the corresponding new measure in Section 3.

Regarding the proposed inclusion of an intrusion detection system (IDS) in paragraphs 2.88 – 2.89 and the corresponding new measure in Section 3, we have loosened the wording to state that outgoing signalling traffic could be checked by deploying an IDS. We have also removed the proposed new measure in Section 3, which suggested public telecoms providers should implement an IDS.

The exposed edge

Paragraph 2.97 outlines a range of equipment that government would normally consider to be ‘physically vulnerable’ and therefore part of the exposed edge, including equipment in road-side cabinets or attached to street furniture. The government proposed adding equipment ‘in shared sites’ as an example of the type of equipment that is physically vulnerable.

A number of measures in the Code already refer to the exposed edge, or equipment in the exposed edge. For example, measure M1.03 provides that ‘Equipment in the exposed edge shall not host sensitive data or Security Critical Functions’.

Summary of responses

A significant number of respondents expressed concern about the proposed inclusion of ‘shared sites’ in paragraph 2.97, and the implication that shared sites would be normally considered part of the exposed edge. Respondents suggested the term is undefined, creating ambiguity over whether secure multi‑tenant spaces such as neutral‑host/third‑party co‑location data centres, and multi-user areas, would now be treated as ‘exposed edge’. Respondents suggested that if this were to be the case, it could disproportionately expand the scope of what is considered ‘exposed edge’ and impose significant cost and operational burdens on shared‑infrastructure and core deployments.

Government response

In response to this feedback, we have removed the proposed reference to ‘shared sites’ in paragraph 2.97 (as an example of equipment that is normally considered part of the exposed edge).

It is, however, important that providers take appropriate and proportionate steps to ensure the security of their equipment placed within shared facilities. To this effect, we have included an additional paragraph in the guidance under ‘exposed edge’  stating that while shared sites - such as co-location hostels, cable landing sites, Internet Exchange Points and data centres - are not generally considered part of the exposed edge, it is recommended that public telecoms providers should assess the risk of unauthorised access to their equipment and mitigate the risk in an appropriate fashion.

Workstations and privileged access

We proposed redrafted wording in paragraphs 3.3 – 3.6 on workstations and privileged access to address concerns that there was insufficient guidance in the Code on the use of privileged access workstations (PAWs). In addition, we proposed amendments to some of the existing measures in Section 3 concerning PAWs (for example, measures M11.24 - M11.26), and to add new measures about PAWs (measures M11.36 - M11.42). These measures are discussed later in this government response. The proposed changes were intended to align the guidance in the Code with European Telecommunications Standards Institute (ETSI) standards.

Summary of responses

Respondents’ feedback varied, with some requesting additional guidance whilst others expressed concern that the existing guidance is overly prescriptive.

Government response

The government must strike a balance between providing sufficiently prescriptive guidance to assist providers in understanding how to meet their legal obligations, whilst also allowing for sufficient flexibility to allow for adaptation as necessary.

There is no single, universal solution and no off the shelf product that can fully address the challenge of protecting high privileged interfaces.

Dedicated physical PAWs are required to ensure the establishment of a secure operational environment. This is consistent with the principles and controls set out within the NCSC guidance on PAWs.

In addition, the provision for controlled external network connectivity, specifically to support essential services such as Mobile Device Management (MDM) and Anti-Virus (AV) platforms, has been aligned with NCSC recommendations. These allowances are designed to maintain the integrity of the privileged environment while enabling the secure integration of necessary management and security services.

In our previous government response, we recommended the development of additional guidance. To support this, the NCSC has collaborated with relevant stakeholders and vendors to establish NCSC principles and align with ETSI standards for PAWs. This guidance has now been updated to reflect that work.

In light of stakeholder feedback, we have made some amendments to the PAW-related measures that we either amended or added in Section 3 of the Code. In particular, in measures M11.38 and M11.41 we are no longer specifying the expected frequency of certain actions. These measures are discussed in more detail later in this government response.

SIM security

The government proposed additional guidance in paragraphs 3.21 - 3.24 of the Code on SIM security intended to reflect the growing uptake of eSIMs, and the associated threats to technology.

These proposed amendments included guidance on checking SIM provider certificates against the GSMA SAS accredited website, on Know Your Customer (KYC) controls, on protection from SIM swaps, and on services that can be used for fraud prevention.

The government also proposed to add a corresponding measure about checking the SIM providers’ certificates in Section 3 of the Code, and a definition of ‘trustworthy’ in the glossary (given this word is used in the added measure).

Summary of responses

Respondents were generally supportive of the intent behind the proposed guidance on SIM security and understood that the issues addressed in the guidance were genuine consumer protection issues.

Respondents were supportive of the new paragraph 3.21 and the corresponding new measure in Section 3, which suggests providers should check SIM provider certificates against the GSMA SAS accredited website and satisfy themselves that the supporting sites and external parties are sufficiently trustworthy.

However, some respondents suggested the paragraphs 3.22 – 3.24, relating to KYC controls, SIM swaps, and fraud prevention dealt with issues that do not belong in security guidance and would be better suited in broader government guidance on consumer fraud. It was suggested that the guidance in these paragraphs, as drafted, represent scope creep and should be removed.  

Government response

We do not agree with respondents’ feedback that paragraphs 3.22 - 3.24 fall outside the scope of the Code. However, we have removed the guidance proposed in those paragraphs in light of stakeholder feedback. For the avoidance of doubt, we note that public telecoms providers should still consider taking appropriate and proportionate measures in relation to KYC controls and SIM swaps.    

We have retained the proposed language in paragraph 3.21, regarding checking SIM providers’ certificates against the GSMA accredited website. As discussed in more detail later in this government response, we have also retained the corresponding measure in Section 3, making some changes to the definition of ‘trustworthy’ for consistency with the Vendor Security Assessment and the schedule to the Regulations.

Encryption and the protection of data

In paragraphs 3.26 – 3.32, the government proposed additional guidance on encryption and the protection of data. It is intended to ensure that, as well as the need to protect personal data, public telecoms providers are aware of the need to protect network data and other bulk data.

Summary of responses

A small number of respondents provided feedback on this additional guidance. Where concerns were raised, they focused on the inclusion of ‘detailed network and system designs’ in paragraph 3.26 as an example of the type of information that could assist an attacker in planning an attack. It was suggested this broadens the scope of the Code beyond essential operational data, which could make Roles-Based Access Control unwieldy.

Government response

In relation to the feedback on paragraph 3.26, the drafting makes clear that detailed network and system designs are provided only as examples of the types of information that could assist an attacker in planning an attack. We do not consider this to represent an expansion of scope, and have therefore retained the proposed wording as drafted.

Monitoring and analysis

The government proposed adding guidance in paragraphs 5.8, 5.9, 5.14, 5.18, and 5.44 of the Code to reflect security best practice on logging and monitoring in light of evolving threats. The government proposed to also add a new measure in Section 3 specifying (in line with the text added at paragraph 5.18) that ‘Regular tests should be conducted to ensure that the logging is functioning as expected’, and to add the same specification in measure M8.07.

Summary of responses

We received only limited feedback on these changes.

Where feedback was provided, it focused primarily on the changes proposed to paragraph 5.14, that outline which security boundaries public telecoms providers should give consideration to in determining where to monitor signals for anomalous behaviour. A small number of providers expressed concerns that the proposed amendments would expand monitoring requirements to include interfaces between public telecoms providers and Mobile Virtual Network Operators, as well as between providers’ own Operational Support Systems (OSS) and Business Support Systems (BSS), which could duplicate existing monitoring in their view.

Government response

Paragraph 5.14 of the Code highlights security boundaries that public telecoms providers ‘should give consideration to’ as part of their overall monitoring approach. By including references to interfaces between public telecoms providers and MVNOs, and between providers own OSS and BSS, our proposed changes clarify that these areas should be considered as part of a providers’ monitoring approach.

The government does not consider this to be a material expansion in scope and suggests there is enough flexibility for providers to determine and take an appropriate and proportionate approach relative to risk. Accordingly, we have retained the proposed wording as drafted.

As discussed in more detail later in this government response, we have retained the new measure about conducting regular tests to ensure that the logging is functioning as expected (M24.01), but omitted these words in measure M8.07 to avoid duplication. 

Service accounts

The government proposed adding new guidance in paragraphs 7.4 – 7.10 and 2 new measures in Section 3 to reflect that service accounts, due to widespread and highly privileged access, are a prime target for compromise and should be treated accordingly.

Summary of responses

Limited feedback was provided on the proposed new guidance in paragraphs 7.4 – 7.10. Most of the feedback we received on Service Accounts focused on the proposed new measures in Section 3 of the Code, which are addressed later in this government response.

One respondent suggested the additional guidance was well warranted and well laid out. Another respondent also suggested the guidance should be more flexible, allowing providers to make risk-based decisions based on their individual circumstances.

Government response

Having considered the limited feedback we received, the only change that we have made to proposed new guidance in paragraph 7.4 – 7.10 is to replace the words ‘asset register’ with ‘an appropriate central repository’ to provide greater flexibility.

As discussed in more detail later in this government response, we have decided to make the same change in the corresponding measure in Section 3, in addition to amending the implementation timeframe for both the new measures on service account to December 2029.

Application Programming Interfaces (APIs)

In paragraphs 7.11 – 7.26, the government proposed new guidance on API security. APIs have become more routinely used and linked to significant data losses since the Code was published. This proposed additional guidance aims to ensure public telecoms providers are taking steps to mitigate the growing threats to APIs.

The government proposed also to add a new API-related measure in Section 3, which is discussed later in this government response.

Summary of responses

We received limited feedback on our proposed new guidance on API security in paragraphs 7.11 – 7.26. Some respondents raised concerns that guidance suggesting providers shall ensure all APIs are fully documented in the asset register (paragraph 7.23) is overly prescriptive and may not be practical in all circumstances. These respondents requested greater flexibility in how API documentation is maintained, provided it remains accessible and secure.

One respondent suggested that further guidance should be added to paragraph 7.12 in recognition that some APIs are accessed via the internet. They suggested requiring further enhanced checks for internet-facing APIs, including IP authentication.

Government response

The government acknowledges concerns about the prescriptiveness of the expectation set out in paragraph 7.23 (and also in the corresponding new measure in Section 3) that public telecoms providers would document APIs specifically in the asset register. In response, we have removed the reference to ‘asset register’ and replaced it with ‘an appropriate central repository’ to provide greater flexibility. For consistency, we have made this change also in the corresponding new API-related measure in Section 3, which is discussed in more detail below.

To allow for greater flexibility, we have also removed the words ‘and fully’ (which was initially intended to qualify how APIs should be documented), both in paragraph 7.23 and the new API-related measure in Section 3.   

Although we note the request for further additional guidance on internet-facing APIs in paragraph 7.12, we do not think it appropriate to add potentially more burdensome guidance to the paragraph after consultation. As such, we have not made further changes to that paragraph.

Patching and updates

We proposed adding guidance in paragraph 11.6 suggesting equipment should be regularly restarted, at least monthly, to remove non-persistent malware.

Summary of responses

Although respondents acknowledged the motivation behind this proposed guidance, most did not agree with its inclusion as currently drafted.

Respondents suggested the guidance was impractical and disproportionate due to the complexity of large networks and the frequency of proposed restarts. Respondents also suggested that it could pose more of a security risk than it solves, due to risks associated with frequent and large scale restarting of network equipment, resulting in loss of availability or service.

Government response

This guidance initially added in paragraph 11.6 was proposed in response to the evolving threat landscape, including the increased risk posed by sophisticated threat actors targeting public telecoms providers. It is intended to mitigate risks associated with non-persistent malware, which can be difficult to detect, by recommending frequent equipment restarts.

In response to the feedback we received, we have removed the reference to restarting network equipment ‘at least monthly’. Instead, we have replaced the wording with guidance recommending that network equipment be restarted periodically as part of routine patching and upgrade cycles, where feasible.

Where restarts are not inherently part of routine upgrade cycles, we have included guidance recommending providers should identify and prioritise high-risk equipment, and implement controlled restart procedures that maintain service resilience and minimise impact on availability. We have also clarified that ‘high risk equipment’ includes devices which are critical to network operations, exposed to external interfaces, or hosting sensitive functions or sensitive data.

Testing

The government proposed adding further guidance on testing to paragraphs 13.3 – 13.18 of the Code. The government proposed to add also 2 further measures on ‘security testing’ in Section 3, which are discussed later in this government response.

Summary of responses

A relatively small number of respondents provided feedback on these proposed changes.

These respondents suggested there was inconsistent use of terminology in some of the proposed changes, particularly in paragraphs 13.3 – 13.7 where ‘security testing’ and ‘security functionality testing’ were used inconsistently.

One respondent expressed concerns regarding proposed new wording in paragraph 13.11, which strongly recommends Ofcom’s TBEST scheme as an example of penetration testing. They suggested there are suitable alternative schemes that achieve the same outcome.

In relation to paragraph 13.13, a respondent noted that the inclusion of the words ‘public telecoms providers should satisfy themselves that negative testing has been carried out by the equipment supplier’ could contradict measure M8.03 in Section 3 of the Code, which states that any third-party testing shall only be accepted if it is ‘performed independently of the network equipment supplier’.

One respondent also suggested that the proposed new wording in paragraph 13.17 was impractical, as it could imply that incident response testing cannot be conducted by the same operational staff who manage the service.

Government response

We acknowledge feedback that terminology could be clearer. We have reviewed this section to improve consistency in the terms used.

In paragraph 13.11, TBEST is included only as an example of suitable testing. Providers may continue to use alternative schemes where appropriate. Therefore, we have kept the proposed wording.

We acknowledge feedback suggesting that the drafting of paragraph 13.13 could be interpreted as conflicting with measure M8.03. To address this, paragraph 13.13 has been revised to state that ‘Public telecoms providers should satisfy themselves that any testing carried out includes negative testing.’

Finally, we agree that the wording in paragraph 13.17 could be considered impractical, as it suggests incident response testing cannot be conducted by the same operational people who manage the service. In response, we have moved paragraph 13.17 to the bullet point list in paragraph 13.10 where it more appropriately applies to penetration testing.

As discussed in more detail below, we have kept one of the additional measures on security testing and incorporated the other into paragraph 13.4 of Section 2.

Cloud security

Where we have proposed changes to guidance throughout the Code, respondents provided a broad range of feedback on the proposed amendments concerning security and use of public cloud services. For example, we specified in the proposed definition of ‘Third-party service providers (3PSPs) or third-party suppliers’ that this includes cloud service providers.

Summary of responses

Overall, there was support for ensuring that the Code remains risk‑based, proportionate, and holistic in its approach.

Several respondents highlighted the need for the Code to explicitly clarify the division of security responsibilities between cloud service providers and public telecoms providers.

Others suggested that aspects of the guidance, particularly those relating to cloud‑native operations and the new API measures, should be simplified and better tailored to reflect modern cloud practices.

Government response

The Code is intentionally technology agnostic and does not look to endorse or prohibit specific platforms, suppliers, or technical approaches. Providers operate different network architectures and outsourcing models. The guidance in the Code needs to allow for this variety.

The Regulations and the Code 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.

As mentioned above, we have removed the definition of ‘Third-party service providers (3PSPs) or third-party suppliers’ as this did not provide the clarity we had intended. Instead, we have provided a new section of guidance covering cloud providers.  

Internal audit

In the proposed updates to the Code, we did not propose any amendments on internal audit.

Summary of responses

We received feedback from one respondent to suggest that the Code should more strongly reflect the role of internal audit in providing independent assurance on telecoms security risks.

The respondent requested additional guidance in Section 2 to strengthen governance by making independent assurance (preferably internal audit) a standard part of both ongoing governance and regulatory reviews, and to require providers to document how this assurance is achieved if internal audit is not available.

Government response

The government acknowledges the feedback proposing the inclusion of additional guidance advocating use of independent assurance and internal audit within the Code.

Although we appreciate the feedback received, it would not be appropriate for us to incorporate the suggested changes at this stage, as this could be interpreted as a significant expansion of scope beyond the original consultation.

As such, we have not added guidance on internal audit at this point in time. However, we will consider including it in future versions of the Code.

Section 3 – Technical guidance measures

Section 3 of the Code sets out specific technical and procedural measures to be taken by public telecoms providers, grouped by the timeframes by which they are expected to be implemented.

To reflect evolving threats and technology, we proposed various updates to Section 3. This included clarification to existing measures, as well as proposing the addition of limited additional measures where we viewed it as appropriate and proportionate.

Amendments to existing measures

Where we proposed amendments to existing measures, for each proposed amendment we asked:

• Q3.1 – 3.10 - Do you agree with the proposed amendment? If no, explain why and propose an alternative solution (if possible).

A summary of the answers we received related to our proposed amendments to each measure, and our responses to those answers, is provided below.

A small number of providers expressed concern about making changes to measures for which the implementation timeframes have already passed. In response, we reviewed each proposed amendment to these measures carefully. Where we perceived a proposed change amounted to more than a clarification, we have shifted that measure to a future implementation timeframe.

Overarching security measures

We proposed to:

• M1.03 - insert the word ‘unnecessary’ into this measure, to qualify the sensitive data of Security Critical Functions which shall not be hosted in equipment in the exposed edge.

Summary of feedback

Many respondents supported the proposed amendment to this measure. However, some respondents raised concerns about the inclusion of the term ‘unnecessary’, arguing that it introduced unhelpful ambiguity around what constitutes ‘necessary’ vs ‘unnecessary’ data. Respondents highlighted that this ambiguity would be particularly problematic in cloud environments, where providers could face a choice between over-restriction that limits efficiency, or under-restriction that exposes vulnerabilities.

Government response

To avoid introducing ambiguity into a measure for which the implementation timeframe has already passed, we have decided to keep the original wording in M1.03 rather than adding the word ‘unnecessary’. As mentioned above, for consistency, we have also decided not to add ‘unnecessary’ to paragraph 2.99 of Section 2.

Management plane 1

We proposed to:

• M2.01 – add ‘as required by the role-based, least privilege model’. This is intended to stress the importance of this principle, which aims to make it harder for an attacker to be able to get system administrator level privileges.
• M2.05 – add ‘this includes test networks or services’, to clarify that default passwords should not be used in any part of the network.

Summary of feedback

Most respondents agreed to the proposed amendments to these measures. The proposed changes to M2.01 received particularly strong support. Some respondents highlighted concerns with the proposed amendment to M2.05. They queried the inclusion of test networks and services, suggesting that they do not form part of the PECN or PECS if they are completely segregated from the production environment.

Government response

Given the broad support for the proposed amendment to M2.01, we have kept it in place.

Regarding respondents’ feedback on M2.05, test networks and services are frequently underestimated in terms of the data they contain, the insights they reveal, and the connections they maintain even when they are not directly linked to live environments.

For a capable adversary, test networks and services can provide valuable intelligence and offer an easy route into production networks, particularly because they rarely receive the same level of security governance and scrutiny as live environments. Moreover, it can be argued that test networks cannot be regarded as accurate or reliable representations of production environments if they are not secured to equivalent standards.

Over the past 2 years, multiple incidents have demonstrated that insecure non‑production environments can lead to significant and wide‑reaching compromises. Notable examples include the 2024 Microsoft breach, in which attackers leveraged a legacy non‑production test tenant, and the 2024 Cloudflare incident, both of which highlight the risks posed by insufficiently secured development and test networks.

With the above in mind, we have made amendments to retain the specification added in M2.05 in a way that recognises this may require additional security work from providers. To do so, we have reverted M2.05 to its original wording, and included a new measure (M22.03) which retains language around test networks and services alongside an amended implementation timeframe of March 2028.

In response to stakeholder feedback suggesting that test networks and services may not form part of the PECN or PECS, we note that in the first instance, it is for public telecoms providers themselves to determine whether their test networks or services form part of the relevant PECN/PECS. We also note that even though failing to protect the test network/service might not in itself be a breach of a security duty, it might be if there are not sufficient controls in place to reduce the risk of it leading to a security compromise on the PECS/PECN.

Signalling plane 1

We proposed to:

• M3.08 – add ‘or other identifiers’, ‘or identifier’, and ‘fraud or’, to reflect evidence to suggest that it is not just number ranges that can be exploited and that this might lead to further fraud as well as security implications.
• M3.10 – add ‘mobile and fixed’, ‘for Mobile Network Operators’, and ‘however public telecoms providers shall also consider for this measure any signalling protocols, including those not explicitly covered by the Global System for Mobile Communications Association (GSMA) guidance.’ This has been added to help ensure public telecoms providers consider relevant guidance beyond that of the GSMA.

Summary of feedback

There were a range of views reflected in responses to the proposed amendments to M3.08 and M3.10.

Some respondents supported the proposed amendments to both measures, others considered that the changes represented an expansion in scope and therefore did not agree with their inclusion.

Where concerns were raised with the proposed amendments to M3.08, they focused on the proposed inclusion of fraud in the measure. Several respondents suggested this would introduce overlap with existing initiatives at Ofcom and within government to tackle fraud, including Ofcom guidance on number management^{[footnote 7]} and Global Title leasing^{[footnote 8]}, which already covers fraud management. It was suggested that this duplication was unhelpful and unnecessary.

Where concerns were raised with the proposed amendments to M3.10, a small number of respondents suggested they expanded the scope to apply to fixed networks and requested that the implementation timeframe for the measure be changed as a result.

Government response

In response to feedback we received suggesting the inclusion of fraud in M3.08 would duplicate Ofcom guidance, we have removed the proposed reference to it in the measure.  

The proposed amendments to M3.10 were intended to clarify the original intent that fixed networks are within the scope of this measure. However, we recognise that some respondents had interpreted the measure differently.

In response, we have reverted M3.10 to its original wording, and included a new measure (M22.04) which retains language on fixed networks and mobile networks and has an implementation timeframe of March 2028.

Third party supplier 1

We proposed to:

• M4.02 – add ‘and consider the Total Cost of Ownership’, to clarify that public telecoms providers should, as a minimum, be considering the end-to-end product costs when making procurement decisions.
• M4.05 – add ‘and document actions’ and ‘when managing risk’, to clarify that as well as documenting risks public telecoms providers should also be documenting the necessary actions undertaken to mitigate those risks.

Summary of feedback

The majority of respondents supported the proposed amendments to M4.02 and M4.05. Where some respondents did raise concerns, these focused on the proposed amendments to M4.02.

Some respondents disagreed with the inclusion of ‘Total Cost of Ownership’, stating that the accompanying glossary definition of the term proposed is too broad, and could lead to inconsistent interpretation. Respondents suggested clarifying the scope of the term by limiting it to security-related costs.

Government response

We have retained the proposed change to M4.05 as drafted, given the broad support expressed in the consultation feedback.

We recognise, however, that the proposed definition of ‘Total Cost of Ownership’ in the Code’s glossary (Annex A of the Code) could be interpreted too broadly. In line with that feedback, we have revised the definition within the glossary to refer only to security-related costs, rather than wider commercial expenditure.

Supporting business processes

We proposed to:

• M5.01 – update references to relevant sections of the Cyber Assessment Framework (CAF). These include separating out some sections of the CAF framework from this specific measure, to include in additional new measures with later implementation timeframes.
• M5.03 – add ‘these backups shall be tested regularly’, to clarify that backups, which act as the main defence against ransomware, should be regularly tested to ensure they are working as intended.

Summary of feedback

The majority of respondents supported the proposed changes to M5.01. Respondents noted that this proposed amendment is largely an administrative update, reflecting the evolution of the CAF and ensuring that references within the Code remain accurate and current.

Respondent’s feedback on the proposed amendments to M5.03 was more divided. While some respondents agreed with the changes, others expressed opposition. Those who disagreed suggested introducing a requirement for regular backup testing in a measure with implementation timeframes that have already passed (31 March 2024 for Tier 1 and 31 March 2025 for Tier 2) would be inappropriate and disproportionate.

Government response

Given the broadly positive feedback we received on our proposed amendments to M5.01, we have not made any further changes to the measure as proposed, to realign the Code with the newest version of the CAF.

We have carefully considered the feedback on our proposed amendment to M5.03. In light of the concerns raised, we have removed the amendments and reverted to the original wording of the measure. However, public telecoms providers should note that paragraph 8.9 of the Code (which we are retaining, with the addition of the words ‘including offline backups’) already suggests that backups should be ‘regularly tested to check they allow the data and network to be recovered effectively’.

Third party supplier 2

We proposed to:

• M8.06 – add ‘any unused protocols, ports or services including’, in response to a developing threat landscape and to reflect security best practice in this area.
• M8.07 – add ‘and regular tests should be conducted to ensure that the logging is functioning as expected’, to clarify that public telecoms providers should be ensuring that logging is functioning appropriately as a fundamental element of fault finding and a good indicator of compromise.

Summary of feedback

Feedback in response to the proposed amendments to M8.06 and M8.07 was mixed, reflecting a range of views from respondents.

For M8.06, several respondents supported the proposed amendment, with one respondent recommending that the measure be further strengthened to require providers to document risks associated with the use of unencrypted management protocols. However, some respondents did not agree with the proposed changes, suggesting they expand the scope of the measure and necessitate time to revisit implementation plans.

For M8.07, a number of respondents indicated that the proposed amendments would result in this measure mirroring the new logging and monitoring measure set out on p.129 of the Code. Those respondents suggested retaining that new measure, and reverting M8.07 to its original wording.

Government response

We have determined that introducing additional requirements into M8.06 to strengthen this measure, as proposed by one respondent, would not be appropriate or proportionate post-consultation.

Whilst several respondents supported the proposed amendments to M8.06, we recognise feedback that the proposed amendment could expand the scope of a measure for which the implementation timeframe has already passed. It was noted that this could incur third party costs to revisit providers approach to implementation.  Accordingly, we have reverted measure M8.06 to its original wording and instead introduced a new measure (M24.09), with an implementation timeframe of December 2029, providing that ‘Public telecoms providers shall disable any unused ports, protocols and services’.

For M8.07, we have reverted the measure to its original wording in response to feedback indicating that the proposed amendments would create overlap with the new measure on logging and monitoring.

Customer premise equipment (CPE)

We proposed to:

• M9.01 – replace ‘configured’ with ‘installed’, to emphasise that credentials should be secure from the point of installation.
• M9.03 – redraft this measure to better reflect security best practice for ensuring that no customer premises equipment (CPE) management interfaces are internet reachable.
• M9.04 – add ‘non-deprecated’, to ensure that protocols that have become obsolete are no longer in use.
• M9.06 – add ‘detected and’, to clarify that the two-step process for protecting the network from unsolicited incoming connections towards the customer’s network (and to support logging and monitoring), shall include detecting such connections in addition to blocking them.

Summary of feedback

Respondents provided minimal feedback on the proposed amendments to M9.01 and M9.04. Where feedback was provided on these specific measures, respondents broadly agreed with the proposed amendments.

Respondents broadly agreed with the intent behind the proposed amendments to M9.03, but a number of respondents suggested that the term ‘internet reachable’ is ambiguous and unclear and requires further scoping.

Several respondents disagreed with the proposed amendment to M9.06. Respondents suggested a requirement to ‘detect and block’ goes beyond the realistic capability of many CPE devices and implies a requirement for active monitoring and logging.

Government response

The minimal feedback we received on the proposed amendments to M9.01 and M9.04 was generally positive. Therefore, we have made no further amendments to these measures.

In response to the feedback received on the proposed amendment to M9.03, and reflecting the suggestions put forward, we have revised the wording to state: ‘CPE management interfaces shall not be accessible from the whole of the internet, but shall be protected by strict ACLs, limiting access to specific management IP address ranges.’

The government notes the feedback on the proposed amendments to M9.06. In response, we have removed the proposed insertion of ‘detected and’, reverting the measure back to its original wording.

Third party supplier measures 3

We proposed to:

• M10.08 – add ‘and carried out securely’, to ensure that any necessary data transfers are being undertaken following security best practice.
• M10.22 – add ‘and have an associated trouble ticket’, which reflects security best practice in tracking and monitoring access to network equipment.
• M10.53 – add references to ‘M8.07, M10.41’ and the addition of ‘and retains any security related configuration’ to ensure consistent protection against threats.

Summary of feedback

Respondents provided minimal feedback on the proposed amendments to M10.08. Where feedback was provided on these specific measures, respondents broadly agreed with the proposed amendments.

In response to the proposed amendments to M10.22, several respondents expressed support for the proposed amendments. Where respondents disagreed with the proposed amendments to this measure, feedback focused on the prescriptiveness of ‘associated trouble ticket’, and concerns that this measure accelerates timeframes for forward ticket-mediated access included in M11 measures.

Several respondents expressed support to the proposed amendments to M10.53. Where concerns were raised, they focused on the inclusion of new references in a measure with a mixed implementation timeframe (M10.53 should be implemented on all new contracts after 31 March 2024 or 31 March 2025, depending on tiering, and on all contracts by 31 March 2027), which according to a respondent would create a differentiator between new and old contracts.

Government response

As the government received minimal feedback on the proposed amendments to M10.08 and the feedback provided was generally positive, we have made no further amendments to that measure.

In response to feedback on M10.22, and in line with suggestions from respondents, we have loosened the wording to ‘an associated trouble ticket or approved change reference’ (adding an ‘approved change reference’ as an alternative option). While we acknowledge the comments regarding the interaction between M10.22, and M11.05 – M11.07, these measures address different requirements. M10.22 relates to third-party access, whilst M11.05 – M11.07 concern all privileged access.

In response to feedback received on M10.53, we have reverted the measure to its original wording in the Code. We have captured the amendments originally proposed in a new measure (M14.03) in ‘Third-party supplier measures 4’, which will have a single implementation timeframe of 31 March 2027, instead of the different timeframes for M10.53 based on the distinction between contracts concluded before or after 31 March 2024 or 31 March 2025 (depending on tiering).

Management plane 3

We proposed to:

• M11.21 – replace ‘these’ with ‘all the management plane’ to help ensure testing procedures are applied to all the rules, policies, and security measures for managing network devices and systems.
• M11.24 – M11.26, M11.29, M11.30 and M11.31 – update and rewrite these measures to provide additional guidance to support the development of an appropriate privileged access workstations (PAWs) solution. The updates are also intended to bring the guidance in the Code in line with ETSI standards on PAWs^{[footnote 9]}.
• M11.36 – M11.42 – add 7 new measures on PAWs. As set out above, we are also proposing to supplement these new measures with additional related guidance in Section 2 of the Code. The addition of these measures is in response to feedback from public telecoms providers. They are intended to ensure the Code aligns with ETSI standards on PAWs.

Summary of feedback

Feedback received in response to amended and additional measures in this section was varied. A number of respondents supported the proposed amendments whilst others raised concerns. In particular, feedback referenced duplication between some of the proposed additional measures, challenges with proposed frequencies for re-testing, and requests for clarification of language used throughout the proposed amendments.

Government response

In response to the feedback, we have refined the existing measures to better align with the NCSC’s PAWs principles^{[footnote 10]} and to improve clarity and consistency with the Act and the Electronic Communications (Security Measures) Regulations 2022. Duplication has been removed, and deprecated requirements will now be managed in line with standard conventions.

The new measures are not necessarily novel; rather, they have been explicitly highlighted to support the implementation of a PAWs solution. Most relate to activities that should already form part of standard Business as Usual processes for any design.

In some measures, we have loosened the guidance regarding the expected timing or frequency of certain actions, and linked it to the public telecoms providers’ risk assessments.  

In particular, we have amended our proposals in relation to the existing and new measures as follows:

(i) In M11.21, we have replaced the words ‘all the management plane controls’ with a more specific reference to ‘all the measures in the management plane sections (M2.01-M2.06, M6.01-M6.05, M11.01-M11.42, M17.01, and M22.03, M24.04 when they are implemented)’.

(ii) In M11.26, we have removed the words ‘and data-at-rest encryption’ as this is already covered by the phrase ‘full disk’ encryption.

(iii) In M11.31, we amended the proposed wording to state that ‘Public telecoms providers shall use device health attestation and compliance to determine access, and quarantine devices that do not comply with their organisation’s configuration policies whilst remediation actions take place. Public telecoms providers shall ensure the above by means of technical controls, unless these controls cannot be used for third-party devices. Where technical controls cannot be used for third-party devices, public telecoms providers shall contractually require and verify that the third-party supplier of the device takes the measures specified above. Public telecoms providers shall also regularly review whether technical controls could be used to ensure the above, and if so, implement these in place of the contractual arrangements.’

(iv) In M11.36, we have replaced the provision of evidence with a more specific reference to the keeping of a written record, and linked the measure to the ‘regular risk reviews’ conducted by public telecoms providers.

(v) In M11.37, we have replaced ‘security governance’ with ‘security team’, for consistency with other guidance set out in the Code (for example, measure M11.40). Similarly to M11.36, we have also replaced the provision of evidence with a more specific reference to the making of a written record.

(vi) In M11.38 and M11.41 we are no longer specifying the expected frequency of certain actions. In M11.41, we have also replaced ‘in real time’ with ‘as soon as network connectivity is available’.

(vii) In M11.40, we have qualified the reference to ‘duties’ as ‘administrative duties’. This is to clarify that this measure refers to administrators being granted access only to the systems and functions necessary for their role.

Noting the importance of these measures from a security perspective, and their alignment with published ETSI standards on PAWs, we have not made amendments to the proposed implementation timeframes.

Third party supplier measures 4

We proposed to:

• M14.01 – add 2 further conditions (‘d’) and (‘e’) to be met for public telecoms providers to continue to use equipment that has reached the vendor’s end-of-life date. These additional conditions relate to having a funded plan to remove equipment and a risk assessment that is updated at least annually and when there is a significant change affecting the equipment in question. These conditions were intended to ensure that decommissioning is completed, and that there is no end-of-life equipment staying in the network that creates unnecessary risks.

Summary of feedback

A number of respondents agreed with the proposed amendments to M14.01 and broadly supported the intent to move away from legacy end-of-life equipment, noting the risks associated with this equipment. One respondent suggested that the measure be strengthened further, by reducing the risk assessment review period and identifying an accountable individual. However, respondents also raised concerns over the proposal. Several respondents suggested requiring a ‘fully funded’ plan to remove all end-of-life equipment was not feasible. Respondents suggested providers work to specific budget cycles, and a fully funded plan would require committing of funds outside the standard planning cycle.

Government response

The government notes that a broad range of views were expressed in response to this proposed amendment. We do not agree with the feedback suggesting strengthening this measure further, as we consider such changes would not be appropriate to make after consultation. In line with feedback received, we have revised bullet points ‘d)’ and ‘e)’ to loosen the guidance and remove the reference altogether to ‘fully funded’.

The guidance has been updated to suggest a risk assessment supporting the use of the equipment is documented and updated at less prescriptive frequency, and that where a risk assessment no longer supports use of equipment, a plan and related cost estimate exists to remove that equipment in a defined timeframe.

Additional new measures

As well as the proposed amendments to existing measures (addressed above), we proposed limited additional measures where we thought them appropriate and proportionate.

Where we proposed additional measures, for each of them we asked:

• Q3.11 – Q3.22 - Do you agree with the proposed new measures? If no, explain why and propose alternative solutions (if possible).

A summary of the feedback we received related to our proposed new measures, and our responses to that feedback, is provided below.

We proposed the following new measures, with proposed implementation timeframes of 31 December 2026 and 31 March 2027 respectively:

• Supporting business processes (31 December 2026) – ‘Public telecoms providers shall have regard to implementing the following parts of the CAF (contained within Annex C) that define the public telecoms provider’s business processes: A2b-Understanding Threat; B2d-Identity and Access Management; B3 a-c Understanding Data, Data in Transit, Stored Data; D2-Lessons Learned.’
• Supporting business processes (31 March 2027) – ‘public telecoms providers shall have regard to implementing the following parts of the CAF (contained within Annex C) that define the public telecoms provider’s business processes: B2b-Device Management.’

These proposed new measures were intended to draw attention to the updated sections from the Cyber Assessment Framework contained in Annex C and give providers sufficient time to have regard to them.

Summary of feedback

Several respondents supported the proposed new measures, noting that they were intended to ensure alignment with the evolution of the CAF.

Some respondents, while supportive in principle, requested further explanation for the inclusion of specific sections from the CAF and exclusion of others. A small number of respondents suggested that, if full alignment between the CAF and the Code is the ambition, all sections of the CAF should be incorporated.

Concerns were also raised by some respondents around implementation timeframes. Respondents highlighted that the proposed amendments represented an expansion in scope, and that following the guidance by December 2026 and March 2027 respectively is likely to be resource-intensive and may not align with organisational funding cycles.

Government response

The government acknowledges the range of feedback provided in response to these proposed new measures and has considered it carefully.

The proposed amendments are intended to align the Code with the latest version of the CAF, and in considering them providers are only expected to ‘have regard’ to the relevant sections of the CAF that are included in the Code.

The measures deliberately draw across sections of the CAF that support the proposed amendments to the wider Code, particularly those related to risk assessment and threat modelling. We do not consider it appropriate or proportionate to include the CAF in its entirety.

In light of this, we have not made further amendments to the text in the measures that we proposed. However, noting feedback provided in relation to implementation timeframes, we have amended the implementation timeframes for both these measures to March 2028. We believe this provides a substantial amount of additional time for providers to have regard to the new sections of the CAF.

We have numbered these measures as M22.01 and M22.02.  

We also proposed a range of new measures with an implementation timeframe of 31 December 2028. These are referred to below.

Some respondents suggested the 31 December 2028 timeframe for these proposed new measures was challenging, and requested no new measures be added to the updated Code with an implementation timeframe before March 2030.

We have considered this feedback carefully and have indicated below where we have made further amendments to the timeframes of specific measures in response to this feedback.

Proposed new measure

• Logging and monitoring – ‘regular tests should be conducted to ensure that the logging is functioning as expected’.

We proposed this new measure aiming to reinforce security best practice with regards to logging and monitoring, in light of evolving threats to the sector.

Summary of feedback

Several respondents expressed support for the proposed new measure on logging and monitoring. One respondent suggested strengthening the measure further, by requiring providers to confirm that logs effectively support threat detection and enable timely investigation.

Some respondents noted potential duplication with the proposed amendments to M8.07. Respondents suggested that this new measure is retained, and the proposed amendments to M8.07 are removed to revert it to its original text.

A small number of respondents requested greater clarity on the term ‘regular’, with one suggesting defining a specific frequency, such as monthly.

Government response

The government acknowledges the feedback provided on this proposed new measure.

We have not made further amendments to strengthen the guidance in this measure, as suggested in some feedback, as we do not consider it appropriate to do so post-consultation.

In response to feedback received, we have reverted M8.07 to its original wording, recognising that the proposed amendments would have created overlap with this new measure.

The government does not consider it appropriate to define a specific timeframe for ‘regular tests’. We have used ‘should’, instead of ‘shall’, in this measure to provide more flexibility, and we encourage providers to adopt a testing frequency that is appropriate and proportionate for their specific contexts.

In response to feedback, we have amended the implementation timeframe for this measure to December 2029.

We have numbered this measure as M24.01.

Proposed new measure

• SIMs – ‘public telecoms providers shall check the SIM providers’ certificates against the GSMA SAS accredited website and satisfy themselves that the supporting sites and external parties are sufficiently trustworthy.’

We proposed this new measure to ensure that public telecoms providers are carrying out appropriate due diligence.

Summary of feedback

Respondents provided minimal feedback on this measure. Where feedback was provided, it was largely supportive of the proposed new measure. The inclusion of the reference to GSMA Security Accreditation Scheme (SAS) as a trusted provider of assurance and certification was strongly supported. However, one respondent suggested that the proposed new measure was a duplicate of M8.14, and requested clarification over its addition.

Government response

The government received minimal feedback on this measure. The majority of those who did provide feedback supported the proposed amendment.

We acknowledge the feedback from one respondent suggesting this proposed new measure duplicates the content of M8.14. The government does not agree that this is the case. M8.14 refers specifically to ‘fixed-profile SIM cards’, whereas the proposed new measure expands the scope to include eSIMs, because it refers, more generally, to ‘SIM providers’ certificates’.

We have retained this new measure as originally proposed and also retained the December 2028 implementation timeframe.

We have numbered this measure as M23.01.

Proposed new measures

• Signalling – ‘number analysis reference data (as per the guidance in paragraph 2.80) that are used to configure network equipment shall be maintained regularly and shall be reviewed frequently.’
• Signalling – ‘public telecoms providers shall protect against the injection of malicious signalling messages into the public telecoms provider’s network.’
• Signalling – ‘the public telecoms provider should implement an Intrusion Detection System (IDS) that monitors outgoing signalling messages and alerts the public telecoms provider where data leaks are discovered. It is recommended that the IDS provider should be different to the signalling firewall (IPS) provider.’

We proposed these new measures to ensure public telecoms providers are taking appropriate steps to protect their networks from malicious interference, ensure accurate and secure configuration of network equipment, and detect potential data leaks.

Summary of feedback

Respondents provided significant amounts of feedback on the proposed new signalling measures. Some respondents commented on the proposed measure concerning number analysis reference data. One respondent requested an exhaustive list of sources to maintain this data, whilst another highlighted that the requirement was unclear for IP networks, which are referenced in paragraph 2.80 of Section 2. Some respondents also considered the requirement to review the data ‘frequently’ to be ambiguous, and that the suggested two-week review cycle in paragraph 2.80 of Section 2 would be burdensome and disproportionate.

Focused feedback was received on the proposed measure to protect against the injection of malicious signalling messages. Several respondents felt this measure was duplicative and already addressed under M12.03 and M12.04.

Significant feedback was received on the proposed measure requiring implementation of an intrusion detection system. Respondents argued the measure would be disproportionate and costly, involving delivery of a major new capability. They also noted that, given the complexity of implementation, the proposed December 2028 timeframe would not be achievable.

Government response

The government acknowledges the range of feedback in response to these proposed new measures.

As mentioned above, in response to feedback on the proposed measure concerning number analysis reference data, we have amended the reference to ‘IP addresses’ in paragraph 2.80 of Section 2 to state ‘GPRS Serving Node IP addresses’. We have also amended the review requirement to ‘regularly with an appropriate frequency commensurate to the risk’. While we are aware that a number of public telecoms providers already carry out such reviews on weekly basis, the wording has been loosened to allow a risk-based approach suited to each organisation.

We have also replaced ‘shall’ with ‘should’, in both the new measure and paragraph 2.80, and added a direct reference to ‘E164, E212, E214 numbering ranges and diameter host names and GPRS Serving Node (GSN) IP addresses’ into the new measure, which avoids the need for a cross-reference to paragraph 2.80.    

In response to feedback, we have also amended the implementation timeframe for this measure to December 2029. In line with this new timeframe, we have numbered the new measure as M24.02.

We do not consider it appropriate to provide an exhaustive list of sources for maintaining this number analysis reference data, as requested by one respondent. There are several commercial providers of such data, and no single definitive source exists.

In response to feedback on the proposed measure to protect against the injection of malicious signalling, we acknowledge concerns that it could be interpreted as duplicative. This proposed new measure was intended to be focused on preventing injection of malicious signalling messages into the networks operated by other public telecoms providers, and therefore different in focus to M12.03 and M12.04, which apply more generally to malicious signalling (including both incoming and outgoing traffic). However, we acknowledge this distinction was unclear and have therefore removed the proposed new measure.

We also acknowledge the feedback on the proposed measure requiring an Intrusion Detection System and, after consideration, have removed this measure in response to stated concerns around cost and proportionality. As mentioned above, we have retained reference to intrusion detection systems (IDSs) in paragraph 2.88, but loosened the wording to state that outgoing signalling traffic could be checked by deploying an IDS.

Proposed new measure

• Governance – ‘public telecoms providers should conduct threat modelling to inform their risk assessments. This modelling must identify relevant threats, vulnerabilities, and potential attack vectors, and should be used to guide the identification and evaluation of security risks across networks and services. For example, through risk assessments or threat models, public telecoms providers should ensure that these risks do not materially affect the proper functioning of the entire network, service, or any significant part of it.’

We proposed this new measure to encourage a holistic approach to security, including through the development of risk assessments and other documentation.

Summary of feedback

The majority of respondents agreed with this proposed new measure. Some respondents highlighted the general importance of threat modelling in their response. One respondent strongly agreed with the proposed measure, noting they have been developing a threat modelling approach and have already seen strong results and security benefits from that work.

However, a small number of respondents cited concerns with this proposed new measure. In particular, those respondents suggested that a definition of ‘threat modelling’ was required, and that guidance should be provided to ensure threat modelling is applied consistently and with appropriate scope.

Government response

In light of the broadly positive responses to this proposed new measure, we have not made substantial further amendments to it.

We note the requests from some respondents for additional guidance on threat modelling. We would encourage providers to review existing NCSC guidance on threat modelling,^{[footnote 11]} which provides details on when threat modelling should be used, and what good threat modelling looks like.

In response to the feedback, we have amended the sentence ‘through risk assessments or threat models’ to ‘through risk assessments and/or threat models’. This revision clarifies that threat modelling is intended to complement, not replace, risk assessments, and to ensure that both are used together as part of a holistic and risk-based approach to security.

In response to feedback, we have also amended the implementation timeframe for this measure to December 2029. In line with this new timeframe, we have numbered the new measure as M24.03.

Proposed new measure

• Management plane – ‘equipment that is subject to high-end attacks shall, where technically possible, implement trusted boot, and periodically be rebuilt/redeployed to an up-to-date known-good state.’

We proposed this new measure to ensure public telecoms providers are undertaking work to prevent and mitigate prepositioning and persistence attacks, in response to evolving threat vectors.

Summary of feedback

Several respondents agreed with this proposed new measure. Others supported the intent behind the proposed new measure but provided feedback on the wording used in the measure. In particular, respondents suggested the term ‘equipment that is subject to high-end attacks’ was unclear and in need of further definition. It was suggested that without a clear definition, the term is open to interpretation and could potentially apply to any network equipment, making the scope overly broad.

Government response

We have seen recent high-profile examples of prepositioning attacks being used to compromise network security. This proposed measure is intended to strengthen protection against this type of threat, by ensuring equipment is in a clean and uncompromised state.

We do not want to be too prescriptive in this proposed new measure, noting that providers are best placed to understand their own networks and services, undertake threat assessments and consider intelligence, and document their own rationale for establishing which network equipment is in scope at a particular point in time.

However, to support this work, and in response to feedback, we have now clarified in the measure that equipment subject to high-end attacks means physical or digital assets that are critical to an organisation’s operations and likely to be attractive targets for sophisticated cyber adversaries, and that these typically include hardware and systems that, if compromised, could cause severe disruption or data breaches.

In response to feedback, we have also amended the implementation timeframe for this measure to December 2029. In line with this new timeframe, we have numbered the new measure as M24.04.

Proposed new measure

• Automation – ‘public telecoms providers shall ensure that the data or software used within automation pipelines is from a trusted source, and validated, and check that the outputs are as expected.’

We proposed this new measure to ensure public telecoms providers are using automation in their networks in a secure way and validating the outputs of automated processes.

Summary of feedback

Several respondents broadly agreed with the proposed new measure on automation.

Where feedback was provided, respondents primarily requested further guidance. In particular, respondents sought clarification on what constitutes a trusted source, the expected level of validation, the types of automation to which the measure applies, and the meaning of ‘outputs are as expected’.

A small number of respondents suggested that the government should develop additional measures to address this topic in greater detail and better reflect the complexities of automation in telecoms networks.

Government response

The government has carefully considered all responses to this proposed measure.

We do not consider it appropriate to provide additional guidance on the terms included in this measure. The drafting is intentionally non-prescriptive to allow providers flexibility in making assessments based on their own risks assessments and operational realities.

We note the feedback from a small number of respondents requesting further measures on network automation. However, it was determined that introducing further measures would not be appropriate or proportionate post-consultation.

We have retained this new measure as originally proposed, and retained the December 2028 implementation timeframe. This new measure has been numbered as M23.03.

Proposed new measure

• Customer premise equipment (CPE) – ‘public telecoms providers shall monitor CPE activity for anomalous behaviour that may have an impact on their networks.’

We proposed this new measure to ensure public telecoms providers are adequately protecting their networks, given this is a common attack vector.

Summary of feedback

Respondents largely supported this measure in principle, but several suggested that the wording as currently drafted is problematic in practice. Primarily, respondents suggested that much CPE is customer-owned, and outside the provider’s control, which makes direct monitoring infeasible.

Government response

This proposed new measure is intended to ensure that providers do not explicitly trust devices, and that they take steps to protect their network from potentially malicious CPE.

In response to the feedback received, we have amended this measure to ‘Public telecoms providers shall block anomalous or potentially malicious CPE activity that could impact the network, to maintain network integrity and service quality.’

In response to feedback, we have also amended the implementation timeframe for this measure to December 2029. In line with this new implementation timeframe, this measure has been numbered as M24.05.

Proposed new measures

• Service accounts – ‘for service accounts, public telecoms providers shall consider whether privileged access is required for each task and follow the role-based, least privilege model and document them in their asset register. They shall be dedicated to the task or service they have been assigned to (i.e. not associated to a user)’.
• Service accounts – ‘a privileged access solution that securely stores and rotates credentials frequently should be used to manage service accounts.’

We proposed these new measures to ensure service accounts are being managed securely, noting that due to their widespread and high privileged access they are a prime target for compromise and should be treated accordingly.

Summary of feedback

The government received a relatively small number of responses to these proposed measures, with several of those responses agreeing in full with them.

Feedback, where received, focused on the guidance to document service accounts in the asset register, which some respondents suggested would create significant administrative burden and duplicate data already managed through access-control systems.

One respondent also noted that the proposed new measure recommending secure credential storage and frequent rotation implies the use of a dedicated Privileged Access Management (PAM) solution, which in their view could be too costly for smaller providers who would prefer to use alternative approaches like encrypted vaults.

Government response

Service accounts are an attractive target for threat actors, and the intent of these new measures is to ensure that public telecoms providers have full visibility of their service accounts to manage their security effectively.

The government acknowledges feedback on the prescriptive nature of expecting public telecoms providers to keep documentation specifically in the asset register. In response, we have removed the reference to ‘asset register’ (both in the new measure and in paragraph 7.6) and replaced it with ‘an appropriate central repository’.

We also acknowledge feedback on the second measure suggesting it implies use of a dedicated PAM solution. Given the limited feedback received on this measure, we do not consider amendments necessary. The measure is intentionally proposed using the modal verb ‘should’, instead of ‘shall’ (in line with the meaning attributed to these terms under paragraph 1.1 of the Code) to allow more flexibility, and providers may adopt alternative solutions where appropriate.

In response to feedback, we have also amended the implementation timeframe for these measures to December 2029. In line with this new implementation timeframe, these measures have been numbered as M24.06 and M24.07.

Proposed new measure

• Application Programming Interfaces (APIs) – ‘public telecoms providers shall ensure their APIs are clearly and fully documented in the asset register, and implemented securely, to minimise exposure to the internet and/or unauthorised parties.’

We proposed this new measure to ensure public telecoms providers are taking steps to mitigate the increase in attacks looking to exploit APIs and drive secure use.

Summary of feedback

Respondents broadly agreed with the proposed new measure. A small number of respondents suggested that a single measure on APIs was insufficient and recommended that the government introduce additional measures to better reflect the complexity of API use in telecoms networks.

Some respondents raised concerns that requiring all APIs to be fully documented in the asset register is overly prescriptive and may not be practical in all circumstances. These respondents requested greater flexibility in how API documentation is maintained, provided it remains accessible and secure.

Government response

Similarly to the feedback received on the proposed new service account measures, the government acknowledges concerns about the prescriptiveness of expecting public telecoms providers to document APIs specifically in the asset register.

In response, we have removed the reference to ‘asset register’ and replaced it with ‘an appropriate central repository’. We have also removed the phrase ‘and fully’ from this measure. These amendments are intended to provide greater flexibility at the discretion of providers.

In response to feedback, we have also amended the implementation timeframe for these measures to December 2029. In line with this new implementation timeframe, this measure has been numbered as M24.08.

Proposed new measures

• Security testing – ‘public telecoms providers shall implement an automated scanning process to identify vulnerabilities, missing patches or configuration changes.’
• Security testing – ‘public telecoms providers are responsible for determining a holistic approach to security testing, which includes security testing that is appropriate, risk-based, and tailored to their specific deployments.’

We proposed these new measures to reduce the time that public telecoms providers are exposed to vulnerabilities, and drive a holistic approach to testing, in line with the additional guidance provided in Sections 1 and 2.

Summary of feedback

The government received a relatively limited number of responses to the proposed addition of new measures on security testing. Of those received, several respondents agreed with the proposed measures as drafted.

Where feedback was provided some respondents suggested that the second proposed measure would better fit as Section 2 guidance, and should be removed and instead incorporated into paragraph 13.4.

Government response

In light of the limited feedback on the first proposed new measure on security testing, we have not made further amendments to this measure, and have retained the December 2028 implementation timeframe, numbering this measure as M23.02.

We acknowledge that the second proposed measure, relating to determining a holistic approach to security testing, is better suited to being included in the Code as guidance within Section 2, rather than as a technical guidance measure in Section 3. Consequently, we have removed the second proposed measure on security testing and incorporated it into paragraph 13.4 of Section 2.

Stakeholders’ comments on additional costs

As part of the consultation, we provided the opportunity for public telecoms providers to let us know of any additional costs for their businesses they foresee from implementing the proposed new/amended measures proposed in Section 3 (questions 3.1 to 3.22).

We asked:

• Q4.1 - Provide an estimate of any additional costs related to the implementation of the new/amended measures proposed in Section 3. If possible, break these costs down with reference to each specific measure.
  
  These estimates should only reflect additional costs relating to the proposed measures. They should not include costs already incurred through implementing measures currently within the Code.

In response to feedback from the original consultation, we also provided Tier 1 and Tier 2 providers with an opportunity to provide further detail on cost estimates through the completion of an additional cost survey.

Summary of feedback

There was considerable variation in the scale of estimated costs across respondents. While most providers projected modest or moderate impacts across many of the proposed updates, a smaller number reported estimates many times higher. This spread suggests that costs may be highly sensitive to each provider’s starting position, with variation driven as much by internal network, systems and infrastructure characteristics and interpretations of the Code as they are by the proposed updates themselves.

In line with the above, respondents indicated that while many proposed updates would generate moderate and more manageable uplifts, a small number of areas would drive significant cost pressures. These were primarily linked to: 

Business Support Systems - The inclusion of business support systems in paragraph 1.2 of the Code was cited by some providers as a proposed amendment which would incur significant additional costs. It was suggested the included definition of the term was too broad, and its inclusion in paragraph 1.2 would, consequently, bring a wide range of IT systems into scope of the guidance that are not relevant to network security.

Shared sites - The proposed inclusion of the term ‘shared sites’ in paragraph 2.97 was also identified by some providers as a potentially expensive and burdensome amendment. Some providers suggested this proposed amendment could impose significant cost and operational burdens on shared‑infrastructure and core deployment.

Patching and updates - Proposed guidance suggesting equipment should be restarted at least monthly was consistently cited as costly, and several providers noted the risk of service disruption, which would require additional staff and contingency planning.  

Signalling security - Proposed new guidance and measures on signalling security were widely described as structurally expensive. This was largely due to proposed guidance suggesting providers should implement an independent Intrusion Detection System, and undertake biweekly reviews of number analysis reference data.

Protection of data and network functions - Costs in this area were driven by encryption requirements, privileged access workstation (PAW) implications for third-party engineers, and the need to apply sensitive data protections across a broader scope of systems.

Third-party supplier measures - Respondents highlighted costs arising from the need to tighten supplier access controls, deploy secure workstations for external staff, conduct more rigorous supplier assessments, and incorporate new requirements into procurement workflows. This was particularly notable for providers with extensive or complex supply chains.  

Implementation timeframes - Many respondents highlighted implementation timeframes for proposed new measures as a consistent and material driver of cost across responses, and suggested estimated costs would be significantly lower if delivery could be spread over a longer period.

Scaling across extensive networks - Some responses highlighted challenges in scaling some elements of the proposed new guidance and measures across extensive networks, meaning relatively modest guidance can become expensive.

Government response

We have carefully considered all cost-related feedback received, both through the original consultation and the subsequent cost survey circulated to Tier 1 and Tier 2 providers.

As set out above, estimated costs varied considerably across respondents. We have reviewed this feedback in detail, balanced differing views from providers, and made a range of further amendments to the draft updated Code in response. These amendments are intended to ensure the proposed updates are appropriate and proportionate.

Detail on the further amendments we have made in response to feedback, including where they relate to cost estimates cited by providers, has already been set out in detail in the preceding sections of this government response. However, some specific amendments we have made in response to feedback to reduce perceived costs where appropriate are repeated here. These amendments include but are not limited to:

• Removing the proposed reference to ‘Business Support Systems’ in paragraph 1.2, reverting the language in that paragraph to that used in the original Code.
• Removing the proposed reference to ‘shared sites’ in paragraph 2.97 (as an example of equipment that is normally considered part of the exposed edge), reverting the language in that paragraph to that used in the original Code.
• Removing the proposed reference to restarting network equipment ‘at least monthly’ in paragraph 11.6 of the Code, and replacing the language with a less prescriptive frequency.
• Loosening wording on signalling related to an intrusion detection system (IDS) to state that outgoing signalling traffic ‘could’ be checked by deploying an IDS, and removing the proposed new measure in Section 3, which suggested public telecoms providers should implement an IDS. In addition, amending the frequency of language relating to reviewing number analysis reference data, to state that this should be done ‘regularly, with an appropriate frequency commensurate to the risk’.
• Reviewing and amending implementation timeframes, following feedback from providers. This has included making a range of amendments, set out in this document, which extend several of the proposed timeframes significantly from those originally proposed in the consultation.

Glossary definitions

We proposed several new definitions to the glossary within the Glossary in Annex A of the Code. These additions were proposed mostly in response to industry feedback, or to support the guidance and measures that we are proposing to add in the Code. Where possible, these definitions replicate existing definitions in guidance or legislation.

We asked:

• Q5.1 - Do you agree with the new definitions added to the Annex A? If no, explain why and propose alternative definitions (if possible).

Summary of feedback

A large number of respondents either did not provide feedback on the proposed amendments to the definitions in Annex A or stated that they supported the proposed amendments. Where respondents did provide feedback on the proposed amendments in the Annex, they covered a wide range of glossary definitions.

Government response

The government has carefully reviewed the definitions of certain terms used in the Annex, in light of the feedback received. As explained above, where we think it is appropriate to do so, we have amended a range of definitions in direct response to the feedback.

Vendor Security Assessment (VSA) extracts

Guidance in the Code (paragraphs 6.30–6.36, measures M4.02 and M10.36) refers to Vendor Security Assessment extracts within Annex B of the document.  We proposed to add a new section to this Vendor Security Assessment annex – ‘V.K – business continuity and disaster recovery (BCDR) planning’.

We proposed adding this section due to the increase in reliance on third parties when it comes to ensuring continuity of service. This addition has been designed to broadly reflect the requirements in the Telecommunications (Security) Act 2021 and the Electronic Communications (Security Measures) Regulations 2022 that are placed on the public telecoms providers themselves.

We asked:

• Q5.2 - Do you agree with the additions to Annex B? If no, explain why.

Summary of feedback

A relatively small number of respondents provided feedback, with most supporting the proposed addition.

Where concerns were raised, respondents emphasised that the VSA is guidance rather than a compliance framework and requested that this be made clear in its inclusion within the Code.

Some respondents also queried the rationale for including business continuity and disaster recovery planning specifically and asked for further clarity on why we proposed including them.

Government response

We proposed the inclusion of V.K – business continuity and disaster recovery planning to emphasise the importance of supply chain security in overall network security. Recent high-profile incidents in other sectors, such as Toyota’s temporary production shutdown following a cyber-attack on a key supplier, illustrate the potential impact of supply chain vulnerabilities on business operations.

We acknowledge feedback suggesting it should be clear that the VSA is guidance rather than a compliance framework. We would highlight that the proposed note added under the section entitled ‘Summary of approach to assessment’ at the beginning of Annex B already states: ‘vendors cannot pass, fail, or comply with the Vendor Security Assessment, nor is this a tick box exercise’. We have also already specified in that note that the vendor can only provide answers to the questions relevant to the service/product being procured to enable the public telecoms provider to make an informed, risk-based decision.

In light of the limited feedback received, we have not made any further amendments to this section.

Cyber Assessment Framework (CAF) extracts

Guidance in the Code (paragraph 9.9 and measures M5.01, M22.01 and M22.02) refers to the extracts from the Cyber Assessment Framework set out in Annex C of the document. The information included in this annex was initially taken from the NCSC’s Cyber Assessment Framework (CAF) Version 3.1, which was published on 11 April 2022.

Since the publication of the Code, this framework has been updated multiple times. We proposed to make amendments to the CAF annex (Annex C) to reflect the current version of the CAF (Version 4.0, which was published on 6 August 2025).

We asked:

• Q5.3 - Do you agree with the additions to Annex C? If no, explain why.

Summary of feedback

Respondents provided a wide range of views on the proposed amendments to Annex C.

Several providers suggested ways to strengthen alignment between the Code and the CAF, including proposing a new measure that would require providers to review updates to the CAF on an annual basis.

Some respondents questioned the rationale for incorporating certain elements of the CAF while excluding others, with a number recommending that Annex C should instead reflect the full CAF in its entirety.

Feedback also varied regarding the impact on scope. While some providers felt that the proposed amendments would broaden the scope of Annex C, others considered that the changes would narrow it.

Government response

Where guidance in the Code expects public telecoms providers to refer to the certain sections of the CAF, we consider it appropriate to annex those sections in the Code. This should facilitate public telecoms providers’ adherence to the Code by ensuring that it is clear on the face of the document which CAF measures are intended to supplement the Code measures (so that public telecoms providers can refer to the Code as a standalone document). In addition, this approach should be in line with the parliamentary scrutiny required under section 105F of the Communications Act 2003, as amended by the Telecommunications (Security) Act 2021, since we cannot make changes to the Code without laying the updated Code before Parliament.

Therefore, we do not consider it appropriate to include a measure in Section 3, or guidance in Section 2, that expects public telecoms providers to have regard to a ‘live’ version of the CAF that may be updated separately to the Code.

However, this does not prevent providers from considering or applying CAF guidance as it evolves. We would encourage public telecoms providers to do so where they find it helpful in strengthening their security practices.

In developing the proposed amendments to Annex C, we have included the elements of the CAF that we consider most relevant to the telecoms sector specifically. We note that the Code already contains substantial guidance relating to supply chain security, and we consider this to meet the needs of the sector.

We would also emphasise that both the Code guidance and the CAF extracts set out in Annex C are intended to give guidance rather than creating a compliance obligation.

Next Steps

• The draft updated Telecommunications Security Code of Practice will be laid in Parliament in due course. This is in accordance with Section 105F of the Communications Act 2003.
• If neither House resolves against the draft updated Code of Practice within the 40-day period, it will then be issued and published in final form.

Annex – Responder Organisations

The following organisations and representative bodies responded to the consultation:

• Amazon Web Services
• BT
• Business Secure
• Chartered Institute of Information Security (CISEC)
• Chartered Institute of Internal Auditors (CIIA)
• Cisco
• Colt
• Daintta Ltd
• Darktrace
• Ericsson
• Exa Infrastructure
• Federation of Communications Services (FCS)
• Gamma Telecom Ltd
• Independent Networks Cooperative Association (INCA)
• InfoBlox
• Internet Service Providers Association (ISPA)
• Joint Operator Technical Specification Forum (JOTS)
• London Internet Exchange (Linx)
• Open Fibre Networks Ltd (OFNL)
• Palo Alto Networks
• Platform X Communications (PXC)
• Sky
• Substantial Group
• Tech UK
• Thales DIS
• Twilio
• VMO2
• VodafoneThree
• Voxyonder
• Zayo Europe

1. National Cyber Security Centre (NCSC) Annual Review. ↩

2. Global System for Mobile Communications Association (GSMA) - The Impact Of Cybersecurity Regulation On Mobile Network Operators. ↩

3. Tier 1 – public telecoms providers with relevant turnover in the relevant period of £1bn or more. ↩

4. Tier 2 – public telecoms providers with relevant turnover in the relevant period of more than or equal to £50m but less than £1bn. ↩

5. Section 105Z(4)(b) of the Communications Act 2003. ↩

6. Section 105I of the Communications Act 2003. ↩

7. Ofcom’s Guidance on the provision of Calling Line Identification facilities and other related services (29 July 2024) and Ofcom’s Good practice guide to help prevent misuse of sub-allocated and assigned numbers (15 November 2022). ↩

8. Ofcom’s Guidance for number range holders to prevent misuse of Global Titles, 22 April 2025. ↩

9. Cyber Security (CYBER); Privileged Access Workstations; Part 1: Physical Device
   
   Cyber Security (CYBER); Privileged Access Workstations; Part 2: Connectivity
   
   Cyber Security (CYBER); Privileged Access Workstations; Part 3: System Integration. ↩

10. Principles for secure privileged access workstations (PAWs) ↩

11. National Cyber Security Centre, Risk management - Threat modelling ↩