Draft Revised Telecommunications Security Code of Practice

Question 1

Structure of the Code of Practice

Accepted Answer

This Code of Practice contains 3 sections:

Section 1 contains introductory and background information on the Code of Practice, including its legal status within the new telecoms security framework, how it applies to public telecoms providers, and its oversight by public authorities.
Section 2 explains the key concepts that need to be understood by all public telecoms providers when applying the specific security measures contained within the Electronic Communications (Security Measures) Regulations 2022 (hereafter referred to as ‘the regulations’) and by public telecoms providers when applying the technical and procedural measures within Section 3 of the Code of Practice, in accordance with the tiering system outlined in paragraphs 0.13-0.18 below.
Section 3 contains technical and procedural measures and maps each individual guidance measure to the relevant security measures in the regulations. It also sets out the implementation timeframes for the technical and procedural measures, which certain public telecoms providers are expected to follow.

Question 2

Section 1: Introduction and background

Accepted Answer

Introduction

0.1 The government’s UK Telecoms Supply Chain Review Report (‘the Review’), published in July 2019, highlighted the security risks as well as the economic opportunities associated with the next generation of telecommunications networks, particularly 5G and full fibre networks.^{[footnote 1]} The Review concluded that existing frameworks were no longer fit for purpose or driving the right behaviours, therefore a new robust security framework was needed for the UK telecoms sector, marking a significant shift to a risk-based approach.

0.2 Since the Review was published, the government has put this recommendation into action, developing a new security framework for providers of Public Electronic Communications Networks or Services (PECN/PECS)^{[footnote 2]} through the Communications Act 2003 (‘the Act’) as amended by the Telecommunications (Security) Act 2021 (‘the TSA’). This security framework, set out in the amendments to the Act, the regulations and this Code of Practice, has been drafted by the government, taking into account its obligations under international law. The regulations and Code of Practice have been informed by a public consultation.

0.3 This new revision of the Code of Practice aims to refine the language and incorporate updates to address new threats and technological advancements. It also reinforces the expectation that public telecoms providers adopt a comprehensive, risk-based approach to security.

0.4 The framework established through the TSA comprises 3 layers:

i) Strengthened overarching security duties on public telecoms providers. These are set out in new sections 105A and 105C of the Act as amended by the TSA.
ii) Specific security measures (hereafter referred to as ‘requirements’). These are set out in the Electronic Communications (Security Measures) Regulations 2022 (‘the regulations’) and detail the specified measures to be taken in addition to the overarching duties in the Act.
iii) Technical guidance. This Code of Practice provides detailed guidelines to large and medium-sized providers of PECN or PECS (hereafter referred to as ‘public telecoms providers’) on the government’s preferred approach to demonstrating compliance with the duties in the Act and the requirements within the regulations.

Technical analysis

0.5 The technical content of this Code of Practice is based on draft guidance developed by experts in the National Cyber Security Centre (NCSC). That guidance was produced following an extensive and detailed analysis of the security of the telecoms sector. It contained a set of technical and procedural measures designed to ensure that security risks are appropriately managed by the providers of PECN and PECS.^{[footnote 3]}

0.6 It is intended that public telecoms providers shall adopt a holistic approach, taking into account the whole Code of Practice, and not just specific parts of it when assessing their risks. As part of this approach, public telecoms providers shall consider the physical^{[footnote 4]} and personnel^{[footnote 5]} security of their PECN and PECS and the implications of future advances in technology. Given cyber security threats and the tools available for cyber security evolve over time, referring to further advice and guidance published from time to time on the NCSC website is likely to assist public telecoms providers in keeping pace with best practices.

Roles and responsibilities of public authorities

0.7 Government: The government is responsible for setting and overseeing national policy on telecoms security and resilience. The government will keep the effectiveness of the telecoms security framework under review, and develop it further as new threats emerge. In doing so, it will be supported by Ofcom through its regular reporting on security to the Secretary of State under section 105Z of the Act, as amended by the TSA.

0.8 Ofcom: Ofcom will regulate the new framework in accordance with its general duty in section 105M of the Act to seek to ensure that public telecoms providers comply with their security duties. This gives Ofcom a clear remit within the new framework to work with public telecoms providers to improve the security of their public networks and services and monitor their compliance.

0.9 The Act (as amended by the TSA) gives Ofcom the ability to monitor and enforce industry compliance with its new legal obligations in the telecoms security framework. It also gives Ofcom new powers to request information from public telecoms providers in order to carry out its functions.

0.10 The NCSC: As the UK’s national technical authority for cyber security, the NCSC will be able to provide expert and impartial advice when requested by Ofcom. The NCSC and Ofcom have consistently worked closely on security matters, and they have agreed a Memorandum of Understanding.^{[footnote 6]} This Memorandum contains information on the roles of the respective organisations and how they will work together and share information with each other as part of the new security framework.

0.11 The NCSC will also continue to offer technical advice to public telecoms providers. However, the NCSC will not report public telecoms providers to Ofcom in cases of non-compliance or advise public telecoms providers on whether the measures they are taking amount to regulatory compliance. It is for each individual public telecoms provider to interpret and act upon the obligations placed upon them. Determinations regarding compliance with regulatory requirements remain solely the responsibility of Ofcom.

Scope of the Code of Practice

0.12 This Code of Practice provides guidance for large and medium-sized public telecoms providers whose security is most crucial to the effective functioning of the UK’s telecoms critical national infrastructure (CNI). However, other public telecoms providers could choose to adopt any aspects of the guidance that they consider would be appropriate to secure their networks and services.

The tiering system

0.13 To ensure security risks are mitigated proportionately, the Code of Practice includes a tiering system which sets out the different expectations on public telecoms providers.

0.14 The tiering system places public telecoms providers in 1 of 3 tiers, based on their commercial scale:

i) Tier 1 – public telecoms providers with relevant turnover in the relevant period of £1 billion or more;
ii) Tier 2 – public telecoms providers with relevant turnover in the relevant period of more than or equal to £50 million but less than £1 billion;
iii) Tier 3 – public telecoms providers whose relevant turnover in the relevant period is less than £50 million, but who are not micro-entities.

Application of the tiering system

0.15 The guidance set out in this Code of Practice is intended to apply to public telecoms providers in the following way:

The measures in the Code of Practice apply to the largest national-scale (Tier 1) public telecoms providers, whose availability and security is critical to people and businesses across the UK. We intend these public telecoms providers to implement measures to the timeframes set out for Tier 1 providers in Section 3.
The measures in the Code of Practice also apply to medium-sized (Tier 2) public telecoms providers. They will have more time than Tier 1 public telecoms providers to implement some of the measures set out in Section 3.
The smaller (Tier 3) public telecoms providers are not expected to follow the measures in the Code of Practice. However, they may choose to adopt the measures included within the Code of Practice where these are appropriate and proportionate to their networks and services.

0.16 Although the measures are intended to address the risk of security compromises to PECN/PECS, providers of private networks may wish to adopt the measures included within the Code of Practice, where applicable

Explanation of terms

Relevant turnover: ‘Relevant turnover’ for the purposes of the tiering system is defined as turnover made from any ‘relevant activity’ carried out wholly or partly in the UK after the deduction of sales rebates, value added tax and other taxes directly related to turnover. Relevant activity means any of the following:

the provision of electronic communications services to third parties;
the provision of electronic communications networks, electronic communications services and network access to communications providers; or
the making available of associated facilities to communications providers.

This is the same as the definition used in the setting of Ofcom’s administrative fees, which is clarified in Ofcom’s guidance^{[footnote 7]}.

Relevant period: It is necessary to consider the relevant turnover of a provider generated during the relevant period to determine their tier in any given reporting cycle. We intend that the ‘relevant period’ will be the twelve-month period commencing on 1 January in the last but one calendar year prior to the reporting cycle in question. So, for example, the relevant turnover generated in 2020 would be used to determine tiers in the 2022/2023 reporting cycle. This approach aligns with Ofcom’s approach to the collection of equivalent data for administrative fees, which should reduce the burden on stakeholders.

Providers moving tiers

0.17 For the purposes of applying guidance set out in the Code of Practice, an existing tier designation will apply to a provider until the provider has been outside of their existing tier’s range for at least 2 years.

0.18 This approach will ensure that changing tiers will reflect a true change in the growth or reduction of a provider’s business operations, rather than seasonal or other short-term changes in relevant turnover.

Legal status of the Code of Practice

0.19 The Code of Practice provides detailed technical guidance to public telecoms providers on the measures to be taken under sections 105A to 105D of the Act. The processes for issuing, revising and withdrawing codes of practice are set out in new sections 105F and 105G of the Act and the legal effects of codes of practice are detailed in section 105H.

Non‑compliance with the guidance measures in the Code of Practice

0.20 The guidance set out in this Code of Practice is not the only way for public telecoms providers to comply with the new security duties and specific security requirements that have been placed into law. We appreciate that where the regulations require public telecoms providers to take ‘appropriate and proportionate’ measures, what is appropriate and proportionate will depend on the particular circumstances of the public telecoms provider.

0.21 A public telecoms provider may choose to comply with those new security duties and specific security requirements by adopting different technical solutions or approaches to those specified in the Code of Practice. 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 of Practice in order to assess whether they are still meeting their legal obligations under the security framework. Public telecoms providers are obliged to explain those reasons to Ofcom under section 105I of the Act, where Ofcom has reasonable grounds for suspecting the public telecoms provider is failing or has failed to comply with the Code of Practice.

0.22 In determining any question arising in connection with the carrying out by Ofcom of a relevant function, Ofcom must also take into account the provisions in the Code of Practice where they are relevant and in force at the time in which the question relates to (see section 105H(3) of the Act).

0.23 In determining any question arising in legal proceedings, courts and tribunals must take the provisions in the Code of Practice into account where they are relevant and in force at the time in which the question relates to (see section 105H(2) of the Act).

Non‑compliance with the new security duties in the Act and/or requirements in the regulations

0.24 In cases of non-compliance with the new security duties and/or specific security requirements, Ofcom will be able to issue a notification of contravention to public telecoms providers setting out that they have not complied, and any remedial action to be taken. Ofcom also has the ability to direct public telecoms providers to take interim steps to address security gaps during the enforcement process.

0.25 In addition, in cases of non-compliance, including where a provider has not complied with a notification of contravention, Ofcom can issue financial penalties. The size of the financial penalties that Ofcom can impose in those instances has been updated through the TSA.

0.26 Further information on how Ofcom will use its powers and regulate the framework will be contained within its procedural guidance^{[footnote 8]}.

Implementation timeframes

0.27 Whilst the security duties, requirements in regulations and Ofcom oversight powers that form the new telecoms security framework came into force on 1 October 2022, it would not be proportionate to expect public telecoms providers to be in a position to meet all their obligations from that date. Instead, specific recommended compliance timeframes for individual measures are contained within this Code of Practice. These are the timeframes by which public telecoms providers would be expected to have taken relevant measures set out in the Code of Practice, whilst recognising that due to the existing threat environment, the quicker public telecoms providers are able to implement measures the better.

0.28 It would not be appropriate, proportionate, or technically feasible, to expect public telecoms providers to implement all measures at the same time. The timeframes within this document reflect which guidance measures are most important and/or most straightforward to implement first, and which guidance measures may require more time to implement. This does not preclude public telecoms providers from implementing measures before these dates where it is prudent to do so, and this should be actively encouraged where possible.

Implementation timeframes and the tiering system

0.29 For the majority of measures, the timeframes are the same for Tier 1 and 2 public telecoms providers. However, a subset of the most straightforward measures have a shorter timeframe for Tier 1 public telecoms providers in recognition of the fact that smaller public telecoms providers will have fewer resources and may need more time to implement measures.

0.30 Tier 3 public telecoms providers must continue to take appropriate and proportionate measures to comply with their new duties under the Act and the regulations. The regulations do not apply to micro-entities^{[footnote 9]}. Tier 3 providers may choose to adopt the measures in the Code of Practice where these are relevant to their networks and services. The government may choose to issue specific guidance for Tier 3 providers in the future.

Providers changing tiers or entering the market

0.31 There may be occasions when public telecoms providers either change tiers, or new public telecoms providers enter the market. Subject to the condition set out in paragraph 0.17 for existing providers, public telecoms providers will be expected to follow the same timeframes as existing providers in their tier, irrespective of how recently they joined that tier.

Updating the Code of Practice

0.32 The government intends to review and update the Code of Practice periodically as new threats emerge and technologies evolve. Proposed updates will most likely be informed by 3 broad categories of information:

security advice provided to the government by the NCSC that sets out where these new threats and vulnerabilities lie, based on its analysis and intelligence;
evidence from public telecoms providers of new vulnerabilities uncovered by continued and expanded security testing, as well as new incident reporting on security compromises; and
security reports prepared by Ofcom after the end of each reporting period, containing information and advice that will assist the government with forming policy. The first reporting period for Ofcom is 2 years following commencement of section 11 of the Act with subsequent reporting periods taking place 12 months thereafter. The security report will include information about the extent to which public telecoms providers have acted in accordance with the Code of Practice. Access to this information will enable the government to determine how well the new framework is working and help identify where changes to the Code of Practice need to be made.

0.33 Where changes to the Code of Practice are proposed, the government will consult affected public telecoms providers, Ofcom and any other relevant parties. All proposed changes, regardless of their source, will be discussed with the NCSC before being incorporated into this Code of Practice. Where the Code of Practice is revised (and issued as a revised document), the Secretary of State will lay a draft copy of it before Parliament for scrutiny.

0.34 This current version of the Code of Practice therefore provides guidance as to the measures to be taken by relevant public telecoms providers under sections 105A to 105D of the Act, unless revised or withdrawn by the government.

Further information

0.35 There are various documents that can be used to further understand the wider telecoms security framework and policy background of the Code of Practice. These include:

NCSC security analysis for the UK telecoms sector^{[footnote 10]}
The Telecommunications (Security) Act 2021^{[footnote 11]}
The Electronic Communications (Security Measures) Regulations 2022^{[footnote 12]}
Ofcom’s Network and Service Resilience Guidance^{[footnote 13]} - Product Security and Telecommunications Infrastructure Act 2022^{[footnote 14]}

Question 3

Section 2: Key concepts

Accepted Answer

Overarching key concepts

1.1 There are certain key concepts that are relevant to the guidance measures set out in this Code of Practice and requirements contained in the regulations. It is important that all public telecoms providers fully understand these key concepts as it will enable them to properly meet the intent of the security requirements. This chapter covers the concepts of Security Critical Functions and Network Oversight Functions which apply throughout, as well as the overarching scope of the Code of Practice.

Explanation of terms

Where the term ‘reduce’ is used in the regulations, it is expected that the public telecoms provider will reduce the risk as far as possible.

The terms ‘shall’, ‘should’ and ‘may’ have been defined in relation to the guidance given in the remainder of the Code of Practice. This is to distinguish between where the government believes there is likely to be only one acceptable way of implementing the specific measure, and those which have potential alternatives.

Shall: The use of the word ‘shall’ indicates where government guidance is that there is likely to only be one viable technical solution to secure the network or service in line with the regulations. We would not expect these technical solutions to vary as a result of different network configurations or business structures.

Should: Where the word ‘should’ is used in the guidance the government views the solution provided as being the best way to implement the measures in the majority of cases. However, there are known alternatives that public telecoms providers could possibly deploy, depending on their network or service configurations and business structures, which could attain a satisfactory security outcome.

May: The use of the word ‘may’ in the guidance indicates that public telecoms providers are likely to have multiple options, all of which could deliver a satisfactory solution and there are likely to be differences between public telecoms providers in their implementation.

Scope of measures within the Code of Practice

1.2 Measures contained within Section 3 of the Code of Practice apply to public telecoms providers and their PECN/PECS^{[footnote 15]}. This includes, but is not limited to, the following elements where they are part of such networks and services:

the systems and services involved in providing public telecommunications services to customers;
proof of concepts or trials on the operational network;
the use of data from the operational network for testing purposes;
interconnection of development, test and operational systems – although this is an activity which is not appropriate in all scenarios;
parts of the operational network operated by third parties on behalf of the provider, including as part of managed service arrangements;
parts of the operational UK network hosted outside the UK; and
networks supporting the operation of the live network, where these supporting networks can have a material impact on the proper functioning of the operational network.

Security Critical Functions

1.3 A ‘Security Critical Function’ in relation to a PECN/PECS means “any function of the network or service whose operation is likely to have a material impact on the proper operation of the entire network or service or a material part of it” (Regulation 2). For example, dependent upon network architecture, a small cell could be considered a Security Critical Function if its failure is likely to have a material impact on the network capacity or coverage of a material part of the network or service. Similarly, automation functionality and any function that is likely to have a material impact on the data encryption used in the conveyance of signals are both likely to be Security Critical Functions. This is because the operation of automation functionality (especially where it can influence the confidentiality, integrity and/or availability of the network or service, as noted in paragraph 2.69 below) and data encryption are likely to have a material impact on the proper operation of the entire network or service or a material part of it.

1.4 Security critical functions will therefore make up different proportions of networks or services, the specific details being dependent on the unique operating mode of each individual network. However, Security Critical Functions will include a broad range of essential functions within the network that could impact its proper operation and not simply those whose primary function is security. The guidance in this Code of Practice sets out specific protections targeted at different functions of networks and services that may be considered critical. It does not seek to exhaustively define components as critical.

1.5 When deciding which functions of the network or service could not be considered as security critical, public telecoms providers should be able to demonstrate (for example with a risk assessment or threat model) that these individual functions do not have a material impact on the proper operation of the entire network or service, or a material part of it.

Network Oversight Functions

Scope

1.6 Network Oversight Functions are the components of the network that oversee and control the Security Critical Functions, which make them vitally important in overall network security. They are essential for the public telecoms provider to understand the network, secure the network, or to recover the network. Scope will differ from provider to provider depending on the type of network and how those networks are architected. For example, automation functionality is likely to be a Network Oversight Function (in addition to a Security Critical Function), because its operation is likely to have a material impact on the proper operation of the entire PECN/PECS or a material part of it, and it normally oversees and controls other Security Critical Functions.

1.7 Given their importance in allowing the public telecoms provider to maintain control of the network, Network Oversight Functions are more likely to be targeted for a security attack and the impact of their compromise is greater.

1.8 Network Oversight Functions include, but are not limited to, the following components of the network where such components oversee and control Security Critical Functions:

element managers;
virtualisation orchestrators;
management systems (e.g. jump boxes);
security functions (e.g. firewalls at the edge of a security zone);
root authentication services (e.g. active directories (ADs));
multi-factor authentication services;
security gateways (e.g. supporting the management plane);
audit and monitoring systems (including network quality monitoring of speech and data); and
Operational Support Systems (OSS).

Guidance

1.9 Best security practices should be implemented for Network Oversight Functions. This includes hardening and rapid patching on release of a security update, including a phased rollout. It also includes rigorously controlling and minimising the attack surface of the function. This could include limiting the accessible interfaces, removing access to third parties, or reducing the number of users with administrative access.

1.10 Wherever possible, more modern security practices should first be implemented in Network Oversight Functions as they are likely to benefit most from these enhanced protections. Specific recommended compliance timeframes for individual measures are contained within Section 3 of this document.

The principle of ‘assumed compromise’

1.11 Public telecoms providers should establish the principle of ‘assumed compromise’. This means that public telecoms providers should normally assume Network Oversight Functions to be subject to high-end attacks, which may not have been detected by the public telecoms provider, and implement business practices which, by their nature, make it difficult for an attacker to maintain covert access to these functions. This can be achieved through establishing secure platforms which implement trusted boot and periodically rebuilding the functions to an up-to-date known-good state.

Management functions for Network Oversight Functions

1.12 In addition, given that security compromises affecting Network Oversight Functions are likely to have a significant impact on the proper operation of the network, the management functions used to manage Network Oversight Functions should have enhanced protections, including using dedicated management functions, a segregated management plane and an enhanced control set.

Approach to monitoring and analysis

1.13 Under Regulation 6, public telecoms providers must take such measures as are appropriate and proportionate to monitor and analyse both access to Security Critical Functions and their operation and investigate any anomalous activity. Given the essential role of Network Oversight Functions, the use of these functions and the systems that manage them should be subject to an enhanced level of monitoring. This should include real-time monitoring of changes to Network Oversight Functions and monitoring for signs of attack and/or compromise before potential exploitation, as well as exploitation itself.

1.14 In addition, when public telecoms providers start performing security analysis to establish the ‘normal behaviour’ of their networks in order to be able to identify and investigate any anomalous activity, they should prioritise the analysis of the behaviour of Network Oversight Functions.

Example of how Network Oversight Functions work with Security Critical Functions

1.15 An example of how Network Oversight Functions and Security Critical Functions can work together in the context of virtualisation workloads is set out below^{[footnote 16]}.

1.16 Typically, when building out the infrastructure to enable the running of virtualised workloads, a public telecoms provider will require:

a hypervisor – the operating system installed on the physical servers to enable them to run virtual machines (the combination of many hypervisors/physical servers/physical networking that links it all together is usually referred to as the ‘virtualisation fabric’);
physical servers to run the hypervisor;
the virtual workloads themselves; and
the virtualisation orchestration software that tells the virtual workloads on which servers to run.

1.17 If the virtual workload is a function whose operation has a material impact on the operation of the network, then the following would be Security Critical Functions:

the virtual workload itself;
orchestration software that establishes the virtual workload;
the hypervisor;
the physical servers on which the virtual workload runs.

In this case, the orchestration tooling would be the Network Oversight Function.

1.18 Because of their importance to overall network security, all Network Oversight Functions should normally be expected to fall within the definition of ‘Security Critical Functions’ set out in the regulations. However, not all Security Critical Functions can be considered as Network Oversight Functions as many do not control or oversee other Security Critical Functions.

Chapter crossovers

1.19 The information in this chapter is useful in understanding the following concepts described in subsequent chapters:

Network architecture (Chapter 2)
Protection of data and network functions (Chapter 3)
Monitoring and analysis (Chapter 5)
Supply chain (Chapter 6)
Prevention of unauthorised access or interference (Chapter 7)
Remediation and recovery (Chapter 8)
Governance (Chapter 9)
Reviews (Chapter 10)
Competency (Chapter 12)
Testing (Chapter 13)

2. Network architecture

2.1 This chapter provides guidance for public telecoms providers on the measures to be taken in accordance with Regulation 3 to design, construct (or where relevant, redesign and develop) and maintain networks securely.

2.2 Regulation 3 is set out below.

3.—(1) A network provider must take such measures as are appropriate and proportionate to ensure—

(a) except in relation to an existing part of the public electronic communications network, that the network is designed and constructed in a manner which reduces the risks of security compromises occurring,

(b) in relation to an existing part of the public electronic communications network, that the part is redesigned and developed in a manner which reduces the risks of security compromises occurring, and

(c) that the public electronic communications network is maintained in a manner which reduces the risks of security compromises occurring.

(2) For the purposes of paragraph (1), an existing part of a public electronic communications network is a part that was brought into operation before the coming into force of these Regulations.

(3) The duty in paragraph (1) includes in particular a duty—

(a) to identify and reduce the risks of security compromises to which the network as a whole and each particular function, or type of function, of the network may be exposed, having appropriate regard to the following—

(i) whether the function contains sensitive data,
(ii) whether the function is a security critical function,
(iii) the location of the equipment performing the function or storing data related to the function, and
(iv) the exposure of the function to incoming signals,

(b) to make a written record, at least once in any period of 12 months, of the risks identified under paragraph (a),

(c) to identify and record the extent to which the network is exposed to incoming signals,

(d) to design and construct the network in such a way as to ensure that security critical functions are appropriately protected and that the equipment performing those functions is appropriately located,

(e) to take such measures as are appropriate and proportionate in the procurement, configuration, management and testing of equipment to ensure the security of the equipment and functions carried out on the equipment,

(f) to take such measures as are appropriate and proportionate to ensure that the network provider—

(i) is able, without reliance on persons, equipment or stored data located outside the United Kingdom, to identify the risks of security compromises occurring,
(ii) is able to identify any risk that it may become necessary to operate the network without reliance on persons, equipment or stored data located outside the United Kingdom, and
(iii) if it should become necessary to do so, would be able to operate the network without reliance on persons, equipment or stored data located outside the United Kingdom.

(4) A network provider must retain any record made under paragraph (3)(b) or (c) for at least 3 years.

(5) A network provider or service provider must take such measures as are appropriate and proportionate to ensure that the public electronic communications network or public electronic communications service is designed in such a way that the occurrence of a security compromise in relation to part of the network or service does not affect other parts of the network or service.

Key concepts for understanding the requirements

2.3 The architectural and design decisions which are made when creating and modifying a public telecoms provider’s network or supporting systems are critical to the security of that network. This security architecture determines how difficult it will be to compromise or disrupt the system, the scale of any associated impact, and whether the public telecoms provider is likely to detect and recover from any compromise.

2.4 As an example, the security architecture determines the network’s attack surface from an attacker’s perspective. Specifically, the attack surface is the equipment (hardware, software, or firmware) and interfaces that the attacker can target from a given location. A mature security architecture will consider attackers to be located both externally and internally and configure the network into security zones which limit the attack surface, as well as lateral movement, appropriately based on risk. This can reduce the impact of a compromise.

2.5 Whilst a technical discipline in its own right, the security architecture is also fundamental to every other security measure described within this document. It determines the risk to equipment, and hence the necessary controls and protections.

2.6 Where public telecoms providers can show there was a demonstrable plan at commencement of the regulations for the removal of specific network equipment and it would not be proportionate for that network equipment to meet specific measures within the code, public telecoms providers shall be required to ensure compliance with their security duties by implementing those measures that remain proportionate, and by taking alternative measures as necessary, based on a detailed risk assessment. This may include earlier replacement of the network equipment with alternative equipment that mitigates the security risk. It is not appropriate to disregard the security of networks based on what may, or may not, happen to them in the future.

The management plane

2.7 The management plane of a network, system or device is the part of a system that configures, monitors and provides management, monitoring and configuration services to all layers of the network stack, and other parts of the system. There might be more than one management plane in a network, system or device.

Scope

2.8 The scope will differ from public telecoms provider to public telecoms provider but this guidance applies to management access to equipment within operational telecommunications networks, and to management access to equipment that supports the operation of telecommunications networks. Also in scope are the networks of third parties where those third parties perform management on the provider’s behalf, and any automated management systems, such as orchestrators and Operational Support Systems (OSS). Public telecoms providers retain responsibility and accountability for management and oversight when third parties are involved.

2.9 Specific solutions and platforms which achieve the security objectives surrounding the management plane are open for public telecoms providers to choose, as is the case for the rest of the security framework. The intention of this document is not to encourage or discourage the use of any specific services. It is important to ensure that any deployments consider relevant threats and risks, use appropriate mitigations and security controls in response, and that any residual risk is clearly articulated, understood and appropriately owned at board level.

Background

2.10 The management plane is the most powerful part of the network infrastructure, making it the primary target for any malicious attack intending to disrupt or otherwise compromise the operation of a network. Exploitation of the management plane could have a long-term impact on the availability and confidentiality of a public telecoms provider’s services, including critical services.

2.11 Attacks on the management plane tend not to be ‘noisy’, meaning that there may be no overt impact on the network. They may remain undetected by security monitoring tools, and they may be maintained for years, growing in scale and complexity over time.

2.12 As an example, on 17 August 2021 it was confirmed that T-Mobile was subject to a data breach which saw the personal data of nearly 50 million customers being exposed.^{[footnote 17]} Evidence has shown that this compromise may have been caused by T-Mobile having the management plane of the core network directly exposed to the internet. It has been indicated that the exposed box was test equipment that was attached to the operational network, and from the test equipment the attacker had access to the Local Area Network (LAN) and could brute force the password on operational servers. This enabled a single hacker to access customer data within a number of weeks.

2.13 Historical management of telecoms networks has relied heavily upon standard corporate devices ‘doubling up’ as administrative workstations. Consequently, the computers that perform standard ‘office’ type functionality such as email, web access and the use of productivity tools are also defining the operation of the network. This is often referred to as a ‘browse up’ architecture, as shown in Figure 1 and described in the security architecture anti-patterns publication by the NCSC^{[footnote 18]}

Figure 1: Example of ‘browse up’ architecture

2.14 A ‘browse up’ architecture brings with it significant risk. Where it is used, several ‘commodity’ classes of attack can be performed with relative ease upon administrative users, and these can achieve a significant impact. Several of these attack vectors exist (e.g. compromise via malicious websites and compromise via infected removable media) but the most notable being the possibilities afforded to an attacker via phishing or social engineering attacks. Compromise of privileged user accounts, whether targeted or otherwise, can result in:

credential loss (e.g. leading to unauthorised remote access or gathering of information for future exploitation);
remote code execution (enabling an attacker to gain a foothold on machines used for administrative use); or
further exploitation of networks or users (the potential to move laterally to other resources through use of privileged user accounts).

Guidance

2.15 Attacks via the management plane are likely to have a significant impact upon both the public telecoms provider and the UK and hence securing the management plane should be treated as a priority by public telecoms providers. The following guidance in paragraphs 2.16-2.29 highlights the key aspects of management plane security for public telecoms providers to understand in order to appropriately secure networks. The guidance also contains examples and further background information where appropriate. However, secure system administration is not solely a challenge within the telecommunications sector, and general advice on this problem can be found on the NCSC website.^{[footnote 19]}

Isolating the management plane

2.16 Given the risks, it is not appropriate for public telecoms providers to be using a ‘browse-up’ architecture. Instead, public telecoms providers shall architect, and operate, their management plane infrastructure to inhibit network compromise through administrative access.

2.17 Workstations dealing with general office productivity tools and external access to external services over the internet shall be logically or physically separate from those with any access to the management plane. Any administrative users who previously performed these functions via a single device will need to operate differently to protect their network.

2.18 As public telecoms providers prepare to isolate their management planes from corporate functions, it may help to consider their network infrastructure as divided by trust boundaries, as shown in Figure 2. This can help public telecoms providers ensure that anything that can impact the operational network cannot be compromised from the corporate network.

Figure 2: Example of ‘browse‑down’ architecture

2.19 To ensure the administrative networks are separated from corporate networks it will be necessary for separate enterprise services to be hosted within these networks.

Secure administration

2.20 Public telecoms providers will need to ensure that administration is performed securely, using effective authorisation, authentication and encryption. Public telecoms providers shall ensure that every administrative access is authorised, time-limited, and monitored, linking that administrative access to a specific purpose or ticket.

2.21 Whenever administrators are gaining an ability to impact the operational network, public telecoms providers shall ensure that Multi-Factor Authentication (MFA) is used as part of the authentication process. MFA would normally be performed as administrators access management platforms (jump boxes, orchestrators, etc) rather than individual hosts. The second factor should be generated or transmitted via a device separate to that being used to perform the administrative functionality. Public channels for delivery of the MFA token, such as SMS, are not appropriate for this use case.

2.22 Given that management traffic typically involves sensitive data and/or credentials being passed via these channels, it is essential that all management is performed over secure protocols. Third party suppliers with a mature approach to security will either provide equipment that is ‘secure-by-default’ on delivery, or will provide hardening guides to explain how to perform an effective lock down of the supplied network infrastructure. These should be followed to ensure the most secure variant of any given management protocol is used (for example SSH in preference to Telnet or HTTPS in preference to HTTP), any unnecessary ports and services are disabled, and that any insecure default settings, such as default credentials, are removed or changed.

2.23 To ensure that compromise of network equipment does not result in onward access to further equipment via the management plane, public telecoms providers shall restrict the ability of network elements to communicate with each other over the management plane. Network restrictions shall be put in place to ensure only equipment that needs to communicate is able to securely communicate over the management plane.

2.24 To protect management platforms (such as jump boxes, element managers, orchestrators, etc) from up-stream attacks from network equipment, the management plane shall be configured to ensure that only necessary connections are allowed. By default, the connections that should be allowed are those established from administrative functions to network equipment.

Third party administrators

2.25 Managed service providers (MSPs) or third party administrators (3PAs) are prime targets for attackers, as they will often have privileged access to multiple networks. Because of this, where these third parties have access to the management plane, they shall have to meet the same security principles as those employed by public telecoms providers themselves, and shall use the same methods.

2.26 MSPs and 3PAs are not required to have separate devices for each public telecoms provider that they support. As is the case for the provider themselves, MSPs, and 3PAs will need to use trusted Privileged Access Workstations (PAWs) for administrative activity that is isolated from external attacks and signals (see guidance in Chapter 3 and Chapter 6). Given a trusted device, MSPs and 3PAs can access securely-segregated management systems for multiple public telecoms providers. Critically, such an approach must maintain the security and integrity of the PAW, and segregation between each provider’s management environment.

2.27 It will be essential for public telecoms providers to have contractual arrangements in place which oblige MSPs and 3PAs to ensure that security controls are applied correctly. It will also be necessary to have robust powers of audit to permit spot-checks and ongoing monitoring of security governance arrangements. Public telecoms providers shall ensure they are able to fully control and monitor access by third parties into their management plane independently of the third party.

Read only access

2.28 For some administrative tasks, administrators only require read-only access to the management plane. While it may seem that such access is lower risk, this access continues to pose a risk to the network and therefore access shall be granted using a role-based, least privilege model. As network equipment commonly treats the management interface as trusted, it may be relatively trivial for a read-only administrator to gain the ability to modify equipment behaviour.

2.29 There remains a risk to network data and therefore the approach to be taken to support read-only accesses to network data is to use administrative tools to extract the necessary data from network equipment, and securely store this data away from the management plane via a cross-domain data transfer (see Chapter 3). This approach allows controlled access to network data without providing privileged access to the management plane, or necessitating the security controls associated with management plane access. It is important that this data is protected when transferred and stored.

Virtualisation and containerisation

2.30 Virtualisation refers to the creation of a virtual resource such as a server, desktop, operating system, file, storage or network.

Scope

2.31 Background information and guidance on virtualisation and containerisation in paragraphs 2.32-2.72 applies to public telecoms providers where they are making use of virtualisation or containerisation to abstract more than one piece of physical hardware from the operational software.

Background

2.32 Prior to the emergence of virtualisation, network functions ran on their own dedicated hardware. Security controls were defined during design, and it was unlikely that these controls would change significantly throughout the equipment’s lifetime. Virtualisation allows for greater flexibility. Operationally it allows services to scale up and down easily. In terms of network security, additional security controls can be added, interfaces can be monitored, or processes can be inspected without affecting on-going services.

2.33 Virtualisation generally establishes two architectural layers;

the virtual functions or virtual instances (usually a set of applications and operating systems);
the ‘virtualisation fabric’ or virtualisation platform, made up of a hardware abstraction layer, such as a hypervisor, and the physical servers and networking equipment used to host the virtualised workloads.

2.34 For the purposes of this document, ‘virtualisation’ is considered to be a system supported by a hypervisor, as shown in Figure 3. Hypervisors run directly on a host machine’s physical hardware and provide a fully abstracted layer between virtual workloads running within the hypervisor and the physical hardware’s resources.

2.35 Virtualisation can be an effective tool for improving the security of a system. By enforcing separation between workloads, it can help prevent lateral movement. By abstracting the hardware, it can allow for better inspection of system behaviour and make the compromise of hardware more complex for an attacker. Virtualisation should also make a system more flexible, allowing security updates and improvements to be implemented more quickly.

2.36 However, in virtualised networks the integrity of the virtualisation fabric becomes critical. Compromise of the virtualisation fabric could result in the compromise or disruption of all workloads supported by that fabric. Virtualised networks are also highly configurable. While this is a strength, public telecoms providers should be aware that the configuration of the virtualised environment can undermine its security properties.

2.37 In comparison, containerisation provides no hardware abstraction, but does provide a quick deployment and scaling opportunity to public telecoms providers by packaging applications within a single host operating system (as shown in Figure 3). Access to resources is limited by the host operating system, but hardware resources are not abstracted, meaning the security benefit is limited.

Figure 3: Example of containers

Hypervisor	No Hypervisor
A trust boundary exists between the Virtual Machines (VMs) - providing there is appropriate network separation. We have confidence in the security of the hypervisor providing it is fully patched. A host (or cluster of hosts) can be used to run workloads at different trusts levels	If you choose to run ‘bare metal’ containers - i.e. where containers are run directly on the host Operating System. You no longer have a trust boundary in software. Containers do not provide security separation. To run workloads across different trust boundaries a physical separation would be required.

2.38 Containerisation is viable for sharing and scaling workloads within the same security zone or trust domain. However, public telecoms providers should assume that an attacker with access to one container will be able to compromise the host and all the other containers supported by that host. Therefore, containers should never be considered as, nor used as, a security boundary.

2.39 Both virtualisation and containerisation are sometimes used together. Virtualisation may be used to abstract the hardware. Containers are used to scale workloads within the virtual function, but never as a security boundary.

Guidance

2.40 Virtualisation security is an evolving subject, with new security solutions and design patterns emerging each year. The following guidance in paragraphs 2.41-2.72 highlights the key aspects of virtualisation security for public telecoms providers to understand and implement, providing examples and further background information where appropriate. When considering the guidance within the document, public telecoms providers should also consider the latest virtualisation security best practices. Public telecoms providers should also consider the importance of threat modelling their designs and understanding their trust boundaries. Additional advice on security design within virtualised environments can be found in the NCSC’s virtualisation security design principles^{[footnote 20]} and NCSC’s guidance on using containerisation^{[footnote 21]}.

Limiting the impact of host compromise

2.41 As previously noted, the compromise of a host within the virtualisation fabric poses a significant security risk to all virtual functions supported by the host. As it cannot be assumed that a host compromise will not occur, public telecoms providers shall ensure that it is possible to reduce the impact from, and recover from, a host compromise.

2.42 To limit the impact of host compromise, public telecoms providers should segregate both their virtualisation fabric and the virtual functions supported by that fabric. This ensures that the network’s security architecture is not undermined by the dynamic nature of the virtualisation.

2.43 For this reason, public telecoms providers will often break large host estates into groups based on risk. For the purposes of this document, these groups of hosts will be called host ‘pools’, an example of which is shown in Figure 4. All hosts within a pool should generally present a similar level of risk to the network. This risk may be based upon the host type, the security features of the host, or the host’s physical location. Hosts may also be pooled for resilience purposes to ensure that load-balancing workloads are in physically separate locations.

Figure 4: Virtualisation fabric broken into host ‘pools’

2.44 Similarly, virtual functions can be grouped based on risk, for example due to exposure, criticality or sensitivity. For the purpose of this document, these groups of virtual functions are called trust domains.

2.45 By associating trust domains with host pools, public telecoms providers can segregate their network, maintaining a physical security architecture within a virtualised network, as shown in Figure 5. These associations are sometimes known as ‘affinity rules’.

Figure 5: Segregating trust domains using host pools

Management of the virtualisation fabric

2.46 As a compromise of physical hosts within a virtualisation fabric would likely compromise many workloads, the administration of hosts is particularly sensitive. Access should be actively monitored and shall be limited to the smallest number of trusted administrators. The host’s network-accessible administration interfaces shall only accept connections from authorised management infrastructure.

2.47 It should rarely be necessary to directly administer physical hosts within an operational virtualised network, as most interaction should be performed by a central orchestration tool. This orchestration tool should be treated as a Network Oversight Function. For resilience and security reasons, this central orchestration tool should not be hosted on the virtualisation fabric that it manages. Should it be hosted within the fabric, this could impede recovery should part or all of the fabric fail or be compromised.

2.48 It is possible that physical Baseband Management Controllers (BMCs) or other integrated lights out (iLO) management interfaces are used to manage hosts. Such alternative administration networks should either use a dedicated network that is physically separated from the virtualisation fabric network or use a lights out management solution that supports secure management as detailed in this document.

A secure virtualisation fabric

2.49 In the event that a host is potentially compromised, public telecoms providers must be able to recover the integrity of the host infrastructure. As replacing the host hardware is expensive, public telecoms providers can instead return the host to a known-good state. This may be achieved where hosts support ‘secure boot’.

2.50 As part of a secure boot, physical hosts record their boot-up sequence from power on to hypervisor load. A hardware root-of-trust (e.g. Trusted Platform Module (TPM)) signs this record before it is sent to an attestation service. The attestation service can then assess whether the state of the physical host has changed. If not, this gives confidence to the public telecoms provider that the host can be trusted to host virtual functions.

2.51 Additionally, should the provider need to transfer hosts between host pools, a secure boot process can be used to give confidence to the provider that the host is ‘clean’ prior to performing the transfer. Public telecoms providers should avoid configuring the virtualisation fabric in such a way as to inhibit the migration of virtual machines as required.

Choosing virtual functions

2.52 Public telecoms providers should use virtual functions that are built for use within a virtualised environment as this provides significant security benefits. Network functions which are built to be virtual will run effectively on any virtualisation fabric or hypervisor and hence are likely to be more secure, avoiding platform-specific functionality or cut-throughs. They are likely to be more resilient, due to a lack of dependence on a specific platform. They also allow for the virtualisation fabric to be more secure, easily supporting migration between hosts to allow for updates and reconfiguration.

2.53 Pinning specific virtual network functions to specific hosts within the virtualisation fabric makes it significantly harder to update and patch those functions and hosts. As such, it should be avoided where possible.

2.54 Ideally, virtual functions will also support secure boot, using the trusted boot path provided by the underlying hosts and exposed securely to the virtual function via the hypervisor.

Authorising virtual functions

2.55 To prevent an attacker from running new virtual functions, or modifying existing virtual functions, only permitted virtual functions should be run by the virtualisation fabric. Public telecoms providers should achieve this by ensuring all virtual functions are signed and authorised by the provider and configuring the virtualisation fabric to verify virtual functions prior to operation.

Separating virtual functions

2.56 As previously stated, virtualisation provides an effective means to provide security separation for different virtual functions running on a single host. Where virtual functions are within separate virtual machines, enforced by a bare-metal hypervisor, it is reasonable for a public telecoms provider to assume that it would be difficult for an attacker to move laterally between these virtual machines via the virtualisation fabric, as long as controls such as the hypervisor are up-to-date and there are no known vulnerabilities or ‘cut-throughs’ in the hypervisor that can be exploited.

2.57 For this reason, it is possible for a single host pool to support multiple trust domains as the separation between the trust domains is maintained by the virtualisation fabric.

2.58 In general, containers do not provide sufficient security separation to be relied upon to segregate virtual functions. Public telecoms providers should assume that a virtual/physical host compromise or a container-to-container compromise is more likely in containerised environments. For this reason, all containers running on a single physical or virtual host should be within a single trust domain. Additionally, where the containers are running directly on a physical host, the host pool should be treated as less trusted.

2.59 Similarly, bare-metal hypervisors are sometimes configured to allow specific virtual machines to address physical hardware directly. These are known as hypervisor ‘cut-throughs’. Cut-throughs can have performance benefits, but they negate the security properties of the bare-metal hypervisor as a virtual machine is now able to directly access and control physical hardware without any of the hypervisor’s security controls. On hosts supporting cut-throughs, the virtual functions should all be within a single trust domain, and the host pool should be treated as less trusted.

2.60 This guidance is not intended to discourage public telecoms providers or third party suppliers from using containers where there is benefit in doing so, but to highlight that such containers should not be treated as a security boundary between trust domains. Similarly, where virtualisation is not being used to provide a security boundary, the security choices relating to the virtual network are less important.

Understanding the virtualised network

2.61 An essential part of a virtualised network is the understanding of that network. Public telecoms providers should ensure that they can easily represent and explore the virtual and physical network architecture, including identifying how the security architecture is enforced both virtually and physically. This can be supported by well-defined, system-enabled processes.

2.62 As a virtualised network may change dynamically, the principles that define the security architecture should be defined within the orchestration systems that establish and modify the network.

2.63 From a physical perspective, public telecoms providers shall ensure that they are able to access full details of hosts, including:

type of host and supporting software (e.g. hypervisor) and software versions;
the last boot time, boot status (e.g. a successful or failed secure boot) and any attested information;
the host pool and security properties associated with the host; and
the trust domains that the host may support and the networks (VLANs/VXLANs) accessible from the host.

2.64 Within the virtual network, public telecoms providers shall ensure that they are able to access the logical flows between virtualised workloads including:

the protocols that should, and should not, flow over the virtualised interfaces;
the physical hosts, equipment and links used to support the logical flow; and
the trust domains within the logical flow and the security enforcing functions splitting up that flow.

2.65 Public telecoms providers should also use the flexibility of virtualisation to enable greater monitoring of processes and flows within the virtualised system.

Network automation

2.66 This guidance demonstrates that managing a secure virtualised environment is complex. However, the majority of the security requirements can be automated.

2.67 Amongst other applications, automation enables rapid prototyping and testing of new features, security patches and changes. Using automation supports network resilience by limiting errors caused by human interaction, and by allowing quicker remediation should issues occur. It also supports network security by increasing the speed at which updates and changes can be made, therefore, allowing the public telecoms providers to keep pace with the threat environment.

2.68 When using automation tools, public telecoms providers should seek to ensure a secure, reproducible and comprehensible method of building, scaling and operating the network. Orchestration and network management tools allow the network infrastructure to be defined as ‘code’, within which security requirements can be embedded. When automating the orchestration and configuration of virtual functions, it is essential that modern development tools and techniques are used. As a minimum, this includes code versioning, continual integration, and delivery pipelines to maintain the security, integrity, and quality of automated builds.

2.69 If the automation tools have the ability to influence the confidentiality, integrity and/or availability of the entire network or a material part of it, it is likely they are a Network Oversight Function and/or a Security Critical Function.

2.70 Whilst automation goes a long way to preventing human errors, it does not come without risks. Therefore, public telecoms providers shall consider which activities are suitable for automation and which are not. As part of this assessment, public telecoms providers should consider:

the risks and appropriate mitigations;
ensuring the data used for decision making is from a trusted source;
validating the input such as data, scripts, and any associated business rules;
reviewing any changes to scripts or configuration;
checking the outputs are as expected;
ensuring the access permissions follow the role-based, least privilege model (for example, not run as a privileged user);
producing alarms when any automated processes are stopped and take appropriate action;
how easy it would be to roll back a failed change; and
how easy it would be to revert back to a manual process.

2.71 Ultimately, any automated processes shall ensure the resilience of the network is retained and there is a named business and operational owner.

2.72 For further advice, the NCSC has published a set of principles^{[footnote 22]} for securing machine learning, which equally apply to automation. The basis of these principles aligns with this Code of Practice.

The signalling plane

2.73 All public telecoms networks connect to each other over signalling networks. These signalling networks allow public telecoms provider networks to connect to each other, reach each other’s services and ultimately allow users to communicate with each other. The signalling plane of a network consists of protocols for control and support of the transmission plane functions. The signalling plane carries out the following functions:

it controls the access connections to the network (e.g. GPRS attach and GPRS detach);
it controls the attributes of an established network access connection (e.g. activation of a packet data protocol (PDP) address);
it manages the routing of information for a dedicated network connection in order to support user mobility;
it adapts network resources depending on the parameters; and
it sets up calls and routes messages.

Scope

2.74 This Code of Practice applies to signalling traffic arriving from external signalling networks, signalling arriving from other networks that are not within the scope of the security framework and outgoing signalling traffic from a public telecoms provider’s network. This includes, but is not limited to: BGP, SS7/MAP/ISUP, DIAMETER, GTP-C, and SIP/IMS.

2.75 Controls apply to all international signalling, including signalling that arrives over national signalling interfaces (e.g. due to mobile number portability). Signalling from Crown Dependencies (including the Channel Islands and Isle of Man) shall be treated as international signalling.

2.76 Public telecoms providers should threat model their signalling interfaces and determine whether similar controls should equally apply to their national and Mobile Virtual Network Operator’s (MVNO’s) connectivity.

2.77 Throughout the Code of Practice it should be noted that public telecoms providers’ live networks should be considered in scope of the guidance measures which concern network signalling protections. This would cover, for example, any trials being conducted on a live network that may have implications for wider network availability, functionality or performance. Protections from risks arising from external signals will also apply to signals originating from the network edge or consumers.

Guidance

2.78 Traditionally, and to a degree currently, telecoms standards have been built on an assumption that all signalling from other telecoms networks can be trusted. However, that assumption is no longer valid as these interfaces are exploited by attackers to conduct attacks. Therefore, public telecoms providers need to operate on the principle that incoming signalling networks are untrusted and build signalling security architecture that can validate incoming derived signalling without impacting critical core network functions. It should be noted, however, that where signalling messages are protected by end-to-end authentication, risk decisions and associated security controls may be determined based upon the authenticated source.

2.79 With respect to signalling networks, public telecoms providers should seek to increase the network’s resilience to disruptive attacks from incoming signalling networks and to inhibit the leaking of subscriber or network data over incoming signalling networks. The following guidance highlights the key aspects of signalling plane security for public telecoms providers to understand and implement, providing examples and further background information where appropriate. Public telecoms providers shall take steps to protect against the injection of malicious signalling messages into their network, as well as monitoring outgoing signalling traffic for evidence of compromise.

2.80 Number analysis reference data that is used to configure network equipment with E164, E212, E214 numbering ranges and diameter host names and GPRS Serving Node (GSN) IP addresses, should be maintained and reviewed regularly, with an appropriate frequency commensurate to the risk.

2.81 A variety of sources should be used to maintain this reference data. These should include (but are not limited to): updates in RAEX IR.21 documents; exception reports from nodes in the network (or analysers) that list unresolved numbers ordered by frequency; and analysis of logs and analyser data to find out ranges used by each roaming partner.

2.82 As a good practice to reduce incoming fake signalling messages, networking nodes should be locked down to accept certain operation codes only from lists of specific known addresses, rather than from open prefix ranges within Visited Public Land Mobile Networks (VPLMNs). For example, Mobile Application Part (MAP) Update Location messages from outbound roamers should be tied down to lists of known foreign Virtual Location Register (VLR) Global Title addresses, rather than be open to E164 prefixes associated with each VPLMN.

Signalling protocols

2.83 Public telecoms providers may use a combination of signalling protocols for different network functions, or variants of commonly accepted protocols. Examples of relevant protocols are listed below in Table 1, along with descriptions of their purpose and function. This list is non-exhaustive.

Table 1: Signalling protocols

Protocol	Purpose and function
Inter-network Mobile Application Part (MAP) and lower layer protocols (SS7/ SIGTRAN)	MAP is used to facilitate mobility management, call handling, SMS and other functions in cellular networks. It is commonly used between circuit-switched core network equipment (e.g. HLR, MSC, VLR), and between circuit-switched core networks and packet-switched core network equipment. Lower layer protocols may include TCAP, SCCP, MTP (1-3), M3UA, SCTP, IP, Ethernet.
Inter-network CAMEL Application Part (CAP) and lower layer protocols (SS7/ SIGTRAN)	CAP provides additional provider services when the user is roaming across cellular networks. Lower layer protocols may include TCAP, SCCP, MTP (1-3), M3UA, SCTP, IP, Ethernet.
Inter-network GTP-C (and lower layer protocols)	The GPRS Tunnelling Protocol – Control plane (GTP-C) when used to establish, update and remove data sessions for transport of user traffic between cellular networks. It can also be used to modify the quality-of-service parameters. It is commonly used between packet-switched core network equipment. Lower layer protocols will likely include UDP and IP, IP and IPSec.
Inter-network SIP/ SDP (and lower layer protocols)	The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) when used for interconnection and roaming between the provider’s IP Multimedia Subsystem (IMS) network and external SIP networks. SIP/SDP is commonly used to provide multimedia services in fixed and mobile networks. Lower layer protocols will likely include TCP/UDP, IP and IPSec.
Inter-network DIAMETER (and lower layer protocols)	A general authentication, authorisation and accounting protocol (AAA) extended for use in mobile networks to support mobility management, call handling (etc). It is commonly used between packet-switched core network equipment in 3G and 4G networks. Lower layer protocols will likely include TLS, SCTP, TCP, IP and IPSec.
Inter-network BGP (and lower layer protocols)	Border Gateway Protocol (BGP) is a standardised exterior gateway protocol designed to exchange routing and reachability information among autonomous systems (AS) on the internet. BGP will announce the best route for traffic between two locations on the internet. Lower layer protocols include TCP/UDP and IP.

Protecting the network

2.84 An attacker may seek to scan the public telecoms provider’s signalling networks to understand the network and inform further attacks. Public telecoms providers shall ensure that the internal network topology of their signalling is not exposed by ensuring that only ‘hub’ signalling addresses can be reached from external networks. These interfaces and addresses should be formally recorded.

2.85 Attackers may also send malformed signalling towards the provider’s network in an attempt to disrupt or compromise the provider’s service. To protect the network, public telecoms providers should ensure that external signalling is fully parsed and processed before reaching a Security Critical Function.

2.86 Architecturally, this may be achieved by public telecoms providers establishing an architectural DeMilitarised Zone (DMZ) between incoming signalling networks and Security Critical Functions, similar to the mechanism used to protect IP networks from any less-trusted sources (such as the internet). It could also be achieved by segregating the core network to limit the impact of any attack.

Protecting users

2.87 Public telecoms providers should seek to prevent the disruption of service or the leaking of customer data, customer identifiers and network topology over signalling interfaces. Where the public telecoms provider’s customers are connected to the provider’s network, the public telecoms provider shall implement mechanisms to protect the customer’s service and data.

2.88 To further enhance signalling security, public telecoms providers should check outgoing signalling traffic for evidence of signalling compromise, or bypass of existing security mechanisms. This could be achieved by deploying an independent signalling Intrusion Detection System (IDS). Ideally, the signalling IDS should be independent in that it is not part of, or a component of, or a report produced by, an existing security system such as a signalling firewall. Where possible, the signalling IDS should be supplied by a separate vendor, or at least be based in a different signalling stack to the signalling firewall. Public telecoms providers are encouraged to ensure that the signalling IDS looks for evidence of bypass by examining:

the types of result messages that are exiting the network to see whether any blocked incoming message types have successfully bypassed security mechanisms;
the format of IMSIs, MSISDNs and other sensitive data leaving the network to ensure that any data obfuscation or masking techniques are implemented completely and consistently;
certain types of error leaving the network that indicate the existence of unrecognised or anomalous signalling that has occurred in relation to outbound roamers.

2.89 Additionally, public telecoms providers should consider ensuring that the signalling IDS implements further rules to assess the nature and integrity of signalling leaving the network.

2.90 Where the public telecoms provider’s customers have roamed onto another network, the public telecoms provider should support the visited network in protecting their customers by informing the visited network of the signalling addresses which will support the customers connection, and proxying call and SMS signalling via the public telecoms provider’s (home) network.

2.91 Where another provider’s customers have roamed onto the public telecoms provider’s network, the public telecoms provider should seek to protect the inbound roamer’s service and data as well as can be achieved given the information available from the roamer’s home network.

Asset management

2.92 Effective asset management is the basis of effective security risk management and effective security architectures. Public telecoms providers shall maintain their own asset management records, rather than relying on suppliers or third parties to maintain asset records. Public telecoms providers may, however, collate such information from suppliers and third parties as part of their own asset management records.

Guidance

2.93 Due to its importance to network security, asset management should always be automated if possible, and business processes such as purchasing processes, auditing and End of Life (EOL) management should help to maintain the integrity of the asset register. Software tools can also be used to automatically enumerate the provider’s network, to ensure that they have an up-to-date network map and that this aligns with the asset register.

2.94 An important aspect of asset management is an assessment of the criticality and sensitivity of network equipment and systems. As part of this process, public telecoms providers will be able to identify their Security Critical Functions and Network Oversight Functions.

2.95 Asset management shall include the recording of any equipment (hardware, software or firmware) in the public telecoms provider’s network that is out of mainline support, along with any limitations of any extended support contracts, as this is likely to be more vulnerable to compromise. Public telecoms providers should have a plan to remove all equipment that is out of mainline support. To effectively manage the risk prior to removal, public telecoms providers will need to implement a risk management plan for this equipment, which mitigates the increased risk of compromise.

2.96 Asset registers and network maps are sensitive data that would be valuable to an attacker seeking to compromise the network. Public telecoms providers shall ensure that they are enforcing appropriate protections for this data. Further guidance on asset management can be found on the NCSC website.^{[footnote 23]}

The exposed edge

2.97 The exposed edge of the network is the equipment that is either within customer premises, directly addressable from customer/user equipment, or is physically vulnerable. Physically vulnerable equipment includes equipment in road-side cabinets or attached to street furniture. For example, the following equipment is normally considered part of the exposed edge:

Customer premises equipment (CPE) is equipment supplied to customers which is used, or intended to be used, as part of the network or service. This excludes consumer electronic devices such as mobile phones and tablets, but does include devices such as routers, edge firewalls, SD-WAN equipment, and fixed wireless access kit;
Base station equipment;
Optical line terminal (OLT) equipment; and
Multi-service access node / digital subscriber line access multiplexer (MSAN/DSLAM) equipment.

Guidance

2.98 Public telecoms providers shall identify what equipment is in their exposed edge, and hence the equipment that is more accessible to potential attackers. Public telecoms providers shall ensure that the compromise or disruption of parts of the exposed edge would not result in a significant incident for them.

2.99 To this end, public telecoms providers should physically and logically separate their exposed edge from Security Critical Functions and ensure that no sensitive datasets are held within the exposed edge.

2.100 Given the increased likelihood of compromise, public telecoms providers are strongly encouraged to implement secure boot mechanisms for all network elements in the exposed edge. This functionality allows equipment to be returned to a ‘known-good’ state, meaning that it becomes possible to recover from a compromise without requiring the physical replacement of network equipment.

2.101 While shared sites such as co-location hostels, cable landing sites, IXPs 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 in these shared sites, and mitigate the risk in an appropriate fashion.

Retaining national resilience

2.102 Regulation 3(3)(f) imposes certain requirements for national resilience. In particular, Regulation 3(3)(f)(iii) requires network providers to take appropriate and proportionate measures to ensure that they would be able to operate the network without reliance on persons, equipment or stored data located outside the United Kingdom if it should become necessary to do so. In addition, the location of equipment performing each particular function, or type of function, or storing data relating to the function is one of the matters to be considered as part of providers’ risk assessments under Regulation 3(3)(a).

Guidance

2.103 The resilience of the UK’s national connectivity shall be maintained by ensuring that a sustainable and critical level of knowledge, expertise, data and equipment are accessible from within the UK at all times. Public telecoms network providers shall take appropriate and proportionate measures to ensure they are able to operate UK networks in emergency situations where there may be reduced international connectivity or travel, and factor this into business plans where they make use of offshored capabilities.

2.104 Public telecoms providers shall ensure that those involved in the security of their networks and/or system(s) have the appropriate expertise to mitigate the risks to services and data. Public telecoms providers shall establish a clear process for determining and verifying the competency of any roles involved in network or service security, such as by registering with the Cyber Security Council.^{[footnote 24]}

2.105 Whilst public telecoms network providers may be unable to maintain 100% of normal service connectivity in the event of loss of international connections, they shall be able to restore, secure and run networks to the levels set out in this Code of Practice in the event they lose access to offshored capabilities. In particular, if it becomes necessary to do so:

Public telecoms network providers shall have the ability to maintain (as relevant, where they provide such forms of connectivity prior to the event) the following UK network connectivity for a period of one month in the event of loss of international connections:
- fixed and mobile data connectivity to UK peering points;
- mobile voice; and
- text-based mobile messaging.
Public telecoms network providers shall be able to transfer into the UK functions required by UK networks to maintain an operational service, should international bearers fail.

2.106 When assessing whether it is necessary to maintain the above network connectivity and transfer functions into the UK to maintain an operational service, public telecoms providers can consider different scenarios in their Business Continuity Planning (BCP) that may be relevant to their decision. These could constitute emergency situations and may include:

loss of access to staff, equipment or data in a specific country or global region, where external factors such as natural hazards or geopolitics limit the access to a public telecoms provider’s resources in a particular country or global region, and those resources are required to operate the critical services set out in paragraph 2.105 above;
compromise of non-UK group functions, where functions of a parent group that are located outside the UK suffer a security compromise, and those functions are required to operate the critical services set out in paragraph 2.105 above;
disruption to connectivity or physical transport links between the UK and rest of the world, where external factors such as natural hazards or geopolitics limit the ability to access a public telecoms provider’s resources outside the UK, and those resources are required to operate the critical services set out in paragraph 2.105 above;
failure of internet routing, where the failure of multiple major global providers, transit routes, or widespread hostile routing updates, or geopolitics cause failure of internet routing, or internet routing protocols, such as eBGP.

2.107 Public telecoms providers shall also seek to ensure a UK-based capability to assess the risks of security compromise to the network. Such risks that could be assessed include:

keeping network security and audit logs outside of the UK;
approving procurement decisions on hardware and software for UK networks using overseas staff;
relying on staff, equipment or data based outside the UK; and
relying on third party suppliers to ensure that basic first and second line support is available from them for the required period, where offshored expertise is lost.

2.108 Public telecoms providers should reassess existing risks in response to changes in the threat or geopolitical landscape.

Chapter crossovers

2.109 Information contained elsewhere in this Code of Practice is useful in understanding network architecture requirements, including the following sections in particular:

Security Critical Functions (Chapter 1)
Network Oversight Functions (Chapter 1)
Signalling plane (Chapter 2)
Workstations and privileged access (Chapter 3)
Monitoring and analysis (Chapter 5)
Supply chain (Chapter 6)
Prevention of unauthorised access or interference (Chapter 7)
Remediation and recovery (Chapter 8)
Governance (Chapter 9)
Risk assessments (Chapter 10).
Competency (Chapter 12)
Testing (Chapter 13).

3. Protection of data and network functions

3.1 This chapter provides guidance for public telecoms providers on the measures to be taken in accordance with Regulation 4 to protect data and network functions that could be at risk of security compromises.

3.2 Regulation 4 is set out below.

4.—(1) A network provider must use such technical means as are appropriate and proportionate —

(a) to protect data which is stored by electronic means and relates to the operation of the public electronic communications network, in a manner which is appropriate to the data concerned, and

(b) to protect functions of the public electronic communications network in a manner which is appropriate to the functions concerned.

(2) A service provider must use such technical means as are appropriate and proportionate—

(a) to protect data which is stored by electronic means and relates to the operation of the public electronic communications service, in a manner which is appropriate to the data concerned, and

(b) to protect functions of the public electronic communications network by means of which the public electronic communications service is provided, so far as those functions are under the control of the service provider, in a manner which is appropriate to the functions concerned.

(3) In paragraphs (1) and (2), ‘protect’, in relation to data or functions, means protect from anything involving a risk of a security compromise occurring in relation to the public electronic communications network or public electronic communications service in question.

(4) The duties in paragraphs (1) and (2) include in particular duties to take such measures as are appropriate and proportionate—

(a) to ensure that workstations through which it is possible to make significant changes to security critical functions are not exposed—

(i) where, in the case of a public electronic communications network, the workstation is directly connected to the network, to signals that are incoming signals in relation to the network,

(ii) where, in the case of a public electronic communications service, the workstation is directly connected to the public electronic communications network by means of which the service is provided, to signals that are incoming signals in relation to that network, or

(iii) where, in either case, the workstation is operated remotely, to signals other than those that the workstation has to be capable of receiving in order to enable changes to security critical functions authorised by the network provider or service provider to be made,

(b) to monitor and reduce the risks of security compromises occurring as a result of incoming signals received in the network or, as the case may be, a network by means of which the service is provided, and

(c) to monitor and reduce the risks of security compromises occurring as a result of the characteristics of any equipment supplied to customers which is used or intended to be used as part of the network or service.

(5) A network provider must use within the public electronic communications network signals which, by encryption, reduce the risks of security compromises occurring.

(6) A service provider must—

(a) monitor and reduce the risks of security compromises relating to customers’ SIM cards occurring in relation to the public electronic communications network by means of which the public electronic communications service is provided, and

(b) replace SIM cards in cases where it is appropriate to do so in order to reduce such risks.

(7) In paragraph (6), ‘SIM card’ means a subscriber identity module or other hardware storage device intended to store an International Mobile Subscriber Identity (IMSI) and associated cryptographic material, and the reference to replacing a SIM card includes a reference to the application to a SIM card of any process which permanently replaces one IMSI and associated cryptographic material with another.

Key concepts for understanding the requirements

Workstations and privileged access

3.3 A network can only be as secure as the devices that are able to administer and/or access the network, and so implementing an effective lock-down of administrative devices is essential. Such trusted, high-integrity physical devices are often known as Privileged Access Workstations (PAWs). The following guidance in paragraphs 3.4-3.6 highlights the key principles of PAW security for public telecoms providers to understand and follow when implementing solutions.

Guidance

3.4 When implementing a PAW-based lockdown, public telecoms providers should include consideration of the following principles.

3.4.1 Establish your organisation’s PAW strategy:

To design your PAW to be an effective security control, you first need to understand how it will fit into your organisation’s existing privileged access management (PAM) strategy. Each organisation is unique, with a different set of threats and access requirements.
You should consider which use cases and accesses your PAW requires, and how to design it in a way that is appropriate for your wider threat context. A good understanding of the threats to your business helps you establish which types of accesses are high risk, and should be secured with a PAW.
This principle helps you understand how a PAW complements other privileged access management approaches, and where it provides unique benefits.

3.4.2 Design your PAW solution to be usable and secure:

An effective PAW solution is designed to meet your organisation’s user needs. Although a PAW can be highly restrictive by nature, it still needs to be an enabling technology. It should provide users with the tools they need to carry out their work effectively, or they will seek less secure alternatives. To ensure you have a secure solution that is also useable in practice, you should take the time to understand these needs. Designing your PAW to balance user needs and risk makes it less likely that people look for less secure workarounds.
As the needs of your organisation and users change over time, the design and implementation of your PAW should evolve too. You will need to revisit and update both for the PAW to stay effective and to help prevent use of insecure workarounds.

3.4.3 Establish a foundation of trust:

A PAW has some of the highest levels of access and permissions in your organisation, so it’s important to build a strong foundation of trust in it, both at the start and throughout its lifecycle. Not doing this could later undermine its security controls.
As part of this, it’s also crucial to consider the supply chain for all of the components, software and services used in your PAW solution. You should think about how you gain effective control and oversight when you design the PAW solution, and how to maintain it throughout its lifecycle.
You should use a ‘clean’ environment to build trust in your PAW solution. A building-block approach is best here, starting with a clean standalone initial device, before then rolling out and operating the PAWs across your organisation at scale.
Starting small helps you establish a foundation of trust on which to build.

3.4.4 Scale the solution:

Where a PAW solution is made up of multiple devices, it’s important to be able to scale your security controls effectively. This requires a well-secured management platform that is administered from a system you trust.
You should make sure that any modifications or changes to your PAW are consistent and reliable, for example, by using Infrastructure as Code (IaC). This allows you to automate the provisioning and configuration of your infrastructure, which reduces human error. This approach also makes it easier to duplicate environments, streamline updates and maintain compliance across your estate.
You should maintain a single view of device compliance across your estate and closely monitor any configuration changes to make sure they are authorised.

3.4.5 Reduce the attack surface

A PAW device should be configured to meet your organisation’s administrative access needs, while also minimising its attack surface. The goal is to mitigate risk as much as possible on your PAW, while ensuring that administrative tasks can still be carried out effectively.
You should carefully consider every feature, application and connection to a PAW and make sure they are adequately protected. Disabling unnecessary functionalities or connections helps prevent a threat actor exploiting them.
Any component of a system that connects externally can pose a threat. For this reason, you should only allow external connections when access is essential and manage it very carefully.
It shouldn’t be possible to directly access any services on the PAW that pose a risk to it. This includes corporate applications, email and communication tools. If you require access to these services, you should make sure you manage it carefully, so that it doesn’t affect the integrity of the PAW. Examples here may include use of isolation and cross domain solution (CDS) technologies.
It’s important that these controls apply to any device used to access high privileged or critical services, including when that use is by a third party, and you should make sure that suitable controls are in place for these users too.

3.4.6 Isolate high-risk activity from your PAW:

Maintaining trust in your PAW is essential but sometimes it may be necessary to enable software or features on it that could undermine its security posture and create additional attack surface. Examples here may include running legacy software that is potentially vulnerable or allowing local system administration to configure the device.
You should avoid this as far as possible, but if it is necessary, you must fully understand the risks of doing so and manage that risk appropriately. An alternative is to implement the required software or feature in a way that isolates it from the PAW. You can use virtualisation to achieve this.

3.4.7 Put in place protective monitoring:

If your PAW is attacked, compromised or abused, it is important to be able to detect and respond accordingly. Implementing protective monitoring and auditing is a crucial part of maintaining trust in your PAW and the wider systems accessed from it.
If you have in place a good PAW strategy and effective system administration, you should have a good understanding of what actions are allowed, or not allowed, on a PAW device. This understanding will make it easier for you to put in place misuse case detections.

3.4.8 Control data entering and leaving the PAW solution:

In some situations, you may need to import files to your PAW from an untrusted third party location. If this data is malicious, it affects the integrity of your PAW.
Similarly, you may need to export data from your PAW which risks sensitive data leaving your device and getting into the hands of an adversary.
This presents a data import and export challenge to your organisation. Failure to put in place effective data transfer measures can drive the adoption of shadow IT or other poor practice.

3.5 Further information on the topic of device lockdown can be found online in the NCSC’s Principles for secure PAWs^{[footnote 25]} and on the NCSC’s device security guidance^{[footnote 26]} and secure system administration guidance^{[footnote 27]} pages, as well as the ETSI standards^{[footnote 28]}.

3.6. In addition, advice on the use of cross domain solutions and on data transfer can be found on the NCSC website.^{[footnote 29]}

SIM security

3.7 The intent of the SIM security measures within this Code of Practice is to ensure that an at-scale compromise of SIM cards cannot be used to disrupt the UK’s telecommunications networks, or to impact subscriber confidentiality. Regulation 4(6) sets out requirements that public telecoms providers must meet in relation to SIM cards.

3.8 The following background information and guidance in paragraphs 3.9-3.21 highlights the key aspects of SIM security for public telecoms providers to understand and implement, providing examples where appropriate.

Universal Integrated Circuit Cards (UICCs)

3.9 Universal Integrated Circuit Cards (UICCs) contain credentials of the SIM/USIM (Universal Subscriber Identity Module), which are used to authenticate subscribers’ access to the telecommunications network.

3.10 Historically, UICCs were used in mobile devices but are increasingly being used for fixed access as well. It is also becoming more common for UICCs to be embedded in mobile and Internet of Things (IoT) devices (eUICC or eSIM), meaning that physical card replacement will not be feasible. In the case of IoT devices with removable UICC the cost of physically accessing the device to change the SIM card would not be financially viable.

3.11 Should a SIM fail to allow access to the network, the subscriber or device will be unable to gain connectivity beyond the default emergency service access. In this case the device could be anything from a car alarm, to a mobile phone, to critical national infrastructure. In some cases, without connectivity, the device will become inoperable. Consequently, at-scale disruption of SIM cards or SIM card infrastructure is a national security concern.

3.12 UICC and eUICC manufacture is performed globally. The addition of SIM information, such as algorithms and keys, is normally performed during the personalisation process in the SIM card manufacturer’s premises. There are 3 disruptive attack vectors of concern:

compromise of over the air (OTA) keys allowing an attacker to remotely corrupt SIM profiles;
misuse of eSIM or remote SIM provisioning (RSP) functionality to corrupt UICCs and eUICCs with modifiable profiles; and
vulnerability in SIMs including the use of obsolete or weakly specified algorithms or use of default or inappropriate values.

3.13 There are 2 attack vectors of concern relating to subscriber confidentiality:

where the UICC is profile-modifiable, the profile could be modified to compromise the device’s connection; and
where the cryptographic key (K/Ki) is compromised, the user’s traffic could be decrypted over the air interface to generate spoofed traffic.

eSIMs

3.14 Efforts must also be made to inhibit the misuse of eSIM functionality (as defined by the GSM Association). As the GSMA has endeavoured to create an open market of eSIM services, these global services could be used to disrupt service or impact confidentiality, potentially at scale. Any resilience risks to networks arising from eSIM technology will need to be managed.

Guidance

3.15 Public telecoms providers should review existing SIM profiles that are in use. If vulnerabilities exist (in comparison with GSMA recommendations), public telecoms providers shall establish a plan for reducing the risk in an appropriate timeframe. Many public telecoms providers globally have used the routine changing of SIM cards, form factor changes, or introduction of new services, to replace, gradually via a process of churn, older obsolete SIM cards for newer more secure profiles. This practice is encouraged to increase the overall security of the SIM population in the network.

3.16 Public telecoms providers should ensure the security functionality of the SIM card meets or exceeds existing GSMA security recommendations. This is especially important for eUICCs which will be difficult or impossible to replace.

3.17 Where possible, and particularly for critical IoT applications, public telecoms providers should seek to update the SIM credentials promptly after they are brought into live service to reduce the supply chain risk. Where this is not possible, public telecoms providers shall ensure that the SIM card manufacturer and whoever provisions the eSIM is sufficiently trustworthy.

3.18 Once operational, SIM cards should be protected from potentially malicious signals. The public telecoms provider shall only allow management (OTA) messages from permitted sources to reach SIM cards which are issued by the public telecoms provider and attached to the public telecoms provider’s network.

3.19 Where UICCs allow profiles to be modified more than once (e.g. through remote SIM provisioning) then public telecoms providers shall ensure that only trustworthy services can add, remove or modify profiles on the public telecoms provider’s network and that this activity is logged and monitored. For any eSIMs issued by the provider, the public telecoms provider should use certificate-pinning to allow only approved services to make profile modifications.

3.20 Should public telecoms providers be made aware of a compromise to customer SIMs, or the data within those SIMs, public telecoms providers shall inform the relevant customers as soon as is reasonably practicable.

3.21 Public telecoms providers shall check the SIM providers’ certificates against the GSMA SAS accredited website^{[footnote 30]} and satisfy themselves that the supporting sites and external parties are sufficiently trustworthy. For the avoidance of doubt, this applies to all types of SIM.

Encryption and the protection of data

3.22 Regulation 4(5) requires public telecoms providers to use within the PECN signals which, by encryption, reduce the risks of security compromises occurring.

Guidance

3.23 Some types of information managed by an organisation would, if acquired by an attacker, significantly assist in the planning and execution of an attack. Such information could be, for example, detailed network and system designs, details of security measures, staff or customer details or large data sets that can be any combination of data types often referred to as bulk data. These should be identified and appropriately protected, for example, with role-based, least privileged access control. The data and its security remain the responsibility of the public telecoms provider irrespective of any contractual arrangements.

3.24 Extra care should be taken where there is a requirement to transfer data from the systems where it is normally stored and protected, e.g. out of the management plane (see 2.29) or to suppliers (see 6.8), to ensure that only the minimum required data is made available.

3.25 Public telecoms providers must ensure data, especially bulk data, is protected whether at rest or in transit. Where possible, public telecoms providers should protect this data through secure encryption. Where data is protected by other means, public telecoms providers should maintain a formal record of this, along with the means by which the data is protected.

3.26 Where data is encrypted either at rest or in transit, it should be encrypted in line with current best practice. For data in transit, encryption protocols such as IPsec and TLS are advised. Guidance on using IPsec and TLS to protect data, including configuration guidance and recommended profiles, is published by the NCSC.^{[footnote 31]} For data at rest, industry best practice should be followed, including the use of a secure encryption algorithm and secure methods for the generation and storage of keys used for encryption. Further guidance about protecting data at rest and in transit is available from the NCSC.^{[footnote 32]}

3.27 NIST maintains a list of currently approved cryptographic algorithm standards in NIST SP800-131A. These may change from time to time, for example as new algorithm standards are introduced and old ones are deprecated in response to the threat to cryptography from quantum computing. The NCSC’s recommendations for cryptographic algorithm profiles may also change from time to time.

3.28 Public telecoms providers shall ensure that access to data, especially bulk data, is tightly controlled and follows the role-based, least-privilege model.

3.29 Further guidance on data security can be found on the NCSC^{[footnote 33]} and NPSA^{[footnote 34]} websites, covering, for example, mobile devices, secure disposal and physical and technical security measures.

Customer Premises Equipment (CPE)

3.30 Customer Premises Equipment (CPE) is supplied to customers and businesses to enable connectivity.

Scope

3.31 In relation to CPE and CPE configuration, the measures in Section 3 of the Code of Practice align with Regulation 4(4)(c) and only apply when these devices are supplied to customers by public telecoms providers and are used, or intended to be used, as part of the public network or service. This excludes consumer electronic devices such as mobile phones and tablets. CPE in scope includes devices such as routers, edge firewalls, SD-WAN equipment, and fixed wireless access kit, where these are provided and managed by the public telecoms provider. CPE provided to business customers is in scope alongside that provided to retail consumers.

3.32 While public telecoms providers are responsible for the security of the default configuration of the devices they supply, they are not responsible for security weaknesses caused by customers independently adjusting the configuration of CPE after distribution. However, public telecoms providers shall take appropriate and proportionate measures to protect their networks from an upstream attack from any end-user device.

Background

3.33 Additional protections to secure devices have been implemented through the Product Security and Telecommunications Infrastructure Act 2022.^{[footnote 35]} The Act gives the government the necessary powers to set minimum security requirements for the manufacturers, importers, and distributors of consumer connectable products. It also defines the type of businesses that must comply with these security requirements, and prevents the sale of products that do not meet these requirements. The initial security requirements the government has set out for manufacturers of relevant connectable products aligns to the top 3 guidelines in the Code of Practice for consumer IoT security^{[footnote 36]}:

ensuring that consumer connectable products do not use universal default passwords;
implementing a means to manage reports of vulnerabilities; and
providing transparency on how long, at a minimum, the product will receive security updates.

3.34 For the customer, the CPE provides the separation between the internal network and the internet. Many customers rely on this separation to protect their local network.

3.35 If a CPE has security vulnerabilities, or has been configured in a way that leaves it vulnerable, it can lead to the following:

either compromised CPEs or other consumer devices being used as part of botnets – threatening UK national infrastructure;
compromise of devices owned by the customer, infringing on their privacy, personal data security, as well as data breaches, or product availability; and
the CPE to be used to carry out cybercrime, allowing criminals to proxy their activities.

Guidance

3.36 Public telecoms providers shall ensure a baseline level of security for CPE. This will help to ensure that both network infrastructure and customers are protected at the point where the CPE is distributed. Additionally, public telecoms providers shall ensure that the CPE has a secure default configuration, which should include limiting inbound connections by default. Public telecoms providers shall also ensure that the CPE will receive regular security updates throughout the device’s lifetime.

3.37 Due to the possibility that exploitation of vulnerabilities in CPE devices could impact the provider’s network at scale, or impact wider infrastructure, it is in the public telecoms provider’s interest to ensure that CPE remains in support and up to date. Acknowledging that public telecoms providers are not responsible for customer behaviour, public telecoms providers shall take proactive measures that aim to ensure CPE devices are being kept up to date during the lifetime of the contract, such as by providing customers with CPE that will automatically update by default. Similarly, public telecoms providers shall take proactive measures that are likely to result in CPE devices being replaced once they go out-of-support.

3.38 Where the public telecoms provider performs on-going management of the CPE, they shall ensure that this is performed securely. In particular, the public telecoms provider shall prevent the CPE’s management interfaces (e.g. TR-069) from being exposed wider than necessary, shall only allow the use of secure management protocols and shall ensure that their CPE credentials are unique to the device and not guessable.

3.39 In any case, public telecoms providers shall monitor for anomalous behaviour and protect their networks from potential harm caused by CPEs.

Chapter crossovers

3.40 Information contained elsewhere in this Code of Practice is useful in understanding the protection of data and network functions, including the following sections in particular:

Security Critical Functions (Chapter 1)
Network Oversight Functions and the principle of ‘assumed compromise’ (Chapter 1)
Management plane, especially browse up architectures (Chapter 2)
Signalling plane, especially risks from incoming signals and the exposed edge (Chapter 2)
Virtualisation fabric (Chapter 2)
National resilience (Chapter 2).
Governance (Chapter 9).

4. Protection of certain tools enabling monitoring or analysis

4.1 This chapter provides guidance for public telecoms providers on the measures to be taken in accordance with Regulation 5 to protect certain tools that enable the monitoring or analysis in real time of the use of the network or service, or the monitoring or analysis of the content of signals.

4.2 Regulation 5 is set out below.

5.—(1) This regulation applies in relation to a public electronic communications network or public electronic communications service if the network or service includes tools that enable—

(a) the monitoring or analysis in real time of the use or operation of the network or service, or

(b) the monitoring or analysis of the content of signals.

(2) If the tools are stored on equipment located outside the United Kingdom, the network provider or service provider must take measures to identify and reduce the risks of security compromises occurring as a result of the tools being stored on equipment located outside of the United Kingdom.

(3) The network provider or service provider must ensure that the tools—

(a) are not capable of being accessed from a country listed in the Schedule, and

(b) are not stored on equipment located in a country so listed.

Key concepts for understanding the requirements

Countries listed in the Schedule

4.3 The Schedule to the regulations sets out the countries that pose the greatest risk to the security of UK public telecoms providers’ networks and services. Monitoring and analysis tools of the type described in Regulation 5(1) shall not be located in these listed countries due to the sensitivity of those tools and the access they provide to management of UK networks and services. Public telecoms providers must also ensure that such monitoring and analysis tools are not capable of being accessed from those listed countries.

4.4 Tools that enable monitoring or analysis in real time under Regulation 5 include functions that allow the collection of traffic from the network (which are Network Oversight Functions) and functions that include network monitoring of speech and data. These must not be accessible from or hosted in any location listed in the Schedule to the regulations.

4.5 If new risks emerge from other countries in the future, or there is a reduction in existing risks associated with the countries listed in the Schedule, the government may look to update the Schedule list. The Code of Practice sets out steps to help public telecoms providers account for any such scenario, including the use of Business Continuity Plans to cover that risk.

Risk assessment

4.6 Regulation 5(2) sets out the need for public telecoms providers to take measures to identify and reduce the risks of security compromises occurring as a result of storing monitoring and analysis tools outside of the UK. Written assessments of these risks are addressed under Regulation 11(b)(ii).

4.7 Relevant activity to consider for identifying such risks may include, for example, the risks associated with performing the following activity outside the UK:

security analysis and anomaly detection, including the operation of Security Operation Centres (SOCs)^{[footnote 37]};
network performance and diagnostic analysis, including the operation of Network Operation Centres (NOCs);
privileged access, where that privileged access grants potential access to real-time network information or the content of transmissions, such as through the interaction with network equipment;
interaction with network or system probes;
interaction with the virtualisation fabric;
access to real-time network orchestration systems or controllers;
SIM provisioning and/or manufacturing; and
access to network data, designs, topologies, or bulk data sets.

4.8 Relevant considerations may include the risk of unauthorised conduct, the risks associated with local laws or their enforcement, or a lack of appropriate understanding of UK-specific risks by local staff. This is not an exhaustive list and just a sample of activities that should make up part of a risk assessment.

Chapter crossovers

4.9 Information contained elsewhere in this Code of Practice may be useful in understanding the protection of tools enabling monitoring or analysis, including the following sections in particular:

Monitoring and analysis (Chapter 5)
Governance (Chapter 9).

5. Monitoring and analysis

5.1 This chapter provides guidance for public telecoms providers on the measures to be taken in accordance with Regulation 6 to monitor and analyse the use of their networks in order to identify any security compromises.

5.2 Regulation 6 is set out below.

6.—(1) A network provider must take such measures as are appropriate and proportionate to monitor and analyse access to security critical functions of the public electronic communications network for the purpose of identifying anomalous activity that may involve a risk of a security compromise occurring.

(2) A network provider or service provider must take such measures as are appropriate and proportionate—

(a) to monitor and analyse the operation of security critical functions of the public electronic communications network or public electronic communications service for the purpose of identifying the occurrence of any security compromise, using automated means of monitoring and analysis where possible, and

(b) to investigate any anomalous activity in relation to the network or service.

(3) The duty in paragraph (2) includes in particular a duty—

(a) to maintain a record of all access to security critical functions of the network or service, including the persons obtaining access,

(b) to identify and record all cases where a person’s access to security critical functions of the network or service exceeds the person’s security permission,

(c) to have in place means and procedures for producing immediate alerts of all manual amendments to security critical functions,

(d) to analyse promptly all activity relating to security critical functions of the network or service for the purpose of identifying any anomalous activity,

(e) to ensure that all data required for the purposes of a duty under paragraph (1) or sub-paragraphs (a) to (c) is held securely for at least 13 months, and

(f) to take measures to prevent activities that would restrict the monitoring and analysis required by this regulation.

(4) A network provider or service provider must record the type, location, software and hardware information and identifying information of equipment supplied by the network provider or service provider which is used or intended to be used as part of the public electronic communications network or public electronic communications service.

Key concepts for understanding the requirements

Monitoring and analysis

5.3 While not directly a set of preventative controls, security monitoring fundamentally underpins the security posture of a network or system. Inadequate coverage of devices or networks from a logging and monitoring perspective will fundamentally limit the ability to identify, and subsequently determine the root cause of, anomalous activity and may also limit the ability to understand the extent of such activity without recourse to extremely labour intensive and expensive forensic work.

5.4 Enabling the collection of relevant information from appropriate devices or systems within a provider environment will permit post-event analysis to be undertaken with significantly more ease and allow public telecoms providers to gain more confidence in their ability to respond to security-related events.

5.5 While collection of this information will permit a range of post-incident analysis and other such activity, proper implementation of monitoring and alerting capabilities on top of this will allow public telecoms providers to identify malicious or unusual behaviour taking place in near real time, enabling response prior to a major or catastrophic event taking place. General guidance and principles on effective monitoring can be found on the NCSC website.^{[footnote 38]}

Guidance

5.6 The following guidance in paragraphs 5.7-5.25 highlights the key aspects of monitoring and analysis for public telecoms providers to understand and implement, providing examples and further background information where appropriate.

Logging and monitoring

5.7 As a minimum, logging and monitoring should cover the following:

who logged in (account or User ID);
what they did (type of event/activity);
when they logged in (date/time);
where the login occurred (resource/source of the event such as location, IP address, terminal ID or other means of identification); and
why the login occurred (a link to the specific ticket that necessitated the login)

5.8 In addition, public telecoms providers should:

ensure log timestamps are synchronised with a trusted Network Time Protocol (NTP) time source to allow correlation with other log and event data;
monitor logs and network behaviours for unusual activity, such as Secure Shell (SSH) connections on abnormal ports or abrupt decreases in log activity;
monitor syslog and Access, Authorisation and Accounting (AAA) logs for unusual activity, including a decrease in normal logging events, or a gap in logged activity;
monitor the environment for unusual changes in behaviour or configuration.

5.9 It is just as important to log unsuccessful events as it is successful events and also to alert if logging or critical software components, such as anti-virus, stop or are turned off. General guidance on what to log can be found on the NCSC website.^{[footnote 39]}

Normal and anomalous activity

5.10 Effective monitoring of network behaviour is dependent on a detailed understanding of the network. This encompasses asset management, but also requires a clear security architecture and an understanding of the behaviour of network equipment. Public telecoms providers are unlikely to be able to effectively monitor their networks without first collating this information.

5.11 This information is essential to determining a relative state of ‘regular’ activity and ‘anomalous’ activity, both between components within a network, and the behavioural state of network equipment. Anomalous activity is activity in a network which does not conform to regular network traffic, or conform to the regular behaviour of network equipment. Exactly what constitutes anomalous activity can only be defined by the network provider itself as they have the best knowledge of what normal activity looks like.

Network‑based monitoring

5.12 Public telecoms providers should use network-based monitoring, specifically the monitoring of signals both internally and at the edge of the provider’s network to determine anomalous behaviour.

5.13 Monitoring needs are to be defined by public telecoms providers themselves as they have the best knowledge of their networks. Public telecoms providers should base this decision on risk, recording both details of their approach to monitoring and the justification for that approach. In making this decision, public telecoms providers should consider factors such as:

the criticality or sensitivity of interfaces and systems;
the exposure of the systems or interfaces to attack;
the vulnerability of interfaces and equipment, which may be higher for legacy and out-of-mainline support network equipment; and
the approaches and interfaces used by security testers, or by attackers during past compromises.

5.14 In determining where to monitor, public telecoms providers should give consideration to the following security boundaries:

between the public telecoms provider’s network and external networks such as customer networks, partner networks, the internet and international or national telecommunications networks;
between public telecoms providers and the MVNOs hosted on their networks;
between the public telecoms provider’s network and third party administrator networks, such as those owned by network equipment suppliers and MSPs;
between the public telecoms provider’s Security Critical Functions and functions in the access network or exposed edge;
between management networks and other networks, including internal networks; and
between the public telecoms provider’s own Operational Support Systems (OSS) and Business Support Systems (BSS) or networks.

Host‑based monitoring

5.15 Host-based monitoring involves monitoring the behaviour of network equipment and supporting devices within the equipment to identify anomalous activity. Public telecoms providers should utilise host-based monitoring wherever possible in their networks, and particularly in the protection of sensitive or critical functions.

5.16 Host-based monitoring may incorporate operating system, application, and virtual machine behaviour, including detailed information at the process level, especially where unexpected reboots/restarts have occurred as these event logs would help to investigate the cause. This may involve deployment of an on-host agent to collect the required information, or simply the forwarding of existing operating system-level logging data.

5.17 Public telecoms providers should be aware that should a host become compromised, the monitoring information produced by a host may also be compromised or may become unreliable. To protect this information, ‘regular’ administrative users should not be able to alter the collection of logging or audit data without ‘high priority’ alerts being raised to flag this event. Administrative users not responsible for maintenance of audit systems or analysis of its content should not be able to view or otherwise affect already-collected log data. Additionally, monitoring information should be exported from the device as quickly as possible, ideally in real-time or near real-time and alarms should be raised if logging stops, pauses, or fails. Further guidance on host-based logging can be found on the NCSC website.^{[footnote 40]}

Protection of monitoring data

5.18 Monitoring data provides information about network behaviour and may therefore be of interest to attackers. It may contain sensitive data such as administrative passwords. As such, public telecoms providers need to ensure that monitoring data is protected against unauthorised access or alteration. Should there be any personally identifiable data or credentials recorded within any monitoring data, this data should be appropriately sanitised and protected. Regular tests should be conducted to ensure that the logging is functioning as expected.

Effective Analysis

5.19 Security analysis allows benefit to be gained from monitoring by identifying anomalous activity. Public telecoms providers frequently co-locate security analysts at a Security Operations Centre (SOC).

5.20 For security analysts to identify anomalous activity, they will need access to detailed information about the network alongside monitoring data. Providing analysts with a clear picture of expected network activity provides them with context for the monitored environment, allows them to focus their activity and maximises the protection they will be able to afford the network. The necessary network information will likely need to be collated from architectural design documentation, asset management systems, configuration management systems, product and interface specifications, network change plans and change systems (known as tickets).

5.21 Public telecoms providers should also aim to provide analysts with monitoring data sourced from both network-based and host-based monitoring. To support effective analysis, there may be benefit in merging these datasets to provide a single picture of network activity and allow analysts to correlate information across a range of infrastructure.

5.22 Further, to help build a ‘story’ of activity, monitoring data should link administrative actions to network administrators and on to tickets. This applies whether the administrator is internal or employed by a third party. With this information, it becomes possible for analysts to build a chain of events, establish the root cause of incidents, and prevent a recurrence of that incident.

Proactive security monitoring

5.23 Analysis of monitoring data is sometimes viewed solely as a reactive exercise based upon configured alerting, or as a response to an incident. Public telecoms providers should seek to perform proactive analysis, or threat hunting, to assess whether activity is present that would not necessarily trigger security alerts. Such analysis should consider behavioural information alongside security alerts.

5.24 Analysts will need to be sufficiently skilled in understanding network and attacker behaviour. They will often benefit from access to threat intelligence feeds. When protecting large-scale networks, public telecoms providers should have access to sufficiently skilled analysts to support multiple investigations of anomalous behaviour at any one time and address any findings.

5.25 General advice on proactive security monitoring can be found on the NCSC website.^{[footnote 41]}

Border Gateway Protocol

5.26 Border Gateway Protocol (BGP) is a signalling protocol which is used to route data between service providers. This protocol can be hijacked, resulting in traffic being deliberately misrouted round the internet. It occurs when either a false ownership claim, or a false route to an IP address is advertised externally by an entity that neither routes to, nor owns, the address. As an example, BGP misrouting was a factor in the global outage of Facebook on 4 October 2021.^{[footnote 42]}

Guidance

5.27 Public telecoms providers are recommended to use a monitoring service/tool to detect potential hijacks and routing leaks and to respond appropriately when hijacks are detected. It is recommended that public telecoms providers ensure their Network Operation Centres (NOCs) are alerted to hijacks and have plans to respond based on the type of hijack. In extremis, this should include blocking traffic from being routed to the hijacked destination.

5.28 Hijacks of internal UK-to-UK provider traffic shall be particularly inhibited, and UK-to-UK routes should be monitored for anomalous activity (such as the inclusion of unexpected transit networks). UK public telecoms providers should share enough information with each other to allow hijacks of internal traffic to be easily detected, and a fallback approach to routing should be established between public telecoms providers in the event of a persistent hijack.

5.29 To help ensure that routing information originating from the community is as accurate and secure as possible, public telecoms providers shall, at a minimum, implement the basic elements set out in Section 2 and 3.

5.30 All address space and autonomous system (AS) resources allocated to a public telecoms provider should be correctly recorded in such a way that it is simple to identify and contact the ‘owner’ to assist in resolving issues. Contact details need to be current and accurate on all the Regional Internet Registries (e.g. RIPE) and other useful locations, such as PeeringDB. Note that all appropriate fields and record types should be secured appropriately, to prevent misuse.

5.31 Implementation of ingress and egress route filtering will help to ensure that only authorised and approved routes are used, and that IP address spoofing is prevented. Before accepting and onward advertising routes, transit providers should check on the relevant Regional Internet Registry (RIR) database(s). Other providers and/or AS ‘owners’ could also implement similar checks on RIR database(s) before accepting routes.

5.32 When implementing ingress and egress route filtering, service providers should pay special attention to:

Special Use Addressing;
BOGONs (although RFC 6441 should be considered);
over-specific prefix lengths;
their own prefixes;
their own AS; and
IXP LANs.

5.33. Accepting routes from unexpected sources could result in the provider propagating routing changes that have not come from the legitimate resource owner. One method to help address this is to limit where external BGP routing updates are accepted from.

5.34 Public telecoms providers should actively monitor BGP routing changes to detect and monitor incidents, including (but not limited to) hijacking and denial of service attacks.

5.35 Prefix origin validation by public telecoms providers using tools such as Resource Public Key Infrastructure (RPKI) will help to ensure that only valid BGP updates from the genuine owner of the address space will be acted on. If public telecoms providers also aggregate routes where possible, this will minimise the number of routes advertised, minimising the number of route updates required.

5.36 In the event of a Global BGP failure, there will be a period of time when routers will be performing discovery and re-building their routing tables. This may take many hours. It is therefore incumbent on the UK public telecoms providers to ensure that they have in place a plan of maintaining UK internal traffic during this time. Route aggregation may help in speeding up the return to normal. If RFC 3682 is implemented, where it is available, it will help limit the possibility of resources on routers being overwhelmed. RFC 3682 provides a method of limiting the ‘Time to Live’ for BGP updates by implementing limits of valid BGP senders where the traffic is between routers that are next to each other, known as ‘Peers’.

5.37 If routing equipment fails, there is the possibility of a route being withdrawn. Public telecoms providers should advertise routes in such a way that this is unlikely to happen. One possible way to do this is by the use of static routes to non-physical, persistent interfaces.

5.38 Where it is available, TCP Authentication Option (TCP-AO) should be the preferred method of authentication. This will allow for stronger authentication algorithms and better, more agile, key management.

Threat hunting

5.39 Analysis of log information is sometimes viewed solely as a reactive exercise based upon configured alerting, or as a response to an incident. Collected log information should be used for proactive analysis to assess whether activity is present that would not trigger previously-configured alerts.

5.40 Threat intelligence information feeds will likely be required as reference material for potential attacker behaviour, and a good knowledge of the typical behaviour of monitored networks and the capabilities of monitoring systems will be necessary. Suitably skilled staff to operate these feeds are also required, whether that be via existing skilled staff or appropriate training.

5.41 Proactive analysis will need to be based upon assessed threat information relating to likely attacks and risks to a provider’s network or service. The risks should be chosen by individual public telecoms providers for this purpose based upon their threat profile and will likely change over time.

Regular scanning

5.42 Attackers are increasingly scanning networks to find exposed vulnerabilities. Public telecoms providers should regularly, ideally continuously, scan their networks to detect vulnerabilities, mistakenly exposed services and ports, or out-of-date equipment and address any findings.

Retaining equipment logs for 13 months

5.43 The retention of logging data ensures that if there is a security compromise it is possible to identify any changes in the network that may have contributed to the compromise. The logs relating to Security Critical Functions must be maintained for at least 13 months as this will ensure the retention of any changes made on a once-yearly basis, for example end of year processes.

5.44 Equipment logs are produced by network equipment to record the equipment’s behaviour and the actions taken by administrative staff in relation to that equipment. Equipment logs do not normally contain customer data. Public telecoms providers should sanitise any customer data prior to storage. Public telecoms providers should be mindful that even sanitised data can expose patterns of life and therefore should ensure it is protected appropriately.

Chapter Crossovers

5.45 Information contained elsewhere in this Code of Practice is useful in understanding monitoring and audit requirements, including the following sections in particular:

Security Critical Functions (Chapter 1)
Network Oversight Functions (Chapter 1)
Countries listed in the Schedule (Chapter 4)
Governance (Chapter 9)
Testing (Chapter 13).

6. Supply chain

6.1. This chapter provides guidance for public telecoms providers on the measures to be taken in accordance with Regulation 7 to identify and reduce the security risk arising from actions taken or not taken by third party suppliers.

6.2 Regulation 7 is set out below.

7.—(1) A network provider or service provider must take such measures as are appropriate and proportionate to identify and reduce the risks of security compromises occurring in relation to the public electronic communications network or public electronic communications service as a result of things done or omitted by third party suppliers.

(2) In this regulation, ‘third party supplier’, in relation to a network provider or service provider, means a person who supplies, provides or makes available goods, services or facilities for use in connection with the provision of the public electronic communications network or public electronic communications service.

(3) The risks referred to in paragraph (1) include—

(a) those arising during the formation, existence or termination of contracts with third party suppliers, and

(b) those arising from third party suppliers with whom the network provider or service provider has a contractual relationship contracting with other persons for the supply, provision or making available of any goods, services or facilities for use in connection with the provision of the public electronic communications network or public electronic communications service.

(4) A network provider or service provider (‘the primary provider’) must take such measures as are appropriate and proportionate—

(a) to ensure, by means of contractual arrangements, that each third party supplier—

(i) takes appropriate measures to identify the risks of security compromises occurring in relation to the primary provider’s network or service as a result of the primary provider’s use of goods, services or facilities supplied, provided or made available by the third party supplier, to disclose any such risks to the primary provider, and to reduce any such risks,

(ii) where the third party supplier is itself a network provider and is given access to the primary provider’s network or service or to sensitive data, takes appropriate measures for the purposes mentioned in section 105A(1) of the Act, in relation to goods, services or facilities supplied, provided or made available by the third party supplier to the primary provider, which are equivalent to the measures that the primary provider is required to take in relation to the primary provider’s network or service,

(iii) takes appropriate measures to enable the primary provider to monitor all activity undertaken or arranged by the third party supplier in relation to the primary provider’s network or service, and

(iv) takes appropriate measures to co-operate with the primary provider in the resolution of incidents which cause or contribute to the occurrence of a security compromise in relation to the primary provider’s network or service or of an increased risk of such a compromise occurring,

(b) to ensure that all network connections and data sharing with third party suppliers, or arranged by third party suppliers, are managed securely, and

(c) to have appropriate written plans to manage the termination of, and transition from, contracts with third party suppliers while maintaining the security of the network or service.

(5) A network provider must—

(a) ensure that there is in place at all times a written plan to maintain the normal operation of the public electronic communications network in the event that the supply, provision or making available of goods, services or facilities by a third party supplier is interrupted, and

(b) review that plan on a regular basis.

Key concepts for understanding the requirements

Management of third party suppliers

6.3 A supply chain involves contractual arrangements between the public telecoms provider and third party supplier, or between third party suppliers. If used and managed correctly, these contractual arrangements can help improve the understanding of the supply chain, assist in investigations of security incidents and assist testing of security mitigations or processes. More general advice on supply chain security can be found on the NCSC website.^{[footnote 43]}

Guidance

6.4 The intent of the security framework in this area is to ensure public telecoms providers fully understand and reduce supply chain risks. One of the key aims is to ensure that public telecoms providers flow-down security requirements to third party suppliers by means of contractual arrangements, ensuring the third party supplier is working to the same security standards in terms of the specific goods, services or facilities it is supplying, providing or making available to the provider.

6.5 Public telecoms providers should consider whether they may require their third party suppliers’ support to perform effective network audits and effective security testing of the provider’s network. For example, where the provider’s network and a third party supplier’s network are closely integrated, security testers will better simulate attacker behaviour if they are permitted to test both networks simultaneously.

6.6 Public telecoms providers should also consider the support they may need from their suppliers should an incident or compromise occur, potentially via the supplier. As public telecoms providers are responsible for the risk to their network or service, they should ensure that suppliers inform them about incidents that may affect the provider’s network or service and that they can access, in a timely manner, the data required to effectively investigate incidents relating to their network or service, including any relevant data that may be owned by the supplier.

6.7 It should also be noted that public telecoms providers are ultimately responsible for the security of their networks and cannot outsource this responsibility to third parties. Where providers do outsource aspects of operations to a third party, responsibility to comply with the obligations contained within sections 105A-D of the Communications Act 2003, and the obligations set out in the regulations, remain with the provider. The provider therefore needs to have sufficient internal capacity to meet those obligations.

6.8 When working with external suppliers, public telecoms providers need to effectively manage the risk to any data, especially bulk data sets, that needs to be shared with the supplier. Suppliers are often targeted by attackers interested in their supply chain, and compromising suppliers’ systems may provide an attractive route to obtaining nationally significant datasets. In this context ‘data’ includes both user data and network data. Particular attention shall be paid to large or bulk data sets.

Guidance

6.9 Under normal governance practices, decisions relating to a dataset will be taken by a ‘data owner’ who is responsible for the data’s protection. As a first principle, data sharing should be limited to only the data necessary for the purpose. In most scenarios, the sharing of data from the operational network is unnecessary and should be avoided. Where data relating to the operational network needs to be shared, it will often need to be sanitised or anonymised first to protect user and network data.

6.10 It is recommended that public telecoms providers establish systems that allow the provider to retain its data within its control whenever possible. This allows the provider to authenticate and authorise any access to their data using MFA, understand full details of that access, control any movement of data, and monitor and detect compromises. Any such data-sharing system is ideally separate from the provider’s corporate and operational systems, ensuring that the data-sharing requirement does not give suppliers wider access to other systems.

6.11 If data must be transferred off the public telecoms provider’s network and into the supply chain, there should be a process to sanitise the data, authorise the secure transfer, validate that the data has arrived, and ensure that it is deleted irretrievably when the task and the reason for the transfer is completed. The public telecoms provider should confirm by both audit and testing that the security of their data, wherever it is held in the supply chain, is appropriately protected, including by using an encrypted and authenticated channel for data sharing, and deleted securely when no longer required.

Third party administrators

Background

6.12 Administrative access (logically and physically) presents a significant security risk to electronic communications networks. Public telecoms providers grant administrative access to MSPs and 3PAs for a variety of reasons. Administrative services provided by an external company within a broader umbrella business or provider group should be considered as 3PAs. 3PAs may also be MSPs as part of a managed service contract, or equipment suppliers as part of a third-line support function.

6.13 Due to their nature, 3PAs may gain access to multiple electronic communications networks. This means that a single set of administrators, and administrative systems, can negatively impact multiple networks. This makes 3PAs particularly attractive to attackers. Should 3PA systems be compromised, or a 3PA be malicious, multiple UK networks could be exploited or disrupted simultaneously.

6.14 As an example, in December 2018 the government attributed a Chinese espionage operation against global MSPs to threat group APT10. This operation was of unprecedented size and scale, targeting several global MSPs, with attacks ongoing since at least 2016. After compromising the MSP, the group exfiltrated a large volume of data from multiple victims, exploiting compromised MSP networks and those of their customers through trusted connections. This indirect approach of reaching many through only a few targets provides a high-profile example of a supply chain attack and a new level of cyber espionage maturity.

6.15 While both managed service access and third-line support can present a risk to UK networks, the risks associated with managed service access is particularly significant due to increased scope and frequency of network access, and frequency of data access. The use of 3PAs by UK networks almost certainly increases the overall threat of cyber attack, requiring careful risk management by industry.

6.16 The use of 3PAs also creates a risk due to the dependence of the provider on the 3PA for the continued operation of networks. Should the 3PA no longer be able to provide the service, this is likely to have an operational impact.

Guidance

6.17 Overall, public telecoms providers should be looking to reduce the risks to networks due to 3PAs, and specifically reduce the risk that a single attack within a 3PA could negatively impact multiple networks.

6.18 Public telecoms providers should ensure that the 3PA is enforcing separation to prevent its network from being connected to another provider’s network via the 3PA. Public telecoms providers will require a robust security boundary between their network and the 3PA, including the ability to control access to infrastructure, control any data flows and limit any administrative accesses across the boundary. Such controls should be applied even when the 3PA is part of the same umbrella company or provider group.

6.19 Public telecoms providers should ensure that a compromise of the 3PA cannot compromise or disrupt multiple providers. Administrative workstations within 3PAs should only be able to access a single public telecoms provider’s network at any one time.

6.20 Further government work is ongoing to address the security risks associated with MSPs. In November 2021, the government published its response to a call for views on the government’s preliminary proposals for managing the cyber risks associated with MSPs.^{[footnote 44]} Those proposals included education and awareness campaigns, certification or assurance marks, minimum requirements in public procurement and legislation. All proposals received positive feedback, and the government responded by recognising that a range of audience-specific interventions will be needed when addressing the security of managed services.

6.21 The government has also published proposals for legislation to improve the UK’s cyber resilience.^{[footnote 45]} This included the proposal to add ‘managed services’ to the list of ‘digital services’ regulated under the Network and Information Systems (NIS) Regulations 2018. This change would require MSPs to comply with the duties currently set out in the NIS regulations, including taking appropriate and proportionate measures to manage risks, and reporting relevant incidents to the Information Commissioner’s Office (ICO) as the relevant regulator.

Cloud providers

6.22
a. If a public telecoms provider wishes to use a cloud provider for any part of its PECN/PECS provision, it will be essential to have contractual arrangements in place that ensure security controls are applied correctly.

b. Public telecoms providers must recognise that the cloud environment is significantly different from the traditional model and therefore a simple ‘lift and shift’ of their current environment will not deliver the necessary control or functionality.

c. There are several risks that shall be assessed and taken into consideration, including:

The shared responsibility model

6.23 Typically, the cloud provider will administer the underlying capabilities (such as physical infrastructure and virtualisation fabric) to be used in the PECN/PECS provision, while the public telecoms provider administers its own telecoms-specific software. The cloud provider may also provide additional cloud services used in the PECN/PECS provision.

6.24 Under this model, cloud providers shall be considered as 3PAs, as well as third party suppliers, at least as regards their physical infrastructure and virtualisation fabric and any additional cloud services provided.

6.25 Public telecoms providers retain responsibility and accountability for management and oversight when third parties are involved and must ensure that the physical infrastructure, virtualisation fabric and services provided and used in the PECN/PECS provision are architected and managed in accordance with the principles described in the Code of Practice and that security controls are applied correctly. Public telecoms providers also remain responsible for the administration of their own telecoms-specific software.

6.26 The configuration and integrity of the virtualisation fabric is critical, as is the security of the underlying physical infrastructure and particular attention shall be paid to virtualisation measures.

The potential threat posed by a third party MSP or 3PA

6.27 Paragraphs 6.13 and 6.14 above explain the potential threat posed by an MSP or 3PA that provides services to multiple organisations. Should 3PA systems be compromised, or a 3PA be malicious, multiple UK networks could be exploited or disrupted simultaneously and it is for this reason that measures relating to the MSP or 3PA itself and how it architects its administration have been included in the Code.

6.28 Some of the measures relevant to MSPs (M10.26, M10.29 and M10.30) may need an alternative approach that is appropriate and proportionate to address the risk in a cloud environment.

National Resilience

6.29 Public telecoms providers choosing to make use of a cloud provider for any part of its PECN/PECS provision shall also consider carefully Regulation 3(3)(f) on resilience (explained further in sections 2.102 – 2.108)

6.30 Cloud services typically have a control plane component responsible for managing the service. Public telecoms providers shall ensure that they have a deep understanding of the impact on their ability to operate if their cloud environment loses connectivity to its control plane.

Network equipment suppliers

Guidance

6.31 Providers procure their network equipment from a set of suppliers. Equipment and contracting risks should therefore be considered as part of relationships with third-party suppliers. For the purposes of this guidance, third party supplier ‘equipment’ includes hardware, software and firmware.

6.32 The following guidance in paragraphs 6.33-6.46 highlights the key areas that public telecoms providers need to understand when working with network equipment suppliers, providing examples and background information where appropriate.

Third party supplier dependency

6.33 Network equipment supply should not be viewed as a single transaction. There are 4 components:

supply of the equipment;
an essential flow of technical information as part of a support contract – comprising training, fixes, updates, enhancements, advice, direct network troubleshooting and replacement of failed equipment;
the upgrade/replacement of the equipment during a network refresh; and
the decommissioning of equipment.

6.34 Where the equipment will be difficult to replace due to time and cost, the provider is establishing a long-term reliance on the supplier. To some degree, the provider is now reliant on the third party supplier to ensure that the provider’s network stays secure.

6.35 The equipment that is most difficult to replace tends to be within nationally distributed networks, particularly the access network. In this network it is costly and time-consuming for providers to replace equipment as there is a very large quantity of equipment and it is geographically distributed. The following subcomponents are involved in ‘access’ networks:

mobile access (base stations and antennas);
fixed access (DSLAMs, MSANs, OLTs etc); and
transport (fibre and microwave links and equipment).

Fault or vulnerability in network equipment

6.36 Low product quality could result in disruptive security compromises within providers’ networks. This risk includes 2 types of cyber event:

systemic failure due to software or firmware faults, which could involve multiple third party suppliers if they use a common component; and
equipment vulnerability exploited by an attacker to cause disruptive effect or compromise the network.

6.37 If there are product quality issues (be it from legacy build environments, poor software development processes or poor vulnerability management), a flaw in one or more products could potentially result in widespread equipment failure or be turned into an exploitable vulnerability, allowing the attacker to gain control of network equipment.

6.38 Regulation 7 is intended to ensure that third party supplier security and quality is sufficiently valued by providers to reduce the risk of security compromise to their networks and services and drive security improvements in third party suppliers. This can be achieved through public telecoms providers regularly performing an evidence-based assessment of network equipment suppliers’ equipment security, recognising the supplier’s positive and negative security behaviours, and ultimately valuing a network equipment supplier’s good security practices during procurement.

The Vendor Security Assessment

6.39 The NCSC’s Vendor Security Assessment (VSA) provides advice on how providers should assess network equipment suppliers’ security processes and the security of their equipment, alongside their usual assessments of network equipment supplier performance and interworking (see Annex B). The purpose of the approach is for providers to objectively quantify the cyber risk due to use of the network equipment supplier’s equipment. This is performed by gathering objective, repeatable evidence on network equipment suppliers’ security processes and the security of the network equipment.

6.40 Evidence on the network equipment supplier’s security practices should be based on the network equipment supplier’s implemented practices, rather than its documentation. Given this, one valuable method of assessing the security of network equipment suppliers’ equipment is through testing. This shall include positive testing, negative testing and fuzzing of the equipment’s interfaces. Ideally this should be automated and repeated at scale to stress test the equipment’s interfaces.

6.41 The VSA will be updated periodically in the future to keep pace with new threats and technologies. Any relevant updates that are made to the guidance in the VSA will be reflected in an updated Annex within future versions of the Code of Practice.

6.42 While public telecoms providers are responsible for ensuring the equipment that they use is sufficiently secure, achieving secure equipment is best achieved through collective security research and transparency. To this end, it is highly recommended that providers encourage their suppliers to publish a response to the NCSC’s VSA.

6.43 During procurement processes for equipment, public telecoms providers shall ensure that security considerations are a significant factor in determining the procurement outcome. This is particularly important for Security Critical Functions. These security considerations should relate to the information gathered during the Vendor Security Assessment, recognising the benefit of any security features that will provide measurable improvement to the security of the network, and the additional costs of mitigating any additional risks or unknowns.

6.44 Where a third party supplier does, or omits, something which increases the risk of security compromise, the risk to the public telecoms provider will increase with the scale of deployment. Specifically, a high quantity of equipment or components in the network which share a supply chain risk increases the risk to the network. To limit the risk of security compromise, public telecoms providers shall consider whether the risk associated with the quantity of equipment or components is manageable given the supplier risk.

6.45 Public telecoms providers should also consider the potential Total Cost of Ownership (TCO) when making their procurement decisions. These are essentially the additional security related costs, as well as the initial purchase cost, that the public telecoms provider will incur when the equipment/software is live. This could be the cost of additional add-on security features, additional hardware, additional staff to design and operate, or controls needed to mitigate security shortfalls or to cover patch management. Public telecoms providers should also assess who is responsible for bearing the costs of implementing mitigations when third party suppliers are unable to promptly address a security vulnerability.

The ‘Trojan horse’ threat

6.46 This threat covers malicious functionality added to equipment either intentionally by the third party supplier or covertly by a hostile actor who has access to the third party supplier’s hardware design or manufacture, or software development systems. As part of the public telecoms provider’s governance of their supply chain, they should assess whether the third party supplier’s corporate and development systems are sufficiently trustworthy given the sensitivity of the equipment being supplied and the information that will be made available to the third party supplier.

Interpretation of regulation 7(4)(a)(ii)

6.47 Where a public telecoms provider supplies its services to a different public telecoms provider in a higher tier, it is expected that only the part of the network or service that is being supplied needs to meet the security standards of the public telecoms provider in the higher tier. Where this is the case, public telecoms providers also need to ensure that the relevant parts of the network or service are sufficiently segregated from the rest of their operations. This will avoid the risk of bringing the wider operations of the public telecoms provider in a lower tier into the scope of regulation 7(4)(a)(ii) and having to hold more of their operations to the security standards of a higher tier.

Management of sites

6.48 Where public telecoms providers have network equipment and facilities within sites that are shared with other public telecoms providers, it is recommended that all public telecoms providers work together to set a consistent set of security measures that meet the regulations and that the site operator should follow.

Existing contracts and new contracts

6.49 In reference to the timeframes in Section 3, whether or not a contract with an existing supplier is ‘new’ should be defined in terms of whether the scope or scale of the contracted work changes. Therefore on this basis:

a renewal of a contract to continue completing the same work would not be defined as new;
software upgrades or service agreements that do not change the scope or scale of the work would not be defined as new (for example, a patch or general version of existing functionality would not be new);
a renewal of a contract which resulted in a software upgrade that leads to a change in the quality of service or enables a new service to be delivered would be new;
a renewal of a contract which resulted in the supply of updated, modified or new equipment hardware would be new;
where there is a framework arrangement in place with individual statements of work under this agreement then a change in either the framework contract or the individual statements of work would be in scope of a new contract if they change the scope or scale of the work; and
where an existing contract is amended to change the scope or scale of the work it would be new.

Chapter Crossovers

6.50 Information contained elsewhere in this Code of Practice is useful in understanding the supply chain requirements, including the following sections in particular:

Customer premises equipment (Chapter 3)
Countries listed in the Schedule (Chapter 4)
Keeping an offline copy (Chapter 8)
Governance (Chapter 9).

7. Prevention of unauthorised access or interference

7.1 This chapter provides guidance for public telecoms providers on the measures to be taken in accordance with Regulation 8 to prevent the occurrence of security compromises that consist of unauthorised access to their networks or services.

7.2 Regulation 8 is set out below.

8.—(1) A network provider or service provider must take such measures as are appropriate and proportionate to reduce the risks of the occurrence of security compromises that consist of unauthorised access to the public electronic communications network or public electronic communications service.

(2) The duty in paragraph (1) includes in particular a duty—

(a) to ensure that persons given responsibility for the taking of measures on behalf of the network provider or service provider for the purposes mentioned in section 105A(1) of the Act (“the responsible persons”) have an appropriate understanding of the operation of the network or service,

(b) to require multi-factor authentication for access to an account capable of making changes to security critical functions,

(c) to ensure that significant or manual changes to security critical functions must, before the change is made, be proposed by one person authorised by the network provider or service provider in question and approved by another person from among the responsible persons,

(d) to avoid the use of default credentials wherever possible, in particular by avoiding, as far as possible, the use of devices and services with default credentials that cannot be changed,

(e) where, despite sub-paragraph (d), default credentials have been used, to assume, for the purpose of identifying the risks of security compromises occurring, that any such default credentials are publicly available,

(f) to ensure that information which could be used to obtain unauthorised access to the network or service (whether or not stored by electronic means) is stored securely, and

(g) to carry out changes to security critical functions through automated functions where possible.

(3) A network provider must have in place, and use where appropriate, means and procedures for isolating security critical functions from signals which the provider does not believe on reasonable grounds to be safe.

(4) A network provider or service provider must limit, so far as is consistent with the maintenance and operation of the public electronic communications network or the provision of the public electronic communications service, the number of persons given security permissions and the extent of any security permissions given.

(5) A network provider or service provider must also—

(a) ensure that passwords and credentials are—

(i) managed, stored and assigned securely, and

(ii) revoked when no longer needed,

(b) take such measures as are appropriate and proportionate to ensure that each user or system authorised to access security critical functions uses a credential which identifies them individually when accessing those functions,

(c) take such measures as are appropriate and proportionate, including the avoidance of common credential creation processes, to ensure that credentials are unique and not capable of being anticipated by others,

(d) keep records of all persons who—

(i) in the case of a network provider, have access to the public electronic communications network otherwise than merely as end-users of a public electronic communications service provided by means of the network, and

(ii) in the case of a service provider, have access to the public electronic communications service otherwise then merely as end-users of the service, and

(e) limit the extent of the access to security critical functions given to a person who uses the network or service to that which is strictly necessary to enable the person to undertake the activities which the provider authorises the person to carry on.

(6) A network provider or service provider must ensure—

(a) that no security permission is given to a person while the person is in a country listed in the Schedule, and

(b) that any security permission cannot be exercised while the person to whom it is given is in a country so listed.

Key concepts for understanding the requirements

Explaining ‘access’ to the PECN or PECS

7.3 In this context, ‘access’ to a PECN or PECS covers both logical/virtual access and physical access by an individual as well as machine-to-machine access or access through Application Program Interfaces (API).

7.4 Regulation 8(6)(a) makes it clear that no security permissions shall be granted to any individual user, group, or class of users whilst in a country listed in the Schedule. Nor may any security permission be exercised by an individual user, group, class of users (either manually or through a system, or automated processes) whilst in a country listed in the Schedule.

Service accounts

7.5 A Service account is an account not associated with a user that is used to run applications, virtual machines, automated services or other background processes. It can also be used as a proxy to perform tasks on behalf of a user. These accounts often have widespread, high privilege access and are therefore a prime target for compromise by threat actors.

Guidance

7.6 Public telecoms providers shall minimise the use of service accounts, consider whether privileged access is required for each task, follow the role-based, least privilege model and document the service accounts in an appropriate central repository.

7.7 A privileged access solution that securely stores, rotates, and propagates credentials frequently should be used to manage service accounts.

7.8 Passwords shall not be stored in scripts, other unprotected systems, logs, documents, or hardcoded into any system or script.

7.9 Service accounts shall be dedicated to the task or service they have been assigned to (i.e. not associated with a user).

7.10 Service accounts shall be audited regularly to remove orphaned service accounts that are no longer required or used, and to detect suspicious behaviours.

Application Programming Interfaces (API)

7.11 Application Programming Interfaces have many uses and can be a powerful tool in a developer’s armoury. Unfortunately, this makes them a valuable target for an attacker to compromise, especially for exfiltrating data.

Guidance

7.12 Public telecoms providers shall minimise exposure of APIs to the Internet and/or unauthorised parties.

7.13 Public telecoms providers shall make sure they don’t expose paths or endpoints that should not be accessed. For example, but not limited to, admin pages or test APIs to the Internet.

7.14 Public telecoms providers shall actively block known malicious IP addresses and domains, or categories of IPs that should not be accessing the API. For example, IP addresses associated with anonymisation proxies or similar.

7.15 Unless a risk assessment deems otherwise, authentication, using a recognised authentication scheme, shall be used to ensure that only authorised users and applications can access the API. Public telecoms providers are advised against using ‘basic authentication’. For a private API or one that’s hosted for a small community a public telecoms provider should also consider mutual authentication at the network layer, for example mTLS, as well as authentication at the API layer.

7.16 Public telecoms providers shall risk assess the data being exposed and who needs access to it. This shall be limited to only the data that is required for the service or function to operate and shall be protected accordingly. Consideration should be given to confidentiality and network availability.

7.17 Access shall be based on the role-based, least privilege model, and used to restrict access to specific API endpoints based on user roles and permissions.

7.18 Public telecoms providers shall perform input validation, to ensure that any request conforms to the API specification or schema to ensure that an attacker cannot add in any data, or any invalid inputs and file sizes should be limited.

7.19 Public telecoms providers should consider scanning for known attack vectors, malware or malicious content.

7.20 Public telecoms providers shall implement rate limiting to prevent abuse, such as brute-force attacks or denial-of-service attempts, and should consider using the services of a DDOS mitigator.

7.21 Public telecoms providers shall consider using an API gateway or similar to centralise and manage access control, traffic management, and security policies.

7.22 Logging and monitoring shall be implemented to detect and respond to suspicious or unauthorised activity.

7.23 Public telecoms providers shall ensure APIs are clearly documented in an appropriate central repository along with any associated token expiry and revocation processes.

7.24 Public telecoms providers shall ensure that any application that receives data over the API has gone through a secure development and testing process, to mitigate the risk of business logic errors and/or bugs and that it functions as expected.

7.25 Public telecoms providers shall implement a change control process for any changes to API specifications or schemas.

7.26 More advice can be found on the NCSC website.^{[footnote 46]}

Chapter Crossovers

7.27 Information contained elsewhere in this Code of Practice is useful in understanding the prevention of unauthorised access or interference, including the following sections in particular:

Security Critical Functions (Chapter 1)
Network Oversight Functions (Chapter 1)
Management plane, especially browse up architectures (Chapter 2)
Countries listed in the Schedule (Chapter 4)
Third party administrators (Chapter 6)
Testing (Chapter 13).

8. Preparing for remediation and recovery

8.1 This chapter provides guidance for public telecoms providers on the measures to be taken in accordance with Regulation 9 to prepare for the occurrence of security compromises with a view to limiting the adverse effects of security compromises and being able to recover from them.

8.2. Regulation 9 is set out below.

9.—(1) A network provider or service provider must take such measures as are appropriate and proportionate to prepare for the occurrence of security compromises with a view to limiting the adverse effects of security compromises and enabling the provider to recover from security compromises.

(2) The duty in paragraph (1) includes in particular a duty—

(a) to create or acquire, for the purposes mentioned in that paragraph, and to retain within the United Kingdom— (i) an online copy of information necessary to maintain the normal operation of the public electronic communications network or public electronic communications service, and

(ii) so far as is proportionate, an offline copy of that information,

(b) to replace copies held for the purpose of sub-paragraph (a) with reasonable frequency, appropriate to the assessed security risk of the network or service,

(c) to have means and procedures in place—

(i) for promptly identifying the occurrence of any security compromise and assessing its severity, impact and likely cause,

(ii) for promptly identifying any mitigating actions required as a result of the occurrence of any security compromise,

(iii) where the occurrence of a security compromise gives rise to the risk of a connected security compromise, for preventing the transmission of signals that give rise to that risk,

(iv) for dealing with the occurrence of a security compromise within a reasonable period appropriate to the assessed security risk of the network provider or service provider, and without creating any risk of a further security compromise occurring,

(v) for ensuring that, if the network provider or service provider is unable to take steps for the purposes of preventing any adverse effects (on the network or service or otherwise) arising from the occurrence of a security compromise within the period of 14 days beginning with the day on which it occurs, the network provider or service provider is able to prepare a written plan as to how and when the provider will take such measures,

(vi) for dealing with any unauthorised access to, or control over, security critical functions by taking action as soon as reasonably possible, and without creating any risk of a further security compromise occurring, to ensure that only authorised users have access to the network or service, and

(vii) for replacing information damaged by security compromises with the information contained in the copy referred to in sub-paragraph (a).

(3) For the purposes of paragraph (2)(a)—

(a) an ‘online copy’ is a copy that is held on the public electronic communications network or public electronic communications service in question, and

(b) an ‘offline copy’ is a copy that is stored in such a way that it is not exposed to signals conveyed by means of the network or service in question.

Key concepts for understanding the requirements

Information necessary to maintain the normal operation of the network/service

8.3 Public telecoms providers should adopt a comprehensive approach and carefully consider the entire Code of Practice. Special attention should be given to this chapter, as many of the measures set out in regulation 9, are also addressed in other sections of the Code in more detail.

8.4 Regulation 9(2)(a)-(b) sets out requirements in relation to the information that providers must create, acquire or retain within the UK and replace with reasonable frequency in order to ensure the normal operation of the relevant network or service. As to the format of such information, providers must hold:

a copy of this information on the network or service in question (i.e. an ‘online copy’) and;
so far as is proportionate, a copy that is stored in such a way that it is not exposed to signals conveyed by means of the network or service in question (i.e. an ‘offline copy’).

8.5 The aim of these requirements is to ensure that public telecoms providers’ networks and services are resilient to security compromises, such that the impacts to end-users are kept to a minimum. This should be fulfilled by having access to the information which is necessary to get networks or services back up and running. For the avoidance of doubt, these requirements are not in place to ensure that public telecoms providers replace all user data that may have been lost during a security compromise.

Keeping an offline copy

8.6 Regulation 9(3)(b) defines an ‘offline copy as “a copy that is stored in such a way that it is not exposed to signals conveyed by means of the network or service in question”. Keeping an offline copy of this information could be achieved through cloud backups, where the cloud service is not itself a part of the network it is backing up and not exposed to signals from the network.

8.7 When the offline backup is not in use it needs to be digitally disconnected. Unlike conventional backup storage, it is not possible to take cloud storage offline by simply unplugging it. However, steps can be taken to apply a similar level of protection:

Identity management – the first step to protect cloud storage is secure account identity. All users able to access cloud backups should be properly protected in line with NCSC advice.^{[footnote 47]} Without a trusted identity, ransomware should not be able to request access to a public telecoms provider’s cloud storage and encrypt it without the public telecoms provider’s permission.
Client management – a backup client is a device with credentials to access cloud storage. Cloud backup clients should not have valid credentials while the cloud storage is not in use. The number of backup clients should also be kept to a minimum with standard user devices unable to modify cloud backups directly. If this practice is followed, a ransomware infection can only compromise the cloud backup if it occurs on an authorised client and while the cloud backup is being used.
Access control – access control should be configured to only allow authorised clients to create new backups (or append to existing ones) and deny connection requests while the storage is not in use (‘cold’ storage). If a ransomware infection occurs while the cloud backup is offline, it will be denied connection requests. This means it will not be able to reach the cloud storage, giving the same level of confidence as unplugging an on-premises storage drive.
Back up plan – some cloud storage services allow a user to restore modified data back to an older version and recover deleted data for a limited time after it was deleted. If ransomware does manage to affect the cloud backup, these features can be used to restore back to the last known-good state.
Guidance on configuring cloud backups to be resilient to destructive actions can be found on the NCSC website – Principles for ransomware resistant cloud backups.^{[footnote 48]}

8.8 Additional guidance with regards to backups can be found on the NCSC website.^{[footnote 49]}

Recovery

8.9 Backups should be created on a regular basis. The more frequently backups are created, the less data is required to be recovered in the event of an incident. Backups, including offline backups, should also be regularly tested to check they allow the data and network to be recovered effectively. For more information, providers should refer to NCSC advice on response and recovery planning.^{[footnote 50]}

Retention of copies within the UK

8.10 For resilience and continuity purposes, Regulation 9(2)(a) requires public telecoms providers to retain copies of information within the UK which is necessary to maintain the normal operation of the network or service. This does not prevent copies being held elsewhere as part of a global business operation.

Chapter Crossovers

8.11 Information contained elsewhere in this Code of Practice is useful in understanding remediation and recovery, including the following sections in particular:

Security Critical Functions (Chapter 1)
National resilience (Chapter 2)
Countries listed in the Schedule (Chapter 4)
Governance (Chapter 9).

9. Governance

9.1 This chapter provides guidance for public telecoms providers on the measures to be taken in accordance with Regulation 10 to ensure appropriate and proportionate management of the persons who are given security-related tasks. This is intended to ensure that providers employ the appropriate security governance and business processes to protect UK networks and services.

9.2 Regulation 10 is set out below.

10.—(1) A network provider or service provider must ensure appropriate and proportionate management of persons given responsibility for the taking of measures on behalf of the provider for the purposes mentioned in section 105A(1) of the Act.

(2) The duty in paragraph (1) includes in particular a duty—

(a) to establish, and regularly review, the provider’s policy as to measures to be taken for the purposes mentioned in section 105A(1) of the Act,

(b) to ensure that the policy includes procedures for the management of security incidents, at varying levels of severity,

(c) to have a standardised way of categorising and managing security incidents, and

(d) to ensure that the policy provides channels through which risks identified by persons involved at any level in the provision of the network or service are reported to persons at an appropriate governance level,

(e) to ensure that the policy provides for a post-incident review procedure in relation to security incidents and that the procedure involves consideration of the outcome of the review at an appropriate governance level and the use of that outcome to inform future policy, and

(f) to give a person or committee at board level (or equivalent) responsibility for—

(i) supervising the implementation of the policy, and

(ii) ensuring the effective management of persons responsible for the taking of measures for the purposes mentioned in section 105A(1) of the Act.

(3) In paragraph (2) ‘security incident’ means an incident involving—

(a) the occurrence of a security compromise, or

(b) an increased risk of a security compromise occurring.

(4) A network provider or service provider must take such measures as are appropriate and proportionate to identify and reduce the risks of security compromises occurring as a result of unauthorised conduct by persons involved in the provision of the public electronic communications network or public electronic communications service.

Key concepts for understanding the requirements

Supporting business processes

9.3 Having an effective security governance framework ensures that procedures, personnel, physical and technical controls continue to work through the lifetime of a network and across the entire business. Without effective governance, it is likely that security improvements will not be sustained or consistent and are likely to leave gaps that can be exploited. Any technical controls deployed outside of an effective security governance framework will be fundamentally undermined and could constrain the business in the future.

9.4 The following guidance in paragraphs 9.5-9.9 highlights the key business processes for public telecoms providers to understand and implement, providing examples and background information where appropriate.

Top‑to‑bottom security governance

9.5 For a public telecoms provider to effectively deliver the requirements of the security framework, it is critical that the whole business has the proper processes and business functions in place to backup and support the appropriate security measures. As such, the security direction of public telecoms providers must have buy-in at all levels. A nominated person or committee at board level (or a person or committee having an equivalent level of responsibility and status) shall have overall responsibility and accountability for security and should champion all security initiatives throughout the organisation and have sufficient knowledge and competency to discharge these responsibilities. Public telecoms providers should refer to NCSC advice on security governance and security policies.^{[footnote 51]}

9.6 Regulation 10(2)(d) requires public telecoms providers to ensure that their security policy “provides channels through which risks identified by persons involved at any level in the provision of the network or service are reported to persons at an appropriate governance level”. This requirement aims to ensure (among other things) that public telecoms providers’ policies include a way to communicate security issues and risks to the top of the organisation, without risk of dilution.

Security and operational changes

9.7 Given the scale of some public telecoms providers’ networks, one of the greatest challenges may be ensuring that security teams are aware of the changes being made by operational teams. Before any decision is made that could impact the network, its operation, or management, the risks should be assessed with the support of the security team. Ideally this should be part of an automated process.

Learning from incidents

9.8 Security incidents that occur within public telecoms providers’ networks are not only a learning opportunity for those public telecoms providers, but also for the sector as a whole. So far as is appropriate and proportionate, public telecoms providers should share information about significant past issues or compromises with other public telecoms providers via suitable trusted groups. Public telecoms providers are also strongly encouraged to feedback their findings from incidents to enhance future versions of this document and the security of the sector as a whole. More information for providers on learning from incidents can be found on the NCSC website.^{[footnote 52]}

The Cyber Assessment Framework (CAF)

9.9 The relevant parts of the CAF that providers shall have regard to in order to ensure that they have appropriate business processes in place are contained within Annex C of this Code of Practice. Any relevant updates that are made to the guidance in the CAF will be reflected in an updated annex within future versions of the Code of Practice. Should any differences arise between the interpretation of the CAF measures in Annex C, and the guidance in the main body of the Code of Practice, the Code shall take precedence.

Chapter Crossovers

9.10 Information contained elsewhere in this Code of Practice is useful in understanding governance, including the following sections in particular:

Security Critical Functions (Chapter 1)
Competency (Chapter 12).

10. Reviews

10.1 This chapter provides guidance for public telecoms providers on the measures to be taken in accordance with Regulation 11 to ensure that regular reviews of their security measures are undertaken.

10.2 Regulation 11 is set out below.

11.A network provider or service provider must—

(a) undertake regular reviews of the provider’s security measures in relation to the public electronic communications network or public electronic communications service, taking into account relevant developments relating to the risks of security compromises occurring, and

(b) undertake at least once in any period of 12 months a review of the risks of security compromises occurring in relation to the network or service in order to produce a written assessment of the extent of the overall risk of security compromises occurring within the next 12 months, taking into account—

(i) in the case of a network provider, risks identified under regulation 3(3)(a),
(ii) risks identified under regulation 5(2),
(iii) risks identified under regulation 6(1),
(iv) risks identified under regulation 7(1),
(v) risks identified under regulation 10(4),
(vi) the results of reviews carried out in accordance with sub-paragraph (a),
(vii) the results of tests carried out in accordance with regulation 14, and
(viii) any other relevant information.

Key concepts for understanding the requirements

Clarifying ‘any other relevant information’ in Regulation 11(b)(viii)

10.3 In undertaking their annual reviews under Regulation 11(b), public telecoms providers must take into account the risks and results listed in Regulation 11(b)(i)-(viii) and “any other relevant information” (Regulation 11(b)(viii)). This latter category of information may include, for example, ‘event correlation analysis’ where relevant. This is where security incidents have been identified by public telecoms providers which may not have amounted to security compromises, but showed similar root causes and can be classified as near misses. These security incidents are important in assessing the risks of security compromises going forward and should therefore be integrated into the reviews process.

Risks to be considered within risk assessments

10.4 Public telecoms providers should refer to the NCSC advice on risk management.^{[footnote 53]} The risk assessment that these providers must carry out as a part of the reviews process under Regulation 11 should be looking at not only the risks to the public telecoms provider’s business and network, but also the risks to end users. This includes, but is not limited to, the risks of loss of availability and of personal data leaks.

10.5 Public telecoms providers should consider threat modelling existing and new services to help with their risk assessments.

10.6 Risk management is a continuous activity and should be regularly reviewed, especially when there are any changes.

Chapter Crossovers

10.7 Information contained elsewhere in this Code of Practice is useful in understanding Reviews, including the following sections in particular:

Security Critical Functions (Chapter 1)
Signalling plane (Chapter 2)
Countries listed in the Schedule (Chapter 4)
Third party administrators (Chapter 6)
Governance (Chapter 9).

11. Patching and updates

11.1 This chapter provides guidance for public telecoms providers on the measures to be taken in accordance with Regulation 12 to deploy patches or mitigations (including software updates and equipment replacement) as well as the necessary security updates and equipment upgrades.

11.2 Regulation 12 is set out below.

12.A network provider or service provider must—

(a) where the person providing any software or equipment used for the purposes of the public electronic communications network or public electronic communications service makes available a patch or mitigation relating to the risks of security compromises occurring (including software updates and equipment replacement), take such measures as are appropriate and proportionate to deploy the patch or mitigation within such period as is appropriate in the circumstances having regard to the severity of the risk of security compromise which the patch or mitigation addresses,

(b) identify any need for a security update or equipment upgrade and implement the necessary update or upgrade within such period as is appropriate, having regard to the assessed security risk of the network provider or service provider, and

(c) arrange for any decision as to what period the network provider or service provider considers appropriate—

(i) for the purposes of sub-paragraph (a), in a case where the network provider or service provider considers in relation to a particular patch or mitigation that a period of more than 14 days beginning with the day on which the patch or mitigation becomes available is appropriate, or

(ii) for the purposes of sub-paragraph (b), in a case where there is a significant risk of a security compromise occurring,

to be taken at an appropriate governance level and recorded in writing.

Key concepts for understanding the requirements

Guidance on the appropriate patching period for network equipment

11.3 Regulation 12(a) requires providers to take appropriate and proportionate measures to deploy any relevant patch or mitigation that becomes available “within such period as is appropriate in the circumstances having regard to the severity of the risk of security compromise which the patch or mitigation addresses”. Table 2 contains guidance on which time periods for patching network equipment are appropriate in different situations, based on how critical the vulnerabilities are and whether they are internally or externally exposed interfaces. These timeframes are intended to ensure that patches are deployed in a way that is proportionate with the risk that the patch addresses. They also seek to counter the risks posed by threat actors who regularly target vulnerabilities soon after patches are made available, often by using easy, cheap and commercially available tools. Public telecoms providers should act swiftly to close these vulnerabilities and in all cases should look to implement patches for network equipment as soon as is practicable and no later than the timeframes in Table 2.

Table 2: Criticality and exposure‑adjusted maximum timeframes for application of patches (from supplier release date)

	Actively exploited in the wild	Critical vulnerability CVSS 9.0 – 10	High vulnerability CVSS 7.0 – 8.9	Other
Externally exposed interface	14 days	14 days	30 days	90 days
Internally exposed interface	14 days	30 days	90 days	As part of normal patching cycle

Guidance

11.4 It is recommended that public telecoms providers request that network equipment suppliers provide important security patches separately to feature updates. It is also recommended that public telecoms providers establish automated and scaled testing processes, and are in control of when and how they take place. This will allow the public telecoms provider to validate that patches will not disrupt the resilience of the network in a timely manner and accelerate rollout. Public telecoms providers shall ensure that they remove any dependence upon any features that are due to be deprecated.

11.5 Where relevant, patches that justifiably need more time than 14 days to be deployed (as outlined in Table 2), Regulation 12(c) requires providers to arrange for any such decisions to be taken at an appropriate governance level and recorded in writing. Providers should ensure that these decisions are based on a rigorous risk assessment process and that robust alternative mitigations are put in place until the relevant patch has been deployed.

11.6 In light of the evolving threat landscape and the increased risk posed by sophisticated threat actors targeting public telecoms providers, it is recommended that network equipment be periodically restarted to mitigate non-persistent malware, which is often difficult to detect. Such restarts should be incorporated into routine patching and upgrade cycles where feasible. Where restarts are not inherently part of the upgrade process, public telecom providers should identify and prioritise high-risk equipment (including devices which are critical to network operations, exposed to external interfaces, or hosting sensitive functions or sensitive data) and implement controlled restart procedures that maintain service resilience and minimise impact on availability.

Governance for decisions about routine maintenance

11.7 Security should form part of the network’s routine maintenance. If a routine security update is postponed, for example due to a network incident, then it must be implemented in the next round of updates or sooner. Should any security functionality be reduced and lead to a significant risk of a security compromise occurring, then public telecoms providers must ensure that the associated risk assessment and the acceptance of the additional risk is signed off by a nominated person or committee at board level (or a person or committee having an equivalent level of responsibility and status) with sufficient knowledge and competency to discharge these responsibilities, as in Regulation 12(c).

11.8 Public telecoms providers should consider putting controls in place to manage their vendors’ automated updates. All updates should be under control of the public telecoms provider.

Chapter Crossovers

11.9 Information contained elsewhere in this code of practice is useful in understanding patching, including the following sections in particular:

Customer Premises Equipment (Chapter 3)
Governance (Chapter 9).

12. Competency

12.1 This chapter provides guidance for public telecoms providers on the measures to be taken in accordance with Regulation 13 to ensure that the persons who have been given security-related tasks can appropriately discharge their duties.

12.2 Regulation 13 is set out below for reference.

13.—(1) A network provider or service provider must take such measures as are appropriate and proportionate to ensure that persons given responsibility for the taking of measures on behalf of the provider for the purposes mentioned in section 105A(1) of the Act (“the responsible persons”)—

(a) are competent to discharge that responsibility, and

(b) are given resources to enable them to do so.

(2) The duty in paragraph (1) includes in particular a duty to take such measures as are appropriate and proportionate—

(a) to ensure that the responsible persons have appropriate knowledge and skills to perform their responsibilities effectively,

(b) to ensure that the responsible persons are competent to enable the network provider or service provider to perform the provider’s duties under regulation 6, and are given resources for that purpose,

(c) to ensure that the responsible persons—

(i) are competent to show appropriate understanding and appraisal of the activities of third party suppliers and of any recommendations made by third party suppliers for the purposes of identifying and reducing the risk of security compromises occurring, and

(ii) are given resources for that purpose, and

(d) where new equipment is supplied, provided or made available by a third party supplier—

(i) to ensure that the equipment is set up according to a secure configuration approved by appropriately trained security personnel, following procedures which enable it to be demonstrated that the configuration has been carried out in that way, and

(ii) to record any failure to meet recommendations of the third party supplier as to the measures that are essential to reduce the risk of security compromises occurring as a result of the way in which the equipment is set up.

(3) In paragraph (2)(c) and (d) ‘third party supplier’ has the meaning given by regulation 7(2).

Key concepts for understanding the requirements

In‑house competency

12.3 Regulation 13(2)(c)-(d) sets out competency requirements for in-house staff in relation to the activities of third party suppliers, their recommendations and the equipment supplied, provided or made available by them.

Guidance

12.4 Where a public telecoms provider is using a third party supplier, in-house staff of both parties need to be competent and able to take appropriate steps to identify and resolve security issues. This is to avoid public telecoms providers relying on the competency of 3PAs, as third parties may not always be available to address security issues.

12.5 Public telecoms providers should also ensure that adequate, appropriate and relevant security training is undertaken by anyone who interacts with Security Critical Functions or sensitive data. For those involved in the security of Security Critical Functions, focussed cyber security training and evaluation should be carried out, including providing staff with an understanding of how a telecommunications network is compromised. Further guidance on staff training can be found on the NCSC website.^{[footnote 54]}

Chapter Crossovers

12.6 Information contained elsewhere in this Code of Practice is useful in understanding Competency, including the following sections in particular:

Security Critical Functions (Chapter 1)
Supporting business processes (Chapter 9)
Monitoring and analysis (Chapter 5)
Third party administrators (Chapter 6).

13. Testing

13.1 This chapter provides guidance for public telecoms providers on the measures to be taken in accordance with Regulation 14 to carry out, or arrange for a suitable person to carry out, appropriate tests.

13.2 Regulation 14 is set out below.

14.—(1) A network provider or service provider must at appropriate intervals carry out, or arrange for a suitable person to carry out, such tests in relation to the network or service as are appropriate and proportionate for the purpose of identifying the risks of security compromises occurring in relation to the public electronic communications network or public electronic communications service.

(2) The tests must involve simulating, so far as is possible, techniques that might be expected to be used by a person seeking to cause a security compromise.

(3) The network provider or service provider must ensure, so far as is reasonably practicable—

(a) that the manner in which the tests are to be carried out is not made known to the persons involved in identifying and responding to the risks of security compromises occurring in relation to the network or service or the persons supplying any equipment to be tested, and

(b) that measures are taken to prevent any of the persons mentioned in sub-paragraph (a) being able to anticipate the tests to be carried out.

(4) The references to tests in relation to the network or service include references to tests in relation to—

(a) the competence and skills of persons involved in the provision of the network or service, and

(b) the possibility of unauthorised access to places where the network provider or service provider keeps equipment used for the purposes of the network or service.

Key concepts for understanding the requirements

Security Testing

13.3 Alongside the usual testing as part of any service or product, public telecoms providers should also perform security functionality^{[footnote 55]} testing. This should include, but is not limited to, testing the following:

Authentication
Authorisation
Access Control
Encryption
Intrusion Detection and Prevention
Security logging and auditing
Patch Management, including hardening
Backup and recovery
Incident management response

Guidance

13.4 Public telecoms providers should take a holistic approach to security testing, which includes security testing that is appropriate, risk-based, and tailored to their specific deployments.

13.5 As the security threats are continually evolving, security testing should not be seen as a one-off exercise and instead should be a continual process at all stages of the product or service lifecycle, from procurement to upgrades and eventually to decommissioning.

13.6 It should be noted that whilst public telecoms providers can outsource various aspects of testing, they remain accountable and responsible for satisfying themselves that the tests meet their requirements, and for assessing and documenting the risks.

Hardening testing

13.7. Public telecoms providers shall test that the hardening standards and/or vendor recommendations have been applied correctly and consistently. This should include, but is not limited to, testing to ensure that all default passwords have been removed and/or changed, that ports and services not required are closed, that the software used is current and in support, and that appropriate patches have been applied.

Guidance

13.8 It is important to ensure that the hardened configuration is retained after any patches, upgrades or investigations and is regularly reviewed, tested and audited against up-to-date hardening baselines.

Penetration testing

13.9 The purpose of testing, or ‘red team’ exercising, is to verify the security defences of the network, and identify any security weaknesses prior to any potential attackers exploiting them. For this reason, it is essential that the testing simulates, so far as possible, real-world attacks.

Guidance

13.10 To achieve this, the following criteria should be in place:

testers or red teams should not be unnecessarily constrained;
defensive teams should not be tipped-off in advance;
monitoring teams should not know the testing is happening (to test their capabilities);
defensive mechanisms should not be modified based on testers’ plans;
testing should be done by sufficiently skilled persons who are fully independent from the team that built and maintain the system under test, and should not be used for routine testing (and compliance); and
scope, tests and results are transparent to Ofcom.

13.11 A strongly recommended example of this type of testing is Ofcom’s TBEST scheme, which can be tailored and focused to meet specific objectives.

Negative testing

13.12 Negative testing is the process of validating the application against invalid inputs. Invalid data is used in testing to compare the output against the given input and the results are monitored for potential vulnerabilities.

Guidance

13.13 Public telecoms providers should satisfy themselves that any testing carried out includes negative testing.

Regular testing

13.14 Automated scanning for vulnerabilities, missing patches and configuration changes is highly recommended. The amount of time a vulnerability is exploitable can be significantly reduced when supported by a process to investigate any anomalies, and remediate or mitigate any findings.

Guidance

13.15 Where it is not possible to remediate or mitigate findings then a risk assessment should be performed and documented.

Incident Response Exercising

13.16 A well-socialised and up-to-date incident response plan that is regularly exercised, is important to mounting an effective and efficient response to an incident when it occurs. This will allow those involved in a response to: understand their roles; help identify any weaknesses in plans and your organisational response; and identify areas in the plan for refinement.

Guidance

13.17 When remediating the findings of tests, the remediation should be carried out across the whole systems’ estate, not just the devices that have been tested.

Tests against equipment locations

13.18 The tests covered by Regulation 14 include those in relation to “the possibility of unauthorised access to places where the network provider or service provider keeps equipment used for the purposes of the network or service” (Regulation 14(4)(b)). This requirement should be read in conjunction with other security requirements concerning the equipment location, such as Regulation 3(3)(a)(iii).

Guidance

13.19 Testing should ensure that the physical security of the buildings, server rooms and network equipment that provide services into the UK meet best-practice standards. Advice produced by the National Protective Security Authority (NPSA) should be consulted for physical and personnel-related security.^{[footnote 56]}

13.20 The Code of Practice does not cover safety planning such as fire drills, as these should be covered by the general planning and health and safety requirements for buildings.

Chapter Crossovers

13.21 Information contained elsewhere in this Code of Practice is useful in understanding Testing, including the following sections in particular:

Signalling plane (Chapter 2)
Third-party administrators (Chapter 6)
Prevention of unauthorised access or interference (Chapter 7)
Competency (Chapter 12).

14. Assistance

14.1 This chapter provides guidance for public telecoms providers on the measures to be taken in accordance with Regulation 15 to reduce the risk of security compromise by seeking and providing appropriate assistance.

14.2 Regulation 15 is set out below.

15.—(1) Where—

(a) a security compromise occurs in relation to a public electronic communications network or public electronic communications service, and

(b) it appears to the network provider or service provider (“the relevant person”) that the security compromise is one that may cause a connected security compromise in relation to another public electronic communications network or public electronic communications service, the relevant person must, so far as is appropriate and proportionate, provide information about the security compromise to the network provider or service provider in relation to the other network or service.

(2) Information provided under paragraph (1) which relates to a particular business may not, without the consent of the person carrying on the business—

(a) be used or disclosed by the recipient otherwise than for the purpose of identifying or reducing the risk of security compromises occurring in relation to the recipient’s network or service or preventing or mitigating the adverse effects of security compromises that have occurred in relation to the recipient’s network or service, or

(b) be retained by the recipient any longer than is necessary for that purpose.

(3) A network provider (‘provider A’) must, when requested by a service provider or another network provider (‘provider B’), give provider B such assistance as is appropriate and proportionate in the taking by provider B of any measure required by these Regulations in relation to anything that—

(a) has occurred in relation to provider A’s public electronic communications network,

(b) is a security compromise in relation to that network, and

(c) may cause a connected security compromise in relation to provider B’s public electronic communications network or public electronic communications service.

(4) A service provider (‘provider A’) must, when requested by a network provider or another service provider (‘provider B’), give provider B such assistance as is appropriate and proportionate in the taking by provider B of any measure required by these Regulations in relation to anything that—

(a) has occurred in relation to provider A’s public electronic communications service,

(b) is a security compromise in relation to that service, and

(c) may cause a connected security compromise in relation to provider B’s public electronic communications network or public electronic communications service.

(5) A network provider or service provider must, where necessary to reduce the risk of security compromises occurring in relation to the provider’s public electronic communications network or public electronic communications service, request another person to give any assistance which paragraph (3) or (4) will require the other person to give.

Key concepts for understanding the requirements

14.3 In certain circumstances it is appropriate for public telecoms providers to receive information from other public telecoms providers that would help to reduce the risk of security compromises occurring (Regulation 15(1)). Whilst not required by Regulation 15, public telecoms providers may also consider whether it is appropriate in certain circumstances to share information with other types of bodies/organisations such as:

educational institutions;
security organisations; and
UK government cyber security experts.

14.4 All information to be provided under Regulation 15(1) should be shared swiftly to ensure recipients are able to address risks effectively.

Guidance

14.5 Subject to competition law, public telecoms providers should establish agreements with other public telecoms providers around mutual assistance and information sharing, as envisaged by the regulations, in the event of an incident or compromise. By establishing such agreements in advance, assistance can be given to other public telecoms providers during an incident without compromising the security of their own networks, systems or data.

Chapter Crossovers

14.6 Information contained elsewhere in this Code of Practice is useful in understanding assistance, including the following sections in particular:

Supply chain (Chapter 6)
Governance (Chapter 9).

Question 4

Section 3: Technical guidance measures

Accepted Answer

Specific technical and procedural measures to be taken by public telecoms providers are set out below, grouped by the date by which they are expected to be completed. However, this does not preclude public telecoms providers from implementing measures before these dates where it is prudent to do so, and this should be actively encouraged where possible. It remains an expectation that public telecoms providers take a holistic approach. Each individual guidance measure is mapped to the relevant security requirements in the regulations, including Regulations which may be indirectly linked to the guidance measure (for example, failing to block certain signals might suggest that the network has not been appropriately monitored).

It should be noted, however, that the extent to which each technical and procedural guidance measure can contribute to ensuring compliance with any specific regulation will depend on the facts of each case. The mapping of measures to regulations in this section is therefore only indicative and non-exhaustive.

The following measures should be completed by 31 March 2024 (Tier 1 public telecoms providers) or by 31 March 2025 (Tier 2 public telecoms providers).

Overarching security measures

Measure number	Description	Relevant Regulation(s)
M1.01	Public telecoms providers^{[footnote 57]} shall maintain accurate records of all externally-facing systems.	3(3)(c),(d),(e) 3(4) 3(5) 4(4)(b) 6(4) 8(3)
M1.02	Security testing on externally-facing systems, excluding CPE, should normally be performed at least every 2 years, and in any case shortly after a significant change occurs.	3(3)(a)(iv) 3(3)(c),(d),(e) 3(5) 4(4)(b) 8(3) 14
M1.03	Equipment in the exposed edge shall not host sensitive data or Security Critical Functions.	3(3)(a),(d) 3(5) 4(1)(a),(b) 4(2)(a),(b) 4(4)(b)
M1.04	Physical and logical separation shall be implemented between the exposed edge and Security Critical Functions. Note that this measure may not be necessary once datasets and functions can be cryptographically-protected from compromise.	3(3)(c),(d),(e) 3(5) 4(4)(b)
M1.05	Security boundaries shall exist between the exposed edge and critical or sensitive functions that implement protective measures.	3(3)(c),(d) 3(5) 4(4)(b)
M1.06	Equipment in the exposed edge shall not be able to impact operation or routing within the core network. As an example, the exposed edge shall not be a PE-node within the provider’s IP Core.	3(3)(c),(d) 3(5) 4(4)(b)

Management plane 1

Measure number	Description	Relevant Regulation(s)
M2.01	Privileged user access rights shall be regularly reviewed and updated as part of business-as-usual management. This shall include updating privileged user rights in line with any relevant changes to roles and responsibilities within the organisation as required by the role-based, least privilege model.	8(4) 8(5)(a),(b),(e) 11(a)
M2.02	All privileged access shall be logged.	4(4)(b) 6(2)(a),(b) 6(3)(a),(b) 8(5)(a) 8(5)(d)(i),(ii)
M2.03	Privileged access shall be via secure, encrypted and authenticated protocols whenever technically viable.	4(4) 8(4) 8(5)(e)
M2.04	Management protocols that are not required shall be disabled on all network functions and equipment	3(3)(e) 7(4)(a)(ii) 8(4) 8(5)(e)
M2.05	Default passwords shall be changed upon initialisation of the device or service and before its use for the provision of the relevant network or service.	3(3)(e) 7(4)(b) 8(2)(d) 8(4) 8(5)(b),(c) 14(1)
M2.06	The infrastructure used to support a public telecoms provider’s network shall be the responsibility of the public telecoms provider, or another entity that adheres to the regulations, measures and oversight as they apply to the public telecoms provider (such as a third party supplier with whom the public telecoms provider has a contractual relationship). Where the public telecoms provider or other entity adhering to the regulations has responsibility, this responsibility shall include retaining oversight of the management of that infrastructure (including sight of management activities, personnel granted management access, and management processes).	3(3)(d) 3(3)(f)(i),(ii),(iii) 3(5) 6(3)(d) 7(4)(a) 8(1) 8(6)

Signalling plane 1

Measure number	Description	Relevant Regulation(s)
M3.01	Public telecoms providers shall understand how incoming signalling arrives into their network, and outgoing signalling leaves their network. Specifically, the interfaces over which signalling enters and leaves the network, and the equipment which sends and processes external signalling.	3(3)(a),(b),(c) 4(4)(b),(c) 8(2)(a)
M3.02	Public telecoms providers shall have an appropriate understanding of what network equipment could be impacted by malicious signalling.	3(3)(a),(b),(d) 4(6)(a) 6(1) 6(4) 7(4)(a)(i)
M3.03	Public telecoms providers shall have an appropriate understanding of what network and user data could be compromised through malicious signalling.	3(3)(a),(b) 4(1)(a) 6(1) 6(2)(a),(b) 6(4) 8(2)(a)
M3.04	Public telecoms providers shall understand who they directly connect with over the signalling network and operate on the principle that incoming signals are from untrusted networks.	3(3)(a),(b) 6(1) 6(2)(a) 6(4) 7(1) 7(4)(a)(i),(ii),(iii)
M3.05	At edge signalling nodes, public telecoms providers shall block any incoming message using any source address internal to the public telecoms provider’s network.	3(3)(a),(d),(e) 4(4)(b) 6(3)(d)
M3.06	Trust shall not be assumed based on the source of any incoming message/signals. For example, ‘UK’ source addresses (e.g. +44 global titles in SS7) shall not be assumed to be trusted and shall not be allowed by default.	3(3)(e) 4(4)(b),(c) 6(3)(d)
M3.07	Where the signalling message is protected by end-to-end authentication, risk decisions and associated security controls may be determined based upon the authenticated source.	3(3)(e) 4(4)(b) 6(3)(d)
M3.08	Where public telecoms providers allow others to use number ranges or other identifiers that have been allocated to them (e.g. GTs, IMSIs), they remain responsible for the activity related to that number range or identifier, and any further security implications. This does not apply in the case of MSISDNs shared through MNP.	3(3)(e) 4(1)(a),(b) 4(4)(b) 6(3)(d)
M3.09	Any outgoing message/signal that uses a source address that should not transit or leave the public telecoms provider’s network shall not be permitted to leave the public telecoms provider’s network.	4(1)(a) 4(2)(a) 4(4)(a) 6(1) 8(1)
M3.10	Networks shall only send outgoing signalling in support of services permitted by the recipient. Guidance on what the GSMA has defined as permitted services is set out within Section 5 of GSMA’s charging and accounting principles^{[footnote 58]} and Section 10 of GSMA’s interconnection and interworking charging principles^{[footnote 59]}.	3(3)(a)(iv) 3(3)(c) 4(4)(b) 6(1) 6(2)(a),(b) 8(3) 9(2)(c)(iii)
M3.11	External BGP updates shall be monitored for evidence of misuse.	3(3)(e) 4(4)(b) 6(3)(a),(c),(d),(e) 9(2)(c)(i)
M3.12	Any BGP misuse that impacts a public telecoms provider’s network or services shall be mitigated in a timely manner, and at least within 12 hours, whenever technically possible.	3(3)(e) 4(4)(b) 6(3)(a),(d) 8(1)
M3.13	Public telecoms providers shall ensure that contact details are current and accurate on all the Regional Internet Registries (e.g. RIPE) and should endeavour to keep other data sources accurate.	3(3)(e) 4(1)(a),(b) 4(2)(a),(b) 8(1)
M3.14	All address space and autonomous system number (ASN) resources allocated to a public telecoms provider shall be correctly recorded in such a way that it is simple to identify and contact the ‘owner’ to assist in resolving issues.	3(3)(e) 4(1)(a),(b) 4(2)(a),(b) 15(5)
M3.15	Public telecoms providers shall implement ingress and egress route filtering.	3(3)(e) 4(2)(a),(b) 4(4)(b) 6(1) 6(2)(a) 8(1)
M3.16	Public telecoms providers shall adopt and implement mechanisms that prevent IP address spoofing.	3(3)(e) 4(2)(a),(b) 4(4)(b) 6(1) 6(2)(a) 8(1)
M3.17	The public telecoms provider shall share such details, as are appropriate and proportionate, of any BGP misuse with other public telecoms providers where it may cause a connected security compromise.	6(3)(d) 15(1) 15(2) 15(3) 15(4)
M3.18	An external path update that includes a prefix owned by the public telecoms provider shall not be accepted.	3(3)(e) 4(4)(b) 6(3)(d) 8(1) 8(3)
M3.19	End-users shall not be able to spoof IPs over the data plane (e.g. in line with BCP38).	3(3)(e) 4(4)(b) 6(1) 6(2)(a) 8(1)

Third party supplier measures 1

Measure number	Description	Relevant Regulation(s)
M4.01	The public telecoms provider shall ensure the risks included in Regulation 7(3) are assessed prior to contract, and this assessment is documented. This assessment shall inform both risk management and procurement processes.	3(3)(e) 7(1) 7(4)(a)(i)
M4.02	During procurement of equipment, prior to contract award, it is recommended that the public telecoms providers should, as a minimum, use the guidance contained in NCSC’s vendor security assessment to assess third party suppliers (as contained in Annex B), and consider the Total Cost of Ownership.	3(3)(a),(b),(d),(e) 3(5) 7(1) 7(4)(a)(i) 10(1) 10(2)(a),(b) 10(4) 13(2)(d)(i),(ii) 14(1)
M4.03	The public telecoms provider shall record all equipment that remains in use but has reached the vendor’s end-of-life date. Public telecoms providers shall regularly review their use of this equipment, with a view to reducing the risk of a security compromise occurring as a result of unsupported equipment remaining in use.	3(3)(a),(b) 3(4) 7(1) 7(4)(c) 11
M4.04	The public telecoms provider shall produce a plan to replace the unsupported equipment at an appropriate time, dependent on the level of risk.	3(3)(a),(b) 3(4) 7(1) 7(4)(c) 7(5) 11
M4.05	The public telecoms provider shall record all risk management processes and document actions undertaken when managing risk. Guidance on risk management processes can be found on the NCSC website.^{[footnote 60]}	3(1) 7(1) 7(4)(c) 7(5) 11
M4.06	Public telecoms providers shall only store SIM credentials and SIM transport keys within secured systems that ensure data integrity and prevent ‘read’ access to key material.	4(6) 7(1) 7(4)(a)(i) 7(4)(b) 8(5)(a)
M4.07	Public telecoms providers shall review the security of existing SIM cards on an annual basis, including the supplier, the protection of keys, the algorithms used by the SIM, and the applets provisioned and running on SIMs.	3(3)(a) 4(6) 7(1) 7(4)(a)(i) 7(4)(b) 8(5)(a) 8(6) 11
M4.08	Public telecoms providers shall phase out the use of SIMs that present an unmitigatable security risk, such as the use of deprecated security algorithms.	4(6)(b)

Supporting business processes

Measure number	Description	Relevant Regulation(s)
M5.01	The public telecoms provider shall implement appropriate business processes. In order to achieve this, 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: A1-Governance; A2a-Risk Management Process; A2c-Assurance; A3-Asset Management; B5-Resilient Networks and Systems; B6-Staff Awareness and Training; D1-Response and Recovery Planning.	3 (1)(a),(b),(c) 3(3)(a)(i)(ii)(iii) 3(3)(b),(d),(e),(f) 3(3)(4) 4(1)(a) 4(2)(a) 6(3)(a) 7(4)(b) 8(1) 8(2)(a) 9(1) 9(2)(a),(b) 10 11(a),(b) 13 14
M5.02	Security changes shall be prioritised and postponements of security changes shall be minimised. Where security changes are postponed, these may need to be recorded as a business risk as appropriate.	3(3)(a),(b) 3(4) 4(1) 4(2) 4(4)(b) 7(1) 7(5)(a),(b) 10(2)(a)-(e) 12(a)(b)(c) 13(1)(a)(b) 13(2)(a),(b)
M5.03	Public telecoms providers shall maintain read-only backups of their infrastructure and information and shall be able to restore them. The backups should contain the information necessary to maintain the normal operation of the public electronic communications network or public electronic communications service.	3(3)(d)(e) 4(1) 4(2) 4(4)(b) 7(1) 7(5)(a),(b) 8(5)(d) 9(2)(a),(b) 9(2)(c)(vii) 9(3) 14(1)
M5.04	Public telecoms providers shall have clear, exercised and implemented processes for managing security incidents, at varying levels of severity.	3(3)(d) 4(1) 4(2) 4(4)(b) 7(1) 7(5)(a),(b) 9(2)(c)(iv) 10(2)(a),(b),(c),(d) 13(2)(a),(b)
M5.05	Public telecoms providers shall perform a root-cause analysis of all security incidents. Outcomes of this analysis shall be escalated to an appropriate level, which may include the public telecoms provider’s board.	3(3)(a),(b),(d) 3(4) 4(1)(a),(b) 4(2)(a),(b) 4(4)(b) 7(1) 7(5)(a),(b) 9(2)(c)(i) 10(2)
M5.06	For significant incidents, public telecoms providers shall share the high-level lessons learned with other public telecoms providers, so far as is appropriate and proportionate.	15(1),(2),(3),(4)
M5.07	Lessons learned from previous security incidents shall be used to inform the security of new products and services.	3(3)(a),(b) 3(4) 10(2)(a),(b) 10(2)(e) 13(2)(a),(b),(c),(d)

The following measures should be completed by 31 March 2025.

Management plane 2

Measure number	Description	Relevant Regulation(s)
M6.01	Non-persistent credentials (e.g. username and password authentication) shall be stored in a centralised service with appropriate role-based access control which shall be updated in line with any relevant changes to roles and responsibilities within the organisation.	3(3)(a),(b),(d) 3(5) 6(2) 6(3)(b),(d) 8(1) 8(2)(f) 8(5)(a)
M6.02	Privileged access shall be via accounts with unique user ID and authentication credentials for each user and these shall not be shared.	8(2)(b) 8(4) 8(5)(a),(b),(c)
M6.03	For accounts capable of making changes to Security Critical Functions, the following measures shall be adopted relating to Multi-Factor Authentication: (a) the second factor shall be locally generated, and not be transmitted; and (b) the multi-factor authentication mechanism shall be independent of the provider’s network and Privileged Access Workstation. Soft tokens (e.g.authenticator apps) may be used.	8(4) 8(2)(b) 8(5)(a),(b),(e)
M6.04	All break-glass privileged user accounts must have unique, strong credentials per individual piece of network equipment.	3(1)(a),(b),(c) 8(2)(b) 8(5)(a),(b),(c) 9(2)(c)(vi)
M6.05	Default and hardcoded accounts shall be disabled.	8(2)(d),(e) 8(4) 8(5)(b),(c)

Signalling plane 2

Measure number	Description	Relevant Regulation(s)
M7.01	Any incoming or outgoing message type that should not be sent over international or external signalling networks shall be blocked at the logical edge of the public telecoms provider’s network. For example, GSMA CAT 1 messages^{[footnote 61]} shall be blocked for SS7 networks, and equivalent messages shall be blocked for other signalling protocols such as Diameter,^{[footnote 62]} GTP,^{[footnote 63]} Interconnect^{[footnote 64]} and SS7/SIGTRAN^{[footnote 65]}.	3(3)(e) 3(3)(f)(i) 4(4)(b) 6(1) 6(3)(d) 8(3) 8(6)
M7.02	When sent over signalling networks, the external exposure of customer data, customer identifiers and network topology information shall be minimised.	4(1)(a),(b) 4(2)(a),(b) 4(4)(a) 4(4) 6(1) 8(1) 8(2)(f) 8(5)(a)
M7.03	Public telecoms providers shall have in place the means for recipients of their BGP routing updates to validate that the BGP routing update originated from the legitimate owner.	3(3)(e) 4(2)b 4(4)(b) 6(1) 6(2)(a) 8(1)
M7.04	Where the necessary information is available, public telecoms providers shall validate that any BGP route updates they receive have originated from the legitimate owner.	3(3)(e) 4(1)(a),(b) 4(2)(a),b 4(4)(b) 6(1) 6(2)(a) 8(1)

Third party supplier measures 2

Measure number	Description	Relevant Regulation(s)
M8.01	During procurement of equipment, prior to contract award, providers shall ensure the security functionality of all equipment has been tested.	3(3)(a),(b),(d),(e) 3(5) 7(1) 7(4)(a)(i) 10(1) 10(2)(a),(b) 10(4) 13(2)(d)(i),(ii) 14(1)
M8.02	During procurement of equipment, prior to contract award, providers shall ensure negative testing and fuzzing of equipment interfaces has been performed.	3(3)(a),(b),(d),(e) 3(5) 7(1) 7(4)(a)(i) 13(2)(d)(i),(ii) 14(1) 14(2)
M8.03	Any third party testing in relation to the security of the network equipment shall only be accepted as evidence by the public telecoms provider if it is repeatable, performed independently of the network equipment supplier and is clearly applicable to the public telecoms provider’s deployment (e.g. relates to the hardware, software and configuration that is being supplied).	3(3)(a),(b),(d),(e) 3(4) 3(5) 7(1) 7(4)(a)(i) 12 13(2)(d)(i),(ii) 14(1) 14(2) 14(3)
M8.04	Public telecoms providers shall ensure that security considerations are a significant factor in determining the procurement outcome for Security Critical Functions, considering available evidence from testing, recognising the benefit of any security features that will provide measurable improvement to the security of the network.	3(3)(e) 7(1) 7(4)(a)(i)
M8.05	Public telecoms providers shall record all equipment deployed in their networks, and proactively assess, at least once a year, their exposure should the third party supplier be unable to continue to support that equipment.	3(1)(a),(b),(c) 7(1) 7(5) 11(b)(i),(iii),(v),(vii) 13(2)(d)(i),(ii)
M8.06	Public telecoms providers shall remove or change default passwords and accounts for all devices in the network, and should disable unencrypted management protocols. Where unencrypted management protocols cannot be disabled, public telecoms providers shall limit and mitigate the use of these protocols as far as possible.	3(3)(e) 4(5) 7(1) 7(3) 8(2)(d) 13(2)(d)
M8.07	Public telecoms providers shall ensure that all security-relevant logging is enabled on all network equipment, and sent to the network logging systems.	3(3)(e) 6(2)(a) 6(3)(a)(b)(c)(d) 14(1)
M8.08	Public telecoms providers shall prioritise critical security patches over functionality upgrades wherever possible.	7(4)(c) 7(5) 12
M8.09	When assessing the risk due to SIM card suppliers, including during procurement, public telecoms providers’ risk assessment shall include the risk due to the loss of sensitive SIM card data.	3(3)(a),(e) 4(6) 7(1) 7(4)(a)(i) 7(4)(b) 8(5)(a) 8(6) 11
M8.10	When transferring the public telecoms provider’s SIM key material from SIM card vendors, transport keys shall not be shared across multiple SIM vendors. Where possible, a range of transport keys shall be used with each SIM card vendor.	4(6) 7(1) 7(4)(a)(i) 7(4)(b) 8(5)(a) 8(6)
M8.11	When providers define new SIM authentication algorithm parameters (e.g. for MILENAGE), the default values shall not be used.	4(6) 7(1) 7(4)(a)(i) 7(4)(b) 8(5)(a)
M8.12	For fixed-profile SIM cards, the public telecoms provider shall ensure that sensitive SIM data is appropriately protected throughout its lifecycle, by both the SIM card vendor and within the operator network, given the risk to network resilience and confidentiality should this information be lost.	4(6) 7(1) 7(4)(a)(i) 7(4)(b) 8(5)(a)
M8.13	For fixed-profile SIM cards, the confidentiality, integrity and availability of the sensitive SIM card data shared with the SIM card vendor shall be protected at every stage of its lifecycle.	4(6) 7(1) 7(4)(a)(i) 7(4)(b) 8(5)(a)
M8.14	For fixed-profile SIM cards, providers shall ensure that the security of the SIM card vendor has been independently audited. For example, using the GSMA’s SAS scheme provides a means to accredit the security of SAS suppliers.^{[footnote 66]}	4(6) 7(1)
M8.15	For profile-modifiable SIM cards the public telecoms provider shall, within the first year of use, update with a new profile (including K/Ki, and OTA keys) that has not been provided externally, including to the SIM card vendor. Additionally public telecoms providers should ensure that all new UICCs can be updated with new K/Ki and OTA keys after receipt from the SIM card vendor.	4(6)(a),(b)
M8.16	When under the public telecoms provider’s control, the provider shall ensure that the SIM card can only be modified by specifically allowed servers (for example, determined by IP address and certificate stored on the SIM card).	4(6)(a),(b)

Customer premises equipment

Measure number	Description	Relevant Regulation(s)
M9.01	Once the CPE has been installed at the customer site, it shall only contain credentials that are both unique to that CPE, and not guessable from CPE metadata.	4(4)(c) 8(5)(c)
M9.02	The public telecoms provider shall ensure that all CPE provided to customers are still supported by the network equipment supplier. For any public telecoms provider-provided CPE that go out of third party supplier support, customers shall be informed prior to, and once the equipment goes out of support, and proactively offered a replacement as soon as reasonably practicable. This shall apply only whilst the public telecoms provider provides the associated service.	4(4)(c) 12
M9.03	CPE management interfaces shall not be accessible from the whole of the internet, but shall be protected by strict ACLs, limiting access to only specific management IP address ranges.	3(3)(a)(e) 4(4)(c) 8(1)
M9.04	Management of the CPE shall use a non-deprecated secure protocol (e.g. TLS 1.2 or newer).	3(3)(a) 4(4)(c)
M9.05	By default, the CPE’s customer-facing management interfaces shall only be accessible from within the customer’s network.	3(3)(a) 4(4)(b),(c) 9(2)(c)(iii)
M9.06	By default, all unsolicited incoming connections towards the customer’s network shall be blocked by the CPE.	3(3)(a) 4(4)(b),(c) 9(2)(c)(iii)

The following measures should be implemented on all new contracts after 31 March 2024 (Tier 1 public telecoms providers) or 31 March 2025 (Tier 2 public telecoms providers), and on all contracts by 31 March 2027 (all public telecoms providers).

Third party supplier measures 3

Measure number	Description	Relevant Regulation(s)
M10.01	The public telecoms provider shall maintain records of third party suppliers’ details, including their third parties and the major components which are used in the provision of goods/services/facilities for the public telecoms provider.	7(1) 7(4)(a)(i)
M10.02	The public telecoms provider shall clearly express the security needs placed on third party suppliers. These shall be defined and agreed in contracts.	7(1) 7(4)(a),(b) 9(1) 9(2)(c)(ii),(iv),(vi)
M10.03	There shall be a clear and documented shared-responsibility model between the public telecoms provider and third party suppliers.	7(1) 7(4)(a) 9(1) 9(2)(c)(ii),(iv),(vi)
M10.04	The public telecoms provider’s incident management process and that of their third party suppliers shall provide mutual support in the resolution of incidents.	7(4)(a)(i),(iv) 9(1) 9(2)(c)(ii),(iv),(vi)
M10.05	Public telecoms providers shall retain control and oversight of their network and user data.	4(1)(a),(b) 4(2)(a),(b) 7(1) 7(4)(a)(i),(iii) 7(4)(b)
M10.06	The public telecoms provider shall define what information is made accessible to any third party supplier, ensuring that it is the minimum necessary to fulfil their function. Public telecoms providers shall place controls on that information and limit third party access to the minimum required to fulfil the business function.	4(1)(a),(b) 4(2)(a),(b) 7(1) 7(4)(a)(i),(ii),(iii) 7(4)(b) 8(5)(e) 15
M10.07	When making network or user data available to third party suppliers outside of a secure privileged access system, the public telecoms provider’s environment that is used to hold and make the network and user data available to the third party shall be secure and segregated from the provider’s wider systems and data.	3(3)(a),(d) 3(5) 4(1)(a),(b) 4(2)(a),(b) 7(1) 7(4)(a)(iii) 7(4)(b)
M10.08	Public telecoms providers shall avoid transferring control of their network and user data to third parties, except where necessary. Any such transfer of control should be limited to the necessary and defined purpose. Where a data transfer is necessary, it shall be through a defined process and carried out securely.	4(1)(a),(b) 4(2)(a),(b) 7(1) 7(4)(a)(i),(ii),(iii) 7(4)(b) 15
M10.09	Where network or user data leaves a public telecoms provider’s control, the public telecoms provider shall contractually require and verify that the data is properly protected as a consequence. This shall include assessing the third party supplier’s controls to ensure public telecoms provider data is only visible or accessible to appropriate employees and from appropriate locations.	4(1)(a),(b) 4(2)(a),(b) 7(1) 7(4)(a)(i),(ii),(iii) 7(4)(b)
M10.10	When sharing user or network data, public telecoms providers and suppliers shall use an encrypted and authenticated channel.	4(1)(a),(b) 4(2)(a),(b) 7(1) 7(4)(a)(i),(ii),(iii) 7(4)(b) 15
M10.11	Public telecoms providers shall contractually oblige third party suppliers to notify the provider within 48 hours of becoming aware of any security incidents that may have caused or contributed to the occurrence of a security compromise, or where they identify an increased risk of such a compromise occurring. This includes, but is not limited to, incidents in the supplier’s development network or their corporate network.	7(4)(a)(i),(iv) 9(1) 9(2)(c)(i) 15
M10.12	Public telecoms providers shall contractually require third party suppliers to support the public telecoms provider in investigations of incidents that cause or contribute to the occurrence of a security compromise in relation to the primary provider, or of an increased risk of such a compromise occurring.	7(4)(a),(iv) 9(1) 9(2)(c) (i),(ii),(iii),(iv),(v),(vi) 15
M10.13	Public telecoms providers shall contractually require the third party suppliers to find and report on the root cause of any security incident that could result in a security compromise in the UK within 30 days, and rectify any security failings found.	7(4)(a)(iv) 9(1) 9(2)(c) (i),(ii),(iv),(v),(vi) 9(4) 9(5) 15
M10.14	Where third party suppliers cannot quickly resolve security failings, the public telecoms provider shall work with the third party supplier to ensure the issue is mitigated until resolved.	7(4)(a)(iv) 9(1) 9(2)(c) (ii),(iv),(v) 15
M10.15	Where third party suppliers do not resolve security failings within a reasonable timeframe, the public telecoms provider shall have a break clause with the third party supplier to allow exit from the contract without penalty to the public telecoms provider.	7(4)(c)
M10.16	Public telecoms providers shall contractually require third party suppliers to support, as far as appropriate, any security audits, assessments or testing required by the public telecoms provider in relation to the security of the public telecoms provider’s own network, including those necessary to evaluate the security requirements in this document.	7(1) 7(4)(a)(i),(iii),(iv) 14(1)
M10.17	Public telecoms providers shall flow down appropriate security measures to the third party administrator. Public telecoms providers shall ensure that the third party administrator applies controls that are at least as rigorous as the public telecoms provider when the third party administrator has access to the provider’s network or service or to sensitive data.	7(3)(a) 7(3)(b) 7(4)(a)(i),(ii)
M10.18	The public telecoms provider shall retain the right to determine permissions of the accounts used to access its network by third party administrators.	7(1) 7(4)(a)(ii),(iii) 7(4)(b)
M10.19	Public telecoms providers shall ensure that they retain sufficient in-house expertise and technical ability to re-tender their managed services arrangements at any time and shall produce and maintain a plan for moving the provided services back in-house, or to another third party supplier.	7(1) 7(4)(a)(ii) 7(5) 8(2)(a) 8(4) 13(1) 13(2)(a) 13(2)(c)(i)
M10.20	Public telecoms providers shall maintain an up-to-date list of all third party administrator personnel that are able to access its network, including their roles, responsibilities and expected frequency of access.	7(1) 7(4)(a)(ii),(iii) 7(4)(b) 8(4) 8(5)(d),(e) 8(6)(a),(b)
M10.21	Public telecoms providers shall have the contractual right to control the members of third party administrator personnel who are involved in the provision of the third party administrator services, including to require the third party administrator to ensure that any member of personnel no longer has access to the network.	7(1) 7(4)(a)(i),(iii) 7(4)(b) 8(4) 8(5)(d),(e) 8(6)(a),(b)
M10.22	Public telecoms providers shall not allow routine, direct access to network equipment by third party administrators. Access shall be via mediation points owned and operated by the public telecoms provider and have an associated trouble ticket or approved change reference.	3(1)(a),(b),(c) 3(3)(e) 4(1)(b) 4(2)(b) 4(4)(b) 7(1) 7(4)(b) 8(4)
M10.23	Public telecoms providers shall implement and enforce security enforcing functions at the boundary between the third party administrator network and the public telecoms provider’s network	3(1)(a),(b),(c) 4(1)(a),(b) 4(2)(a),(b) 4(4)(b) 7(1) 7(4)(b)
M10.24	Public telecoms providers shall contractually require that the third party administrators implement technical controls to prevent one public telecoms provider or their network from adversely affecting any other public telecoms provider or their network.	4(1) 4(2) 7(1) 7(4)(a)(i),(ii) 7(4)(b) 9(2)(c)(iii),(v)
M10.25	Public telecoms providers shall contractually require that the third party administrators implement logical separation within the third party administrator network to segregate customer data and networks.	4(1)(a),(b) 4(2)(a),(b) 7(1) 7(4)(a)(i),(ii) 7(4)(b)
M10.26	Public telecoms providers shall contractually require that the third party administrators implement separation between third party administrator management environments used for different public telecoms provider’s networks.	4(1)(a),(b) 4(2)(a),(b) 7(1) 7(4)(a)(i),(ii) 7(4)(b)
M10.27	Public telecoms providers shall contractually require that the third party administrators implement and enforce security enforcing functions at the boundary between the third party administrator network and the public telecoms provider’s network.	4(1)(a),(b) 4(2)(a),(b) 4(4)(b) 7(1) 7(4)(a)(i),(ii) 7(4)(b)
M10.28	Public telecoms providers shall contractually require that the third party administrators implement technical controls to limit the potential for users or systems to negatively impact more than one public telecoms provider.	4(1)(a),(b) 4(2)(a),(b) 4(4)(b) 7(1) 7(4)(a)(i),(ii) 7(4)(b)
M10.29	Public telecoms providers shall contractually require that third party administrators implement logically-independent privileged access workstations per provider.	4(4)(a) 7(1) 7(4)(a)(i),(ii) 7(4)(b)
M10.30	Public telecoms providers shall contractually require that third party administrators implement independent administrative domains and accounts per provider.	7(1) 7(4)(a)(i),(ii)
M10.31	Public telecoms providers shall ensure that the elements of the public telecoms provider’s network that are accessible by the third party administrator shall be the minimum required to perform its contractual function.	7(1) 7(4)(a)(i),(ii) 8(4) 8(5)(e)
M10.32	Public telecoms providers shall both log and record all third party administrator access into its networks.	6(1), 6(2)(a),(b) 6(3)(a) 7(4)(a)(iii),(iv) 8(5)(d)(i),(ii) 9(1) 9(2)(c)(iv),(v)
M10.33	The public telecoms provider shall contractually require the third party administrator to monitor and audit the activities of the third party administrator’s staff when accessing the public telecoms provider’s network.	6(1), 6(2)(a),(b) 7(4)(a)(iii),(iv) 8(5)(d)(i),(ii) 9(1) 9(2)(c)(iv),(v)
M10.34	The public telecoms provider shall contractually require from the third party administrator all logs relating to the security of the third party administrator’s network to the extent that such logs relate to access into the public telecoms provider’s network.	6(1) 6(2)(a),(b) 6(3)(a) 7(4)(a)(iii),(iv) 8(5)(d)(i),(ii) 9(1) 9(2)(c)(iv),(v)
M10.35	Public telecoms providers shall require that networks of the third party administrator that could impact the public telecoms provider undergo the same level of testing as the public telecoms provider applies to themselves (e.g. TBEST testing as set for the provider by Ofcom from time to time).	7(4)(a)(i),(iii) 14(1) 14(2)
M10.36	Public telecoms providers shall contractually require network equipment suppliers to share with them a ‘security declaration’ on how they produce secure equipment and ensure they maintain the equipment’s security throughout its lifetime. It is recommended that any such declaration should cover all aspects described within the Vendor Security Assessment (VSA) (see Annex B), and providers should encourage their suppliers to publish a response to the VSA.	3(3)(a),(b),(e) 7(4)(a)(i),(iii),(iv) 7(4)(b)
M10.37	As part of the security declaration, any differences in process across product lines shall be recorded.	3(3)(a),(b) 3(3)(e) 7(4)(a)(i),(iii),(iv) 7(4)(b)
M10.38	Public telecoms providers shall ensure, by contractual arrangements, that the network equipment supplier’s security declaration is signed-off at an appropriate governance level.	3(3)(a),(b),(e) 7(4)(a)(i),(iii),(iv) 7(4)(b)
M10.39	Where the network equipment supplier claims to have obtained any internationally recognised security assessments or certifications of their equipment (such as Common Criteria or NESAS), public telecoms providers shall contractually require equipment suppliers to share with them the full findings that evidence this assessment or certificate.	3(3)(a),(b),(e) 7(4)(a)(i),(iii),(iv) 7(4)(b)
M10.40	Public telecoms providers shall contractually require network equipment suppliers to adhere to a standard no lower than the network equipment supplier’s security declaration.	3(3)(a),(b) 3(4) 7(1) 7(3)(a),(b) 7(4)(a)(i),(iv) 7(4)(c)
M10.41	Public telecoms providers shall contractually require network equipment suppliers to supply up-to-date guidance on how the equipment should be securely deployed.	3(3)(a),(b) 3(4) 7(1) 7(3)(a),(b) 7(4)(a)(i),(iv) 7(4)(c) 12(a) 13(2)(d)(i),(ii)
M10.42	Public telecoms providers shall contractually require network equipment suppliers to support all equipment and all software and hardware subcomponents for the length of the contract. The period of support of both hardware and software shall be written into the contract.	3(3)(a),(b) 3(4) 7(1) 7(3)(a),(b) 7(4)(a)(i),(iv) 7(4)(c) 12(a) 13(2)(d)(i),(ii)
M10.43	Public telecoms providers shall contractually require network equipment suppliers to provide details (product and version) of major third party components and dependencies, including open source components and the period and level of support.	3(3)(a),(b) 3(4) 7(1) 7(3)(a),(b) 7(4)(a)(i),(iv) 7(4)(c) 12(a) 13(2)(d)(i),(ii)
M10.44	Where relevant to a public telecoms provider’s particular usage of equipment, public telecoms providers shall contractually require third party suppliers to remediate all security issues that pose a security risk to a public telecoms provider’s network or service discovered within their products within a reasonable time of being notified, providing regular updates on progress in the interim. This shall include all products impacted by the vulnerability, not only the product for which the vulnerability was reported.	3(3)(a),(b) 3(4) 7(1) 7(3)(a),(b) 7(4)(a)(i),(iv) 7(4)(c) 12(a) 12(c)(i),(ii) 15(1) 15(4)
M10.45	Public telecoms providers shall record where third party suppliers fail to meet their security obligations.	7(4)(iii),(iv)
M10.46	Public telecoms providers shall ensure that their contracts allow details of security issues to be shared as appropriate to support the identification and reduction of the risks of security compromises occurring in relation to the public electronic communications network or public electronic communications service as a result of things done or omitted by third party suppliers.	7(1) 7(3)(a),(b) 7(4)(a)(i),(iv) 7(4)(c)
M10.47	Public telecoms providers shall contractually require network equipment suppliers to deliver critical security patches separately to feature releases, to maximise the speed at which the patch can be deployed.	3(3)(a),(b) 3(4) 7(1) 7(4)(a)(i) 7(4)(c) 12(a) 12(c)(i),(ii)
M10.48	Public telecoms providers shall ensure their equipment is in a secure-by-default configuration, based on the principle that only required services are made available.	3(3)(e) 13(2)(d)
M10.49	Public telecoms providers shall ensure that all deployed equipment either meets the network equipment supplier’s recommended secure configuration (as a minimum), or that any variations are recorded and the risk assessed.	3(3)(e) 11 13(2)(d)
M10.50	Public telecoms providers shall implement necessary mitigations based on identified equipment risks (e.g. use of an out-of-support component), such that these equipment risks do not increase the overall risk to their networks.	3(3)(e) 11 13(2)(d)
M10.51	Public telecoms providers shall update all supported equipment within such period as is appropriate of any relevant and appropriate version being released.	7(4)(c) 7(5) 12
M10.52	Public telecoms providers shall deploy all security related patches and patches with a security element in a way that is proportionate to the risk of security compromise that the patch is intended to address (see Table 2). Should this not be possible, patches shall be deployed as soon as practicable and effective alternative mitigations put in place until the relevant patch has been deployed. Where a patch addresses an exposed, actively exploited vulnerability, providers shall ensure that such patches are deployed as soon as can reasonably be achieved, and at most within 14 days of release.	7(4)(c) 7(5) 12
M10.53	Public telecoms providers shall ensure that network equipment continues to meet the requirements in M8.04, M8.05, M8.06, M10.48 and M10.49 throughout its lifecycle including after an upgrade or patch.	7(4)(c) 7(5) 12
M10.54	The public telecoms provider shall verify that their third party network equipment suppliers have a vulnerability disclosure policy. This shall include, at a minimum, a public point of contact and details around timescales for communication.	4(4)(c) 7(4)(a)(i) 12

The following measures should be completed by 31 March 2027

Management plane 3

Measure number	Description	Relevant Regulation(s)
M11.01	Operational changes shall only be made according to a formal change process except under emergency or outage situations.	3(3)(d) 3(5) 6(2) 6(3)(d) 8(1) 8(2)(b),(c),(g) 10(2)(b)
M11.02	Any persistent credentials and secrets (e.g., for break-glass access) shall be protected and not available to anyone except for the responsible person(s) in an emergency.	3(3)(a),(b),(d) 3(5) 6(2) 6(3)(b),(d) 8(1) 8(2)(f) 8(5)(a)
M11.03	Central storage for persistent credentials shall be protected by hardware means. For example, on a physical host the drive could be encrypted with the use of a TPM. Where a virtual machine (VM) is used to provide a central storage service, that VM and the data included in it shall also be encrypted, use secure boot and be configured to ensure that it can only be booted within an appropriate environment. This is to ensure that data cannot be removed from the operational environment and accessed.	3(3)(a),(b),(d) 3(5) 6(2) 6(3)(b),(d) 8(1) 8(2)(f) 8(5)(a)
M11.04	Privileged users are only granted specific privileged accounts and associated permissions which are essential to their business role or function.	8(4) 8(5)(a),(e)
M11.05	Privileged access shall be temporary, time-bounded and based on a ticket associated with a specific purpose. Administrators shall not be able to grant themselves privileged access to the network.	8(4) 8(5)(a),(b),(e)
M11.06	While open, tickets shall be updated daily as a record of why privileged access granted to a user remains required and shall be closed once privileged access is no longer required.	8(4) 8(5)(a),(e)
M11.07	Privileged access shall be automatically revoked once the ticket is closed.	8(4) 8(5)(a),(b),(e)
M11.08	Privileged user accounts are generated from a least privilege role template and modified as required. The permissions associated with this account shall not be copied from existing users.	8(4) 8(5)(a),(b),(e)
M11.09	Given a business need, administrators can have multiple roles, each with its own account, provided the risk of doing so has been considered and accepted as part of the public telecoms provider’s risk management processes.	8(5)(a),(b),(e) 8(6)(a),(b)
M11.10	When an emergency occurs, security requirements may temporarily be suspended. Clean-up steps shall be performed after the emergency is resolved to ensure the suspension of these requirements has not compromised the network. Where an ‘emergency’ event occurs, this shall be recorded and audited, along with the reason and time period for which controls were suspended.	3(1)(a),(b),(c) 3(3)(a),(b),(c) 3(5) 6(3)(a) 8(1) 8(3) 9(1) 9(2)(c) 11(a)
M11.11	Break-glass privileged user accounts should be present for emergency access outside of change windows, but alerts shall be raised when these are used, the circumstances investigated, and all activity logs audited post emergency.	3(1)(a),(b),(c) 3(3)(a),(b),(c) 3(5) 8(4) 8(5)(b),(d) 9(2)(c)(v)
M11.12	Break-glass privileged user account credentials should be single-use and changed after use.	3(1)(a),(b),(c) 8(5)(a),(b),(c) 9(2)(c)(v)
M11.13	All privileged access activity undertaken during a management session shall be fully recorded.	4(4)(b) 6(2)(a),(b) 6(3)(a),(b) 8(5)(a) 8(5)(d)(i),(ii)
M11.14	A device that is not necessary to perform network management or support management operations shall not be able to logically access the management plane.	3(3)(d) 3(5) 6(3)(d) 8(3) 8(5)(e)
M11.15	Privileged access to network equipment shall be via a centralised element manager or equivalent configuration deployment system. For example, privileged users shall not be provided with direct access to any management terminal, except where network connectivity is not available (e.g. break-glass situations).	3(3)(d) 3(5) 6(3)(d) 8(2)(f) 8(4) 8(5)(a),(e)
M11.16	It shall not be possible to directly communicate between managed elements over the management plane.	3(3)(d) 3(5) 6(3)(d) 8(2)(f) 8(4) 8(5)(e)
M11.17	The management plane shall be segregated by third party supplier, and between access networks and core networks (e.g. by VLAN). This would not preclude the use of a single orchestration and management solution, provided it is compliant with measure M11.23.	3(3)(d) 3(5) 6(3)(d) 8(2)(f) 8(4) 8(5)(a),(e)
M11.18	The management plane shall be configured to ensure that only necessary connections are allowed. Specifically, element managers and other administrative functions shall only be able to communicate with the network equipment that they administer. Further, network equipment shall only be able to communicate with its administrative functions and its ability to establish a connection with these functions shall be limited.	3(3)(d) 3(5) 6(3)(d) 8(4) 8(5)(e)
M11.19	The function authorising privileged user access (e.g. the root authentication service) shall be within a trusted security domain (not the corporate network).	3(3)(d) 3(5) 6(3)(d) 8(2)(f) 8(5)(a)
M11.20	Multi-Factor Authentication supporting and authorisation functions shall be treated as a Network Oversight Function and shall be within a separate security domain to the corporate security domain.	3(3)(d) 3(5) 6(3)(d) 8(2)(f) 8(5)(a)
M11.21	Testing procedures shall be established and utilised to verify that management networks enforce 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).	3(3)(d),(e) 3(5) 6(3)(d) 8(2)(f) 8(4) 8(5)(a),(e) 14(1)
M11.22	The public telecoms provider’s wider network outside of the management plane shall be continuously scanned to detect and remediate unnecessary open management protocols, ports and services.	3(3)(d) 3(5) 6(3)(b) 6(3)(d) 8(2)(f) 8(4) 8(5)(a),(e) 14(1)
M11.23	The management plane shall be segregated in such a way that a disruption to a segment shall not affect the entirety of the provider’s UK network.	3(3)(d) 3(5) 8(1)
M11.24	A PAW’s access to internet services shall be restricted to the services that are essential for it to operate. This may include receiving updates, configurations from Mobile Device Management, or carrying out administrative tasks on a cloud portal.	3(3)(c) 4(4)(a) 8(1)
M11.25	A PAW shall not have direct access to corporate applications, including email and messaging systems. If indirect access is permitted from a PAW, strict technical controls shall be implemented, accompanied by an appropriate risk assessment.	3(1)(a) 3(3)(a)(b)(c) 4(4)(a) 8(1) 11(a),(b)(i)
M11.26	A PAW device shall use secure boot, boot attestation and full disk encryption backed by a hardware root of trust.	4(1) 9(1)
M11.27	A PAW shall be kept patched and up-to-date with a supported OS throughout its lifetime.	12
M11.28	Security critical patches shall be applied to PAWs within 14 days.^{[footnote 67]} Should this not be possible, patches shall be deployed to PAWs as soon as practicable and robust alternative mitigations put in place until the relevant patch has been deployed.	12
M11.29	A PAW shall prevent the execution of any unauthorised applications or code including linked libraries or macros within documents.	3(3)(c) 4(1)
M11.30	Void NOTE: measure omitted as it is a subset of M11.26	4(1) 4(2)
M11.31	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.	3(3)(c) 7(1) 8(6) 14(1)
M11.32	All new deployments of equipment shall be administered via secure, encrypted and authenticated protocols. Insecure or proprietary security protocols shall be disabled.	3(1) 3(3)(e) 13(2)(d)
M11.33	Where administrative access is not via secure channels, the risk this poses and the mitigation applied shall be justified, fully documented and reported at board level.	3(3)(a) 3(3)(b) 8(4) 10(2)(d),(f) 11(b)
M11.34	Security protocols and algorithms shall not be proprietary whenever technically viable.	8(4)
M11.35	Each network equipment shall have strong, unique credentials for every account.	8(2)(b),(d) 8(4) 8(5)(b),(c)
M11.36	A public telecoms provider shall have a written record of how their PAWs and PAM systems are designed. The public telecoms provider shall also identify key privileged access risks and corresponding mitigations in their regular risk reviews.	8(4) 8(5)(a),(b),(e) 11
M11.37	The PAW solution shall include documented user requirements, reviewed and approved by a security team. The PAW design shall be reviewed at least annually, making a written record with evidence of updates and mitigations of any identified insecure workarounds.	3(1) 3(3)(a) (b) 6(1)7(1) 7(3)(a)(b) 8(1)8(4) 8(5)(a),(b),(e) 11 14(1)
M11.38	The PAW shall be built using a validated secure build process, incorporating documented integrity checks that are verified at deployment and re-tested in line with your organisation’s security policies for PAWs. Ongoing trust validation measures shall be recorded and reviewed annually to ensure the PAW’s integrity is maintained throughout its lifecycle.	3(1) 3(3)(d) 3(5) 6(1) 6(3)(e) 11 14(1)
M11.39	The PAW shall be deployed on a physically or logically separate infrastructure, with documented network diagrams and segmentation controls. Connection to other systems shall only occur after a formal security readiness review confirms all required controls are implemented and verified.	3(1) 3(3)(d) 3(5) 6(1) 6(3)(e) 11 14(1)
M11.40	The PAW device shall enforce strict separation of administrative duties using technical controls to isolate PAW functions from high-risk activities. Any exceptions must be documented with an appropriate risk assessment, reviewed and approved by the security team.	3(1) 3(3)(d) 3(5) 6(1) 6(3)(e) 7(1) 7(3)(a)(b) 8(1) 8(4) 8(5)(a),(b),(e) 11 14(1)
M11.41	The PAW shall have protective monitoring enabled with event logs streamed as soon as network connectivity is available to a secure, tamper-evident logging system. Log integrity, access controls and audit trails shall be verified regularly in line with a documented risk assessment to ensure logs are not altered or deleted.	6(1) 6(2) 6(3)(a)-(e) 6(4) 11 14(1)
M11.42	The PAW shall implement a documented, secure data transfer process to maintain the integrity of the system when data is imported. This process shall include event logging to ensure all transfers are fully auditable. Transfer logs shall be retained in accordance with the public telecoms provider’s data retention policy and must support traceability of user, time, and file details.	3(1) 3(3)(e) 3(5) 6(1) 6(2) 6(3)(a)-(e) 6(4) 11 14(1)

Signalling plane 3

Measure number	Description	Relevant Regulation(s)
M12.01	Incoming and outgoing signalling traffic shall be monitored.	4(4)(b) 5(3) 6(1) 6(2)(a),(b) 6(3)(a),(d)
M12.02	Signalling records are sensitive data and shall be protected from misuse or extraction.	3(3)(a)(i) 4(1)(a) 4(2)(a) 4(4)(b) 5(3) 6(1) 6(2)(b) 6(3)(a),(d)
M12.03	Security analysis shall be performed on signalling traffic to find and address anomalous signalling and malicious signalling.	4(4)(b) 6(1) 6(2)(a),(b) 6(3)(a),(d),(f) 8(1)
M12.04	Public telecoms providers shall establish an effective means to alert each other to malicious signalling where there could be a connected security compromise.	4(4)(b) 6(1) 6(2)(a),(b) 6(3)(d),(e) 15
M12.05	Detailed negative testing and fuzzing shall be performed for all interfaces that process data provided over an external signalling interface (this applies to all equipment that this measure applies to, including existing equipment). The provider shall test that the live configuration prevents malformed, inconsistent, unexpected, or abnormally high volumes of signalling messages from disrupting Security Critical Functions.	3(3)(a)(iv) 3(3)(c),(d),(e) 3(3)(f)(i),(ii) 4(1)(a),(b) 4(2)(a),(b) 4(4)(b),(c) 6(1) 14(1) 14(2)

Virtualisation 1

Measure number	Description	Relevant Regulation(s)
M13.01	The virtualisation fabric shall be robustly locked-down, shall use the latest patch for the software version and shall be in support.^{[footnote 68]}	3(1)(a),(b),(c) 3(3)(d),(e) 3(5) 4(1)(a),(b) 4(2)(a),(b) 4(4)(b) 7(1) 12(a),(b),(c)
M13.02	It shall be possible to update the virtualisation fabric without negatively impacting the network functionality.	3(1)(a),(b),(c) 3(3)(d),(e) 3(5) 4(1) (a),(b) 4(2)(a),(b) 4(4)(b) 12(a),(b),(c)
M13.03	All interfaces on physical hosts shall be locked down to restrict access. The only incoming connection to the physical host shall be for management purposes or to support the virtualisation function. There shall be no outgoing connections except to support virtual workloads. Communication between physical hosts shall be inhibited other than as part of data flows between virtual workloads.	3(1)(a),(b),(c) 3(3)(d),(e) 3(5) 4(1)(a),(b) 4(2)(a),(b) 4(4)(b) 6(1) 6(2)(a),(b) 8(1)
M13.04	Controls shall be in place to ensure that only known physical hosts can be added to the virtualisation fabric.	3(1)(a),(b),(c) 3(3)(d),(e) 3(5) 4(1)(a),(b) 4(2)(a),(b) 4(4)(b) 8(1) 12(a)
M13.05	Modification of databases and systems that define the operation of the network shall require sign off by two authorised persons.	3(1)(a),(b),(c) 3(3)(d),(e) 3(5) 4(1)(a),(b) 4(2)(a),(b) 4(4)(b) 8(2)(b),(c) 12(a),(b),(c)
M13.06	As part of the virtualisation fabric, physically separate ports shall be used to segregate internal interface and external interface network traffic.	3(1)(a),(b),(c) 3(3)(d),(e) 3(5) 4(1)(a),(b) 4(2)(a),(b) 4(4)(b)12(a),(b),(c)
M13.07	The virtualisation fabric shall be configured to limit the exposure of virtual workloads (e.g. disable virtual span ports by default).	3(1)(a),(b),(c) 3(3)(d),(e) 4(1)(a),(b) 4(2)(a),(b)
M13.08	The virtualisation fabric shall be configured to prevent use of hard-coded MAC addresses by default (e.g. by individual VNFs).	3(1)(a),(b),(c) 3(3)(d),(e) 4(1)(a),(b) 4(2)(a),(b)
M13.09	Where public telecoms providers cannot guarantee the security of the physical environment (e.g. within the exposed edge, or within a shared data centre/exchange), the virtualisation fabric shall be configured to encrypt data at rest (no data is written to the host’s storage unencrypted and data is encrypted when the host is powered off).	3(1)(a),(b),(c) 3(3)(d),(e) 4(1)(a),(b) 4(2)(a),(b) 4(5) 7(4)(b) 8(1)
M13.10	Where there is risk of exposure during transmission, the virtualisation fabric shall be configured to securely encrypt data in transit. Examples and guidance on the use of encryption can be found on the NCSC website.^{[footnote 69]}	3(1)(a),(b),(c) 3(3)(d),(e) 4(1)(a),(b) 4(2)(a),(b) 4(5)
M13.11	All physical hosts shall be placed into a host security ‘pool’. Pools may be defined based on the environment within which that host resides, the type of host, resilience and diversity, purpose etc.	3(1)(a),(b),(c) 3(3)(d) 3(5) 4(1)(a),(b) 4(2)(a),(b) 8(1)
M13.12	Virtual workloads shall be authorised, tagged with a specific trust domain, and signed prior to use. The specific trust domain shall be based on the risks associated with the workload.	3(3)(d) 3(5) 4(1)(a),(b) 4(2)(a),(b) 8(1)
M13.13	There shall be separation between trust domains. This separation may be enforced by the virtualisation fabric, provided virtualisation cut-throughs are not used.	3(1)(a),(b),(c) 3(3)(d) 4(1)(a),(b) 4(2)(a),(b)
M13.14	Host pools shall be tagged with trust domains they can execute. This will be based on risk and ensure that sensitive functions are not executed alongside vulnerable functions, or in physically exposed locations. The virtualisation fabric shall verify that the virtual workload is signed and complies with policy prior to use, including that the virtual workload’s trust domain is permitted to execute within the host’s pool.	3(1)(a),(b),(c) 3(3)(d) 3(5) 4(1)(a),(b) 4(2)(a),(b) 4(4)(c)
M13.15	A physical host shall not be able to impact hosts in other host pools. This includes, but is not limited to, spoofing VLAN/VXLANs of virtual networks.	3(1)(a),(b),(c) 3(3)(d) 3(3)(e) 3(5) 4(1)(a),(b) 4(2)(a),(b) 4(4)(c) 6(1) 6(3)(b)
M13.16	Containers shall not be used to implement separation between trust domains. To implement separation between trust domains, providers shall use Type-1 hypervisors (without cut-throughs) or discrete physical hardware.	3(1)(a),(b),(c) 3(3)(d) 3(5) 4(1)(a),(b) 4(2)(a),(b)
M13.17	Containerised hosts shall only support a single trust domain.	3(1)(a),(b),(c) 3(3)(d) 3(5) 4(1)(a),(b) 4(2)(a),(b)
M13.18	The control and orchestration functions for virtualisation are Network Oversight Functions and shall reside in a trusted physical and logical location.	3(3)(d) 3(5)
M13.19	The administration network of the virtualisation fabric is a management plane and shall be protected as such.	3(3)(d) 3(5) 4(1) 4(2)
M13.20	Privileged access to the virtualisation fabric shall only be available over authenticated and encrypted channels.	3(3)(a) 3(3)(d) 3(5) 4(1) 4(2) 8(5)(e)
M13.21	Functions that support the administration and security of the virtualisation fabric shall not be run on the fabric it is administering.	3(3)(a) 3(3)(d) 3(5) 4(1) 4(2)
M13.22	Functions that support the administration and security of the virtualisation fabric are Network Oversight Functions and shall reside in a trusted physical and logical location.	3(3)(a) 3(3)(d) 3(5) 4(1) 4(2)
M13.23	The number of privileged accounts for the virtualisation fabric shall be constrained to the minimum necessary to meet the provider’s needs.	3(3)(d) 4(1)(b) 4(2)(b) 7(1) 8(1) 8(2)(a) 8(4)
M13.24	Virtualisation fabric administrator accounts shall not have any privileged rights to other services within the provider, or vice-versa.	3(3)(d) 4(1)(b) 4(2)(b) 7(1) 8(1) 8(2)(a) 8(4)
M13.25	Virtualisation fabric administrator accounts shall only be provided with the privileges and accesses required to carry out their role.	3(3)(d) 4(1)(b) 4(2)(b) 7(1) 8(1) 8(2)(a) 8(4)
M13.26	Virtualisation fabric administrator accounts shall not have access to the public telecoms provider’s workloads running within the virtualised environment.	3(3)(d) 4(1)(b) 4(2)(b) 7(1) 8(1) 8(2)(a) 8(4)
M13.27	Network Oversight Functions shall not share trust domains or host pools with workloads that are not Network Oversight Functions.	3(3)(d) 3(5)
M13.28	Containers shall not be used to enforce separation between different Network Oversight Functions and between Network Oversight Functions and other functions.	3(3)(d) 3(5)

Third party supplier measures 4

Measure number	Description	Relevant Regulation(s)
M14.01	Once equipment reaches the vendor’s end-of-life date, public telecoms providers shall only continue to use the equipment if the following conditions are met: a) the equipment’s configuration is rarely modified, and modifications are reviewed; b) either the addressable interfaces of the unsupported equipment are monitored and use of those interfaces can be explained, or there is no realistic possibility that exploitation of all unsupported equipment would have an impact on the network; c) the network exposure (attack surface) of the unsupported equipment is minimal (e.g. some transport equipment); d) a risk assessment supporting the use of the equipment is documented and is updated at least annually or when there is a significant change affecting the equipment in question; and e) where the risk assessment no longer supports the use of that equipment, a plan and related cost estimate exists to remove the equipment within a defined timeframe.	3(3)(a),(b),(e) 3(4) 6(2) 6(3) 7(1) 7(4)(c) 11
M14.02	The provider shall block and record any SIM OTA messages sent to their own SIMs, except where these are sent from allowed sources.	4(6) 7(1) 7(4)(a)(i) 7(4)(b) 8(5)(a) 8(6)
M14.03	Public telecoms providers shall ensure that network equipment continues to meet the requirements in M8.07 and M10.41 (in addition to those listed in measure M10.53) and retains any security related configuration throughout its lifecycle, including after an upgrade or patch.	7(4)(c) 7(5) 12

Network Oversight Functions

Measure number	Description	Relevant Regulation(s)
M15.01	Network Oversight Functions shall be robustly locked-down, in support and patched within such period as is proportionate to the risk of security compromise that the patch is intended to address (see Table 2). Should this not be possible, patches shall be deployed on Network Oversight Functions as soon as practicable and robust alternative mitigations put in place until the relevant patch has been deployed.	3(3)(a),(d),(e) 3(5) 4(1)(b) 4(2)(b) 8(3) 12
M15.02	Any service that supports or contains Network Oversight Functions shall be rebuilt from an up-to-date known-good software state every 24 months. This includes the operating system and application software. This can be performed in line with a system upgrade.	3(3)(a),(d),(e) 4(1)(b) 4(2)(b) 8(3) 12
M15.03	Any workstations or functions (e.g. jump boxes) through which it is possible to make administrative changes to Network Oversight Functions shall be rebuilt from an up-to-date known-good software state on a yearly-basis. This applies to the workstation or function’s operating systems and above.	3(3)(a),(d),(e) 4(1)(b) 4(2)(b) 8(3) 12
M15.04	Network Oversight Functions shall run on trusted platforms.	3(3)(a),(d),(e) 4(1)(b) 4(2)(b) 8(3) 12
M15.05	Where providers cannot guarantee the security of the physical environment (e.g. within the exposed edge, or within a shared data centre/exchange) Network Oversight Functions shall not be deployed.	3(3)(a),(d),(e) 4(1)(b) 4(2)(b) 8(3)
M15.06	Network Oversight Functions shall only be managed by a minimal set of trusted privileged users.	3(3)(a),(d),(e) 3(5) 4(1)(b) 4(2)(b) 4(4)(a) 8(2)(a),(f) 8(4) 8(5)(a),(b),(e) 8(6)
M15.07	The management functions (e.g. jump box) used to manage Network Oversight Functions shall only be accessible from a PAW.	3(3)(a),(d),(e) 3(5) 4(1)(b) 4(2)(b) 4(4)(a) 8(2)(f) 8(3) 8(4) 8(5)(a),(e)
M15.08	Dedicated management functions shall be used to manage Network Oversight Functions.	3(3)(a),(d),(e) 3(5) 4(1)(b) 4(2)(b) 8(3) 8(4)
M15.09	The management plane used to manage Network Oversight Functions shall be isolated from other internal and external networks, including the management plane used by other equipment.	3(3)(a),(d),(e) 3(5) 4(1)(b) 4(2)(b) 8(2)(f) 8(4) 8(5)(a),(e)
M15.10	All management accesses to Network Oversight Functions shall be pre-authorised by a limited set of people who have been assigned with an appropriate role.	3(3)(a),(d) 3(5) 4(1)(b) 4(2)(b) 6(2)(a),(b) 6(3)(a),(b) 8(2)(a),(c),(f) 8(4) 8(5)(b),(e) 8(6) 13(2)(a),(b)
M15.11	Changes to Network Oversight Functions shall be monitored in real-time (e.g. Syslog).	3(3)(d) 4(1)(b) 4(2)(b) 4(4)(a) 5(3) 6(2)(a),(b) 6(3)(a),(b),(c),(d),(f) 8(2)(c) 8(5)(b),(d)
M15.12	PAWs, dedicated management functions and the Network Oversight Functions themselves shall be monitored for signs of exploitation.	3(3)(d) 4(1)(b) 4(2)(b) 4(4)(a) 5(3) 6(2)(a),(b) 6(3)(a),(b),(c),(d),(f) 8(2)(c) 8(5)(b),(d)
M15.13	Network Oversight Functions shall only access services (e.g. AAA, network time, software updates) over internally-facing interfaces.	3(3)(a),(d) 3(5) 4(1)(b) 4(2)(b) 8(2)(f)

Monitoring and analysis 1

Measure number	Description	Relevant Regulation(s)
M16.01	Public telecoms providers shall use appropriately skilled and dedicated resources to understand and analyse security-related network activity. These resources may be provided by a third party supplier.	8(2)(a) 13(2)(a),(b),(c) 14(1)
M16.02	Public telecoms providers shall ensure that threat hunting is periodically performed using available logging and monitoring data.	6(1) 6(2)(a),(b) 6(3)(d) 10(2)(a) 11(a) 11(b)(viii) 14(1)
M16.03	Public telecoms providers may outsource threat hunting to an independent third party, but, if possible, should not outsource audit or threat hunting to any party involved in operating the network	10(1) 14(1) 14(4)(a)
M16.04	Asset management and network monitoring systems shall be kept up to date to enable security staff to identify and track down anomalies within networks. This shall include comprehensive details of normal system and traffic behaviour (e.g. source and destination, frequency of communication, protocols and ports used, and expected bandwidth consumed).	3(1) 3(3)(e) 4(1)(b) 4(2)(b) 6(3)(a)-(f) 6(4) 9(1) 9(2)(c)(i),(v) 11(a)
M16.05	Network changes that could impact network security shall be notified to those monitoring the network. Monitoring processes shall be maintained and modified if necessary.	3(1)(c) 3(3)(a) 4(1)(b) 4(2)(b) 5(2) 5(3) 6(2)(a),(b) 6(3)(a)-(f) 6(4) 8(2)(c) 9(1) 9(2)(c)(i),(v) 11(a) 11(b)
M16.06	Public telecoms providers shall monitor physical and logical interfaces between networks that operate at different trust levels, as well as between groups of network functions (e.g. core networks and access networks).	3(3)(a) 4(1)(b) 4(2)(b) 5(2) 5(3) 6(2)(a),(b) 6(3)(a)-(f) 6(4) 9(1) 9(2)(c)(i),(v)
M16.07	Systems that collect and/or process logging and monitoring data shall be treated as Network Oversight Functions.	3(3)(a),(d) 3(5) 4(1)(a),(b) 4(2)(a),(b)
M16.08	The integrity of logging data shall be protected, and any modification alerted and attributed.	3(3)(a),(d) 4(1)(a) 4(2)(a) 8(2)(b),(c) 8(5)(b)
M16.09	All actions involving stored logging or monitoring data (e.g. copying, deleting, modification, or viewing) shall be traceable back to an individual user.	3(3)(a),(d) 4(1)(a) 4(2)(a) 8(2)(c) 8(5)(a),(b),(c),(d)
M16.10	Logging datasets shall be synchronised, using common time sources, so separate datasets can be correlated in different ways.	3(3)(a),(d),(e) 4(1)(a) 4(2)(a)
M16.11	An alarm shall be raised if logs stop being received from any network equipment.	3(3)(a),(d),(e) 4(1)(a) 4(2)(a)
M16.12	Logs for network equipment in Security Critical Functions shall be fully recorded and made available for audit for 13 months.	3(3)(a),(d),(e) 4(1)(b) 4(2)(b) 6(2)(a),(b) 6(3)(a)(b),(c),(e),(f) 6(4) 9(2)(c)(i),(iv)
M16.13	Network-based and host-based sensors shall be deployed and run throughout networks to obtain traffic to support security analysis.	6(1) 6(2)(a),(b) 6(3)(a),(d),(e),(f) 9(2)(c)(i),(iv)
M16.14	Access events to network equipment shall be collected. Unauthorised access attempts shall be considered a security event.	4(4)(b),(c) 6(1) 6(2)(a),(b) 6(3)(a),(b),(d),(e) 7(4)(a)(iii) 8(5)(d) 9(2)(c)(i),(iv) 13(2)(a)
M16.15	Logging data shall be enriched with other network knowledge and data. In order to successfully analyse logging data, it must be used in conjunction with knowledge of the public telecoms provider’s network as well as other pertinent data needed for understanding log entries.	6(1) 6(2)(a),(b) 6(3)(e) 9(2)(c)(i),(iv)
M16.16	Network equipment configurations shall be regularly and automatically collected and audited to detect unexpected changes.	3(3)(e) 6(1) 6(2)(a),(b) 6(3)(c),(d),(e) 6(4) 8(2)(g) 9(2)(c)(i) 12(b) 14(1)
M16.17	Logs shall be linked back to specific network equipment or services.	6(1) 6(2)(a) 6(3)(a),(e) 6(4) 9(2)(c)(i),(iv)
M16.18	Logs shall be processed and analysed in near real-time (in any case within 5 minutes) and generate security relevant events.	4(4)(b) 5(1)(a) 6(1) 6(2)(a),(b) 6(3)(c),(d),(e) 9(2)(c)(i),(iv) 11(a) 11(b)(iii)
M16.19	The public telecoms provider shall ensure that tools and techniques are utilised to support analysts in understanding the data collected.	6(1) 6(2)(a),(b) 6(3)(c),(e) 7(4)(iv) 9(1) 11(a)
M16.20	Public telecoms providers shall regularly review access logs and correlate this data with other access records and ticketed activity.	6(1) 6(2)(a),(b) 6(3)(a)-(e) 8(5)(d) 9(2)(c)(i),(iv)
M16.21	Indications of potential anomalous activity, and potential malicious activity, shall be promptly assessed, investigated and addressed.	6(1) 6(2)(a),(b) 6(3)(d),(e) 9(2)(c)(i),(ii),(iv),(v)
M16.22	Logging data shall be correlated with data within asset management systems to detect anomalies. Models shall be developed to characterise ‘normal’ traffic within networks, including type and volume.	6(1) 6(2)(a),(b) 6(3)(a),(d),(e) 9(2)(a) 9(2)(c)(i),(iv)

The following measures should be completed by 31 March 2028

Management plane 4

Measure number	Description	Relevant Regulation(s)
M17.01	Administrators should not need privileged access to network equipment to make administrative changes. Administrators should instead have privileged access to administrative systems (e.g. OSS) which make the necessary changes on the administrator’s behalf. Administrative systems should group administrative changes to automate administrative processes and minimise administrator input and risk. When an administrator uses a privileged access into a Security Critical Function, which is not an administrative system, this shall create a security alert.	3(5) 6(2) 6(3)(c),(d) 8(1) 8(2)(g)

Signalling plane 4

Measure number	Description	Relevant Regulation(s)
M18.01	The public telecoms provider shall ensure that their critical, core and signalling security systems are highly resilient to signalling attacks. Signalling messages shall be validated at the logical edge of the network prior to being forwarded to critical or core nodes. Messages that are not encoded in a normal manner, or that are unrelated to a normal operation or call flow in the network, shall be blocked. All exceptions to this shall be understood, justified, and documented.	3(3)(a)(iv) 3(3)(c),(d),(e) 3(4) 4(1)(b) 4(2)(b) 4(4)(b) 8(3)
M18.02	A signalling failure for an externally-facing service shall not impact core nodes or Security Critical Functions.	3(3)(a),(d),(e) 3(5) 4(1)(b) 4(2)(b) 4(4)(b) 8(3)
M18.03	With the exception of SS7 and GTP-C, only ‘hub’ signalling addresses shall be exposed externally. This shall be done in such a way that internal signalling addresses are not shared or exposed externally.	4(1)(a) 4(2)(a) 4(4)(a) 4(5) 6(1) 8(1)
M18.04	Outgoing signalling shall be authenticated where this is supported by international standards.	4(4)(b) 6(1) 6(2)(a),(b)
M18.05	Customer data and customer identifiers shall be obfuscated before being released over an external signalling network, except where it is functionally essential to provide this information.	4(1)(a),(b) 4(2)(a),(b) 4(4)(b) 4(5) 6(1) 6(2)(a) 8(1) 8(5)(a)
M18.06	In protocols other than SS7 and GTP-C, signalling network topology information shall be obfuscated before being released over an external signalling network, except where it is functionally essential to provide this information.	4(1)(a),(b) 4(2)(a),(b) 4(4)(b) 4(5) 6(1) 6(2)(a) 8(1) 8(2)(f) 8(5)(a)

Virtualisation 2

Measure number	Description	Relevant Regulation(s)
M19.01	All non-ephemeral secrets, passwords and keys shall be stored in hardware-backed secure storage. Where public telecoms providers are not able to apply this measure to existing networks and services they must set out what mitigating steps they are taking.	3(1)(a),(b),(c) 3(3)(d),(e) 3(5) 4(1)(a),(b) 4(2)(a),(b) 8(5)(a) 12(a),(b),(c)
M19.02	Only physical hosts that have cryptographically attested to be in a known-good state can be provisioned into the virtualisation fabric.	3(1)(a),(b),(c) 3(3)(d),(e) 3(5) 4(1)(a),(b) 4(2)(a),(b) 4(4)(b) 8(3) 8(4) 12
M19.03	Where the virtualisation fabric allows virtual functions to have direct access to the physical hardware (cut-throughs), it shall not be treated as a security boundary.	3(1)(a),(b),(c) 3(3)(d),(e) 4(1)(a),(b) 4(2)(a),(b)
M19.04	Where possible, the virtualisation fabric shall be built and updated through an automated and verifiable process.	3(3)(d),(e) 8(2)(g) 12
M19.05	Where possible, only automated and verifiable methods of configuration shall be used for administration of the virtualisation fabric (authorised API calls etc).	3(3)(e) 8(2)(g)
M19.06	Where possible, administration of the virtualisation fabric shall be automated during normal operation.	8(2)(g)
M19.07	Manual administration of the virtualisation fabric (e.g. access to a command line on host infrastructure) shall produce an immediate alert.	6(3)(c) 8(2)(g)

Monitoring and analysis 2

Measure number	Description	Relevant Regulation(s)
M20.01	Automated tools shall be used to find and prioritise events that require manual analysis.	3(3)(a) 4(1)(b) 4(2)(b) 5(3) 6(2)(a),(b) 6(3)(d),(f) 9(1) 9(2)(c)(i),(iv),(v),(vi)

Retaining national resilience and capability

Measure number	Description	Relevant Regulation(s)
M21.01	Procedures should ensure contingencies are in place in the event that further locations are added to the Schedule of the Electronic Communications (Security Measures) Regulations 2022.	3(3)(a)(iii) 3(3)(d),(e) 3(5) 5(2) 5(3) 7(1) 7(5) 8(1) 8(2)(a) 8(6)
M21.02	The measures to be taken by the public telecoms provider under Regulation 3(3)(f) should normally include ensuring, so far as is reasonably practicable, that the equipment performing public telecoms provider’s Network Oversight Functions is located within the UK, and operated using UK-based staff.	3(3)(f)(i)
M21.03	The public telecoms provider shall retain a UK-based technical capability to provide subject matter expertise on the operation of the public telecoms provider’s UK networks and the risks to the public telecoms provider’s UK networks.	3(3) 13(1)
M21.04	Where data is stored offshore, the public telecoms provider shall maintain a list of locations where the data is held. The risk due to holding the data in these locations, including any risk associated with local data protection law, shall be managed as part of the public telecoms provider’s risk management processes.	3(3)(a) 3(3)(f)(i),(ii),(iii) 5(2) 11
M21.05	Decisions about holding outside of the UK data relating to more than 100,000 UK subscribers, the operation of the large parts of the network, or the operation of Network Oversight Functions, shall be taken at an appropriate governance level and recorded in writing. The sign-off for these decisions should normally be given by a person or committee at board level (or equivalent) with sufficient knowledge and competency to discharge these responsibilities.	3(3)(a) 3(3)(f)(i),(ii),(iii) 5(3) 10(2)
M21.06	If it should become necessary to do so, the public telecoms provider shall have the ability to maintain (as relevant, where it provides such a form of connectivity prior to the event) the following UK network connectivity for a period of one month in the event of loss of international connections: fixed and mobile data connectivity to UK peering points; mobile voice; and text-based mobile messaging.	3(3)(f)(iii) 5(2)
M21.07	If it should become necessary to do so, the public telecoms provider shall be able to transfer into the UK functions required by UK networks to maintain an operational service, should international bearers fail.	3(3)(f)(iii) 5(2)

New Measures

The following measures should be completed by 31 March 2028.

However, this does not preclude public telecoms providers from implementing the measure before this date where it is prudent to do so, and this should be actively encouraged where possible. It remains an expectation that public telecoms providers take a holistic approach.

Measure number	Description	Relevant Regulation(s)
M22.01 Supporting Business Processes	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.	3(1) 3(3)(a)(i)(ii)(iii) 3(5) 4(1)(a) 4(2)(a) 5(1)(a) 6(1) 6(2) 6(3) 7(1) 7(4)(b) 8(1) 8(2)(a) 9(1) 9(2) 10 11 13
M22.02 Supporting Business Processes	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.	3(3)(e) 6(1) 6(2) 6(3) 7 8(1) 8(2)(a) 9 10 11 13 14
M22.03 Management Plane	Default passwords for test networks or services, whose compromise is likely to increase the risk of the associated PECN/PECS also being compromised, shall be changed upon initialisation of the device or service.	3(3)(e) 7(4)(b) 8(2)(d) 8(4) 8(5)(b),(c) 14(1)
M22.04 Signalling Plane	M3.10 applies in relation to fixed networks, in addition to mobile networks, and public telecoms providers shall also consider for this measure any signalling protocols, including those not explicitly covered by the GSMA guidance.	3(3)(a)(iv) 3(3)(c) 4(4)(b) 6(1) 6(2) 8(3) 9(2)(c)(iii)

The following measures should be completed by 31 December 2028.

However, this does not preclude public telecoms providers from implementing measures before this date where it is prudent to do so and this should be actively encouraged where possible. It remains an expectation that public telecoms providers take a holistic approach.

Measure number	Description	Relevant Regulation(s)
M23.01 SIMs	Public telecoms providers shall check the SIM providers’ certificates against the GSMA SAS accredited website^{[footnote 70]} and satisfy themselves that the supporting sites and external parties are sufficiently trustworthy.	4(6) 7(1) 7(4)(a)(i) 7(4)(b) 11(b)(iv)
M23.02 Security testing	Public telecoms providers shall implement an automated scanning process to identify vulnerabilities, missing patches or configuration changes.	12
M23.03 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.	7(1) 7(4) 11(b)(iv) 12 14(1)

The following measures should be completed by 31 December 2029.

However, this does not preclude public telecoms providers from implementing measures before this date where it is prudent to do so and this should be actively encouraged where possible. It remains an expectation that public telecoms providers take a holistic approach.

Measure number	Description	Relevant Regulation(s)
M24.01 Logging and monitoring	Regular tests should be conducted to ensure that the logging is functioning as expected.	6(2) 6(3)(e) 14(1) 14(2) 14(4)(a)(b)
M24.02 Signalling	Number analysis reference data that is used to configure network equipment (with E164, E212, E214 numbering ranges and Diameter host names and GPRS Serving Node (GSN) IP addresses) should be maintained and reviewed regularly with an appropriate frequency commensurate to the risk.	6(1) 11(b)(iii) 14(1)
M24.03 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. Through risk assessments and/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.	3(1) 3(2)3(3)(a)-(e) 3(4) 11 14(1)
M24.04 Management Plane	Equipment subject to high-end attacks (i.e. physical or digital assets that are critical to an organisation’s operations and likely to be attractive targets for sophisticated cyber adversaries) shall, where technically possible, implement trusted boot, and periodically be rebuilt/redeployed to an up-to-date known-good state. These typically include hardware and systems that, if compromised, could cause severe disruption or data breaches.	3(1) 3(3)(d)(e) 12 14(1)
M24.05 CPE	Public telecoms providers shall block anomalous or potentially malicious CPE activity that could impact the network, to maintain network integrity and service quality.	3(3)(a)(i) 4(1)(a) 4(2)(a) 4(4)(b) 5(3) 6(1) 6(2) 6(3)(a),(d),(f) 8(1) 11(b)(iii)
M24.06 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 an appropriate central repository. The service account shall be dedicated to the task or service they have been assigned to (i.e. not associated to a user).	3(3)(a),(b),(d) 3(5) 6(2) 6(3)(b),(d) 8(1) 8(2)(b)(f) 8(5)(a)(b)(c)(e)
M24.07 Service accounts	A privileged access solution that securely stores and rotates credentials frequently should be used to manage service accounts.	3(3)(a),(b),(d) 3(5) 6(2) 6(3)(b),(d) 8(1) 8(2)(f) 8(5)(a)
M24.08 APIs	Public telecoms providers shall ensure their APIs are clearly documented in an appropriate central repository, and implemented securely, to minimise exposure to the internet and/or unauthorised parties.	3(1)(c) 3(3)(e) 4(1)(b) 4(2)(b) 6(3) 6(4) 9(1) 9(2)(c)(i),(v) 11(a)
M24.09 Overarching security measures	Public telecoms providers shall disable any unused ports, protocols and services.	3(1) 3(3)(a)(iv) 3(3)(c)(d)(e) 8(1) 9(c)(iii)

Question 5

Annex A – Glossary of terms

Accepted Answer

The terms listed below are used throughout the Code of Practice.


Access Network	The part of the network that connects directly to customers. This includes, but is not limited to, the Radio Access Network, Passive Optical Network (PON), and copper access networks.
Application Programming Interface (API)	A set of rules or protocols that enables software applications to communicate with each other to exchange data, features and functionality.
Asset	Anything of value, financial or otherwise, that is required to enable the operations of an organisation.
Authentication, Authorisation, and Accounting (AAA)	A security framework used to control and track entity access to computer networks and resources. Authentication - verifies the identity of an entity attempting to access a network or resource, typically through a credential. Authorisation - determines what resources or actions an entity is allowed to access after successful authentication. Accounting - tracks and logs entity activity, including resource consumption and access times, for auditing and billing purposes. Common AAA protocols include RADIUS, TACACS+, and Kerberos.
Bare-Metal Hypervisor	Another name for a Type 1 hypervisor, so called as it does not run on top of a host’s operating system but on the ‘bare-metal’ of the host’s hardware.
Break-Glass	A method of bypassing normal access controls to gain access to a system or service in an emergency.
Bulk data	A term used to describe large quantities of data, including but not limited to personal, financial or technical data (often held in, or accessible from one place and therefore requiring special protection).
Business Continuity and Disaster Recovery Planning	The process of creating systems of prevention and recovery to deal with potential risks.
Business Support Systems (BSS)	Corporate systems that are indirectly involved in the running of the telecoms network and/or the service provision.
Container	Software that packages up code and all its dependencies so the application runs efficiently and reliably from one computing environment to another.
Containerisation	The running of multiple containers on a single system. The host system provides the separation between these containers. As a hypervisor is not used, a container is not a security boundary.
Core nodes	The main network elements that process data and store information.
Corporate Security Domain	A system or group of systems that all have the same level of security which protects the provider’s own data.
Cryptographically attested	Identity, security and integrity of a system or sub system is confirmed by an encrypted algorithm.
Customer Premises Equipment (CPE)	Customer Premises Equipment refers to equipment provided to customers by the public telecoms provider that is used, or intended to be used, as part of the network or service. This excludes consumer electronic devices such as mobile phones and tablets, but does include devices such as edge firewalls, SD-WAN equipment, and fixed wireless access kit.
Cyber Assessment Framework (CAF)	The CAF provides a systematic and comprehensive approach to assessing the extent to which cyber risks to essential functions are being managed by the organisation responsible.
DeMilitarised Zone (DMZ)	A perimeter network that protects, and adds an extra layer of security to, an organisation’s internal local-area network from external untrusted traffic.
Digital Subscriber Line Access Multiplexer (DSLAM)	A network device that receives signals from multiple customer Digital Subscriber Line (DSL) connections and puts the signals on a high-speed backbone line using multiplexing techniques.
E164, E212, E214	Internationally recognised standards for number formats.
Exposed Edge	Equipment that is either within customer premises, directly addressable from customer/user equipment, or is physically vulnerable. Physically vulnerable equipment includes mobile base sites, equipment in road-side cabinets or attached to street furniture.
Externally‑facing Interface	Any system interface that is accessible to people or systems outside of the provider’s direct control.
Externally‑facing System or Service	Any system or service with an externally-facing interface.
Fixed‑profile SIM	A Subscriber Identity Module Card where the credentials used to authenticate access to the network cannot be modified.
Fuzzing	An automated software testing technique that involves providing invalid, unexpected, or random data as inputs to assess a system’s vulnerability to them.
Global System for Mobile Communications (GSM)	A digital mobile network that is widely used by mobile phone users in Europe and other parts of the world.
GSMA’s Network Equipment Security Assurance Scheme (NESAS)	An industry-wide security assurance framework to facilitate improvements in security levels across the mobile industry.
Hardening	The process of securing a system by reducing its attack surface.
Home Location Register (HLR)	A database containing pertinent data regarding subscribers authorised to use a global system for mobile communications (GSM) network, including their last known location and service they are allowed to use.
Host‑based sensors	Pieces of code installed in a computer or other devices to collect and forward information on system activity.
Hub signalling address	The parts of the network that need to communicate with other providers (e.g. for roaming or number portability).
Insecure Protocols	An insecure protocol should be considered to be any protocol that is unencrypted, deprecated or a proprietary security protocol. Some examples of protocols that are more secure than others include HTTPS rather than HTTP, SSH rather than Telnet, TaACACS+ rather than TACACS. This is not an exhaustive list and is constantly evolving.
Internally‑facing interface	Any system interface that is only accessible by people and systems within the provider’s direct control.
Internet Exchange Point (IXP)	An Internet Exchange Point is a physical infrastructure where different networks (ISPs, content providers, cloud providers and enterprises) connect directly to exchange internet traffic with each other.
IR.21	A GSMA (Global System for Mobile Communications Association) document that details the technical information required for roaming between mobile network operators (MNOs).^{[footnote 71]}
Jump Box	A system on a network used to access and manage devices in a separate security zone.
Know Your Customer (KYC)	A process that verifies a customer’s identity and financial profile.
Logical edge of the network	The furthest element of the network that can be electronically reached.
Malformed signalling messages	Signalling messages should be correctly formed and only directed to the appropriate parts of the network from parts of the network which are authorised and expected to initiate them. Malformed messages can be caused by transmission faults, but they may also be deliberate attempts to attack a network and as such should be blocked. See also ‘Fuzzing’. A malformed signalling message would not meet a recognised standard such as FS11 and FS19; be longer or shorter than it should be; could be an internal type message arriving at an external interface and/or would fail to meet FS11 and FS19.
Managed Service Provider (MSP)	Any entity that delivers services, such as network, application, infrastructure and security, via ongoing and regular management, support and active administration on customers’ premises, in their MSP’s data centre (hosting), or in a third-party data centre.
Management Access	Access to control or modify the operation of a device or network.
Management Networks	A collective term for systems that are responsible for network management.
Management Plane	The interfaces and connectivity and supporting equipment that allows network equipment to be managed.
Media Access Control address (MAC)	A unique identifier assigned to a network interface controller for use as a network address in communications within a network segment.
Mobile Device Management	Software that helps organisations secure, monitor, and control employee mobile devices. It enables: - Security policy enforcement - Remote data wipe - App and update deployment - Device tracking.
Mobile Switching Centre (MSC)	The MSC connects calls between subscribers by switching the digital voice packets between network paths. It also provides information needed to support mobile subscribers’ services that the home location register has given access to.
Multi‑Factor Authentication (MFA)	An authentication method that requires the user to provide two or more verification factors to gain access to a resource.
Multi‑Service Access Node (MSAN)	A device that connects customers’ telephone lines to the core network, to provide telephone, ISDN, and broadband, all from a single platform.
National Cyber Security Centre (NCSC)	The UK’s technical authority for cyber security. It is part of the Government Communications Headquarters (GCHQ).
Negative Testing	The process of validating the application against invalid inputs. Invalid data is used in testing to compare the output against the given input and the results are monitored for potential vulnerabilities.
Network and Information Systems Regulations (NIS Regulations)	These regulations provide legal measures to protect essential services and infrastructure by improving the security of their network and information systems and maturing their resilience.
Network Data	The network identifiers, logs and documents that help to describe the network and the equipment in the network.
Network equipment	Includes hardware, software and firmware that is used to provide the network or service.
Network‑based sensors	A component installed in a network to collect and forward information on system activity.
Network Function Virtualisation (NFV)	A way to virtualise network services, such as routers, firewalls, and load balancers, that have traditionally been run on proprietary hardware.
Network Operations Centre (NOC)	A physical or logical location from where network engineers can continuously monitor the performance and health of a network.
Network Oversight Function (NOF)	Network Oversight Functions are the components of the network that oversee and control the Security Critical Functions, which make them vitally important in overall network security. They are essential for the network provider to understand the network, secure the network, or to recover the network.
Network Time Protocol (NTP)	Network Time Protocol is a protocol used to synchronize the clocks of computers and network devices over a network, so they all keep accurate and consistent time.
Operational Support Systems (OSS)	Any system that is used to directly support the operation of the network or service.
Optical Line Terminal (OLT)	The endpoint hardware device in a passive optical network.
Privileged Access / Administrative Access	An access to network equipment where greater capabilities are granted than a standard user or customer. Any access over the management plane, or to management ports of network equipment is privileged access.
Privileged Access Workstation (PAW)	An appropriately secured device that enables a user to make changes to Security Critical Functions and/or Network Oversight Functions, via a management plane.
Privileged User / Administrator	A person who is granted privileged access, through their role, access and credentials, or through any other means.
Profile‑modifiable SIM	A SIM card where the SIM profile credential used to authenticate access to the network can be modified or deleted, or where new SIM profiles and credentials may be added. A profile-modifiable SIM card is also able to support encryption key changes.
Remote Desktop Protocol (RDP)	A proprietary protocol which provides a user with a graphical interface to connect to another computer over a network connection.
RFC3682	The specification for the Generalised ‘Time to live’ (TTL) Security Mechanism (GTSM).
Secure Channel	A communications flow that is encrypted in line with NCSC guidance where issued, or otherwise current industry best practice such as TLS 1.3, SSHv2, or IPsec with NCSC-recommended cipher suites. This is not an exhaustive list and is constantly evolving.
Security Analysis	Considering data or information with the intent of detecting a threat actor or understanding the behaviour of a threat actor. Used to determine mitigating actions.
Security Critical Function	A ‘Security Critical Function’ in relation to a public telecoms provider means “any function of the network or service whose operation is likely to have a material impact on the proper operation of the entire network or service or a material part of it”.
Security failings	Security failings refer to instances where security measures fail to protect systems, data, or networks from unauthorised access, use, or attacks. These failings can result from various factors, including inadequate security controls, outdated software, or human error.
Security Functionality	The security-related features, functions, mechanisms, services, procedures, and architectures implemented within organisational information systems or the environments in which those systems operate. ^{[footnote 72]}
Security permission	‘Security permission’, in relation to a public electronic communications network or a public electronic communications service, means “a permission given to a person in relation to the network or service that would give the person an opportunity to cause a security compromise to occur in relation to the network or service”. For clarity, security permissions also include attributes or privileges that allow users to access systems or data.
Service account	A service account is an account not associated with a user that is used to run applications, virtual machines, automated services or other background processes. It can also be used as a proxy to perform tasks on behalf of a user. These accounts often have widespread, high privilege access.
Signalling System No7 (SS7 or CCITT #7)	A telecommunications signalling architecture traditionally used for the set up and clear down of telephone calls and services in fixed or mobile telecommunications networks.
SIM Card	A Subscriber Identity Module (SIM) is a unique hardware component or token, and associated software, used to authenticate the subscriber’s access to the network. As used in this document, the SIM encompasses the hardware UICC/eUICC, the SIM/USIM/ISIM applications, eSIM and RSP functionality and any SIM applets. Note that this is a broader definition than the true technical definition (which defines the SIM to be the GSM authentication application running on a UICC). Instead, we are using the term ‘SIM’ as it is commonly used in the public domain to refer to the token in a device in its entirety.
SIM OTA	SIM Over-The-Air – technology that updates and changes data in a profile modifiable SIM card without having to physically replace it.
SIM Profile	The provider-defined identity, credential, algorithms, parameters and applets stored on the SIM card.
Small Cell	Small cells including femtocells, picocells and microcells, are compact, short‑range mobile base stations intended to enhance mobile coverage and increase network capacity.
Software Defined – Wide Area Network (SD‑WAN)	A virtual WAN architecture that allows enterprises to leverage any combination of transport services to securely connect users to applications.
Subscriber Data	Information gathered and retained by the public telecoms provider about its subscribers, typically comprising personal, technical, and service-related data.
Third Party Administrators (3PA)	Third party administrators are external partners that carry out privileged access/administrative access on behalf of public telecoms providers. These services could be provided either by organisations external to the public telecoms provider, or by functions within the public telecoms provider’s parent or group organisation.
Third party Supplier Equipment or Network Equipment	Either a software or hardware component of the provider’s network that transmits or receives data or provides supporting services to components of the provider’s network that transmit or receive data. It includes both virtual machines and physical hardware.
Total Cost of Ownership (TCO)	The security related additional costs, as well as the initial purchase cost, that the public telecoms provider will incur when the equipment/software is live. This could be the cost of additional add-on security features, additional hardware, additional staff to design and operate the service/solution, or controls needed to mitigate security shortfalls or to cover patch management.
Transport Layer Security (TLS)	A widely adopted security protocol designed to facilitate privacy and data security for communications over the internet.
Trust levels	Where all the devices at the same level have the same standard of security, integrity and availability.
Trusted Platform	A secure platform that has the characteristics defined in NCSC’s secure by default platforms guidance.^{[footnote 73]}
Trusted Platform Module (TPM)	Trusted Platform Module (TPM) technology is designed to provide hardware-based, security-related functions. A TPM chip is a secure crypto-processor that is designed to carry out cryptographic operations. The chip includes multiple physical security mechanisms to make it tamper-resistant, and malicious software is unable to tamper with the security functions of the TPM. The most common TPM functions are used for system integrity measurements and for key creation and use. During the boot process of a system, the boot code that is loaded (including firmware and the operating system components) can be measured and recorded in the TPM. The integrity measurements can be used as evidence for how a system started and to make sure that a TPM-based key was used only when the correct software was used to boot the system.
Trusted Platform / Trusted Computing Platform	A platform that uses roots of trust to provide reliable reporting of the characteristics that determine its trustworthiness.
Trustworthy	Reliable and of good reputation. In considering whether something is trustworthy, public telecoms providers are advised to have regard to the ‘security expectations’ outlined in the Vendor Security Assessment and consider the risks associated with sourcing services/personnel from the countries listed in the Schedule to the Electronic Communications (Security Measures) Regulations 2022.
Universal Integrated Circuit Card (UICC)	Any physical card containing SIM-like credentials allowing network access, including permanently soldered-in UICCs in some handsets and IoT devices. An eSIM does not require a UICC.
Up‑to‑date known‑good software state	A piece of software that is proven to be current, supported and unmodified from the agreed standard.
User Data	The collection of identifiable and non-identifiable information related to a person’s interaction with a digital or physical service/asset, including personal details, behavioural patterns, preferences, and system usage. It extends beyond subscribers and can include users of the services (e.g. roamers) as well as employees and anyone involved in the delivery of services.
Vendor’s End‑Of‑Life Date	The end of the vendor’s standard, global support for the equipment. It is the point at which no further security patches will be provided.
Virtualisation Administrators	Administrators who are granted privileged access to virtualisation infrastructure (NFVi), or the functions which manage virtualisation infrastructure.
Virtualisation ‘Cut‑Through’ and Paravirtualisation	Paravirtualisation is when specific guest OS kernel modifications are made to replace non-virtualisable instructions with hypercalls that communicate directly with the virtualisation layer hypervisor. The hypervisor also provides hypercall interfaces for other critical kernel operations such as memory management, interrupt handling and time keeping. These are often referred to as ‘cut-throughs’.
Virtualisation Fabric	The physical servers and networking equipment used to provide the resources for virtualised workloads to run on.
Virtual Extensible LAN (VXLAN)	A network virtualisation technology that attempts to address the scalability problems associated with large cloud computing deployments.
Virtual LAN (VLAN)	Any broadcast domain that is partitioned and isolated in a computer network at the data link layer.
Visitor Location Register (VLR)	A vital part of the mobile network. It is used as a temporary database that stores subscriber/user data.
Visited Public Land Mobile Network (VPLMN)	Refers to the mobile network that a subscriber connects to when they are roaming outside of their home network.
Wide Area Network (WAN)	A data network that extends over a large geographic area for the primary purpose of computer networking.

Question 6

Annex B – Vendor Security Assessment

Accepted Answer

Introduction

The security of equipment deployed within a network is critical to the protection of that network. When selecting equipment that will support a critical service or critical infrastructure, public telecommunications providers should make an assessment of the security of that equipment and consider that assessment as part of their procurement and risk management processes.

This Annex provides advice on how to assess the security of network equipment. It provides guidance to support public telecommunications providers (the providers of Public Electronic Communications Networks and Services), in meeting their duties under the Telecommunications (Security) Act 2021, and the Electronic Communications (Security Measures) Regulations 2022. For example, under Regulation 3(3)(e), the network provider is required:

“to take such measures as are appropriate and proportionate in the procurement, configuration, management and testing of equipment to ensure the security of the equipment and functions carried out on the equipment”.

The guidance in this Annex should be used when making selection decisions for network equipment. However, security is an ongoing activity. As with other areas of performance, public telecoms providers should continue to assess and retain evidence of the vendor’s track record in security during the equipment’s lifetime, as this will support future security assessments.

The guidance in this Annex does not take account of, and cannot mitigate, the threats that may arise because of additional risks specific to a particular vendor in the supply chain. These risks include the degree to which it might be susceptible to being influenced or required to act contrary to the interests of the customer or their national security. In such circumstances, additional controls specific to the vendor in question may be required. This shall be considered as part of the total cost of ownership when making a procurement decision.

The guidance below is taken from the NCSC’s Vendor Security Assessment (VSA). Any references to ‘customers’ should be interpreted as ‘public telecoms providers’ in the context of this Code of Practice.

Summary of approach to assessment

This document provides guidance on how to assess a vendor’s security processes and their supplied network equipment. The purpose of the approach is to objectively assess the cyber risk due to use of the vendor’s equipment. This is performed by gathering objective, repeatable evidence on the security of the vendor’s processes and network equipment.

Assessing the cyber risk due to a vendor requires:

evidence from the vendor themselves;
testing to validate the vendor’s claims;
third party evidence.

For each criterion in this document, there are a range of product-specific spot checks that may be performed and evidence may be obtained directly from lab-tests on the product itself. These 3 components together will help build an understanding of how well a vendor is building a new product.

However, such an approach will always be fallible. While evidence will be customer-driven, it can only provide examples of vendor behaviour. To be effective, both the approach and security standards need to be sustained over many years, with evidence of good and bad practice recorded to support future security assessments and procurement decisions.

When assessing vendor security practices, the NCSC recommends operators to not rely exclusively upon vendor documentation to assess vendor security. Security assessments should be based on the vendor’s implemented security behaviour. This includes product-line specific spot checks, and objective evidence extracted from the product.

Note: Vendors cannot pass, fail nor comply with the Vendor Security Assessment, neither is this a tick-box exercise. 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.

External audits and international schemes

One of the biggest challenges when assessing the security of network equipment is the industry practice of producing regional or operator-specific versions of products. Where vendors follow this practice, international customers cannot share the burden of gaining evidence or assurance about product quality or security, whether through working with each other or through international testing schemes.

It may be possible to rely on independent, external sources to provide some of the required evidence, provided:

it is applicable to the customer’s product (specifically the same hardware and code base);
all evidence can be revalidated by the customer, and some evidence has been randomly selected to be revalidated.

Generally, vendor audits or evaluations that rely on vendor documentation are unlikely to provide useful evidence unless it is possible to verify that the audit relates to the security of the network equipment. For the same reason, audits or evaluations where the evidence behind the audit is not widely available and testable should also not be considered. For example, as currently defined, the private, paper-based assessments performed under GSMA’s NESAS^{[footnote 74]} scheme are unlikely to provide useful evidence in support of the customer’s assessment of product security.

Support from the security research community

Given the range, scale and complexity of network equipment, participation from the global security research community (including both commercial labs and academia) is essential to support customers in understanding security risk. For this reason, vendors should be encouraged to be transparent and open about their security practices, and should be encouraged to support responsible, independent security researchers in performing their own testing and analysis.

To support the development of increasingly secure and open telecommunications equipment, DSIT has established a UK Telecoms Lab (UKTL). This is a secure research facility that will bring together public telecoms providers, existing and new suppliers, academia, and the government. The lab will be built using major incumbent vendors’ carrier grade network offerings and virtualised network technology to research and test new ways of increasing security and interoperability.

The approach to assessment

Assessing a vendor’s approach to security requires a four-tiered approach:

Assess

Assessing a Security Declaration provided by the vendor. This should state the vendor’s approach to security, and the security promises that the vendor makes to its customers. In the interests of developing the security ecosystem, the NCSC recommends that the vendor openly publishes their Security Declaration. This provides confidence to customers that the vendor’s approach is consistent for all customers and product lines and allows the wider security community to participate in the security discussion.

Check

Performing Spot Checks on the vendor’s implemented security processes for specific, independently chosen product releases. As all details should be readily available to the vendor within their own systems, providing advance notice of the choice should not be necessary.

Analyse

Performing Lab Tests against equipment. The tests should either be against all equipment or the equipment should be randomly selected from the equipment provided by the vendor. Lab tests should be automated wherever possible so they can be easily repeated at low cost. Lab tests performed independent of the customer should be against the same product version track, hardware, software, firmware, and configuration as used by the customer.

Sustain

Holding vendors to the standard in the Security Declaration throughout the entire period of the customer’s relationship with the vendor. Customers should analyse root causes of issues and record the vendor’s security performance to ensure future assessments are made with a rigorous evidence base.

Recommendations for applying this four-tiered approach are provided below.

Assessing vendor security performance

When assessing vendor security practices one essential source of data is the vendor’s security performance. Customers should consider both the vendor’s security culture and behaviour as evidenced by:

maturity of vendor risk assessment and security assessment processes;
vendor transparency, openness, and collaboration with the security research community;
vendor assessment, management, and support to customers in relation to any security vulnerabilities and incidents;
vendor compliance with security obligations and requirements;
vendor approach to product and component support.

Security incidents in themselves are not evidence of poor security practice. All major companies are likely to be impacted by security incidents and depending on their cause and how they are handled, security incidents may provide an example of good practice. The customer should consider whether the incident could have been reasonably avoided, or its impact could have been reasonably reduced.

Similarly, product security vulnerabilities or issues are not in themselves evidence of poor security practice as such issues will occur in all products. However, where issues are simplistic, or due to poor product management or maintenance, this may be evidence of poor practice.

Vendor security assessment criteria

The following table can be used to assist in assessing the security processes of vendors and their network equipment. The table describes the information that customers should expect within the Security Declaration, Spot Checks that should be considered to collect evidence, and the Lab Testing that customers or third parties should consider making against equipment. For Spot Checks and Lab Testing, it is assumed that the customer will be given sufficient access to vendor processes and equipment to perform an effective evaluation prior to making decisions based upon this evaluation.

When third parties are used, the customer should satisfy themselves that the third party was sufficiently independent, had sufficient technical competence, and gained sufficient information about the vendor’s day-to-day practices to provide them with the confidence required for reliable evidence.

Topic: V.A: Product lifecycle management	Security Expectation	Why it matters	Evaluation: Security Declaration	Evaluation: Customer or third‑party Spot‑checks	Evaluation: Customer or third‑party lab test
V.A: Overall aim	The vendor’s products are properly supported throughout the lifetime of the product.	To provide confidence that a product will be maturely managed by the vendor, receiving updates and security critical fixes for the supported lifetime of the product.	As part of the Security Declaration, the vendor describes how products are supported.	-	-
V.A.1: Product lifecycle process	The vendor clearly identifies the lifecycle for each product. Vendors should have an End of Life Policy which details how long products will be supported after End of Sale.	To provide confidence that products will be supported until a given date. Also, that the vendor’s support dates apply globally, meaning that the vendor is likely to continue to invest in product maintenance throughout this period.	The vendor describes their product’s lifecycle within the Security Declaration. For each release within a product line, the vendor publishes End of Sale dates on their website as soon as they become applicable. The End of Life Policy should detail how long, and in what way, products will be supported after the End of Sale date has been announced. The location of this information is referenced in the Security Declaration.	Check product release history. Explore how the vendor is keeping components up-to-date.	-
V.A.2: Software maintenance	Each product is maintained through its published life cycle. This maintenance, as a minimum, covers security fixes for the product.	To provide confidence that products can be patched against security issues discovered in the product throughout its supported lifetime.	The vendor clearly describes how they will support products during their lifetime, including what support they will provide under each support class.	View records showing the history of security fixes applied to the product, including a roadmap for resolution of any outstanding vulnerabilities.	Pick a sample of known vulnerabilities for a customer-selected product and check how and when they were patched in accordance with the vendor’s policies. (see V.A.7). Test the product to verify that the equipment is no longer vulnerable to the vulnerability or variants of the vulnerability.
V.A.3: Software version control	Each product has a version-controlled code repository which logs every code modification. This audit log will detail: what code has been modified, added, or removed; why the change was made; who made the change; when the change was made; and which version of the code has been built into the released product.	To provide confidence that the vendor can track exactly what code is being deployed within products. It is essential for effective investigation of supply chain attacks.	The vendor describes how they maintain the integrity of their code base.	The vendor demonstrates how changes are made based on normal processes, and how changes via other means would be rejected. Explore a change and verify that processes were followed.	-
V.A.4: Software releases	Each product goes through a rigorous software release cycle including internal testing before a version is released for general availability. Software will not be released if it does not comply with the Secure Engineering requirements detailed below. Each product should have regular external testing carried out on it by an independent third party.	This requirement exists to provide confidence that vendors test their software releases and validate that their internal secure engineering processes have been followed. The tests should also ensure that previously resolved security vulnerabilities are not reintroduced.	The vendor describes their software release cycle, including the gates, and the testing performed.	View the build and test process. Review the testing performed against a customer-chosen product line and version. Check that testing tools are well configured and view the test results. Verify that tests are included to check for previously resolved vulnerabilities and issues. The vendor demonstrates that issues were correctly fixed as a result of any failed tests.	Check accuracy of a set of the vendor’s test results by repeating the tests in the customer’s or third party’s lab.
V.A.5: Development processes and feature development	There is one primary release train of the product. Forking of new versions is minimised. Where necessary, customer-specific functionality is provided as optional modules. Any new features are brought into the main product line during the standard development roadmap.	This requirement exists to provide confidence that the vendor is shipping them a generally available version of the product, so they know the product can be supported throughout its lifetime using the general support routes. It is highly unlikely that the vendor will be able to properly support a proliferation of feature-specific product versions.	The Security Declaration describes the vendor’s development process, including how and when new product versions are released, and how the number of versions is kept to a manageable level.	-	-
V.A.6: International release and forking	The vendor maintains a single, global version line for each product. There are a minimal number of other versions (ideally none).	This requirement exists to provide the confidence that the product is globally supported and that any issues discovered can easily be mitigated. It is highly unlikely that the vendor will be able to properly support a proliferation of customer-specific product versions.	The vendor publishes details of all released versions of their products, including binary hashes. It is expected that this information will be on the vendor’s website. The vendor references its public list of product versions within its Security Declaration.	The vendor describes the full release train of the product, including why each version was created.	Based on the vendor’s published information, or otherwise, test that product versions supplied by the vendor are the ‘global’ versions and have matching binary hashes.
V.A.7: Use of tools, software and libraries	Third party tools (e.g. code compilers), software components and software libraries that are used within and in the development of the product are inventoried. Any of the above that are material to the security of the vendor’s software are maintained throughout its lifetime.	Out-of-support tools, software components, software, or libraries are unlikely to use modern security features. If exposed, they can cause known vulnerabilities to be embedded in the product. Vulnerabilities in critical security protections of the product must be patched, to minimise the impact of exploits.	The Security Declaration describes how third party software components are maintained, explicitly stating when, if ever, out-of-support components will be included in any product versions, stating justifications.	For a customer-selected product, the vendor provides a list of third party components that are material to the security of the product, (e.g. those components exposed via interfaces). Verify that these components are still actively maintained, and there is a support plan for the lifetime of the product.	Scan product interfaces to inventory known third party tools and determine if they are being maintained. Examine the product to verify that the vendor’s component list appears accurate.
V.A.8: Software documentation	The vendor provides up-to-date and technically accurate documentation alongside new releases of the product. This documentation, as a minimum, shall detail how to securely configure, manage, and update the product.	This provides the customer with the information they require to help them securely deploy and manage the product throughout its lifetime in their networks, and independently assess the security of that configuration. This helps to reduce the customer’s on-going dependence on the vendor.	The Security Declaration makes commitments about the release of product documentation to customers.	-	Using documentation, set-up, operate, configure, and update the product without support from the vendor.

Topic: V.B: Product security management	Security Expectation	Why it matters	Evaluation: Security Declaration	Evaluation: Customer or third‑party Spot‑checks	Evaluation: Customer or third‑party lab test
V.B: Overall aim	Products will be developed in a ‘secure by default’ manner.	These requirements exist to provide confidence that a product they deploy has been developed using standard security mitigations and secure coding techniques.	-	-	-
V.B.1: Security culture	The vendor has a security culture which ensures that security principles are followed.	This provides confidence that developers within the company are known to follow the security principles and development requirements.	The Security Declaration describes the senior ownership of the security culture within the vendor, and the mechanisms that exist to allow staff to raise security concerns.	-	-
V.B.2: Secure development lifecycle	The vendor has a Secure Development Lifecycle^{[footnote 75]} to embed security into product development. All development teams follow, and can evidence that they follow, the Secure Development Lifecycle processes.	This provides confidence that security is embedded in the development process and that there is a consistent security culture within the company.	The Security Declaration describes how the vendor develops secure products, including how the vendor verifies that its secure coding standards are followed.	The vendor demonstrates how they gain confidence that the Secure Development Lifecycle has been followed by developers. The vendor describes how they ensure their code is of high quality. Verify examples of security controls built into the product development processes.	Search for signs that the vendor’s security controls built into their Secure Development Lifecycle are working (e.g. that subcomponents are resistant to malformed inputs).
V.B.3: Internal component management	Any shared internal components or libraries are kept up to date and only the latest stable, supported version is used. These components and libraries are not to be modified for specific builds and are supported for the lifetime of the product.	This provides confidence that any internal shared components being used within a product will be maintained throughout the lifetime of the main product.	The Security Declaration makes clear commitments around the maintenance of internal components.	For a customer-selected product, the vendor can list the product’s software and hardware components. Verify that only recently released versions of shared internal components and libraries are used. Explore whether the product line has forked any shared libraries.	In a lab, verify that the released product contains only one version of each internal software component or library, and that all internal components have been recently built.
V.B.4: External component management	Only supported external components are used within a product. The vendor monitors the external component’s changelog so that only the latest supported, stable version is used within the product. Additionally, the vendor monitors the external component’s security advisories and pull in any security fixes and integrate them into their product with a security update.	This provides confidence that any third party component a vendor chooses to use will be currently supported, and that any security issue discovered with the component will be patched. Extended support contracts are likely to increase security risk and should be avoided.	The Security Declaration makes clear commitments on the use of supported external components.	For a customer-selected product release, verify that it is only using supported versions of external components and libraries. Explore how these components will be updated when they reach end-of-life. Explore whether the product line has forked any externally-developed code, and if so, explore how it is maintained.	In a lab, verify that the released product is only using fully supported versions of all external components. Search for evidence of internally- forked external components or libraries.
V.B.5: Unsafe functions	There are no unsafe functions used within the vendor’s released code. Unsafe functions are those commonly associated with security vulnerabilities or those considered unsafe by industry best practice.	These functions are frequently the cause of product vulnerabilities.	The Security Declaration clearly states whether unsafe functions are used within the vendor’s code base.	Request code metrics on use of unsafe functions	-
V.B.6: Redundant and duplicate code	The vendor’s source tree is maintained to a level that there is limited redundant or duplicate code.	Redundant code makes a product more difficult to understand and maintain. Increases the likelihood that security critical changes won’t be applied to access the product.	The Security Declaration makes clear statements about how the vendor produces code to reduce complexity and increase maintainability.	Request code metrics on how much duplicated code exists within the source tree.	-
V.B.7: File structure	The vendor’s source tree is maintained to a level where code complexity is minimised, and functions perform single, clear, actions.	Code clarity reduces the risk of error or vulnerability and makes issues easier to spot.	The Security Declaration makes clear statements about how the vendor produces code to reduce complexity and increase maintainability.	-	-
V.B.8: Debug functionality	There is no engineering debug functionality present within the vendor’s released products that could weaken or bypass the product’s security mechanisms.	Engineering debug functionality may be used by an attacker to exploit a product.	The Security Declaration makes clear statements confirming that no engineering debug functionality is present within a released version of a product.	Ask the vendor to demonstrate that inclusion of debug functionality within a release build results in a build failure.	-
V.B.9: Comments	The source tree has suitable and understandable comments through it, explaining what the code is for and why it performs its actions.	Commenting helps ensure products can be easily supported in the future and speeds up vulnerability fixes.	The Security Declaration makes clear statements about how the vendor produces code to reduce complexity and increase maintainability.	-	-

V.C: Protected development and build environments	Security Expectation	Why it matters	Evaluation: Security Declaration	Evaluation: Customer or third‑party Spot‑checks	Evaluation: Customer or third‑party lab test
V.C: Overall aim	The NCSC expects the product is developed within a secure environment.	A secure environment helps to maintain the integrity of the product and reduces the risk of supply chain attack.	The Security Declaration describes how the vendor maintains the integrity of its products through securing the development and build environments.	‑	‑
V.C.1: Segregation of development environment	Development environment is segregated from corporate network and protected from the internet.	This protects the development environment from compromise via straight-forward attacks.	-	Ask to see details of penetration-tests or red team^{[footnote 76]} exercises, where the objective was to modify the vendor’s codebase or development environment.	-
V.C.2: Segregation of build environment	Build environment is segregated from corporate network and protected from the internet. Very few people can make changes.	This protects the build environment from compromise via straight-forward attacks.	-	Ask to see details of penetration-tests or red team exercise , where the objective was to modify the vendor’s build environment.	-
V.C.3: Build environments and automation	Build environments are simple, and the build process is automated.	Simple build environments and an automated build process makes the product build easier to understand, less likely to have errors and reduces the risk of compromise.	The Security Declaration describes how the vendor build process can be understood and maintained.	For a customer-selected product release, the vendor explains the build environment and its dependencies, and demonstrates the automated process via which a build is performed.	-
V.C.4: Role‑based access	Only individuals with a need have access to the internal code base, and access is controlled and limited based on role.	Minimising access reduces the impact of a malicious insider.	The Security Declaration describes how the vendor enforces role-based access controls to its development and build environments.	The vendor demonstrates that access to the development and build environment is limited.	-
V.C.5: Code review	All code is independently reviewed prior to acceptance. Feedback processes exist.	Code review is essential to maintaining coding standards, and to reduce the risk due to a malicious insider.	The Security Declaration describes how and when the vendor carries out internal code review and audit.	For any change made to the code, the vendor can demonstrate how that change was reviewed or audited.	-
V.C.6: Repeatable builds	All builds of released software can be replicated at a future date.	Replicated builds allow the vendor to demonstrate what components were included in a past build. Tracking of each build, what components are built into it and which versions of the components were used is critical to verifying the integrity of a build.	The Security Declaration makes clear statements about how the vendor maintains their build environment and code base to enable repeated builds with a minimal number of differences – with an explanation for each difference.	The vendor reproduces a previous build and confirms that it is functionally identical to a version that was released. The vendor demonstrates that they have retained copies of any external dependencies necessary for the build.	A released build and a reproduced build are compared to verify functional equivalence.

V.D: Exploit mitigations	Security Expectation	Why it matters	Evaluation: Security Declaration	Evaluation: Customer or third‑party Spot‑checks	Evaluation: Customer or third‑party lab test
V.D: Overall aim	The vendor implements standard security mitigations used in a modern product.	Each of these mitigations has a demonstrable positive impact on the security of a product by helping to mitigate well known vulnerability classes. Modern platforms, operating systems, development languages, libraries and development tools regularly offer security enhancing technologies to both minimise the occurrence of security defects, and to minimise their impact should they occur.	The Security Declaration describes the vendor’s policy with respect to the use of defensive security techniques.	‑	‑
V.D.1: Heap protections	The vendor makes use of modern heap protection mitigations to help prevent heap-based memory corruption attacks against the product.	Widely used to make it more difficult for an attacker to exploit any security issues.	The Security Declaration states whether the vendor’s products use heap protections throughout their product.	-	Verify that heap mitigations are enabled by (automatically) inspecting the product for this mitigation.
V.D.2: Stack protections	The vendor only ships executable code that has been compiled using modern stack mitigations.	Widely used to make it more difficult for an attacker to exploit any security issues.	The Security Declaration states whether the vendor’s products use stack protections throughout their product.	-	Verify that stack mitigations are enabled by (automatically) inspecting the product for this mitigation.
V.D.3: Data execution prevention	The vendor supports hardware-enforced data execution prevention (for example DEP or NX).	Widely used to make it more difficult for an attacker to exploit any security issues.	The Security Declaration states whether the vendor’s products use hardware-enforced data execution prevention throughout their product.	-	Verify that data execution prevention mitigations are enabled by (automatically) inspecting the product for this mitigation.
V.D.4: Address space layout randomisation	The vendor only ships executable code that has been compiled using modern ASLR techniques.	Widely used to make it more difficult for an attacker to exploit any security issues.	The Security Declaration states whether the vendor’s products use ASLR throughout their product.	-	Verify that address space layer randomisation mitigations are enabled by (automatically) inspecting the product for this mitigation.
V.D.5: Memory mapping protections	The vendor’s product will have no memory pages mapped by default as both ‘Writeable’ and ‘Executable’. This excludes areas of the code required to do Just-In-Time code compilation.	Widely used to make it more difficult for an attacker to exploit any security issues.	The Security Declaration states whether the vendor’s products have any read-write memory pages. If any Just-In-Time code compilation is required, this should be described in the security declaration.	-	Verify that there are no executables that map memory pages as both writeable and executable by (automatically) inspecting the product.
V.D.6: Least privilege code	The vendor follows a ‘least privilege’ methodology when developing and executing code within their products. The vendor ensures that their product only runs at or requests the minimum privilege level required for it to fulfil its advertised purpose. If higher privilege levels are ever required, then the product implements segregations to elevate privilege for the specific task.	Products that run at higher privilege levels than required can provide a route for attackers to exploit a host system.	The Security Declaration states the vendor’s ‘least privilege’ methodology.	-	Verify that executable code running on the vendor’s platform runs with the least level of privilege required. Verify that any privileged executables drop privilege after completing their privileged task.
V.D.7: Security improvement and secure execution environments	The vendor has plans to continue to improve its product’s security. As an example, this may include detailing how and when they plan to implement secure execution environments^{[footnote 77]}.	Product security needs to continue to evolve to keep pace with the threat environment.	-	Explore the vendor’s future security roadmap, discussing how the vendor’s product security will increase over time.	-

V.E: Secure updates and software signing	Security Expectation	Why it matters	Evaluation: Security Declaration	Evaluation: Customer or third‑party Spot‑checks	Evaluation: Customer or third‑party lab test
V.E: Overall aim	The source of the code that runs on the device is known, and the mechanisms to change the code on the device are secure.	Reduces the risk of supply chain attack between code production by the vendor, and delivery to the device.	‑	‑	‑
V.E.1: Software and firmware signing	Vendor’s software and firmware is digitally-signed.	Signing of software and firmware provides strong evidence that the developer produced the code.	The Security Declaration describes whether software and firmware are digitally signed, and any processes for allowing customers to deploy their own code.	-	Test that shipped executable code (binaries, scripts, etc) are digitally signed using the vendor’s public code signing certificate by automatically inspecting each file.
V.E.2: Signature verification	Software signatures are verified before binaries are executed.	Allows the device to check the source of the code.	The Security Declaration describes how signatures are checked prior to code execution. States whether that check is hardware-backed.	-	Test that a modification of a signed binary results in the device refusing to run the binary.
V.E.3: Secure update	Updates are delivered via a secure channel that is mutually authenticated between the device and the update server.	Using a secure channel reduces the risk of an attacker exploiting the update mechanism.	The Security Declaration describes the security properties of the update mechanism.	-	Perform the update process, verifying that updates are delivered over a secure channel.
V.E.4: Downgrade protection	Built-in detection capabilities alert whenever software is downgraded during an install process.	Publicly known vulnerabilities in an older version of the product are common causes of exploit and compromise.	The Security Declaration describes how downgrade attacks are prevented by the vendor.	-	Test that a signed update which is of an older version to that currently installed produces a log message or other alert likely be seen by the system administrator.

V.F: Hardware roots of trust and secure boot	Security Expectation	Why it matters	Evaluation: Security Declaration	Evaluation: Customer or third‑party Spot‑checks	Evaluation: Customer or third‑party lab test
V.F: Overall aim	The vendors use a secure hardware root of trust within their products. These are commonly referred to as one of the following: TEE (Trusted Execution Environment), TPM (Trusted Platform Module), or DSC (Dedicated Security Component).	A hardware root of trust enables the vendor to use modern security mitigations such secure boot and code signing.	The Security Declaration describes the vendor’s approach to the provision of hardware‑backed security.	‑	‑
V.F.1: Hardware root‑of‑trust	The equipment contains a hardware root-of-trust for identity and storage.	A hardware root-of-trust is necessary to provide hardware-backed functionality that cannot be remotely modified by an attacker.	The Security Declaration states the presence and properties of any hardware root of trust with the products.	-	Test that private keys associated with identity or device secrets are not stored in the filesystem in clear text.
V.F.2: Secure boot	Each product will support a secure boot process, initiated by the hardware root-of-trust (V.F.1) to bring the equipment into a known-good state on restart.	Secure boot makes it harder for any compromise of the device to persist after a power-cycle. Should devices be compromised, secure boot is required to restore trust in the equipment. Otherwise, the equipment may need to be scrapped.	The Security Declaration describes the vendor’s support of a secure boot, and how the vendor’s products can be returned to a known-good state in the event of compromise	-	Verify that the product can be returned to a ‘known-good’ state. Test that the device fails to boot should one or more of the signed binaries or scripts used during the boot process be modified.
V.F.3: Securing JTAG	Each compute element on a product will have debug interfaces (such as JTAG and UART) access disabled.	With physical access, debug interfaces like JTAG can be used to circumvent the integrity of a product or steal device secrets.	-	-	Test that JTAG equipment cannot establish communication with any of the system’s JTAG TAP controllers.

V.G: Security testing	Security Expectation	Why it matters	Evaluation: Security Declaration	Evaluation: Customer or third‑party Spot‑checks	Evaluation: Customer or third‑party lab test
V.G: Overall aim	The vendor rigorously tests the security of their products prior to release.	Through security testing and resolution, the number of vulnerabilities in the product is reduced, as is the risk of exploitation.	The Security Declaration describes the vendor’s approach to security testing across its product range.	‑	‑
V.G.1: Automated testing	Once developed, extensive security tests are automatically run against all versions of applicable products.	This ensures that testing is at a scale comparable to that employed by an attacker.	-	The Security Declaration describes the automated tests run against every product version.	For a customer-chosen product release, ask to see the test results from automated testing	The customer, or third-party, applies their own automated tests where possible.
V.G.2: Testing rigour	Developers cannot modify the build environment to hide or disregard build issues, or issues detected by automated tests. Failing builds are automatically rejected. Therefore, code used in released products do not create any compiler errors or security related warnings during build.	Developers may seek to bypass checks if permitted, leading to more vulnerable products.	The Security Declaration states whether tests can be bypassed.	For a customer-chosen product release, ask to see build results. Verify that the results do not highlight issues that should not be accepted in a released build.	-
V.G.3: Security testing	Security functionality is tested to demonstrate correct operation.	If security functionality is mis-implemented, the device will likely be vulnerable.	The Security Declaration states whether security testing is performed to verify correct operation.	For a customer-chosen product release, ask to see the results from security testing. Verify that issues were resolved, including root-causes.	Repeat tests of security functionality.
V.G.4: Negative testing	Extensive negative testing is performed against every product release, including a wide range of potential failure cases, inappropriate message sequencing and malformed messages.	By testing with extensive negative test cases, the vendor is more likely to catch easy-to-detect issues.	The Security Declaration states whether negative testing is performed and describes the scale of this testing.	For a customer-chosen product release, ask to see the test results from negative testing. Verify that issues were resolved, including root-causes.	Perform negative tests against the product, ideally using a distinct toolset to the vendor.
V.G.5: Fuzzing	Fuzzing is performed against the product, especially focusing on interfaces which cross security boundaries. The approach is sophisticated enough to ensure that a high proportion of code is tested.	A specific form of negative testing, the vendor tests their products against randomly-generated, malformed data, to catch easy-to-detect issues.	The Security Declaration states whether fuzz testing is performed and indicates the scope of this testing.	For customer-chosen product release, ask to see the test results from fuzzing, alongside data on code coverage. Verify that issues were resolved, including root-causes.	Perform fuzzing of the product, ideally using a distinct toolset to the vendor.
V.G.6: External testing	External security research teams perform testing against a selection of major product releases. Some of this testing is un-scoped.	By subjecting the device to an external third party, vulnerabilities are more likely to be detected and remediated.	The Security Declaration contains explicit details about how the vendor partners with external labs and academics to ensure the security of their products is independently tested.	Ask to see the results from external tests. Verify that issues were resolved, including root-causes.	-
V.G.7: Dynamic application security testing (DAST) ^{[footnote 78]}	The vendor has a DAST solution integrated into the vendor’s test process	Applying DAST during testing can identify different types of vulnerabilities to that of fuzzing and negative testing.	The Security Declaration states how the vendor performs dynamic application security testing.	Ask to see the results from the DAST suite. Verify that issues were resolved, including root-causes.	Perform dynamic application security testing on the product, ideally using a distinct toolset to the vendor.

V.H: Secure management and configuration	Security Expectation	Why it matters	Evaluation: Security Declaration	Evaluation: Customer or third‑party Spot‑checks	Evaluation: Customer or third‑party lab test
V.H: Overall aim	Any product can be easily setup to run securely.	Insecurely configured products are more likely to be exploited.	The Security Declaration describes the vendor’s approach to helping operators securely configure products. This includes whether products are released in a ‘secure’ configuration.	-	-
V.H.1: Product hardening	The product can be easily hardened into a secure configuration. Documentation exists to help customers perform this hardening process. Alerts are created should the device be taken out of the hardened state.	Insecurely configured products are more likely to be exploited.	The Security Declaration states whether products can be easily hardened into a secure configuration.	Verify that guidance is provided on secure configuration for provided products.	Test that the hardening guide can be easily deployed as-is to the product without impacting necessary functions. Test that alerts are created should the device be taken out of the hardened state.
V.H.2: Protocol standardisation	The product can be configured to only use standardised protocols.	Proprietary protocols do not allow for thorough, independent security testing, or correct behaviour to be understood by the customer.	-	-	Analyse traffic from the equipment to ensure that there are no proprietary protocols in use.
V.H.3: Management plane security	By default, the product is configured to only use up-to-date, secure protocols on the management plane.	Without secure protocols and user-based access it is not possible to securely manage equipment and associate administrative changes with a specific administrator.	The Security Declaration confirms whether the product only uses secure management protocols by-default.	-	Test that no weak or deprecated security protocols are enabled on the management plane.
V.H.4: Management access	Access to the management plane is user-based and supports asymmetric-key-based (e.g. X.509 certificates or SSH keys).	This allows customers to limit administrative privilege and investigate potentially malicious changes. The use of asymmetric key based authentication allows for more secure authentication and helps mitigate the risk of password sharing.	-	-	Test that the management plane gives administrators user-based access and supports asymmetric-key-based authentication.
V.H.5: No unencrypted protocols	Secure protocols are used whenever possible (e.g. SSH and HTTPS). If an unencrypted protocol is enabled, and a secure alternative exists, the product warns the administrator, and provides the option to create a security alert.	To prevent the use of insecure protocols, which increases the risk of exploitation.	-	-	Test that there are no unencrypted protocols and services are enabled by default on the product. Test that enabling an unencrypted protocol on the product results in appropriate warnings and alerts.
V.H.6: No un‑documented administrative mechanisms	The product does not have any undocumented administrator accounts. Examples include, but are not limited to, hard coded passwords, access key pairs (SSH keys) or other administrative access tokens.	Undocumented administrative accounts may be exploited without customer awareness.	The Security Declaration explicitly states whether there are any undocumented administrative accounts on the product.	-	Search for evidence of undocumented administrator accounts in released products.
V.H.7: No un‑documented administrative features	The product does not have any undocumented administration features.	Undocumented administrative features may be exploited without customer awareness.	The Security Declaration explicitly states whether there are any undocumented administrative features on the product.	-	Search for evidence of undocumented administrator features in released products.
V.H.8: No default credentials	No default passwords are left on the device after the initial setup. For clarity, this also means there are no administrative accounts coded into the vendor’s software.	Failure to disable any non-unique or hardcoded accounts renders the equipment highly vulnerable to exploitation.	The Security Declaration explicitly states how default credentials are removed from all devices, and whether hard-coded administrative accounts exist.	-	Test that there are no default credentials on the device after initial setup. Scan products for potential hardcoded password strings.
V.H.9: Good practice guidance	The vendor is explicit about the threats to the equipment that they have sought to mitigate, and those they have not. The vendor provides detailed configuration and notes on how the equipment can be protected in networks.	By helping understand the security decisions taken by the vendor, and setup the equipment securely, security mistakes are less likely to be made.	The Security Declaration describes the vendors approach to security analysis, and how they support customers in minimising risk.	For a customer-chosen product, explore the vendor’s product security analysis, and consider whether the vendor has understood the risk environment and established appropriate mitigations.	-

V.J: Vulnerability and Issue Management	Security Expectation	Why it matters	Evaluation: Security Declaration	Evaluation: Customer or third‑party Spot‑checks	Evaluation: Customer or third‑party lab test
V.J: Overall aim	Effective processes exist to manage security issues and vulnerabilities. These issues are quickly and effectively resolved.	Products are most vulnerable from when an issue is discovered until it is patched. Effective issue management reduces this risk.	The Security Declaration describes the vendors approach to resolving issues.	-	-
V.J.1: Issue tracking and remediation	The vendor has a process for issuing remediation. This ensures the vulnerability is resolved in all impacted products. Vulnerabilities are patched within appropriate timeframes.	If issues are not resolved across all versions of all product lines, the same issue may continue to be exploitable in some product version.	The Security Declaration provides the vendor’s timescales on the resolution of security issues and describes how the vendor traces vulnerabilities across all products.	Assuming a software component is vulnerable, ask to see all products that contain that component.	Test whether a previously reported and resolved vulnerability may still be exploited across a range of products.
V.J.2: Issue comprehension	For issues, the vendor identifies the root cause analysis of the issue and is able to detail the origin of the vulnerability.	Proper vulnerability management requires the vendor to understand its own product and quickly assess impact of a vulnerability.	-	For a customer-chosen vulnerability, the vendor can provide details of the vulnerability, the root cause of the vulnerability, and how and when the vulnerability was correctly resolved.	-
V.J.3: Vulnerability reporting	The vendor provides a publicly advertised route for disclosure of security issues that links into their vulnerability management process.	This allows external people and organisations to responsibly disclose security issues to the vendor.	The Security Declaration describes how vulnerabilities may be reported to the vendor.	Explore how the vendor resolved a previously reported issue.	-
V.J.4: Issue transparency	The vendor is transparent about their patching of security issues.	In the sector, most security issues are patched without customers becoming aware of their existence. This makes it difficult for customers to judge risk.	The Security Declaration provides metrics on security issues, both reported and resolved. A list of all patched security issues in the product is available.	-	-
V.J.5 Product Security Incident Response Team (PSIRT) ^{[footnote 79]}	The vendor has set up the PSIRT structures within its organisation.	Product security is not restricted to R&D. PSIRT brings together R&D, QM, TAC, OPS to be responsible for secure product operation by customers.	The Security Declaration describes how to contact vendor’s PSIRT team.	Ask the vendor for Product Security Incident Response plan of selected release.	When vulnerabilities are found during lab testing, report these to the PSIRT team and verify that the vendor’s response is effective.

V.K: Business Continuity and Disaster Recovery Planning	Security Expectation	Why it matters	Evaluation: Security Declaration	Evaluation: Customer or third‑party Spot‑checks	Evaluation: Customer or third‑party lab test
V.K: Overall aim	Effective plans and processes exist to maintain the supply chain if an incident occurs.	Products and services are susceptible to interruptions that could affect the operator if the vendors do not have adequate plans in place.	The Security Declaration describes the vendors plans and testing of BCP and DR.	-	-
V.K.1: Business continuity plans for production	The vendor has a funded plan in place to ensure they can still deliver on their contractual commitments if a production facility is disabled.	If the vendor is not able to move to a ‘backup’ production facility then new software, hardware or components to repair existing hardware may not be available.	The Security Declaration provides confirmation that a plan exists.	Assuming a plan exists review it to ensure it covers the products that the vendor is supplying and its time frames are suitable	-
V.K.2: Business continuity plans for key staff	The vendor has succession plans in place to replace key staff to ensure there are no single points of failure.	If staff with specific key skills are not available due to long term illness or leaving the business, it may be unable to discharge its contractual duties.	The Security Declaration confirms that the vendor has identified key staff and put in place succession planning.	Confirm that the vendor has identified key individuals and succession plans at least cover those key individuals that you as a customer are aware of.	-
V.K.3: Business continuity plans for staff	The vendor has a plan for relocating staff to backup facilities or replacing them if relocation is not possible or practicable.	There is no point in having a backup site if there are no staff to operate it.	The security declaration provides confirmation that a plan exists.	Confirm that the plan contains details of staff to relocate, how this will happen and where to.	-
V.K.4: Business continuity plans have been exercised	The vendor has a process for regularly exercising their BCP plans.	If plans are not exercised there is no guarantee that in time of need they will work. They should be fully ‘live’ tested at least once every 5 years or when a major process change occurs.	The Security Declaration provides details of the type (desk or live) and frequency of the exercises conducted by the vendor.	Assuming plans have been exercised review the outcomes and confirm that any lessons learned have been included into new plans.	-

Question 7

Annex C – Extracts from the Cyber Assessment Framework

Accepted Answer

Introduction

The information in this Annex is taken from the NCSC’s Cyber Assessment Framework Version 4.0, which was published on 6 August 2025. Any references in this Annex to ‘essential functions’ should be considered as ‘Security Critical Functions’ for the purpose of this Code of Practice.

CAF – Principles and contributing outcomes

Each top-level NCSC security and resilience principle defines a broad cyber security outcome. The precise approach organisations should adopt to achieve each principle is not specified as this will vary according to organisational circumstances. However, each principle can be broken down into a collection of lower-level contributing cyber security and resilience outcomes, all of which will normally need to be achieved to fully satisfy the top-level principle.

An assessment of the extent to which an organisation is meeting a particular principle is accomplished by assessing all the contributing outcomes for that principle. In order to inform assessments at the level of contributing outcomes:

each contributing outcome is associated with a set of Indicators of Good Practice (IGPs) and;
using the relevant IGPs, the circumstances under which the contributing outcome is judged ‘achieved’, ’not achieved’ or (in some cases) ‘partially achieved’ are described.

For each contributing outcome the relevant IGPs have conveniently been arranged into table format. The resulting tables, referred to as IGP tables, constitute the basic building blocks of the CAF. In this way, each principle is associated with several tables of IGPs, one table per contributing outcome.

Using IGPs

Assessment of contributing outcomes is primarily a matter of expert judgement and the IGPs do not remove the requirement for the informed use of cyber security expertise and sector knowledge. IGPs will usually provide good starting points for assessments but should be used flexibly and in conjunction with the NCSC guidance associated with the top-level cyber security and resilience principles. Conclusions about an organisation’s cyber security and resilience should only be drawn after considering additional relevant factors and special circumstances.

The ‘achieved’ (GREEN) column of an IGP table defines the typical characteristics of an organisation fully achieving that outcome. It is intended that all the indicators would normally be present to support an assessment of ‘achieved’. The exception would be when an IGP may not be applicable if there are compensating measures that would meet the requirements of the relevant objective.

When present, the ‘partially achieved’ (AMBER) column of an IGP table defines the typical characteristics of an organisation partially achieving that outcome. It is also important that the partial achievement is delivering specific worthwhile cyber security and resilience benefits. An assessment of ‘partially achieved’ should represent more than giving credit for doing something vaguely relevant.

The following table summarises the key points relating to the purpose and nature of IGPs:

Purpose and nature of IGPs	IGPs are…	IGPs are not…
Purpose	…intended to help inform expert judgement.	…a checklist to be used in an inflexible assessment process.
Scope	…important examples of what an assessor will normally need to consider, which may need to be supplemented in some cases.	… an exhaustive list covering everything an assessor needs to consider.
Applicability	…designed to be widely applicable across different organisations, but applicability needs to be established.	…guaranteed to apply verbatim to all organisations.

CAF – Objective A – Managing security risk

Appropriate organisational structures, policies, processes and procedures in place to understand, assess and systematically manage security risks to network and information systems supporting essential functions.

Principle A1 Governance

The organisation has appropriate management policies, processes and procedures in place to govern its approach to the security of network and information systems.

A1.a Board Direction

You have effective organisational security management led at board level and articulated clearly in corresponding policies.

Not Achieved

Achieved

At least one of the following statements is true

All the following statements are true

The security of network and information systems related to the operation of essential function(s) is not discussed or reported on regularly at board-level.

Board-level discussions on the security of network and information systems are based on partial or out-of-date information, without the benefit of expert guidance.

The security of network and information systems supporting your essential function(s) are not driven effectively by the direction set at board-level.

Senior management or other pockets of the organisation consider themselves exempt from some policies or expect special accommodations to be made.

Your organisation’s approach and policy relating to the security of network and information systems supporting the operation of your essential function(s) are owned and managed at board-level. These are communicated, in a meaningful way, to risk management decision-makers across the organisation.

Regular board-level discussions on the security of network and information systems supporting the operation of your essential function(s) take place, based on timely and accurate information and informed by expert guidance.

There is a board-level individual who has overall accountability for the security of network and information systems and drives regular discussion at board-level.

Direction set at board-level is translated into effective organisational practices that direct and control the security of network and information systems supporting your essential function(s).

The board has the information and understanding needed in order to effectively discuss how the security and resilience of network and information systems contributes to the delivery of essential function(s) and what the potential impact from compromise of those systems would be.

Security is recognised as an important enabler for the resilience of your essential function(s) and considered in all relevant discussions.

A1.b Roles and Responsibilities

Your organisation has established roles and responsibilities for the security of network and information systems at all levels, with clear and well‑understood channels for communicating and escalating risks.

Not Achieved

Achieved

At least one of the following statements is true

All the following statements are true

Key roles are missing, left vacant, or fulfilled on an ad-hoc or informal basis.

Staff are assigned security responsibilities but without adequate authority or resources to fulfil them.

Staff are unsure what their responsibilities are for the security of the essential function(s).

Key roles and responsibilities for the security of network and information systems supporting your essential function(s) have been identified. These are reviewed regularly to ensure they remain fit for purpose.

Appropriately capable and knowledgeable staff fill those roles and are given the time, authority, and resources to carry out their duties.

There is clarity on who in your organisation has overall accountability for the security of network and information systems supporting your essential function(s).

A1.c Decision‑making

You have senior‑level accountability for the security of network and information systems, and delegate decision‑making authority appropriately and effectively. Risks to network and information systems related to the operation of your essential function(s) are considered in the context of other organisational risks.

Not Achieved

Achieved

At least one of the following statements is true

All the following statements are true

What should be relatively straightforward risk decisions are constantly referred up the chain, or not made.

Risks are resolved informally (or ignored) at a local level when the use of a more formal risk reporting mechanism would be more appropriate.

Decision-makers are unsure of what senior management’s risk appetite is, or only understand it in vague terms such as ‘averse’ or ‘cautious’.

Decision-makers are unable to justify their risk management decisions.

Organisational structure causes risk decisions to be made in isolation. (e.g. engineering and IT do not talk to each other about risk).

Risk priorities are too vague to make meaningful distinctions between them. (e.g. almost all risks are rated ‘medium’ or ‘amber’).

Senior management have visibility of key risk decisions made throughout the organisation.

Risk management decision-makers understand their responsibilities for making effective and timely decisions in the context of the risk appetite regarding the essential function(s), as set by senior management.

Risk management decision-making is delegated and escalated where necessary, across the organisation, to people who have the skills, knowledge, tools and authority they need.

Risk management decisions are regularly reviewed to ensure their continued relevance and validity.

Principle A2 Risk Management

The organisation takes appropriate steps to identify, assess and understand security risks to network and information systems supporting the operation of essential functions. This includes an overall organisational approach to risk management.

A2.a Risk Management Process

Your organisation has effective internal processes for managing risks to the security and resilience of network and information systems related to the operation of your essential function(s) and communicating associated activities.

Not Achieved	Partially Achieved	Achieved
At least one of the following statements is true	All the following statements are true	All the following statements are true
Risk assessments are not based on a clearly defined set of threat assumptions. Risk assessment outputs are too complex or unwieldy to be consumed by decision-makers and are not effectively communicated in a clear and timely manner. Risk assessments for network and information systems supporting your essential function(s) are a ‘one-off’ activity or not done at all. The security elements of projects or programmes are solely dependent on the completion of a risk management assessment without any regard to the outcomes. There is no systematic process in place to ensure that identified security risks are managed effectively. Systems are assessed in isolation, without consideration of dependencies and interactions with other systems. (e.g. interactions between IT and OT environments). Security requirements and mitigations are arbitrary or are applied from a control catalogue without consideration of how they contribute to the security of network and information systems supporting your essential function(s). Risks remain unresolved on a register for prolonged periods of time awaiting senior decision making or resource allocation to resolve.	Your organisational process ensures that security risks to network and information systems relevant to essential function(s) are identified, analysed, prioritised, and managed. Your risk assessments are informed by an understanding of known and well understood threats and vulnerabilities in network and information systems supporting your essential function(s). The output from your risk management process is a clear set of security requirements that will address the risks in line with your organisational approach to security. Significant conclusions reached in the course of your risk management process are communicated to key security decision-makers and accountable individuals. You conduct risk assessments when significant events potentially affect the essential function(s), such as replacing a system, introducing new or emergent technologies or a change in the cyber security threat.	Your organisational process ensures that security risks to network and information systems relevant to essential function(s) are identified, analysed, prioritised, and managed. Your approach to risk is focused on the possibility of adverse impact to your essential function(s), leading to a detailed understanding of how such impact might arise as a consequence of possible threat actor actions and the security properties of network and information systems supporting your essential function(s). Your risk assessments are based on a clearly understood set of threat assumptions, informed by an up-to-date understanding of threats to network and information systems supporting your essential function(s), your sector and wider national infrastructure. Your risk assessments are informed by an understanding of the vulnerabilities in network and information systems supporting your essential function(s). The output from your risk management process is a clear set of traceable and prioritised security requirements that will address the risks in line with your organisational approach to security. Significant conclusions reached in the course of your risk management process are communicated to key security decision-makers and accountable individuals. Your risk assessments are dynamic and readily updated in the light of relevant changes which may include technical changes to network and information systems supporting your essential function(s), change of use, the introduction of new or emergent technologies or new threat information. The effectiveness of your risk management process is reviewed regularly, and improvements made as required. You anticipate technological developments that could be used to adversely impact network and information systems supporting your essential function(s).

A2.b Understanding Threat

You understand the capabilities, methods and techniques of threat actors and what network and information systems they may compromise to adversely impact your essential function(s).

This information is used to inform security and resilience risk management decisions, adjusting, enhancing or adding security measures to better defend against threats.

Not Achieved	Partially Achieved	Achieved
At least one of the following statements is true	All the following statements are true	All the following statements are true
You are unable to perform threat analysis. You do not understand the threats to network and information systems supporting your essential function(s). You do not have a clearly defined set of threat assumptions. You do not use your understanding of threat to inform your risk management decisions.	You perform threat analysis and understand how common threats apply to network and information systems supporting your essential function(s). You understand common types of cyber attacks, including the methods and techniques, and how these might apply to network and information systems supporting your essential function(s). This understanding is kept up to date. You anticipate what threat actors might target in network and information systems to cause an adverse impact to your essential function(s). Your understanding of threat is informed by common incidents. You apply your understanding of threat to inform your risk management decision-making.	You perform detailed threat analysis and understand how this applies to network and information systems supporting your essential function(s), in the context of your sector and wider national infrastructure. Your detailed understanding of threat includes the methods and techniques available to capable and well-resourced threat actors and how they could be used systematically against network and information systems supporting your essential function(s). You use appropriate techniques to develop an understanding of network and information systems supporting your essential function(s) from a threat actor’s perspective. You anticipate probable attack methods and techniques, targets and objectives, and develop plausible scenarios. You understand the different steps a capable and well-resourced threat actor would need to take to reach the probable target(s). You identify and justify what measures can be used at each step to reduce the likelihood of the threat actor reaching the probable target(s) or achieving their objective(s). You maintain a detailed understanding of current threats (e.g. by threat intelligence and proactive research). You apply your detailed understanding of threat to inform your risk management decision-making. You have documented the steps required to undertake detailed threat analysis.

A2.c Assurance

You have gained confidence in the effectiveness of the security of your technology, people, and processes relevant to the operation of network and information systems supporting your essential function(s).

Not Achieved

Achieved

At least one of the following statements is true

All the following statements are true

A particular product or service is seen as a ‘silver bullet’ and vendor claims are taken at face value.

Assurance methods are applied without appreciation of their strengths and limitations.

Assurance is assumed because there have been no known problems to date.

You validate that the security measures in place to protect network and information systems supporting your essential function(s) are effective and remain effective for the lifetime over which they are needed.

You understand the assurance methods available to you and choose appropriate methods to gain confidence in the security of network and information systems supporting your essential function(s).

Your confidence in the security as it relates to your technology, people, and processes can be justified to, and verified by, a third party.

Security deficiencies uncovered by assurance activities are assessed, prioritised and remedied when necessary in a timely and effective way.

The methods used for assurance are reviewed to ensure they are working as intended and remain the most appropriate method to use.

Principle: A3 Asset Management

Everything required to deliver, maintain or support network and information systems necessary for the operation of essential functions is determined and understood. This includes data, people and systems, as well as any supporting infrastructure (such as power or cooling).

A3.a Asset Management

Not Achieved

Achieved

At least one of the following statements is true

All the following statements are true

Inventories of assets relevant to network and information systems supporting your essential function(s) are incomplete, non-existent or inadequately detailed.

Only certain domains or types of asset are documented and understood. Dependencies between assets are not understood (such as the dependencies between IT and OT).

Information assets, which could include personally identifiable information and / or important / critical data, are stored for long periods of time with no clear business need or retention policy.

Knowledge critical to the management, operation, or recovery of network and information systems supporting your essential function(s) is held by one or two key individuals with no succession plan.

Asset inventories are neglected and out of date.

All assets relevant to the secure operation of network and information systems supporting your essential function(s) are identified and inventoried (at a suitable level of detail). The inventory is kept up-to-date.

Dependencies on supporting infrastructure (e.g. power, cooling etc) are recognised and recorded.

You have prioritised your assets according to their importance to the operation of network and information systems supporting your essential function(s).

You have assigned responsibility for managing all assets, including physical assets, relevant to the operation of network and information systems supporting your essential function(s).

Assets relevant to network and information systems supporting your essential function(s) are managed with cyber security in mind throughout their lifecycle, from creation through to eventual decommissioning or disposal.

CAF – Objective B – Protecting against cyber‑attack

Proportionate security measures are in place to protect network and information systems supporting essential functions from cyber attack.

Principle: B2.b Device Management

You fully know and have trust in the devices that are used to access your networks, information systems and data that support your essential function(s).

Not Achieved	Partially Achieved	Achieved
At least one of the following statements is true	All the following statements are true	All the following statements are true
Users can connect to network and information systems supporting your essential function(s) using devices that are not corporately owned and managed. Privileged users can perform privileged operations from devices that are not corporately owned and managed. You have not gained assurance in the security of any third-party devices or networks connected to your systems. Physically connecting a device to network and information systems gives that device access without device or user authentication.	Only corporately owned and managed devices can access your essential function(s) network and information systems. All privileged operations are performed from corporately owned and managed devices. These devices provide sufficient separation, using a risk-based approach, from the activities of standard users. You have sought to understand the security properties of third-party devices and networks before they can be connected to your systems. You have taken appropriate steps to mitigate any risks identified. The act of connecting to a network port or cable does not grant access to any systems. You are able to detect unknown devices being connected to network and information systems and investigate such incidents.	All privileged operations performed on network and information systems supporting your essential function(s) are conducted from highly trusted devices, such as Privileged Access Workstations, dedicated solely to those operations. You either obtain independent and professional assurance of the security of third-party devices or networks before they connect to network and information systems, or you only allow third-party devices or networks that are dedicated to supporting network and information systems to connect. You perform certificate-based device identity management and only allow known devices to access systems necessary for the operation of your essential function(s). You perform regular scans to detect unknown devices and investigate any findings.

Principle: B2.d Identity and Access Management (IdAM)

You closely manage and maintain identity and access control for users, devices and systems accessing network and information systems supporting your essential function(s).

Not Achieved	Partially Achieved	Achieved
At least one of the following statements is true:	All the following statements are true:	All the following statements are true:
Greater access rights are granted than necessary. Identity validation and requirement for access of a user, device or systems is not carried out. User access rights are not reviewed when users change roles. User access rights remain active when users leave your organisation. Access rights granted to devices or systems to access other devices and systems are not reviewed on a regular basis (at least annually).	You follow a robust procedure to verify each user and issue the minimum required access rights. You regularly review access rights and those no longer needed are revoked. User access rights are reviewed when users change roles via your joiners, leavers and movers process. All user, device and system access to the systems supporting the essential function(s) is logged and monitored, but it is not compared to other log data or access records.	You follow a robust procedure to verify each user and issue the minimum required access rights, and the application of the procedure is regularly audited. User access rights are reviewed both when people change roles via your joiners, leavers and movers process and at regular intervals - at least annually. All user, device and systems access to network and information systems supporting your essential function(s) is logged and monitored. You regularly review access logs and correlate this data with other access records and expected activity. Attempts by unauthorised users, devices or systems to connect to network and information systems supporting your essential function(s) are alerted, promptly assessed and investigated.

Principle: B3 Data Security

Data stored or transmitted electronically is protected from actions such as unauthorised access, modification, or deletion that may cause an adverse impact on essential functions. Such protection extends to the means by which authorised users, devices and systems access critical data necessary for the operation of essential functions. It also covers information that would assist a threat actor, such as design details of network and information systems.

B3.a Understanding Data

You have a good understanding of data important to the operation of network and information systems supporting your essential function(s), where it is stored, where it travels and how unavailability or unauthorised access, uncontrolled release, modification or deletion would adversely impact the essential function(s). This also applies to third parties storing or accessing data important to the operation of your essential function(s).

Not Achieved	Partially Achieved	Achieved
At least one of the following statements is true	All the following statements are true	All the following statements are true
You have incomplete knowledge of what data is used by and produced in the operation of network and information systems supporting your essential function(s). You have not identified the important data on which network and information systems supporting your essential function(s) relies. You have not identified who has access to data important to the operation of network and information systems supporting your essential function(s). You have not clearly articulated the impact of data compromise or lack of availability.	You have identified and catalogued all the data important to the operation of network and information systems supporting your essential function(s), or that would assist a threat actor. You have identified and catalogued who has access to the data important to the operation of network and information systems supporting your essential function(s). You regularly review location, transmission, quantity and quality of data important to the operation of network and information systems supporting your essential function(s). You have identified all mobile devices and media that hold data important to the operation of network and information systems supporting your essential function(s). You understand and document the impact on your essential function(s) of all relevant scenarios, including unauthorised data access, uncontrolled release, modification or deletion, or when authorised users are unable to appropriately access this data. You occasionally validate these documented impact statements.	You have identified and catalogued all the data important to the operation of network and information systems supporting your essential function(s), or that would assist a threat actor. You have identified and catalogued who has access to the data important to the operation of network and information systems supporting your essential function(s). You maintain a current understanding of the location, quantity and quality of data important to the operation of network and information systems supporting your essential function(s). You take steps to remove or minimise unnecessary copies or unneeded historic data. You have identified all mobile devices and media that may hold data important to the operation of network and information systems supporting your essential function(s). You maintain a current understanding of the data links used to transmit data that is important to network and information systems supporting your essential function(s). You understand the context, limitations and dependencies of your important data. You understand and document the impact on your essential function(s) of all relevant scenarios, including unauthorised data access, uncontrolled release, modification or deletion, or when authorised users are unable to appropriately access this data. You validate these documented impact statements regularly, at least annually.

B3.b Data in Transit

You have protected the transit of data important to the operation of network and information systems supporting your essential function(s). This includes the transfer of data to third parties.

Not Achieved	Partially Achieved	Achieved
At least one of the following statements is true	All the following statements are true	All the following statements are true
You do not know what all your data links are, or which carry data important to the operation of the essential function(s). Data important to the operation of the essential function(s) travels without technical protection over non-trusted or openly accessible carriers. Critical data paths that could fail, be jammed, be overloaded, etc. have no alternative path.	You have identified and protected (effectively and proportionately) all the data links that carry data important to the operation of your essential function(s). You apply appropriate physical and / or technical means (e.g. cryptography) to protect data that travels over non-trusted or openly accessible carriers, but you have limited or no confidence in the robustness of the protection applied.	You have identified and protected (effectively and proportionately) all the data links that carry data important to the operation of your essential function(s). You apply appropriate physical and / or technical means (e.g. cryptography) to protect data that travels over nontrusted or openly accessible carriers, with justified confidence in the robustness of the protection applied. Suitable alternative transmission paths are available where there is a significant risk of impact on the operation of the essential function(s) due to resource limitation (e.g. transmission equipment or function failure, or important data being blocked or jammed).

B3.c Stored Data

You have protected stored soft and hard copy data important to the operation of network and information systems supporting your essential function(s).

Not Achieved	Partially Achieved	Achieved
At least one of the following statements is true	All the following statements are true	All the following statements are true
You have no, or limited, knowledge of where data important to the operation of network and information systems supporting your essential function(s) is stored. You have not protected vulnerable stored data important to the operation of network and information systems supporting your essential function(s) in a suitable way. Backups are incomplete, untested, not adequately secured or could be inaccessible in a disaster recovery or business continuity situation.	All copies of data important to the operation of network and information systems supporting your essential function(s) are necessary. Where this important data is transferred to less secure systems, the data is provided with limited detail and / or as a read-only copy. You have applied suitable physical and / or technical means to protect this important stored data from unauthorised access, modification or deletion. If cryptographic protections are used you apply suitable technical and procedural means, but you have limited or no confidence in the robustness of the protection applied. You have suitable, secured backups of data to allow the operation of network and information systems supporting your essential function(s) to continue should the original data not be available. This may include off-line or segregated backups, or appropriate alternative forms such as paper copies.	All copies of data important to the operation of network and information systems supporting your essential function(s) are necessary. Where this important data is transferred to less secure systems, the data is provided with limited detail and / or as a read-only copy. You have applied suitable physical and / or technical means to protect this important stored data from unauthorised access, modification or deletion. If cryptographic protections are used you apply suitable technical and procedural means, and you have justified confidence in the robustness of the protection applied. You have suitable, secured backups of data to allow the operation of network and information systems supporting your essential function(s) to continue should the original data not be available. This may include off-line or segregated backups, or appropriate alternative forms such as paper copies. Necessary historic or archive data is suitably secured in storage.

Principle: B5 Resilient Networks and Systems

The organisation builds resilience against cyber attack and system failure into the design, implementation, operation and management of systems that support the operation of your essential function(s).

B5.a Resilience Preparation

You are prepared to restore the operation of your essential function(s) following adverse impact to network and information systems.

Not Achieved	Partially Achieved	Achieved
At least one of the following statements is true	All the following statements are true	All the following statements are true
You have limited understanding of all the elements that are required to restore operation of network and information systems supporting your essential function(s). You have not completed business continuity and disaster recovery plans for network and information systems, including their dependencies, supporting the operation of the essential function(s). You have not fully assessed the practical implementation of your business continuity and disaster recovery plans.	You know all network and information systems, and underlying technologies, that are necessary to restore the operation of your essential function(s) and understand their interdependence. You know the order in which systems need to be recovered to efficiently and effectively restore the operation of the essential function(s).	You have business continuity and disaster recovery plans that have been tested for practicality, effectiveness and completeness. Appropriate use is made of different test methods (e.g. manual fail-over, table-top exercises, or red-teaming). You use your security awareness and threat intelligence sources to identify new or heightened levels of risk, which result in immediate and potentially temporary security measures to enhance the security of network and information systems supporting your essential function(s), (e.g.in response to a widespread outbreak of very damaging malware).

B5.b Design for Resilience

You design network and information systems supporting your essential function(s) to be resilient to cyber security incidents. Systems are appropriately segregated and resource limitations are mitigated.

Not Achieved	Partially Achieved	Achieved
At least one of the following statements is true	All the following statements are true	All the following statements are true
Network and information systems supporting the operation of your essential function(s) are not appropriately segregated. Internet services, such as browsing and email, are accessible from network and information systems supporting your essential function(s). You do not understand or lack plans to mitigate all resource limitations that could adversely affect your essential function(s).	Network and information systems supporting the operation of your essential function(s) are logically separated from your business systems (e.g. they reside on the same network as the rest of the organisation, but within a DMZ). Internet services, such as browsing and email, are not accessible from network and information systems supporting your essential function(s). Resource limitations (e.g. network bandwidth, single network paths) have been identified but not fully mitigated.	Network and information systems supporting the operation of your essential function(s) are segregated from other business and external systems by appropriate technical and physical means (e.g. separate network and system infrastructure with independent user administration). Internet services, such as browsing and email, are not accessible from network and information systems supporting your essential function(s). You have identified and mitigated all resource limitations (e.g. bandwidth limitations and single network paths). You have identified and mitigated any geographical constraints or weaknesses. (e.g. systems that your essential function(s) depends upon are replicated in another location, important network connectivity has alternative physical paths and service providers). You review and update assessments of dependencies, resource and geographical limitations and mitigations when necessary.

B5.c Backups

You hold accessible and secured current backups of data and information needed to recover operation of your essential function(s) following an adverse impact to network and information systems.

Not Achieved	Partially Achieved	Achieved
At least one of the following statements is true	All the following statements are true	All the following statements are true
Backup coverage is incomplete and does not include all relevant data and information needed to restore the operation of your essential function(s). Backups are not frequent enough for the operation of your essential function(s) to be restored effectively. Your restoration process does not restore your essential function(s) in a suitable time frame.	You have appropriately secured backups (including data, configuration information, software, equipment, processes and knowledge). These backups will be accessible to recover from an extreme event including ransomware attack. You routinely test backups to ensure that the backup process function(s) correctly and the backups are usable.	Your comprehensive, automatic and tested technical and procedural backups are secured at centrally accessible or secondary sites to recover from an extreme event. Backups of all important data and information needed to recover the essential function(s) are made, tested, documented and routinely reviewed.

Principle: B6 Staff Awareness and Training

Staff have appropriate awareness, knowledge and skills to carry out their organisational roles effectively in relation to the security of network and information systems supporting the operation of your essential function(s).

B6.a Cyber Security Culture

You develop and maintain a positive cyber security culture and a shared sense of responsibility.

Not Achieved	Partially Achieved	Achieved
At least one of the following statements is true	All the following statements are true	All the following statements are true
People in your organisation do not understand what they contribute to the cyber security of network and information systems supporting your essential function(s). People in your organisation do not know how to raise a concern about cyber security. People believe that reporting issues may get them into trouble. Your organisation’s approach to cyber security is perceived by staff as hindering the business of the organisation and may encourage poor security behaviours. Formal or informal incentives and rewards conflict with the promotion of positive security outcomes.	Your executive management understand and widely communicate the importance of a positive cyber security culture. Positive attitudes, behaviours and expectations are described for your organisation. All people in your organisation understand the contribution they make to the cyber security of network and information systems supporting your essential function(s). All individuals in your organisation know who to contact and where to access more information about cyber security. They know how to raise a cyber security issue. You identify and address issues that inhibit people from behaving in a manner that supports your intended cyber security outcomes.	Your executive management clearly and effectively communicates the organisation’s cyber security priorities and objectives to all staff. Your organisation displays positive cyber security attitudes, behaviours and expectations. People in your organisation raising potential cyber security incidents and issues are treated positively. Individuals at all levels in your organisation routinely report concerns or issues about cyber security and are recognised for their contribution to keeping the organisation secure. Your management is seen to be committed to and actively involved in cyber security. Your organisation communicates openly about cyber security, with any concern being taken seriously. People across your organisation collaborate in cyber security activities and improvements, building joint ownership and bringing knowledge of their area of expertise.

B6.b Cyber Security Training

The people who support the operation of network and information systems supporting your essential function(s) are appropriately trained in cyber security.

Not Achieved	Partially Achieved	Achieved
At least one of the following statements is true	All the following statements are true	All the following statements are true
There are teams who operate and support your essential function(s) that lack any cyber security training. Cyber security training is restricted to specific roles in your organisation. Cyber security training records for your organisation are lacking or incomplete. Training is used as a ‘silver bullet’ for all user security behaviours. The success of training is only measured by the number of people reached, rather than assessing whether it has a positive impact on security behaviours. Training materials contain out of date or contradictory information, or information that conflicts with other policies, processes or procedures.	You have defined appropriate cyber security training and awareness activities for all roles in your organisation, from executives to the most junior roles. You use a range of teaching and communication techniques for cyber security training and awareness to reach the widest audience effectively. Cyber security information is easily available.	All people in your organisation, from the most senior to the most junior, follow appropriate cyber security training paths. Each individuals cyber security training is tracked and refreshed at suitable intervals. You routinely evaluate your cyber security training and awareness activities to ensure they reach the widest audience and are effective. You make cyber security information and good practice guidance easily accessible, widely available and you know it is referenced and used within your organisation.

CAF – Objective D – Minimising the impact of cyber security incidents

Capabilities exist to minimise the adverse impact of a cyber security incident on the operation of essential functions, including the restoration of those function(s) where necessary.

Principle D1 Response and Recovery Planning

There are well‑defined and tested incident management processes in place, that aim to ensure continuity of essential function(s) in the event of system or service failure. Mitigation activities designed to contain or limit the impact of compromise are also in place.

D1.a Response Plan

You have an up‑to‑date incident response plan that is grounded in a thorough risk assessment that takes account of network and information systems supporting the operation of your essential function(s) and covers a range of incident scenarios.

Not Achieved	Partially Achieved	Achieved
At least one of the following statements is true	All the following statements are true	All the following statements are true
Your incident response plan is not documented. Your incident response plan does not include your organisation’s identified essential function(s). Your incident response plan is not well understood by relevant staff.	Your incident response plan covers network and information systems supporting your essential function(s). Your incident response plan comprehensively covers scenarios that are focused on likely impacts of known and well-understood attacks only. Your incident response plan is understood by all staff who are involved with your organisation’s response function. Your incident response plan is documented and shared with all relevant stakeholders. Your incident response plan is readily accessible, even when your organisations IT systems have been adversely affected by an incident. Your incident response plan is regularly reviewed to ensure it remains effective.	Your incident response plan is based on a clear understanding of the security risks to network and information systems supporting your essential function(s). Your incident response plan is comprehensive (i.e. covers the complete lifecycle of an incident, roles and responsibilities, and reporting) and covers likely impacts of both known attack patterns and of possible attacks, previously unseen. Your incident response plan is documented and integrated with wider organisational business plans and supply chain response plans, as well as dependencies on supporting infrastructure (e.g. power, cooling etc). Your incident response plan is communicated and understood by the business areas involved with the operation of your essential function(s).

D1.b Response and Recovery Capability

You have the capability to enact your incident response plan, including effective limitation of impact on the operation of your essential function(s). During an incident, you have access to timely information on which to base your response decisions.

Not Achieved

Achieved

At least one of the following statements is true

All the following statements are true

Inadequate arrangements have been made to make the right resources available to implement your response plan.

Your response team members are not equipped to make good response decisions and put them into effect.

Inadequate back-up mechanisms exist to allow the continued operation of your essential function(s) during an incident.

You understand the resources that will likely be needed to carry out any required response activities, and arrangements are in place to make these resources available.

You understand the types of information that

will likely be needed to inform response decisions and arrangements are in place to make this information available.

Your response team members have the skills and knowledge required to decide on the response actions necessary to limit harm, and the authority to carry them out.

Key roles are duplicated, and operational delivery knowledge is shared with all individuals involved in the operations and recovery of the essential function(s).

Back-up mechanisms are available that can be readily activated to allow continued operation of your essential function(s), although possibly at a reduced level, if primary network and information systems fail or are unavailable.

Arrangements exist to augment your organisation’s incident response capabilities with external support if necessary (e.g. specialist cyber incident responders).

D1.c Testing and Exercising

Your organisation carries out exercises to test response plans, using past incidents that affected your (and other) organisation, and scenarios that draw on threat intelligence and your risk assessment.

Not Achieved

Achieved

At least one of the following statements is true

All the following statements are true

Exercises test only a discrete part of the process (e.g. that backups are working), but do not consider all areas.

Incident response exercises are not routinely carried out or are carried out in an ad‑hoc way.

Outputs from exercises are not fed into the organisation’s lessons learned process.

Exercises do not test all parts of the response cycle.

Exercise scenarios are based on incidents experienced by your and other organisations or are composed using experience or threat intelligence.

Exercise scenarios are documented, regularly reviewed, and validated.

Exercises are routinely run, with the findings documented and used to refine incident response plans and protective security, in line with the lessons learned.

Exercises test all parts of your response cycle relating to your essential function(s) (e.g. restoration of normal function(s) levels).

Principle D2 Lessons Learned

When an incident occurs, steps are taken to understand its causes and to ensure remediating action is taken to protect against future incidents.

D2.a Post Incident Analysis

When an incident occurs, your organisation takes steps to understand its causes, informing appropriate remediating action.

Not Achieved

Achieved

At least one of the following statements is true

All the following statements are true

You are not usually able to resolve incidents to a root cause or identify the contributing factors within a broader systems context.

You do not have a formal process for investigating causes.

Investigators form theories early in the process and only seek evidence that affirms their belief.

Investigations are solely focused on identifying the person(s) who can be held responsible for the incident.

Post incident analysis is conducted routinely as a key part of your lessons learned activities following an incident.

Your post incident analysis is comprehensive, considering organisational factors (e.g. policies, processes and procedures), technical factors (e.g. system design, vulnerabilities), human factors (e.g. training, security culture) and any changes to threat.

All relevant incident data is made available to the analysis team to perform post incident analysis.

Your analysis considers what could have happened under plausible, alternative circumstances (e.g. ‘what if’ / ’if only’ scenarios).

D2.b Using Incidents to Drive Improvements

Your organisation uses lessons learned from incidents to improve your security measures.

Not Achieved

Achieved

At least one of the following statements is true

All the following statements are true

Following incidents, lessons learned are not captured or are limited in scope.

Improvements arising from lessons learned following an incident are not implemented or not given sufficient organisational priority.

Changes are made as a ‘knee jerk’ reaction to an incident without proper analysis and testing to ensure the change is appropriate.

You wait until a severe or high-profile incident has occurred before you take steps to improve.

You have a documented incident review process / policy which ensures that lessons learned from each incident, including near misses, are identified, captured, and acted upon.

Lessons learned cover issues with reporting, roles, governance, skills and organisational policies, processes and procedures as well as technical aspects of network and information systems.

You use lessons learned to improve security measures, including updating and retesting response plans when necessary.

Security improvements identified as a result of lessons learned are prioritised, with the highest priority improvements completed promptly.

Analysis is fed to senior management and incorporated into risk management and continuous improvement.

Your organisation maximises the lessons learned by using the analysis into ‘what if’ / ’if only’ scenarios.

Your organisation learns from reported incidents in your sector and the wider national infrastructure.

Cookies on GOV.UK

Structure of the Code of Practice

Section 1: Introduction and background

Introduction

Technical analysis

Roles and responsibilities of public authorities

Scope of the Code of Practice

The tiering system

Application of the tiering system

Explanation of terms

Providers moving tiers

Legal status of the Code of Practice

Non‑compliance with the guidance measures in the Code of Practice

Non‑compliance with the new security duties in the Act and/or requirements in the regulations

Implementation timeframes

Implementation timeframes and the tiering system

Providers changing tiers or entering the market

Updating the Code of Practice

Further information

Section 2: Key concepts

Overarching key concepts

Scope of measures within the Code of Practice

Security Critical Functions

Network Oversight Functions

Scope

Guidance

The principle of ‘assumed compromise’

Management functions for Network Oversight Functions

Approach to monitoring and analysis

Example of how Network Oversight Functions work with Security Critical Functions

Chapter crossovers

2. Network architecture

Key concepts for understanding the requirements

The management plane

Scope

Background

Figure 1: Example of ‘browse up’ architecture

Guidance

Isolating the management plane

Figure 2: Example of ‘browse‑down’ architecture

Secure administration

Third party administrators

Read only access

Virtualisation and containerisation

Scope

Background

Figure 3: Example of containers

Guidance

Limiting the impact of host compromise

Figure 4: Virtualisation fabric broken into host ‘pools’

Figure 5: Segregating trust domains using host pools

Management of the virtualisation fabric

A secure virtualisation fabric

Choosing virtual functions

Authorising virtual functions

Separating virtual functions

Understanding the virtualised network

Network automation

The signalling plane

Scope

Guidance

Signalling protocols

Table 1: Signalling protocols

Protecting the network

Protecting users

Asset management

Guidance

The exposed edge

Guidance

Retaining national resilience

Guidance

Chapter crossovers

3. Protection of data and network functions

Key concepts for understanding the requirements

Workstations and privileged access

Guidance

SIM security

Universal Integrated Circuit Cards (UICCs)

eSIMs

Guidance