Guidance

Draft Revised Telecommunications Security Code of Practice: change log

Published 3 June 2026

All substantive changes to the Code of Practice are reflected in this document. In some instances, we have made more minor changes which have not been reflected here. These include: 

• the terms ‘telecoms providers’ and ‘providers’ have been replaced with ‘public telecoms providers’ throughout to ensure consistency across the document.
• corrections to minor formatting and grammatical errors

Section 1: Introduction and background

Original Code v1.0 Reference	Changed From/Removed	Revised Code v1.1 Reference	Changed To/Added
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. The Review concluded that a new, robust security framework was needed for the UK telecoms sector, marking a significant shift from the previous model.	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. 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.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.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 and personnel 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.
0.9	The NCSC will also continue to offer technical advice to telecoms providers. However, the NCSC will not report providers to Ofcom in cases of non-compliance or advise providers on whether the measures they are taking amount to regulatory compliance.	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.
0.26	It would not be appropriate, proportionate, or technically feasible, to expect 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.	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.
0.33	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 - The Telecommunications (Security) Act 2021 - The Electronic Communications (Security Measures) Regulations 2022.	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 - The Telecommunications (Security) Act 2021 - The Electronic Communications (Security Measures) Regulations 2022 - Ofcom’s Network and Service Resilience guidance - Product Security and Telecommunications Infrastructure Act 2022

Section 2: Key concepts

Original Code v1.0 Reference	Changed From/Removed	Revised Code v1.1 Reference	Changed To/Added
1.3	A ‘Security Critical Function’ in relation to a public electronic communications network or service 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).	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.5	When deciding which functions of the network or service could not be considered as security critical, providers should be able to demonstrate that individual functions do not have a material impact on the proper operation of the entire network or service, or a material part of it.	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.
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 network 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.	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.9	Best security practices should be implemented for network oversight functions. This includes rapid patching on release of a security update. 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.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.13	Under Regulation 6, 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, including real-time monitoring of changes to network oversight functions and monitoring for signs of exploitation.	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.
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 and interfaces that the attacker can target from a given logical 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 appropriately based on risk.	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.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.	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.
2.8	The scope will differ from provider to 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).	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 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, but to ensure that any deployments use the appropriate security controls.	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.
2.11	Attacks of this type tend not to be ‘noisy’, meaning that there may be no overt impact on the network, and they may be maintained for years, growing in scale and complexity over time.	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.
Figure 1	Example of ‘browse up’ architecture	Figure 1	Example of ‘browse up’ architecture [original deleted and replaced with updated version]
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 attacks. Phishing of privileged user accounts, whether targeted or otherwise, can initially 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).	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).
2.18	As public telecoms providers prepare to isolate their management planes from corporate functions, it may help providers to consider their network infrastructure as divided into security ‘zones’, as shown in Figure 2. This can help providers ensure that anything that can impact the operational network cannot be compromised from the corporate zone.	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	Figure 2	Example of ‘browse‑down’ architecture [original deleted and replaced with updated version]
2.19	To ensure the administrative zones are separated from corporate zones it will be necessary for separate enterprise services to be hosted within these zones. This will likely include, but is not limited to, authentication services, system update services and document stores.	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.
2.20	In some instances remote access may be necessary (see paragraphs 3.6-3.7). More information on privileged access workstations can also be found in paragraphs 3.3-3.13.
2.21	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 and time-limited, linking that administrative access to a specific purpose or ticket.	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.23	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).	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.24	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 communicate over the management plane.	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.26	Managed service providers (MSPs) or third party administrators (3PAs) are prize 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 ideally shall use the same methods.	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.27	This does not require MSPs and 3PAs to have separate devices for each public telecoms provider that they support. As is the case for the provider themselves, 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). Given a trusted device, 3PAs can access securely-segregated management systems for multiple providers, as shown in Figure 3. Critically, such an approach must maintain the security and integrity of the PAW, and segregation between each provider’s management environment.	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.
Figure 3	Third party administrator secure access to multiple providers		[figure deleted]
2.28	To ensure that security controls are applied correctly, it will be essential for public telecoms providers to have contractual arrangements in place which oblige third party administrators to undertake this activity. 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.	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.
2.29	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. There remains a risk to network data and, 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.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.30	Because of this, the recommended approach to support read-only administrative accesses to network equipment 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.	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.
2.31	Virtualisation refers to the creation of a virtual resource such as a server, desktop, operating system, file, storage or network. The use of this technology is growing significantly across the telecoms sector.	2.30	Virtualisation refers to the creation of a virtual resource such as a server, desktop, operating system, file, storage or network.
Figure 4	Example of bare metal hypervisors	Figure 3	Example of containers [original deleted and replaced with updated version]
Figure 5	Example of containers		[figure deleted]
2.41	Virtualisation security is an evolving subject, with new security solutions and design patterns emerging each year. The following guidance in paragraphs 2.42-2.69 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. Furthermore, additional advice on security design within virtualised environments can be found in the NCSC’s virtualisation security design principles.	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 and NCSC’s guidance on using containerisation.
2.57	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 like the hypervisor are up-to-date and there are no known vulnerabilities in the hypervisor that can be exploited.	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.68	Automation also allows for rapid prototyping and testing of new features, security patches and changes. This approach supports network resilience by limiting errors caused by human interaction and by allowing quicker remediation should issues occur. The approach supports network security by increasing the speed at which updates and changes can be made, allowing the provider to keep pace with the threat environment.	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.69	When automating, public telecoms providers should seek to use a secure, reproducible and comprehensible method of building and scaling a network. Orchestration and network management tools allow providers to define the network infrastructure as ‘code’, within which security requirements can be embedded. When automating the orchestration and configuration of virtual functions, it is essential that public telecoms providers use modern development tools and techniques. As a minimum, this includes code versioning, continual integration, and delivery pipelines to maintain the security, integrity, and quality of automated builds.	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 for securing machine learning, which equally apply to automation. The basis of these principles aligns with this Code of Practice.
		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.75	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 in paragraphs 2.76-2.82 highlights the key aspects of signalling plane security for telecommunications providers to understand and implement, providing examples and further background information where appropriate.	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.
		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.84	Due to its importance to network security, asset management should be automated whenever possible, and business processes 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.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.86	Asset management shall include the recording of any equipment in the provider’s network that is out of mainline support, 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.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.87	Asset registers and network maps are sensitive data that would be valuable to an attacker seeking to traverse the network. Public telecoms providers should ensure that they are enforcing appropriate protections for this data. Further guidance on asset management can be found on the NCSC website.	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 1].
		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.
		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.
		2.108	Public telecoms providers should reassess existing risks in response to changes in the threat or geopolitical landscape.
3.3	A workstation is a computer device or an appropriately segregated and protected part of a computer device. A network can only be as secure as the devices that are able to administer the network, and so implementing an effective lock-down of administrative devices is essential. Such trusted, high-integrity devices are often known as privileged access workstations (PAWs). The following guidance in paragraphs 3.4-3.13 highlights the key aspects of workstation security for public telecoms providers to understand when implementing solutions, providing examples and background information where appropriate.	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.
3.4	When implementing a PAW-based lockdown, public telecoms providers should include consideration of the following areas: - use of a ‘clean’ known-good operating system image to build PAWs from, rather than an OEM-provided image or other modified source; - approved application list – use of AppLocker or other OS-appropriate mechanisms to ensure that only authorised applications are permitted to run, minimising the potential for malicious code execution; - encryption – use of data at rest encryption to maintain security of data in case of theft or loss. This should incorporate use of a hardware-backed element such as a TPM, and in the case of full-disk encryption this should be unlocked with a PIN or passphrase prior to boot; - regular updates – security updates should be applied to both PAWs and management plane infrastructure within such a period as is proportionate with the risk of the threat the update addresses (see Table 2) to ensure vulnerabilities are patched in a timely manner; - approved removable media list – removable media use should be blocked by default, and only used by exception. Regular data transfer should be performed via another method; - use of ‘regular’ user accounts – network administrators should use non-privileged accounts on their local PAW device for performing administrative activity within the network. This minimises the ability for malicious code to run and to compromise the entirety of the workstation, or for settings critical to security to be altered intentionally or otherwise; and - feed into monitoring – all PAW-like devices should be incorporated into available security monitoring systems for the detection of malicious or unusual activity.	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 at NCSC’s device security guidance pages or secure system administration guidance and for Windows devices at Microsoft’s PAW guidance.	3.5	Further information on the topic of device lockdown can be found online in the NCSC’s Principles for secure PAWs and on the NCSC’s device security guidance and secure system administration guidance pages, as well as the ETSI standards[footnote 2].
3.6	Sometimes it may be necessary to use PAWs remotely, rather than directly connected to the administrative zone. To protect the integrity of these devices, a standard solution would be to use an ‘always on’ virtual private network (VPN) to provide access to the administrative zone, without leaving the PAW vulnerable to internet-based attacks. Generic guidance and good practice around setting up VPNs and other methods for remote access can be found on the NCSC’s website.[footnote 3]
3.7	A remote PAW solution will likely be highly attractive to attackers as a potential route to the provider’s management plane. For this reason, public telecoms providers should consider implementing additional security controls to prevent and detect potential compromises. For example, when supporting remote PAWs, public telecoms providers should monitor the time and location from which the PAW is accessing the network, alongside broader device health information. Remote PAWs could also implement additional logging and be patched within a minimal timeframe.
3.8	Some administrative users may require access to corporate resources and services while simultaneously performing administrative activity. Assuming that this requirement cannot be fulfilled using a separate corporate device to the PAW, administrative users will require some form of cross-domain solution. The key requirement is to ensure that by granting access to these services, the security of the PAW is not compromised.
3.9	There are a range of solutions to providing access to corporate services to PAWs. One common solution is via the implementation of a virtualised environment existing within the corporate security zone (see Figure 2). PAWs connect into a virtual machine to access corporate services, rather than accessing these services themselves.
3.10	Virtualised environments can be implemented on the PAW device itself, but this can add significant complexity. An alternative is to host a set of virtualised desktops within the corporate zone that can be accessed by PAWs over a remote access protocol such as the remote desktop protocol (RDP).
3.11	Administrative users may also need to transfer data between the administrative zone and the corporate zone. Public telecoms providers should not use unmanaged removable media for this task. Instead, public telecoms providers could consider using a push-pull mechanism to transfer data, as shown in Figure 8.
Figure 8	Example of cross‑domain data transfer		[Figure 8 deleted]
3.12	In this example, services are set up in each security zone with the responsibility of transferring data between them using automated scripts. However, user interaction (and associated authentication) will be required to both ‘push’ files into the sending device, and ‘pull’ it out at the opposite end. This method ensures that the transfer is a deliberate action of a user, and allows transfers to be filtered, verified and monitored.
3.19	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.	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 three 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.21	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. eSIM technology is in an early phase of market adoption, therefore, as it is adopted, any resilience risks to networks will need to be managed.	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.
3.22	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 providers globally have used the routine changing of SIM cards, form factor changes, or introduction of new services, to churn out 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.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.24	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 is sufficiently trustworthy to handle the SIM credentials given the risk.	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.26	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. 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.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.21	Public telecoms providers shall check the SIM providers’ certificates against the GSMA SAS accredited website and satisfy themselves that the supporting sites and external parties are sufficiently trustworthy. For the avoidance of doubt, this applies to all types of SIM.
		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.29	Public telecoms providers must ensure 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.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.30	Where data is encrypted either at rest or in transit, it should be encrypted in line with current industry best practice. For data in transit, public telecoms providers should consider the use of IPSec or TLS – detailed information and best practice guidance provided by NCSC can be found on its website. For data-at-rest providers should consider using AES used in GCM mode using keys at least 128-bits in length. NIST guidance for data at rest can be found on the NIST website.	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 4]. 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.
		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 and NPSA websites, covering, for example, mobile devices, secure disposal and physical and technical security measures.
3.32	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 network 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 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.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.33	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.	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.
3.36	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 (for example, in 2016, the Mirai botnet was used to attack the DNS provider Dyn, as well as later targeting UK banks); - compromise of devices owned by the customer, infringing on their privacy or product availability; and - the CPE to be used to carry out cybercrime, allowing criminals to proxy their activities.	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.
		3.39	In any case, public telecoms providers shall monitor for anomalous behaviour and protect their networks from potential harm caused by CPEs.
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 any location listed in the Schedule to the regulations.	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.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); - 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; and - access to real-time network orchestration systems or controllers.	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); - 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.
		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.7	It is just as important to log unsuccessful events as it is successful events. General guidance on what to log can be found on the NCSC website.	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.
5.12	In determining where to monitor, public telecoms providers should give consideration to the following security boundaries: - between the provider’s network and external networks such as customer networks, partner networks, the internet and international telecommunications networks; - between the provider’s network and third party administrator networks, such as those owned by network equipment suppliers and MSPs; - between the provider’s security critical functions and functions in the access network or exposed edge; and - between management networks and other networks, including internal networks.	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.
5.15	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. Similarly, 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. Further guidance on host-based logging can be found on the NCSC website.	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.
5.16	Monitoring data provides information about network behaviour and can contain sensitive data such as administrative passwords. As such, public telecoms providers need to ensure that monitoring data is protected. Should there be any customer data recorded within any monitoring data, this data should be appropriately sanitised.	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.
5.22	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, providers should have access to sufficient skilled analysts to support multiple investigations of anomalous behaviour at any one time.	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	Public telecoms providers are recommended to use a monitoring service/tool (e.g. NCSC’s BGP Spotlight) to detect potential hijacks and to respond appropriately when hijacks are detected. It is recommended that 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.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.27	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 3.	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.32	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. Tools such as BGP Spotlight are specifically designed for this purpose by NCSC, but other commercial and non-commercial tools are available.	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.34	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 service providers to ensure that they have in place a plan of maintaining UK internal traffic during this time. Route aggregation may help in speeding 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.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.40	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.	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.
5.42	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.	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.
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 the data required to effectively investigate incidents relating to their network or service, including accessing any relevant data that may be owned by the supplier.	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.8	When working with external suppliers, public telecoms providers need to effectively manage the risk to any data 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.	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.
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 authorise the transfer, validate that the data has arrived, and ensure that it is deleted irretrievably when 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.	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.
6.12	Administrative access presents a significant security risk to electronic communications networks. Providers grant administrative access to third party administrators for a variety of reasons. Administrative services provided by an external company within a broader umbrella business or provider group should be considered as third party administrators. Third party administrators may also be MSPs as part of a managed service contract, or equipment supplier as part of a third-line support function.	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.19	Public telecoms providers should ensure that a compromise of the third party administrator cannot compromise or disrupt multiple providers. Administrative workstations within third party administrators should only be able to access a single provider’s network. Such workstations may be virtualised, allowing a single device to support multiple operators.	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.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:
		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.
		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.
		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.
6.22	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 both hardware and software.	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.34	During procurement processes for security critical functions, public telecoms providers shall ensure that security considerations are a significant factor in determining the procurement outcome. 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.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.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.
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.	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.
		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.
		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.
		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.
		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.
		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.6	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. Without a trusted identity, ransomware should not be able to request access to a provider’s cloud storage and encrypt it without the 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.	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. 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.
		8.8	Additional guidance with regards to backups can be found on the NCSC website.
8.7	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 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.	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.
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. Without effective governance, it is likely that security improvements will not be sustained or consistent. Any technical controls deployed outside of an effective security governance framework will be fundamentally undermined.	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.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. Public telecoms providers should refer to NCSC advice on security governance and security policies.	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 5]
		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.
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. 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.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.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.
11.6	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 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), as in Regulation 12(c).	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.
12.4	Where a public telecoms provider is using a third party supplier, in-house staff of that provider 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 third party administrators or third party suppliers, as those third parties may not always be available to address security issues.	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.
		13.3	Alongside the usual testing as part of any service or product, public telecoms providers should also perform security functionality 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
		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.
		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.
		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.
13.3	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. For this reason it is essential that the testing simulates, so far as possible, real world attacks.	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.
13.5	An example of this type of testing is Ofcom’s TBEST scheme.	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.
		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.
		13.13	Public telecoms providers should satisfy themselves that any testing carried out includes negative 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.
		13.15	Where it is not possible to remediate or mitigate findings then a risk assessment should be performed and documented.
		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.
		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.
13.7	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 Centre for the Protection of National Infrastructure (CPNI) should be consulted for physical and personnel-related security.	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.

Section 3: Technical guidance measures

Original Code v1.0 Reference	Changed From/Removed	Revised Code v1.1 Reference	Changed To/Added
	Specific technical measures to be taken by providers are set out below, grouped by the date by which they are expected to be completed. Each individual guidance measure is also 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 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.		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.
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.	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.
M3.06	Trust shall not be assumed based on the source of any incoming message. 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.	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.
M3.08	Where providers allow others to use number ranges that have been allocated to them (e.g. GTs, IMSIs), they remain responsible for the activity related to that number range, and any further security implications. This does not apply in the case of MSISDNs shared through MNP.	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.
M3.09	Any outgoing message that uses a source address that should not transit or leave the provider’s network shall not be permitted to leave the provider’s network.	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.
M4.02	During procurement of equipment, prior to contract award, it is recommended that 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).	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.
M4.05	The provider shall record all risk management processes undertaken. Guidance on risk management processes can be found on the NCSC website.	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.
M5.01	The provider shall implement appropriate business processes. In order to achieve this, providers shall have regard to implementing the parts of the CAF that define the provider’s business processes. These are contained within Annex C. These are: A1-Governance; A2-Risk Management; A3-Asset Management; B5-Resilient Networks and Systems; B6-Staff Awareness and Training; D1-Response and Recovery Planning; D2-Lessons Learned.	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.
M8.15	For profile-modifiable SIM cards the provider shall, within the first year of use, update with a new profile (including K/Ki, and OTA keys) that has not been provided externally, including to the SIM card vendor. Providers should aim to ensure that all new UICCs can be updated with new K/Ki and OTA keys after receipt from the SIM card vendor.	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.
M9.01	Once the CPE has been configured at the customer site, it shall only contain credentials that are both unique to that CPE, and not guessable from CPE metadata.	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.
M9.03	WAN CPE management interfaces shall only be accessible from specified management locations (e.g. URL or IP address).	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.
M9.04	Management of the CPE shall use a secure protocol (e.g. TLS 1.2 or newer).	M9.04	Management of the CPE shall use a non-deprecated secure protocol (e.g. TLS 1.2 or newer).
M10.08	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.	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.
M10.15	Where third party suppliers do not resolve security failings within a reasonable timeframe, the provider shall have a break clause with the third party supplier to allow exit from the contract without penalty.	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.
M10.22	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 provider.	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.
M10.45	Providers shall record where third party suppliers fail to meet these security obligations.	M10.45	Public telecoms providers shall record where third party suppliers fail to meet their security obligations.
M11.21	Testing procedures shall be established and utilised to verify that management networks enforce these controls.	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).
M11.24	A PAW shall only have access to the internet to the extent it is needed to carry out changes to security critical functions, and such access shall be secured (e.g. via VPN).	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.
M11.25	The PAW shall only have access to internal‑only business systems (e.g. not corporate email).	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.
M11.26	A PAW shall support secure boot, boot-attestation, data-at-rest encryption backed by a hardware root of trust.	M11.26	A PAW device shall use secure boot, boot attestation and full disk encryption backed by a hardware root of trust.
M11.29	A PAW shall prevent the execution of unauthorised code such as binaries or macros within documents.	M11.29	A PAW shall prevent the execution of any unauthorised applications or code including linked libraries or macros within documents.
M11.30	A PAW shall use data-at-rest encryption.	M11.30	Void NOTE: measure omitted as it is a subset of M11.26
M11.31	Health attestation of the PAW shall be used wherever possible, and particularly where the PAW is located outside the UK.	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.
		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.
		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.
		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.
		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.
		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.
		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.
		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.
M14.01	Once equipment reaches the vendor’s end-of-life date, 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; and c) the network exposure (attack surface) of the unsupported equipment is minimal (e.g. some transport equipment).	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.
		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.
M15.07	The management functions (e.g. jump box) used to manage network oversight functions shall only be accessible from designated PAWs.	M15.07	The management functions (e.g. jump box) used to manage Network Oversight Functions shall only be accessible from a PAW.
M15.12	The designated PAWs, dedicated management functions and the network oversight functions themselves shall be monitored for signs of exploitation.	M15.12	PAWs, dedicated management functions and the Network Oversight Functions themselves shall be monitored for signs of exploitation.
M16.07	Systems that collect and process logging and monitoring data shall be treated as network oversight functions.	M16.07	Systems that collect and/or process logging and monitoring data shall be treated as Network Oversight Functions.
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 of critical core nodes are not shared or exposed externally.	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.
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).	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.
		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.
		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.
		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.
		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.
		M23.01 SIMs	Public telecoms providers shall check the SIM providers’ certificates against the GSMA SAS accredited website and satisfy themselves that the supporting sites and external parties are sufficiently trustworthy.
		M23.02 Security testing	Public telecoms providers shall implement an automated scanning process to identify vulnerabilities, missing patches or configuration changes.
		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.
		M24.01 Logging and monitoring	Regular tests should be conducted to ensure that the logging is functioning as expected.
		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.
		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.
		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.
		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.
		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).
		M24.07 Service accounts	A privileged access solution that securely stores and rotates credentials frequently should be used to manage service accounts.
		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.
		M24.09 Overarching security measures	Public telecoms providers shall disable any unused ports, protocols and services.

Annex A: Glossary

Original Code v1.0 Reference	Changed From/Removed	Revised Code v1.1 Reference	Changed To/Added
		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.
		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	Corporate systems that are indirectly involved in the running of the telecoms network and/or the service provision.
Container	The environment created by the Type 2 (Hosted) hypervisor in which a Virtual Machine runs.	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 term for the use of a Type 2 hypervisor (or Hosted Hypervisor) environment. This type of hypervisor runs inside the operating system of a physical host machine.	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.
Customer Premises Equipment (CPE)	Customer Premises Equipment refers to equipment provided to customers by the provider, and managed by the 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.	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.
		E164, E212, E214	Internationally recognised standards for number formats.
		Hardening	The process of securing a system by reducing its attack surface.
Insecure Protocols	An insecure protocol should be considered to be any protocol where a more secure or encrypted variant of that protocol exists. Some examples are to use HTTPS rather than HTTP, SSH rather than Telnet, TaACACS+ rather than TACACS. This is not an exhaustive list and is constantly evolving.	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.
		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 6]
		Know Your Customer (KYC)	A process that verifies a customer’s identity and financial profile.
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’.	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.
		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.
		Network equipment	Includes hardware, software and firmware that is used to provide the network or service.
		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.
Privileged Access Workstation (PAW)	An appropriately secured device that is able to make changes to security critical functions via a management plane.	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.
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 a SIM that is able to support encryption key changes.	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.
Secure Channel	A communications flow which is encrypted using industry best practice such as TLS 1.2, SSHv2, or IPsec with industry best practice cipher suites. This is not an exhaustive list and is constantly evolving.	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 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.
		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.
		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.
		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)	Managed Service Providers, provider group functions, or external support for third-party supplier equipment (e.g. third-line support function).	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.
		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.
		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.
UICC	Any physical card SIM-like credential allowing network access, including permanently soldered-in UICCs in some handsets and IoT devices. An eSIM does not require a UICC.	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.
		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.
		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.

Annex B: Vendor Security Assessment

New section added to Vendor Security Assessment annex - ‘V.K – Business Continuity and Disaster Recovery (BCDR) planning’.

Annex C: Cyber Assessment Framework

Sections included from NCSC’s Cyber Assessment Framework updated to reflect Version 4.0, published on 6 August 2025.

New sections added including: A2.b Understanding Threat; B2.b Device Management; B2.d Identity and Access Management; B3.a Data Security; B3.b Data in Transit; and B3.c Stored Data.

1. NCSC CAF guidance A:3 Asset management (NCSC, 2025) and Asset management (NCSC, 2021) ↩

2. Cyber Security (CYBER); Privileged Access Workstations; Part 1: Physical Device and Cyber Security (CYBER); Privileged Access Workstations; Part 2: Connectivity and TS 103 994-3 - V1.1.1 - Cyber Security (CYBER); Privileged Access Workstations; Part 3: System Integration ↩

3. Device security guidance: Virtual Private Networks (VPNs) (NCSC, 2021), and Device security guidance: network architectures (NCSC, 2020) ↩

4. Using IPsec to protect data (NCSC, 2016) Xand Using TLS to protect data (NCSC, 2021) ↩

5. NCSC CAF guidance: A.1 Governance (NCSC, 2025) and NCSC CAF guidance: B.1 Service protection policies, processes and procedures (NCSC, 2025) ↩

6. IR.21, GSM Association Roaming Database, Structure and Updating, version 18, 24 October 2025, © GSM Association   ↩