Security Measures Code of Practice

2

REPORT

This report provides notice of the intention to issue a Code of Practice under Article 24O of the Telecommunications (Jersey) Law 2002. This Article will become effective on 1 June 2026 following the making of the Telecommunications Law Amendment (Jersey) Commencement No.2 Order 2026 on 19 March 2026 via MD-SED-2026-259.

Once  the  Telecommunications  Law  (Jersey)  Amendment  Regulations  2024  (the Amendment Regulations) are commenced, Article 24O of the Telecommunications (Jersey) Law 2002 , will provide the Minister for Sustainable Economic Development (the  Minister)  with  the  power  to  issue  codes  of  practice  giving  Jersey's telecommunications (telecoms) providers guidance about the duties imposed about telecoms security.

Before  issuing  guidance  in  the  form  of  a  code  of  practice,  Article  24O  of  the Amendment Regulations requires that the Minister first:

• publish a draft of the code of practice;

• consult with the Jersey Competition Regulatory Authority, telecoms providers and other stakeholders; and then

• lay a copy of the code of practice before the States Assembly.

Government published a draft of its code of practice in July 2025 and began a process of consultation. That process of consultation formally ended 3 October 2025. A further consultation began in December 2025 and ended in January 2026. Government has now considered responses provided.

This report provides for the Minister to lay a copy of the code of practice before States Assembly  to  take  effect  on  commencement  of  Article  24O  of  the  Amendment Regulations.

R.68/2026

Telecommunications Security Code of Practice

June 2026  1

Contents

Structure of the Code of Practice  5 Section 1: Introduction and background  6 Introduction  6 Legal status of this Code of Practice  11 Implementation timeframes  12 Updating this Code of Practice  13 Section 2: Key concepts  14

1. Overarching key concepts  14
2. Network Architecture  19
3. Protection of data and network functions  40
4. Protection of certain tools enabling monitoring or analysis  46
5. Monitoring and analysis  48
6. Supply Chain  56
7. Prevention of unauthorised access or interference  64
8. Preparing for remediation and recovery  67
9. Governance  70
10. Reviews  73
11. Patching and updates  75
12. Competency  78
13. Testing  80
14. Assistance  82

Section 3: Technical guidance measures  84 Overarching security measures  84 Management plane 1  85 Signalling plane 1  86 Third party supplier measures 1  88 Supporting business processes  89 Management plane 2  92 Signalling plane 2  92 Third party supplier measures 2  93 Customer Premises Equipment  96 Third party supplier measures 3  97 Management plane 3  106 Signalling plane 3  110 Virtualisation 1  111

Third party supplier measures 4  115 Network Oversight Functions  115 Monitoring and analysis 1  117 Management plane 4  121 Signalling plane 4  121 Virtualisation 2  122 Monitoring and analysis 2  123 Retaining national resilience and capability  123 Annex - Glossary of terms  125

Structure of the Code of Practice

This Code of Practice contains three sections:

Section 1 contains introductory and background information on this Code of Practice, including its legal status within Jersey's telecoms security framework, how it applies to Public Telecoms Providers, and its oversight in Jersey.

Section 2 explains the key concepts that need to be understood by Public Telecoms Providers when applying the specific security measures contained within the Telecommunications (Security Measures) (Jersey) Order 2026 (hereafter referred to as the Order') and by those Public Telecoms Providers specified in the Order when applying the technical guidance measures within Section 3 of the Code of Practice.  

Section 3 contains the technical guidance measures and maps each individual guidance measure to the relevant security measures in the Order. It also sets out the implementation timeframes for the technical guidance measures, which those Public Telecoms Providers specified in the Order are expected to follow.  

Section 1: Introduction and background

Introduction

1. Government of Jersey's Digital Economy Strategy vision is "to unleash a thriving, innovative and inclusive digital future powered by world-class infrastructure and enabling legislation, that delivers sustainable growth for our Island economy."[1]
2. The strength of Jersey's economy, and reputation as an international financial services centre and a centre of innovation, are based not only on its laws and high standards but also on the secure and resilient digital connectivity provided by Jersey's telecommunications (telecoms) networks and services.
3. That digital connectivity underpins Jersey's vision of a consistently high-performing, environmentally sustainable and technologically advanced small Island economy. Providing reliable, secure access to the world while sitting at the heart of our Island community, digital connectivity is a key driver of sustainable economic growth and productivity. Economic growth and productivity are especially important to meet future challenges, around an ageing population. Digital connectivity will be at the heart of this growth and other wider service solutions.
4. Maintaining the security and resilience of Jersey telecoms networks and services in a rapidly changing world with ever more complex threats and risks is challenging and of crucial importance to Jersey, its businesses and all Islanders.
5. In recognising the scale and nature of those challenges, States Assembly agreed in September 2024, to amend the existing the Telecommunications (Jersey) Law 2002 in the interests of the security of Jersey and to closely align Jersey's approach to telecoms security with that of the UK.  
6. Jersey's relationship with the UK is deep and long-standing. Jersey's closet cultural, economic and diplomatic relationships are with the UK and Jersey looks to the UK Government for its defence and international representation. Jersey's Public Telecoms Providers use UK+44 phone numbers and work closely with UK Public Telecoms Providers and UK Government agencies to maintain the security of our networks and services.
7. Jersey has developed a telecoms security framework for Jersey's providers of public electronic communications networks and services (PECN / PECS)[2] that has much in common with the UK's framework introduced by the UK's Telecommunications (Security) Act 2021 (the Act).
8. Jersey remains an independent jurisdiction. The Act does not apply to Jersey, nor do the UK's Electronic Communications (Security Measures) Regulations 2022, or the UK's Telecommunications Security Code of Practice issued in December 2022.

Ofcom has no telecoms security functions or duties for Jersey. Jersey's telecoms security framework including the Order and this, Jersey's Code of Practice, are underpinned by Jersey legislation, the Telecommunications (Jersey) Law 2002, as amended (the Law).  

9. Jersey's framework comprises three layers:

1. Security duties on all Public Telecoms Providers. These are set out in new Part 5A of the Law and apply irrespective of the application of the Order.
2. Specific security measures (hereafter referred to as requirements'). These are set out in the Order and detail the specified measures to be taken in addition to the overarching duties in the Law.
3. Technical guidance. This Code of Practice provides detailed guidelines to specified providers of PECN and PECS (hereafter referred to as Public Telecoms Providers') on the Government's preferred approach to demonstrating compliance with the duties in the Law and the requirements within the Order.

10. Meeting the duties and requirements of Jersey's framework will require Public Telecoms Providers to develop and maintain a positive cyber security culture. Leadership, active engagement and participation at all levels is required to achieve the desired outcome – a continuously improving security culture. Creating the right cultural conditions for security is important. Public Telecoms Providers should have regard to NCSCs guidance about how to create the cultural conditions in an organisation that support and encourage the desired cyber security behaviours.[3]
11. Public Telecoms Providers' Boards and executive teams must be engaged in the management of risks. Cyber security is a critical risk for boards and executive teams. A culture of cyber security starts with the Board. The need for Public Telecoms Providers to take a risk-based approach to securing data and systems should be led by the Board and executive teams.
12. The NCSC has published guidance about how Boards can deliver, communicate and champion strong cyber leadership including a Cyber Security Toolkit for Boards and Cyber Governance for Boards.

Technical Analysis

13. The technical content of this, Jersey's Code of Practice, is based on the UK's Code of Practice[4] published in December 2022 and is therefore informed by guidance developed by experts in the National Cyber Security Centre (NCSC). The NCSC provides advice and assistance to Jersey and the other Crown Dependencies as part of existing defence and security arrangements.

14. NCSC's guidance was produced following an extensive and detailed analysis of the security of the UK's telecoms sector. Government has worked closely with the NCSC to understand the extent to which the NCSC's guidance as set out the UK's Code of Practice is appropriate and proportionate for Jersey and Jersey's Public Telecoms Providers. This, Jersey's Code of Practice is, therefore, informed by the guidance provided by NCSC and contains a set of technical and procedural measures designed to ensure that security risks are appropriately managed by Jersey's Public Telecoms Providers.[5] NCSC's guidance stresses the need for organisations to take a risk-based approach to securing their networks and services.[6] Public Telecoms Providers shall, therefore, take a risk-based approach to securing their networks and services.
15. It is important that Public Telecoms Providers ensure that all of the risks they face including cyber, physical[7] and personnel[8] risks are assessed, appropriately managed, and that effective governance in in place. Public Telecoms Providers shall among other things consider NCSC's risk management guidance, the Cyber Assessment Framework, the Vendor Security Assessment guidance, and the guidance provided by the UK's National Protective Security Agency who, like the NCSC, provide advice to Jersey and the other Crown Dependencies.
16. The guidance, technical and procedural measures in this Code of Practice should be viewed and addressed holistically, not as separate, discrete elements or requirements to be understood and addressed in isolation.
17. Cyber and Telecoms security is constantly evolving in response to rapidly changing and new threats. Public Telecoms Providers should in addition to this Code of Practice, consider and understand guidance, advice and information published by among others the NCSC, UK National Protective Security Authority, European Telecommunications Standards Institute (ETSI), and Jersey Cyber Security Centre (JCSC). Revisions and updates to the UK's Code of Practice that provide clarifications and introduce additional measures should also be considered and where appropriate addressed until such time they are incorporated into Jersey's Code of Practice.
18. The Order and this Code of Practice make clear that those persons – "responsible persons"- who have been given security-related tasks by Public Telecoms Providers shall be both competent to discharge the responsibility, and are given resources to enable them to do so.
19. It is equally important that Public Telecoms Providers continually improve their approach to risk management, considering risks posed by new and evolving technologies such as Artificial Intelligence, application programming interfaces and eSIMs. Public Telecoms Providers should make use of threat intelligence, information sharing and analysis resources.

20. This Code of Practice does not contain guidance or measures about the application of Artificial Intelligence. Nevertheless, Public Telecoms Providers should have regard to guidance published by NCSC[9] and ETSI[10] in order to assess and address the risks arising from the use of Artificial Intelligence by themselves, suppliers and bad actors.

Roles and responsibilities of public authorities

21. The Minister for Sustainable Economic Development (the Minister) is responsible for setting and overseeing national policy on telecoms security and resilience. The Minister will keep the effectiveness of the telecoms security framework under review, and develop it further as new threats emerge. In doing so, it will be supported by the Jersey Competition Regulatory Authority (JCRA)[11] through its regular reporting on security to the Minister under Article 24Z of the Law.
22. Government has also introduced legislation to improve the cyber resilience of Jersey's Operators of Essential Services.[12] Adopted by States Assembly in January 2026 the Cyber Security (Jersey) Law 202- will once commenced require Operators of Essential Services to report significant cyber security incidents.[13]
23. JCRA: JCRA will regulate the new framework in accordance with its duty in Article 24V of the Law, to seek to ensure that Public Telecoms Providers comply with their security duties. This gives JCRA a clear remit within the new framework to work with Public Telecoms Providers to improve the security of their public networks and services and monitor their compliance.
24. The Law gives JCRA the ability to monitor and enforce compliance with its new legal obligations in the telecoms security framework. It also gives JCRA new powers to request information from Public Telecoms Providers in order to carry out its functions.
25. The NCSC: The NCSC is the UK's national technical authority for cyber security and provides expert and impartial advice to the Government and its agencies including the JCRA.
26. The NCSC will also continue to offer technical advice to Jersey's Public Telecoms Providers, to Government, JCRA, and to the JCSC. However, the NCSC will not report Public Telecoms Providers to JCRA in cases of non-compliance or advise

Public Telecoms Providers on whether the measures they are taking amount to regulatory compliance.

27. The JCSC: JCSC established through the Cyber Security (Jersey) Law 202- is the local technical authority with regard to cyber security and provides expert and impartial advice to Government and its agencies including the JCRA. The JCSC and JCRA have agreed a Memorandum of Understanding. The Memorandum contains information on the roles of the respective organisations and how they will work together and share information with each other as part of the new security framework.

Scope of this Code of Practice

28. This Code of Practice provides guidance to those Public Telecoms Providers whose security is most crucial to the effective functioning of Jersey's telecoms critical national infrastructure (CNI). However, other Public Telecoms Providers could choose to adopt any aspects of the guidance that they consider would be appropriate to secure their networks and services.

Application of this Code of Practice

0.29 The guidance in this Code of Practice is intended to apply to Public Telecoms Providers in the following way:

The measures in this Code of Practice apply to those Public Telecoms Providers whose availability and security is critical to people and businesses across Jersey.  

Other Public Telecoms Providers are not expected to follow the measures in this Code of Practice. However, they may choose to adopt the measures included within this Code of Practice where these are appropriate and proportionate to their networks and services.  

0.30 The Public Telecoms Providers whose availability and security is critical to people and businesses across Jersey are those in every calendar year in which the JCRA determines that the provider's relevant turnover in the preceding calendar year was at least £1,000,000.

0.31 To ensure stability in the application of the guidance, the Code of Practice will continue to apply to a network provider or service provider for two calendar years after the calendar year in which their relevant turnover falls below £1,000,000 per calendar year.

0.32 Relevant turnover means the network provider's or service provider's turnover in a calendar year from any relevant activity carried out wholly or partly in Jersey after the deduction of goods and services tax (GST) payable under the Goods and Services Tax (Jersey) Law 2007;

"relevant activity" means –

1. the provision of an electronic communications service to a third party;

2. the provision of 1 or more of the following to a communications provider – 1.i  (i) an electronic communications network;

1.ii  (ii) an electronic communications service;

1.iii  (iii) access to an electronic communications network;

3. the making available, to a communications provider, of facilities associated with sub-paragraphs (a) and (b).

33. Whilst the measures are intended to address the risk of security compromises to public electronic communications networks and services, providers of private networks may wish to adopt the measures included within this Code of Practice where applicable.

Legal status of this Code of Practice

34. This Code of Practice provides detailed technical guidance to Public Telecoms Providers about the measures to be taken under Part 5A of the Telecoms Law. The processes for issuing, revising and withdrawing Codes of Practice are set out in Articles 24O and 24P of the Law and the legal effects of Codes of Practice are detailed in Article 24Q.

Non-compliance with the guidance measures in this Code of Practice

35. Non-compliance with the guidance set out in this Code of Practice does not, of itself, make the Public Telecoms Provider liable to legal proceedings and is not the only way for Public Telecoms Providers to comply with the security duties in the Law and the specific security requirements in the Order. Where the Order requires Public Telecoms Providers to take appropriate and proportionate' measures, what is appropriate and proportionate will depend on the particular circumstances of the Public Telecoms Provider.
36. A Public Telecoms Provider may choose to comply with its security duties and specific security requirements by adopting different technical solutions or approaches to those specified in this Code of Practice. When they do so, JCRA may require the Public Telecoms Provider to explain the reasons why they are not acting in accordance with the provisions of this Code of Practice in order to assess whether they are still meeting their duties under the Law. Public Telecoms Providers are obliged to explain those reasons to JCRA under Article 24R of the Law, where JCRA has reasonable grounds for suspecting a Public Telecoms Provider is failing or has failed to comply with this Code of Practice.
37. In determining any question arising in connection with the carrying out by JCRA of a relevant function, JCRA must also take into account the provisions in this Code of Practice where they are relevant and in force at the time at which the question relates to (see Article 24Q(3) of the Law).

38. In determining any question arising in legal proceedings, a Court must take the provisions in this Code of Practice into account where they are relevant and in force at the time in which the question relates to (see Article 24Q(2) of the Law).

Non-compliance with the security duties in the Law and/or requirements in the Order

39. In cases of non-compliance with the security duties and/or specific security requirements, JCRA will be able to issue a notification of contravention to Public Telecoms Providers setting out that they have not complied, and any remedial action to be taken. JCRA also has the ability to direct Public Telecoms Providers to take interim steps to address security gaps during the enforcement process.
40. In addition, in cases of non-compliance, including where a Public Telecoms Provider has not complied with a notification of contravention, JCRA can issue financial penalties. The level of the financial penalties that JCRA can impose in those instances is set out in the Law.
41. Further information on how JCRA will use its powers and regulate the framework will be contained within its Procedural Guidance required under Article 24Y of the Law.

Implementation timeframes

42. Whilst the overarching security duties that form the new telecoms security framework will come into force on a date to be confirmed, it would not be proportionate to expect Public Telecoms Providers to be in a position to meet all their obligations by that date. Instead, specific recommended compliance timeframes for individual measures are contained within this Code of Practice. These are the timelines by which Public Telecoms Providers would be expected to have taken relevant measures set out in this Code of Practice. Nevertheless, Public Telecoms Providers might well consider a risk-based approach that considers the threats to their networks and services means it is appropriate achieve compliance before the timelines set out in this Code of Practice.
43. 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.

Public Telecoms Providers entering the market

44. New Public Telecoms Providers entering the market will be expected to follow the same timeframes as existing Public Telecoms Providers, irrespective of how recently they entered the market.

Updating this Code of Practice

0.45 Government intends to review and update this Code of Practice periodically. Updates will most likely be informed by the following broad categories of information:

updates made by the UK Government to the UK's Code of Practice;

security advice provided to the by the NCSC and JCSC that sets out where these new threats and vulnerabilities lie, based on its analysis and intelligence;

evidence from Public Telecoms Providers of new vulnerabilities uncovered by continued and expanded security testing, as well as new incident reporting on security compromises and risks of security compromises; and  

security reports prepared by Ofcom and JCRA containing information and advice that will assist the Government with forming policy.

0.46 Where changes to this Code of Practice are proposed, Government will consult affected Public Telecoms Providers, JCRA and any other relevant parties. All proposed changes, regardless of their source, will be discussed with the NCSC and JCSC before being incorporated into the Code of Practice. After carrying out the consultation, and before issuing the Code of Practice, Government will lay a copy of the Code of Practice before the States Assembly.

0.47 This current version of the Code of Practice provides guidance as to the measures to be taken by Public Telecoms Providers under Articles 24K to 24N of the Act, unless revised or withdrawn by the Government.

Further information

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

NCSC's security analysis for the UK telecoms sector[14]

The Telecommunications Law (Jersey) Amendment Regulations 2024

The Telecommunications (Security Measures) (Jersey) Order 2026

Section 2: Key concepts

1. Overarching key concepts

1. There are certain key concepts that are relevant to the guidance measures set out in this Code of Practice and requirements contained in the Order. It is important that all Public Telecoms Providers fully understand these key concepts as it will enable them to properly apply the intent of the security requirements. This chapter covers the concepts of security critical functions and network oversight functions which apply throughout, as well as the overarching scope of this Code of Practice.

Explanation of terms

Where the term reduce' is used in the Order, it is expected that the Public Telecoms Provider will reduce the risk as far as possible.

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

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

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

May: The use of the word may' in the guidance indicates that Public Telecoms Providers are likely to have multiple options, all of which could deliver a satisfactory solution and there are likely to be differences between Public Telecoms Providers in their implementation.

Scope of measures within this Code of Practice

2. Measures contained within Section 3 of this Code of Practice apply to Public Telecoms Providers. This includes, but is not limited to, the following elements where they are part of such networks and services:

the systems and services involved in providing public telecoms services to customers;

proof of concepts or trials on the operational network;

the use of data from the operational network for testing purposes;

interconnection of development, test and operational systems - although this is an activity which is inappropriate in all scenarios;

parts of the operational network operated by third parties on behalf of the Public Telecoms Provider, including as part of managed service arrangements;

parts of the operational network hosted outside the British Islands; and

networks supporting the operation of the live network, where these supporting networks can have a material impact on the proper functioning of the operational network.

Security critical functions

3. A "security critical function" in relation to a Public Telecoms Provider's 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" (Article 1 of the Order).
4. Security critical functions will therefore make up different proportions of networks or services, the specific details being dependent on the unique operating mode of each individual network. However, security critical functions will include a broad range of essential functions within the network that could impact its proper operation and not simply those whose primary function is security. The guidance in this Code of Practice sets out specific protections targeted at different functions of networks and services that may be considered critical. It does not seek to exhaustively define components as critical.
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 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.

Network oversight functions Scope

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 Public Telecoms Provider to understand the network, secure the network, or to recover the network. Scope will differ from Public Telecoms Provider to Public Telecoms Provider depending on the type of network and how those networks are architected.

7. Given their importance in allowing the Public Telecoms Provider to maintain control of the network, network oversight functions are more likely to be targeted for a security attack and the impact of their compromise is greater.
8. Network oversight functions include, but are not limited to, the following components of the network where such components oversee and control security critical functions:

element managers;

virtualisation orchestrators;

management systems (e.g. jump boxes);

security functions (e.g. firewalls at the edge of a security zone);

root authentication services (e.g. active directories - ADs);

multi-factor authentication services;

security gateways (e.g. supporting the management plane);

audit and monitoring systems (including network quality monitoring of speech and data); and

operational support systems.

Guidance

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.
10. Wherever possible, more modern security practices should first be implemented in network oversight functions as they are likely to benefit most from these enhanced protections. Specific recommended compliance timeframes for individual measures are contained within Section 3 of this document.

The principle of assumed compromise'

11. Public Telecoms Providers should establish the principle of assumed compromise'. This means that Public Telecoms Providers should normally assume network oversight functions to be subject to high-end attacks, which may not have been detected by the Public Telecoms Provider, and implement business practices which, by their nature, make it difficult for an attacker to maintain covert access to these functions. This can be achieved through establishing secure platforms which implement trusted boot, and periodically rebuilding the functions to an up-to-date known-good state.

Management functions for network oversight functions

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

Approach to monitoring and analysis

13. Under the Article 6 of the Order, 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, including real-time monitoring of changes to network oversight functions and monitoring for signs of exploitation.
14. In addition, when Public Telecoms Providers start performing security analysis to establish the normal behaviour' of their networks in order to be able to identify and investigate any anomalous activity, they should prioritise the analysis of the behaviour of network oversight functions.

Example of how network oversight functions work with security critical functions

1.15 An example of how network oversight functions and security critical functions can work together in the context of virtualisation workloads is set out below.

1.16 Typically, when building out the infrastructure to enable the running of virtualised workloads a Public Telecoms Provider will require:

the hypervisor – the operating system installed on the physical servers to enable them to run virtual machines (the combination of many hypervisors/physical servers/physical networking that links it all together is usually referred to as the virtualisation fabric');

physical servers to run the hypervisor;

the virtual workloads themselves; and

the virtualisation orchestration software that tells the virtual workloads on which servers to run.

1.17 If the virtual workload is a function whose operation has a material impact on the operation of the network, then the following would be security critical functions:

the virtual workload itself;

orchestration software that establishes the virtual workload;

the hypervisor;

the physical servers on which the virtual workload runs.

In this case, the orchestration tooling would be the network oversight function.

18. Because of their importance to overall network security, all network oversight functions should normally be expected to fall within the definition of "security critical functions"

set out in the Order. However, not all security critical functions can be considered as network oversight functions as many do not control or oversee other security critical functions.

2. Network Architecture

1. This chapter provides guidance for Public Telecoms Providers on the measures to be taken in accordance with Article 3 of the Order to design, construct (or where relevant, redesign and develop) and maintain networks securely.
2. Article 3 of the Order is set out below.

Key concepts for understanding the requirements

3. The architectural and design decisions which are made when creating and modifying a Public Telecoms Provider's network or supporting systems are critical to the security of that network. This security architecture determines how difficult it will be to compromise or disrupt the system, the scale of any associated impact, and whether the Public Telecoms Provider is likely to detect and recover from any compromise.
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.
5. Whilst a technical discipline in its own right, the security architecture is also fundamental to every other security measure described within this document. It determines the risk to equipment, and hence the necessary controls and protections.
6. Where there is a demonstrable plan at commencement of the Order for the removal of specific network equipment and it would not be proportionate for that network equipment to meet specific measures within this Code of Practice, Public Telecoms Providers shall be required to ensure compliance with their security duties by implementing those measures that remain proportionate, and by taking alternative measures as necessary, based on a detailed risk assessment. This may include earlier replacement of the network equipment with alternative equipment that mitigates the security risk. It is not appropriate to disregard the security of networks based on what may, or may not happen to them in the future.

The management plane

7. The management plane of a networking 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.

Scope

8. The scope will differ from Public Telecoms Provider to Public Telecoms Provider but this guidance applies to management access to equipment within operational telecoms networks, and to management access to equipment that supports the operation of telecoms networks. Also in scope are the networks of third parties where those third parties perform management on the Public Telecoms Provider's behalf, and any automated management systems, such as orchestrators and Operational Support Systems (OSS).
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, but to ensure that any deployments use the appropriate security controls.

Background

10. The management plane is the most powerful part of the network infrastructure, making it the primary target for any malicious attack intending to disrupt or otherwise compromise the operation of a network. Exploitation of the management plane could have a long- term impact on the availability and confidentiality of a Public Telecoms Provider's services, including critical services.
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.
12. As an example, on 17 August 2021 it was confirmed that T-Mobile was subject to a data breach which saw the personal data of nearly 50 million customers being exposed. Evidence has shown that this compromise may have been caused by T-Mobile having the management plane of the core network directly exposed to the internet. It has been indicated that the exposed box was test equipment that was attached to the operational network, and from the test equipment the attacker had access to the LAN and could brute force the password on operational servers. This enabled a single hacker to access customer data within a number of weeks.
13. Historical management of telecoms networks has relied heavily upon standard corporate devices doubling up' as administrative workstations. Consequently, the computers that perform standard 'office' type functionality such as email, web access and the use of

productivity tools are also defining the operation of the network. This is often referred to as a browse up' architecture, as shown in Figure 1 and described in the security architecture anti-patterns publication by the NCSC[15].

Figure 1: Example of browse up' architecture

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).

Guidance

15. Attacks via the management plane are likely to have a significant impact upon both the Public Telecoms Provider and Jersey and hence securing the management plane should be treated as a priority by Public Telecoms Providers. The following guidance highlights the key aspects of management plane security for Public Telecoms Providers

to understand in order to appropriately secure networks. The guidance also contains examples and further background information where appropriate. However, secure system administration is not solely a challenge within the telecoms sector, and general advice on this problem can be found on the NCSC website.[16]

Isolating the management plane

16. Given the risks, it is not appropriate for Public Telecoms Providers to be using a browse-up' architecture. Instead, Public Telecoms Providers shall architect, and operate, their management plane infrastructure to inhibit network compromise through administrative access.
17. Workstations dealing with general office productivity tools and external access to external services over the internet shall be logically or physically separate from those with any access to the management plane. Any administrative users who previously performed these functions via a single device will need to operate differently to protect their network.
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 Public Telecoms Providers ensure that anything that can impact the operational network cannot be compromised from the corporate zone.

Figure 2: Example of browse-down' architecture

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.

20. In some instances remote access may be necessary.

Secure administration

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.
22. Whenever administrators are gaining an ability to impact the operational network, Public Telecoms Providers shall ensure that multi-factor authentication (MFA) is used as part of the authentication process. MFA would normally be performed as administrators access management platforms (jump boxes, orchestrators, etc) rather than individual hosts. The second factor should be generated or transmitted via a device separate to that being used to perform the administrative functionality. Public channels for delivery of the MFA token, such as SMS, are not appropriate for this use case.
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).
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.
25. To protect management platforms (such as jump boxes, element managers, orchestrators, etc) from up-stream attacks from network equipment, the management plane shall be configured to ensure that only necessary connections are allowed. By default, the connections that should be allowed are those established from administrative functions to network equipment.

Third party administrators

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.

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 Public Telecoms Providers 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 Public Telecoms Provider's management environment.

Figure 3: Third party administrator secure access to multiple providers

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.

Read only access

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.
30. Because of this, the recommended approach to support read-only administrative access 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.

Virtualisation and containerisation

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.

Scope

32. Background information and guidance on virtualisation and containerisation in this Code of Practice applies to Public Telecoms Providers where they are making use of virtualisation or containerisation to abstract more than one piece of physical hardware from the operational software.

Background

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

2.34 Virtualisation generally establishes two architectural layers;

the virtual functions or virtual instances (usually a set of applications and operating systems);

the virtualisation fabric' or virtualisation platform, made up of a hardware abstraction layer, such as a hypervisor, and the physical servers and networking equipment used to host the virtualised workloads.

2.35 For the purposes of this document, virtualisation' is considered to be a system supported by a bare-metal' hypervisor, as shown in Figure 4. Bare-metal hypervisors run directly on a host machine's physical hardware and provide a fully abstracted layer between virtual workloads running within the hypervisor and the physical hardware's resources.

Figure 4: Example of bare-metal hypervisors

VM = Virtual machine OS = Operating system

36. Virtualisation can be an effective tool for improving the security of a system. By enforcing separation between workloads, it can help prevent lateral movement. By abstracting the hardware, it can allow for better inspection of system behaviour and make the compromise of hardware more complex for an attacker. Virtualisation should also make a system more flexible, allowing security updates and improvements to be implemented more quickly.
37. However, in virtualised networks the integrity of the virtualisation fabric becomes critical. Compromise of the virtualisation fabric could result in the compromise or disruption of all workloads supported by that fabric. Virtualised networks are also highly configurable. While this is a strength, Public Telecoms Providers should be aware that the configuration of the virtualised environment can undermine its security properties.
38. In comparison, containerisation provides no hardware abstraction, but does provide a quick deployment and scaling opportunity to Public Telecoms Providers by packaging applications within a single host operating system (as shown in Figure 5). Access to resources is limited by the host operating system, but hardware resources are not abstracted, meaning the security benefit is limited.

Figure 5: Example of containers

OS = Operating system

39. Containerisation is viable for sharing and scaling workloads within the same security zone or trust domain (Figure 6). However, Public Telecoms Providers should assume that an attacker with access to one container will be able to compromise the host and all the other containers supported by that host. Therefore, containers should never be considered as, nor used as, a security boundary.
40. Both virtualisation and containerisation are sometimes used together. Virtualisation may be used to abstract the hardware. Containers are used to scale workloads within the virtual function, but never as a security boundary.

Guidance

41. Virtualisation security is an evolving subject, with new security solutions and design patterns emerging each year. The guidance in this Code of Practice 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[17].

Limiting the impact of host compromise

42. As previously noted, the compromise of a host within the virtualisation fabric poses a significant security risk to all virtual functions supported by the host. As it cannot be assumed that a host compromise will not occur, Public Telecoms Providers shall ensure that it is possible to reduce the impact from, and recover from, a host compromise.
43. To limit the impact of host compromise, Public Telecoms Providers should segregate both their virtualisation fabric and the virtual functions supported by that fabric. This ensures that the network's security architecture is not undermined by the dynamic nature of the virtualisation.
44. For this reason, Public Telecoms Providers will often break large host estates into groups based on risk. For the purposes of this document, these groups of hosts will be called host pools', an example of which is shown in Figure 6. All hosts within a pool should generally present a similar level of risk to the network. This risk may be based upon the host type, the security features of the host, or the host's physical location. Hosts may also be pooled for resilience purposes to ensure that load-balancing workloads are in physically separate locations.

Figure 6: Virtualisation fabric broken into host pools'

45. Similarly, virtual functions can be grouped based on risk, for example due to exposure, criticality or sensitivity. For the purpose of this document, these groups of virtual functions are called trust domains.
46. By associating trust domains with host pools, Public Telecoms Providers can segregate their network, maintaining a physical security architecture within a virtualised network, as shown in Figure 7. These associations are sometimes known as affinity rules'.

Figure 7: Segregating trust domains using host pools

Management of the virtualisation fabric

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

48. It should rarely be necessary to directly administer physical hosts within an operational virtualised network, as most interaction should be performed by a central orchestration tool. This orchestration tool should be treated as a network oversight function. For resilience and security reasons, this central orchestration tool should not be hosted on the virtualisation fabric that it manages. Should it be hosted within the fabric, this could impede recovery should part or all of the fabric fail or be compromised.
49. It is possible that physical baseband management controllers (BMCs) or other integrated lights out (iLO) management interfaces are used to manage hosts. Such alternative administration networks should either use a dedicated network that is physically separated from the virtualisation fabric network or use a lights out management solution that supports secure management as detailed in this document.

A secure virtualisation fabric

50. In the event that a host is potentially compromised, Public Telecoms Providers must be able to recover the integrity of the host infrastructure. As replacing the host hardware is expensive, Public Telecoms Providers can instead return the host to a known-good state. This may be achieved where hosts support secure boot'.
51. As part of a secure boot, physical hosts record their boot-up sequence from power on to hypervisor load. A hardware root-of-trust (e.g. TPM) signs this record before it is sent to an attestation service. The attestation service can then assess whether the state of the physical host has changed. If not, this gives confidence to the Public Telecoms Provider that the host can be trusted to host virtual functions.
52. Additionally, should the Public Telecoms Provider need to transfer hosts between host pools, a secure boot process can be used to give confidence to the Public Telecoms Provider that the host is clean' prior to performing the transfer. Public Telecoms Providers should avoid configuring the virtualisation fabric in such a way as to inhibit the migration of virtual machines as required.

Choosing virtual functions

53. Public Telecoms Providers should use virtual functions that are built for use within a virtualised environment as this provides significant security benefits. Network functions which are built to be virtual will run effectively on any virtualisation fabric or hypervisor and hence are likely to be more secure, avoiding platform-specific functionality or cut- throughs. They are likely to be more resilient, due to a lack of dependence on a specific platform. They also allow for the virtualisation fabric to be more secure, easily supporting migration between hosts to allow for updates and reconfiguration.
54. Pinning specific virtual network functions to specific hosts within the virtualisation fabric makes it significantly harder to update and patch those functions and hosts. As such, it should be avoided where possible.

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

Authorising virtual functions

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

Separating virtual functions

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 Providers 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.
58. For this reason, it is possible for a single host pool to support multiple trust domains as the separation between the trust domains is maintained by the virtualisation fabric.
59. In general, containers do not provide sufficient security separation to be relied upon to segregate virtual functions. Public Telecoms Providers should assume that a virtual/physical host compromise or a container-to-container compromise is more likely in containerised environments. For this reason, all containers running on a single physical or virtual host should be within a single trust domain. Additionally, where the containers are running directly on a physical host, the host pool should be treated as less trusted.
60. Similarly, bare-metal hypervisors are sometimes configured to allow specific virtual machines to address physical hardware directly. These are known as hypervisor cut- throughs'. Cut-throughs can have performance benefits, but they negate the security properties of the bare-metal hypervisor as a virtual machine is now able to directly access and control physical hardware without any of the hypervisor's security controls. On hosts supporting cut-throughs, the virtual functions should all be within a single trust domain, and the host pool should be treated as less trusted.
61. This guidance is not intended to discourage Public Telecoms Providers or third party suppliers from using containers where there is benefit in doing so, but to highlight that such containers should not be treated as a security boundary between trust domains. Similarly, where virtualisation is not being used to provide a security boundary, the security choices relating to the virtual network are less important.

Understanding the virtualised network

62. An essential part of a virtualised network is the understanding of that network. Public Telecoms Providers should ensure that they can easily represent and explore the virtual and physical network architecture, including identifying how the security architecture is enforced both virtually and physically. This can be supported by well-defined, system- enabled processes.
63. As a virtualised network may change dynamically, the principles that define the security architecture should be defined within the orchestration systems that establish and modify the network.
64. From a physical perspective, Public Telecoms Providers shall ensure that they are able to access full details of hosts, including:

type of host and supporting software (e.g. hypervisor) and software versions;

the last boot time, boot status (e.g. a successful or failed secure boot) and any attested information;

the host pool and security properties associated with the host;

the trust domains that the host may support and the networks (VLANs/VXLANs) accessible from the host.

2.65 Within the virtual network, Public Telecoms Providers shall ensure that they are able to access the logical flows between virtualised workloads including:

the protocols that should, and should not, flow over the virtualised interfaces;

the physical hosts, equipment and links used to support the logical flow;

the trust domains within the logical flow and the security enforcing functions splitting up that flow.

2.66 Public Telecoms Providers should also use the flexibility of virtualisation to enable greater monitoring of processes and flows within the virtualised system.

Network automation

67. This guidance demonstrates that managing a secure virtualised environment is complex. However, the majority of the security requirements can be automated.
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 Public Telecoms Provider to keep pace with the threat environment.
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 Public Telecoms 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.

The signalling plane

70. All Public Telecoms Providers' networks connect to each other over signalling networks. These signalling networks allow Public Telecoms Provider networks to connect to each other, reach each other's services and ultimately allow users to communicate with each other. The signalling plane of a network consists of protocols for control and support of the transmission plane functions. The signalling plane carries out the following functions:

it controls the access connections to the network (e.g. GPRS attach and GPRS detach);

it controls the attributes of an established network access connection (e.g. activation of a packet data protocol (PDP) address);

it manages the routing of information for a dedicated network connection in order to support user mobility;

it adapts network resources depending on the parameters; and

it sets up calls and routes messages.

Scope

71. This Code of Practice applies to signalling traffic arriving from external signalling networks, signalling arriving from other networks which are not within the scope of the security framework and outgoing signalling traffic from a Public Telecoms Provider's network. This includes, but is not limited to: BGP, SS7/MAP/ISUP, DIAMETER, GTP-C, and SIP/IMS.
72. Controls apply to all international signalling, including signalling which arrives over national signalling interfaces (e.g. due to mobile number portability). Signalling from the other Crown Dependencies shall be treated as international signalling.
73. Throughout this Code of Practice it should be noted that Public Telecoms Providers' live networks should be considered in scope of the guidance measures which concern network signalling protections. This would cover, for example, any trials being conducted on a live network that may have implications for wider network availability, functionality or performance. Protections from risks arising from external signals will also apply to signals originating from the network edge or consumers.

Guidance

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

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 this Code of Practice highlights the key aspects of signalling plane security for Public Telecoms Providers to understand and implement, providing examples and further background information where appropriate.

Signalling protocols

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

Protecting the network

77. An attacker may seek to scan the Public Telecoms Provider's signalling networks to understand the network and inform further attacks. Public Telecoms Providers shall ensure that the internal network topology of their signalling is not exposed by ensuring that only hub' signalling addresses can be reached from external networks. These interfaces and addresses should be formally recorded.
78. Attackers may also send malformed signalling towards the Public Telecoms Providers network in an attempt to disrupt or compromise the Public Telecoms Provider's service. To protect the network, Public Telecoms Providers should ensure that external signalling is fully parsed and processed before reaching a security critical function.
79. Architecturally, this may be achieved by Public Telecoms Providers establishing an architectural demilitarised zone (DMZ) between incoming signalling networks and security critical functions, similar to the mechanism used to protect IP networks from any less-trusted sources (such as the internet). It could also be achieved by segregating the core network to limit the impact of any attack.

Protecting users

80. Public Telecoms Providers should seek to prevent the disruption of service or the leaking of customer data, customer identifiers and network topology over signalling interfaces. Where the Public Telecoms Providers' customers are connected to the Public Telecoms Providers' network, the Public Telecoms Provider shall implement mechanisms to protect the customer's service and data.

81. Where the Public Telecoms Provider's customers have roamed onto another network, the Public Telecoms Provider should support the visited network in protecting their customers by informing the visited network of the signalling addresses which will support the customers connection, and proxying call and SMS signalling via the Public Telecoms Provider's (home) network.
82. Where another Public Telecoms Providers' customers have roamed onto Public Telecoms Providers' network, the Public Telecoms Provider should seek to protect the inbound roamer's service and data as well as can be achieved given the information available from the roamer's home network.

Asset management

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

Guidance

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 Public Telecoms Provider's network, to ensure that they have an up-to-date network map and that this aligns with the asset register.
85. An important aspect of asset management is an assessment of the criticality and sensitivity of network equipment and systems. As part of this process, Public Telecoms Providers will be able to identify their security critical functions and network oversight functions.
86. Asset management shall include the recording of any equipment in the Public Telecoms Provider 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.
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[18].

The exposed edge

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

Customer premises equipment (CPE) is equipment supplied to customers which is used, or intended to be used, as part of the network or service. This excludes consumer electronic devices such as mobile phones and tablets, but does include devices such as routers, edge firewalls, SD-WAN equipment, and fixed wireless access kit;

Base station equipment;

Optical line terminal (OLT) equipment; and

Multi-service access node / digital subscriber line access multiplexer (MSAN/DSLAM) equipment.

Guidance

89. Public Telecoms Providers shall identify what equipment is in their exposed edge, and hence the equipment that is more accessible to potential attackers. Public Telecoms Providers shall ensure that the compromise or disruption of parts of the exposed edge would not be a significant incident for them.
90. To this end, Public Telecoms Providers should physically and logically separate their exposed edge from security critical functions and ensure that no sensitive datasets are held within the exposed edge.
91. Given the increased likelihood of compromise, Public Telecoms Providers are strongly encouraged to implement secure boot mechanisms for all network elements in the exposed edge. This functionality allows equipment to be returned to a known-good' state, meaning that it becomes possible to recover from a compromise without requiring the physical replacement of network equipment.

Retaining national resilience

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

Guidance

93. The resilience of Jersey's national connectivity should be maintained by ensuring that a sustainable and critical level of security expertise, data and equipment are accessible from within the British Islands at all times. Public Telecoms Providers should take appropriate and proportionate measures to ensure they are able to operate Jersey's networks in emergency situations where there may be reduced off-Island connectivity or off-Island travel, and factor this into business plans where they make use of offshored capabilities.
94. Whilst Public Telecoms Providers may be unable to maintain 100% of normal service connectivity in the event of loss of off-Island connections, they should be able to restore, secure and run networks to the levels set out in this Code of Practice in the event they lose access to offshored capabilities. In particular, if it becomes necessary to do so:

Public Telecoms Providers should have the ability to maintain (as relevant, where they provide such forms of connectivity prior to the event) the following Jersey on- Island connectivity for a period of one month in the event of loss of international connections:

- on-Island mobile voice; and

- on-Island text-based mobile messaging.

Public Telecoms Providers should be able to transfer into Jersey functions required by Jersey networks to maintain an operational service, should international bearers fail.

95. When assessing whether it is necessary to maintain the above network connectivity and transfer functions into Jersey to maintain an operational service, Public Telecoms Providers can consider different scenarios in their business continuity and disaster recovery planning that may be relevant to their decision. These could constitute emergency situations and may include:
    1. Loss of access to staff, equipment or data in a specific country or global region, where external factors such as natural hazards or geopolitics limit the access to a Public Telecoms Provider's resources in a particular country or global region, and those resources are required to operate the critical services set out above.
    2. Compromise of non-British Islands group functions, where functions of a parent group that are located outside the British Islands suffer a security compromise, and those functions are required to operate the critical services set out above.
    3. Disruption to connectivity or physical transport links between Jersey and the British Islands and rest of the world, where external factors such as natural hazards or geopolitics limit the ability to access a Public Telecoms Provider's resources outside the British Islands, and those resources are required to operate the critical services set out above.
    4. Failure of internet routing, where the failure of multiple major global providers, transit routes, or widespread hostile routing updates, or geopolitics cause failure of internet routing, or internet routing protocols, such as eBGP.
96. Public Telecoms Providers should also seek to ensure a British Islands-based capability to assess the risks of security compromise to the network. Such risks that could be assessed include:

keeping network security and audit logs outside of the British Islands;

approving procurement decisions on hardware and software for Jersey networks using overseas (non-British Islands) staff;

relying on staff, equipment or data based outside the British Islands; and

relying on third-party suppliers to ensure that basic first and second line support is available from them for the required period, where offshored expertise is lost.

3. Protection of data and network functions

1. This chapter provides guidance for Public Telecoms Providers on the measures to be taken in accordance with Article 4 of the Order to protect data and network functions that could be at risk of security compromises.  
2. Article 4 of the Order is set out below.

Key concepts for understanding the requirements Workstations and privileged access

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).
4. Public Telecoms Providers shall apply the NCSC's March 2025 guidance on PAWs. NCSC's guidance sets out principles about how to design and securely build management devices for high-risk system maintenance and administration.[19]
5. In addition to any current or future NCSC PAW guidance, Public Telecoms Providers should have regard to the ETSI's technical specification: Cyber Security (CYBER); Privileged Access Workstations; Part 1: Physical Device, and any future ETSI technical specifications for PAWs.[20]

6. ETSI's guidance covers the PAW device and the technical specification that would ensure the confidentiality of the end user device. Additional documents will cover other aspects of PAWs that can work in conjunction with each other to meet the needs of the overall system architecture and the relevant security aims

SIM security

7. The intent of the measures within this Code of Practice is to ensure that an at-scale compromise of SIM cards cannot be used to disrupt Jersey's Public Telecoms Providers, or to impact subscriber confidentiality. Article 4(6) of the Order sets out requirements that Public Telecoms Providers must meet in relation to SIM cards.
8. The following background information and guidance highlights the key aspects of SIM security for Public Telecoms Providers to understand and implement, providing examples where appropriate.

Universal Integrated Circuit Cards (UICCs)

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

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

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

3.12 UICC and eUICC manufacture is performed globally. The addition of SIM information, such as algorithms and keys, is normally performed during the personalisation process in the SIM card manufacturer's premises. There are 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;

vulnerability in SIMs including the use of obsolete or weakly specified algorithms.

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

where the UICC is profile-modifiable, the profile could be modified to compromise the device's connection;

where the cryptographic key (K/Ki) is compromised, the user's traffic could be decrypted over the air interface to generate spoofed traffic.

eSIMs

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. eSIM technology is in an early phase of market adoption, therefore, as they are adopted, any resilience risks to networks will need to be managed.
15. Public Telecoms Providers should ensure they have regard to and apply any guidance or advice about eSIMs published by NCSC or ETSI.

Guidance

16. 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 Telecoms 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 to be encouraged to increase the overall security of the SIM population in the network.
17. Public Telecoms Providers should ensure the security functionality of the SIM card meets or exceeds existing GSMA security recommendations. This is especially important for eUICCs which will be difficult or impossible to replace.
18. 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.
19. Once operational, SIM cards should be protected from potentially malicious signals. The Public Telecoms Provider shall only allow management (OTA) messages from permitted sources to reach SIM cards which are issued by the Public Telecoms Provider and attached to the Public Telecoms Providers' network.
20. 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 Public Telecoms Provider, the Public Telecoms Provider should use certificate-pinning to allow only approved services to make profile modifications.

21. Should Public Telecoms Providers be made aware of a compromise to customer SIMs, or the data within those SIMs, Public Telecoms Providers shall inform the relevant customers as soon as is reasonably practicable.

Encryption

22. Article 4(5) of the Order requires Public Telecoms Providers to use within the public electronic communications network signals which, by encryption, reduce the risks of security compromises occurring.

Guidance

23. 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.
24. 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 IPSec or TLS - detailed information and best practice guidance provided by NCSC can be found on its website.[21] For data-at-rest Public Telecoms 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.[22]

Customer Premises Equipment (CPE)

25. Customer premises equipment is supplied to customers and businesses to enable connectivity.

Scope

26. In relation to CPE and CPE configuration, the measures in Section 3 of this Code of Practice align with Article 4(4)(c) of the Order 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 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.

Background

27. 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.
28. For the customer, the CPE provides the separation between the internal network and the internet. Many customer devices rely on this separation to protect their local network.
29. 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 Jersey 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.

Guidance

30. Public Telecoms Providers shall ensure a baseline level of security for CPE. This will help to ensure that both network infrastructure and customers are protected at the point where the CPE is distributed. Additionally, Public Telecoms Providers shall ensure that the CPE has a secure default configuration, which should include limiting inbound connections by default. Public Telecoms Providers shall also ensure that the CPE will receive regular security updates throughout the device's lifetime.
31. Due to the possibility that exploitation of vulnerabilities in CPE devices could impact the Public Telecoms Provider's network at scale, or impact wider infrastructure, it is in the Public Telecoms Provider's interest to ensure that CPEs remain in support and up to date. Acknowledging that Public Telecoms Providers are not responsible for customer behaviour, Public Telecoms Providers shall take proactive measures that aim to ensure CPE devices are being kept up to date during the lifetime of the contract, such as by providing customers with CPEs that will automatically update by default. Similarly, Public Telecoms Providers shall take proactive measures that are likely to result in CPE devices being replaced once they go out-of-support.
32. Where the Public Telecoms Provider performs on-going management of the CPE, they shall ensure that this is performed securely. In particular, the Public Telecoms Provider shall prevent the CPE's management interfaces (e.g. TR-069) from being exposed wider than necessary, shall only allow the use of secure management protocols and shall ensure that their CPE credentials are unique to the device and not guessable.

4. Protection of certain tools enabling monitoring or analysis

1. This chapter provides guidance for Public Telecoms Providers on the measures to be taken in accordance with Article 5 of the Order to protect certain tools that enable the monitoring or analysis in real time of the use of the network or service, or the monitoring or analysis of the content of signals.
2. Article 5 of the Order is set out below.

Key concepts for understanding the requirements Countries listed in the Schedule

3. The Schedule 2 to the Order sets out the countries that pose the greatest risk to the security of Public Telecoms Providers. Monitoring and analysis tools of the type described in Article 5(1) of the Order may not be located in these listed countries due to the sensitivity of those tools and the access they provide to management of Jersey's networks and services. Public Telecoms Providers must also ensure that such monitoring and analysis tools are not capable of being accessed from those listed countries.
4. Tools that enable monitoring or analysis in real time under Article 5 of the Order 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 2 to the Order.
5. If new risks emerge from other countries in the future, or there is a reduction in existing risks associated with the countries listed in Schedule 2 to the Order, the Government

may look to update the Schedule 2 list. This Code of Practice sets out steps to help Public Telecoms Providers account for any such scenario, including the use of business continuity and disaster recovery plans to cover that risk.

Risk assessment

6. Article 5(2) of the Order sets out the need for Public Telecoms Providers to take measures to identify and reduce the risks of security compromises occurring as a result

of storing monitoring and analysis tools outside of the British Islands. Written

assessments of these risks are addressed under Article 11(b)(ii) of the Order.

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

security analysis and anomaly detection, including the operation of security operation centres (SOCs);[23]

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.

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

5. Monitoring and analysis

1. This chapter provides guidance for Public Telecoms Providers on the measures to be taken in accordance with Article 6 of the Order to monitor and analyse the use of their networks in order to identify any security compromises.
2. Article 6 of the Order is set out below.

Monitoring and analysis

3. While not directly a set of preventative controls, security monitoring fundamentally underpins the security posture of a network or system. Inadequate coverage of devices or networks from a logging and monitoring perspective will fundamentally limit the ability to identify and subsequently determine the root cause of anomalous activity and may also limit the ability to understand the extent of such activity without recourse to extremely labour intensive and expensive forensic work.
4. Enabling the collection of relevant information from appropriate devices or systems within a Public Telecoms Provider's environment will permit post-event analysis to be undertaken with significantly more ease and allow Public Telecoms Providers to gain more confidence in their ability to respond to security-related events.
5. While collection of this information will permit a range of post-incident analysis and other such activity, proper implementation of monitoring and alerting capabilities on top of this will allow Public Telecoms Providers to identify malicious or unusual behaviour taking place in near real time, enabling response prior to a major or catastrophic event taking place. General guidance and principles on effective monitoring can be found on the NCSC website.[24]

Guidance

6. The following guidance highlights the key aspects of monitoring and analysis for Public Telecoms Providers to understand and implement, providing examples and further background information where appropriate.

Logging and monitoring

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

who logged in (account or UserID);

what they did (type of event/activity);

when they logged in (date/time);

where the login occurred (resource/source of the event such as location, IP address, terminal ID or other means of identification); and

why the login occurred (a link to the specific ticket that necessitated the login).

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[25].

Normal and anomalous activity

8. Effective monitoring of network behaviour is dependent on a detailed understanding of the network. This encompasses asset management, but also requires a clear security architecture and an understanding of the behaviour of network equipment. Public Telecoms Providers are unlikely to be able to effectively monitor their networks without first collating this information.
9. This information is essential to determining a relative state of 'regular' activity and anomalous' activity, both between components within a network, and the behavioural state of network equipment. Anomalous activity is activity in a network which does not conform to regular network traffic, or conform to the regular behaviour of network equipment. Exactly what constitutes anomalous activity can only be defined by the Public Telecoms Providers itself as they have the best knowledge of what normal activity looks like.

Network-based monitoring

10. Public Telecoms Providers should use network-based monitoring, specifically the monitoring of signals both internally and at the edge of the Public Telecoms Provider's network to determine anomalous behaviour.
11. What to monitor can only be defined by the Public Telecoms Provider itself as they have the best knowledge of their networks. Public Telecoms Providers should base this decision on risk, recording both details of their approach to monitoring and the justification for that approach. In making this decision, Public Telecoms Providers should consider factors such as:

the criticality or sensitivity of interfaces and systems;

the exposure of the systems or interfaces to attack;

the vulnerability of interfaces and equipment, which may be higher for legacy and out-of-mainline support network equipment; and

the approaches and interfaces used by security testers, or by attackers during past compromises.

12. 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 telecoms 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; and

between management networks and other networks, including internal networks.

Host-based monitoring

13. Host-based monitoring involves monitoring the behaviour of network equipment and supporting devices within the equipment to identify anomalous activity. Public Telecoms Providers should utilise host-based monitoring wherever possible in their networks, and particularly in the protection of sensitive or critical functions.
14. Host-based monitoring may incorporate operating system, application, and virtual machine behaviour, including detailed information at the process level, especially where unexpected reboots/restarts have occurred as these event logs would help to investigate the cause. This may involve deployment of an on-host agent to collect the required information, or simply the forwarding of existing operating system-level logging data.
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.[26]

Protection of monitoring data

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.

Effective Analysis

17. Security analysis allows benefit to be gained from monitoring by identifying anomalous activity. Public Telecoms Providers frequently co-locate security analysts at a security operations centre (SOC).
18. For security analysts to identify anomalous activity, they will need access to detailed information about the network alongside monitoring data. Providing analysts with a clear picture of expected network activity provides them with context for the monitored environment, allows them to focus their activity and maximises the protection they will be able to afford the network. The necessary network information will likely need to be collated from architectural design documentation, asset management systems, configuration management systems, product and interface specifications, network change plans and change systems (known as tickets).

19. Public Telecoms Providers should also aim to provide analysts with monitoring data sourced from both network-based and host-based monitoring. To support effective analysis, there may be benefit in merging these datasets to provide a single picture of network activity and allow analysts to correlate information across a range of infrastructure.
20. Further, to help build a 'story' of activity, monitoring data should link administrative actions to network administrators and on to tickets. This applies whether the administrator is internal or employed by a third-party. With this information it becomes possible for analysts to build a chain of events, establish the root cause of incidents, and prevent a recurrence of that incident.

Proactive security monitoring

21. Analysis of monitoring data is sometimes viewed solely as a reactive exercise based upon configured alerting, or as a response to an incident. Public Telecoms Providers should seek to perform proactive analysis, or threat hunting, to assess whether activity is present that would not necessarily trigger security alerts. Such analysis should consider behavioural information alongside security alerts.
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, Public Telecoms Providers should have access to sufficient skilled analysts to support multiple investigations of anomalous behaviour at any one time.
23. General advice on proactive security monitoring can be found on the NCSC website.[27] Border Gateway Protocols
24. Border Gateway Protocol (BGP) is a signalling protocol which is used to route data between Public Telecoms Providers. This protocol can be hijacked, resulting in traffic being deliberately misrouted round the internet. It occurs when either a false ownership claim, or a false route to an IP address is advertised externally by an entity that neither routes to, nor owns the address. As an example, BGP misrouting was a factor in the global outage of Facebook on 4 October 2021.[28]

Guidance

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 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.26 Hijacks of internal British Islands Public Telecoms Provider traffic shall be particularly inhibited, and British Islands routes should be monitored for anomalous activity (such as the inclusion of unexpected transit networks). Public Telecoms Providers should share enough information with each-other to allow hijacks of internal traffic to be easily detected, and a fallback approach to routing should be established between Public Telecoms Providers in the event of a persistent hijack.

5.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.28 All address space and autonomous system (AS) resources allocated to a Public Telecoms Provider should be correctly recorded in such a way that it is simple to identify and contact the "owner" to assist in resolving issues. Contact details need to be current and accurate on all the Regional Internet Registries (e.g. RIPE) and other useful locations, such as Peering DB. Note that all appropriate fields and record types should be secured appropriately, to prevent misuse.

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

5.30 When implementing ingress and egress route filtering, Public Telecoms Providers should pay special attention to:

Special Use Addressing;

BOGONs (although RFC 6441 should be considered);

over-specific prefix lengths;

their own prefixes;

their own AS;

IXP LANs.

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

5.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.

33. Prefix origin validation by Public Telecoms Providers using tools such as Resource Public Key Infrastructure (RPKI) will help to ensure that only valid BGP updates from the genuine owner of the address space will be acted on. If Public Telecoms Providers also aggregate routes where possible, this will minimise the number of routes advertised, minimising the number of route updates required.
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 Public Telecoms Providers to ensure that they have in place a plan of maintaining Jersey 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.
35. If routing equipment fails, there is the possibility of a route being withdrawn. Operators should advertise routes in such a way that this is unlikely to happen. One possible way to do this is by the use of static routes to non-physical, persistent interfaces.
36. Where it is available, TCP Authentication Option (TCP-AO) should be the preferred method of authentication. This will allow for stronger authentication algorithms and better, more agile key management.

Threat hunting

37. Analysis of log information is sometimes viewed solely as a reactive exercise based upon configured alerting, or as a response to an incident. Collected log information should be used for proactive analysis to assess whether activity is present that would not trigger previously-configured alerts.
38. Threat intelligence information feeds will likely be required as reference material for potential attacker behaviour, and a good knowledge of the typical behaviour of monitored networks and the capabilities of monitoring systems will be necessary. Suitably skilled staff to operate these feeds is also required, whether that be via existing skilled staff or appropriate training.
39. Proactive analysis will need to be based upon assessed threat information relating to likely attacks and risks to a Public Telecoms Provider's network or service. The risks should be chosen by individual Public Telecoms Providers for this purpose based upon their threat profile and will likely change over time.

Regular scanning

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.

Retaining equipment logs for 13 months

41. The retention of logging data ensures that if there is a security compromise it is possible to identify any changes in the network that may have contributed to the compromise. The logs relating to security critical functions must be maintained for at least 13 months as this will ensure the retention of any changes made on a once-yearly basis, for example end of year processes.
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.

6. Supply Chain

1. This chapter provides guidance for Public Telecoms Providers on the measures to be taken in accordance with Article 7 of the Order to identify and reduce the security risk arising from actions taken or not taken by third party suppliers.
2. Article 7 of the Order is set out below.

Key concepts for understanding the requirements Management of third party suppliers

3. A supply chain involves contractual arrangements between the Public Telecoms Provider and third party supplier, or between third party suppliers. If used and managed correctly, these contractual arrangements can help improve the understanding of the supply chain, assist in investigations of security incidents and assist testing of security mitigations or processes. More general advice on supply chain security can be found on the NCSC website.[29]
4. Public Telecoms Providers cannot delegate or outsource responsibility for their duties under the Law or the Order to third party suppliers through contractual arrangements. Public Telecoms Providers remain responsible for ensuring compliance with the duties imposed by the Law and Order.

Guidance

5. The intent of the security framework in this area is to ensure Public Telecoms Providers fully understand and reduce supply chain risks. One of the key aims is to ensure that Public Telecoms Providers flow-down security requirements to third party suppliers by means of contractual arrangements, ensuring the third party supplier is working to the same security standards.
6. Public Telecoms Providers should consider whether they may require their third party suppliers' support to perform effective network audits and effective security testing of the

Public Telecoms Provider's network. For example, where the Public Telecoms Provider's network and a third party supplier's network are closely integrated, security testers will better simulate attacker behaviour if they are permitted to test both networks simultaneously.

7. 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 Public Telecoms Providers 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.
8. It should also be noted that Public Telecoms Providers are ultimately responsible for the security of their networks and cannot outsource this responsibility to third parties. Where Public Telecoms Providers do outsource aspects of operations to a third party, responsibility to comply with the obligations contained within the Law, and the obligations set out in the Order, remain with the Public Telecoms Provider. The Public Telecoms Provider therefore needs to have sufficient internal capacity to meet those obligations.

Data sharing

9. 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 supplier's systems may provide an attractive route to obtaining nationally significant datasets. In this context data' includes both user data and network data.

Guidance

10. Under normal governance practices, decisions relating to a data set will be taken by a data owner' who is responsible for the data's protection. As a first principle, data sharing should be limited to only the data necessary for the purpose. In most scenarios, the sharing of data from the operational network is unnecessary and should be avoided. Where data relating to the operational network needs to be shared, it will often need to be sanitised or anonymised first to protect user and network data.
11. It is recommended that Public Telecoms Providers establish systems that allow the Public Telecoms Providers to retain its data within its control whenever possible. This allows the Public Telecoms Provider to authenticate and authorise any access to their data using MFA, understand full details of that access, control any movement of data, and monitor and detect compromises. Any such data-sharing system is ideally separate from the Public Telecoms Provider's corporate and operational systems, ensuring that the data-sharing requirement does not give suppliers wider access to other systems.

12. 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.

Third party administrators Background

13. Administrative access presents a significant security risk to electronic communications networks. Public Telecoms 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 Public Telecoms Provider's 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.
14. Due to their nature, third party administrators may gain access to multiple electronic communications networks. This means that a single set of administrators, and administrative systems, can negatively impact multiple networks. This makes third party administrators particularly attractive to attackers. Should third party administrator systems be compromised, or a third party administrator be malicious, multiple networks could be exploited or disrupted simultaneously.
15. As an example, in December 2018 the UK Government attributed a Chinese espionage operation against global MSPs to threat group APT10. This operation was of unprecedented size and scale, targeting several global MSPs, with attacks ongoing since at least 2016. After compromising the MSP, the group exfiltrated a large volume of data from multiple victims, exploiting compromised MSP networks and those of their customers through trusted connections. This indirect approach of reaching many through only a few targets provides a high-profile example of a supply chain attack and a new level of cyber espionage maturity.
16. While both managed service access and third-line support can present a risk to Jersey's networks, the risks associated with managed service access is particularly significant due to increased scope and frequency of network access, and frequency of data access. The use of third-party administrators by Jersey networks almost certainly increases the overall threat of cyber-attack, requiring careful risk management by industry.
17. The use of third party administrators also creates a risk due to the dependence of the Public Telecoms Providers on the third party administrator for the continued operation of networks. Should the third party administrator be no longer able to provide the service, this is likely to have an operational impact.

Guidance

18. Overall, Public Telecoms Providers should be looking to reduce the risks to networks due to third-party administrators, and specifically reduce the risk that a single attack within a third party administrator could negatively impact multiple networks.
19. Public Telecoms Providers should ensure that the third-party administrator is enforcing separation to prevent its network from being connected to another Public Telecoms Provider's networks via the third-party administrator. Public Telecoms Providers will require a robust security boundary between their network and the third-party administrator, including the ability to control access to infrastructure, control any dataflows and limit any administrative accesses across the boundary. Such controls should be applied even when the third-party administrator is part of the same umbrella company or Public Telecoms Provider group.
20. Public Telecoms Providers should ensure that a compromise of the third-party administrator cannot compromise or disrupt multiple Public Telecoms Providers. Administrative workstations within third-party administrators should only be able to access a single Public Telecoms Provider's network. Such workstations may be virtualised, allowing a single device to support multiple operators.
21. In October 2023, the NCSC published supply chain guidance. Broken down into Foundations, Application and Consolidation sections, the NCSC's Supply Chain Guidance sets out essential information, guidance and advice on securing supply chains.[30]

Network equipment suppliers Guidance

22. Public Telecoms 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.
23. The following guidance highlights the key areas that Public Telecoms Providers need to understand when working with network equipment suppliers, providing examples and background information where appropriate.

Third party supplier dependency

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

supply of the equipment;

an essential flow of technical information as part of a support contract - comprising training, fixes, updates, enhancements, advice, direct network troubleshooting and replacement of failed equipment;

the upgrade/replacement of the equipment during a network refresh; and

the decommissioning of equipment.

25. Where the equipment will be difficult to replace due to time and cost, the Public Telecoms Provider is establishing a long-term reliance on the supplier. To some degree, the Public Telecoms Provider is now reliant on the third party supplier to ensure that the Public Telecoms Provider's network stays secure.
26. The equipment that is most difficult to replace tends to be within nationally distributed networks, particularly the access network. In this network it is costly and time- consuming for Public Telecoms Providers to replace equipment as there is a large quantity of equipment and it is geographically distributed. The following subcomponents are involved in access' networks:

mobile access (base stations and antennas);

fixed access (OLTs etc); and

transport (fibre and microwave links and equipment).

Fault or vulnerability in network equipment

6.27 Low product quality could result in disruptive security compromises within Public Telecoms Providers' networks. This risk includes two types of cyber event:

systemic failure due to software or firmware fault which could involve multiple third party suppliers if they use a common component; and

equipment vulnerability exploited by an attacker to cause disruptive effect or compromise the network.

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

6.29 Article 7 of the Order is intended to ensure that third party supplier security and quality is sufficiently valued by Public Telecoms Providers to reduce the risk of security compromise to their networks and services and drive security improvements in third party suppliers. This can be achieved through Public Telecoms Providers regularly performing an evidence-based assessment of network equipment suppliers' equipment security, recognising the supplier's positive and negative security behaviours, and ultimately valuing a network equipment supplier's good security practises during procurement.

The Vendor Security Assessment

30. The NCSC have published advice on how to assess the security of network equipment.[31] The NCSC's Vendor Security Assessment (VSA) provides advice on how Public Telecoms Providers should assess network equipment suppliers' security processes and the security of their equipment, alongside their usual assessments of network equipment supplier performance and interworking.
31. The purpose of the approach is for Public Telecoms Providers to objectively quantify the cyber risk due to use of the network equipment supplier's equipment. This is performed by gathering objective, repeatable evidence on network equipment suppliers' security processes and the security of the network equipment.
32. Evidence on the network equipment supplier's security practices should be based on the network equipment supplier's implemented practices, rather than its documentation. Given this, one valuable method of assessing the security of network equipment suppliers' equipment is through testing. This shall include positive testing, negative testing and fuzzing of the equipment's interfaces. Ideally this should be automated and repeated at scale to stress test the equipment's interfaces.
33. The VSA will be updated periodically, to keep pace with new threats and technologies. Public Telecoms Providers should ensure they are aware of any relevant updates that are made to the NCSC's VSA advice and access the latest version of the VSA as published on NCSC's website.
34. While Public Telecoms Providers are responsible for ensuring the equipment that they use is sufficiently secure, achieving secure equipment is best achieved through collective security research and transparency.
35. 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.
36. Where a third-party supplier does, or omits, something which increases the risk of security compromise, the risk to the Public Telecoms Providers will increase with the scale of deployment. Specifically, a high quantity of equipment or components in the network which share a supply chain risk increases the risk to the network. To limit the risk of security compromise, Public Telecoms Providers shall consider whether the risk associated with the quantity of equipment or components is manageable given the supplier risk.

The Trojan horse' threat

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

Management of sites

38. Where Public Telecoms Providers have network equipment and facilities within sites that are shared with other Public Telecoms Providers, it is recommended that all Public Telecoms Providers work together to set a consistent set of security measures that meet the Order and that the site operator should follow.

Existing contracts and new contracts

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

a renewal of a contract to continue completing the same work would not be defined as new;

software upgrades or service agreements that do not change the scope or scale of the work would not be defined as new (for example, a patch or general version of existing functionality would not be new);

a renewal of a contract which resulted in a software upgrade that leads to a change in the quality of service or enables a new service to be delivered would be new;

a renewal of a contract which resulted in the supply of updated, modified or new equipment hardware would be new;

where there is a framework arrangement in place with individual statements of work under this agreement then a change in either the framework contract or the individual statements of work would be in scope of a new contract if they change the scope or scale of the work;

where an existing contract is amended to change the scope or scale of the work it would be new.

7. Prevention of unauthorised access or interference

1. This chapter provides guidance for Public Telecoms Providers on the measures to be taken in accordance with Article 8 of the Order to prevent the occurrence of security compromises that consist of unauthorised access to their networks or services.
2. Article 8 of the Order is set out below.

Key concepts for understanding the requirements Explaining "access" to the Public Telecoms Provider  

3. In this context, "access" to a Public Telecoms Provider covers both logical/virtual access and physical access by an individual as well as machine-to-machine access.

Application Programming Interfaces

4. Application programming interfaces (APIs) underpin a great range of digital functions, and facilitate seamless data exchange between systems and services. NCSC has reported that an increased use of APIs provides attackers with greater opportunities to exploit vulnerabilities within their design and implementation.[32]

5. In response to the increased threats NCSC has published guidance on securing HTTP- based APIs. Public Telecoms Providers shall follow the NCSC's guidance when designing or building secure applications that offer an HTTP API.[33]
6. Public Telecoms Providers remain responsible for ensuring the security of APIs supplied by vendors and third parties. Public Telecoms Providers should ensure that those supplying APIs and software are aware of and follow NCSC's guidance on securing HTTP-based APIs.

8. Preparing for remediation and recovery

1. This chapter provides guidance for Public Telecoms Providers on the measures to be taken in accordance with Article 9 of the Order to prepare for the occurrence of security compromises with a view to limiting the adverse effects of security compromises and being able to recover from them.
2. Article 9 of the Order is set out below.

risk of a further security compromise occurring, to ensure that only authorised users have access to the network or service; and

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

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

1. an "online copy" is a copy that is held on the public electronic communications network or public electronic communications service in question; and
2. an "offline copy" is a copy that is stored in a way that ensures it is not exposed to signals conveyed by means of the network or service in question.

Key concepts for understanding the requirements

The necessary information to maintain the normal operation of the network/service

8.3 Article 9(2)(a)-(b) of the Order sets out requirements in relation to the information that Public Telecoms Providers must create or acquire, retain and replace with reasonable frequency in order to ensure the normal operation of the relevant network or service. As to the format of such information, Public Telecoms Providers must hold:

Within the British Islands a copy of this information on the network or service in question (i.e. an "online copy"); and

so far as is proportionate, in Jersey a copy that is stored in such a way that it is not exposed to signals conveyed by means of the network or service in question (i.e. an "offline copy").

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

Keeping an offline copy

5. Article 9(3)(b) of the Order defines an "offline copy" as "a copy that is stored in such a way that it is not exposed to signals conveyed by means of the network or service in question". Keeping an offline copy of this information could be achieved through cloud backups, where the cloud service is not itself a part of the network it is backing up and not exposed to signals from the network.
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.[34] Without a trusted identity, ransomware should not be able to request access to a Public Telecoms Providers' 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.

Recovery

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, Public Telecoms Providers should refer to NCSC advice on response and recovery planning.[35]

Retention of copies within the British Islands and Jersey

8. For resilience and continuity purposes, Article 9(2)(a) of the Order requires Public Telecoms Providers to retain online copies of information within the British Islands which is necessary to maintain the normal operation of the network or service and an offline copy of that information in Jersey. This does not prevent copies being held elsewhere as part of a global business operation.

9. Governance

1. This chapter provides guidance for Public Telecoms Providers on the measures to be taken in accordance with Article 10 of the Order to ensure appropriate and proportionate management of the persons who are given security-related tasks. This is intended to ensure that Public Telecoms Providers employ the appropriate security governance and business processes to protect UK networks and services.
2. The NCSC has published guidance about how Boards can deliver, communicate and champion strong cyber leadership including a Cyber Security Toolkit for Boards[36], Cyber Governance for Boards[37] and about the key role of culture[38].
3. Article 10 of the Order is set out below.

occurring as a result of unauthorised conduct by persons involved in the provision of the public electronic communications network or public electronic communications service.

Key concepts for understanding the requirements Supporting business processes

4. 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.
5. The following guidance highlights the key business processes for Public Telecoms Providers to understand and implement, providing examples and background information where appropriate.

Top-to-bottom security governance

6. 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.3940
7. Article 10(2)(d) of the Order requires Public Telecoms Providers to ensure that their security policy "provides channels through which risks identified by persons involved at any level in the provision of the network or service are reported to persons at an appropriate governance level". This requirement aims to ensure (among other things) that Public Telecoms Providers policies include a way to communicate security issues and risks to the top of the organisation, without risk of dilution.

Security and operational changes

8. Given the scale of some Public Telecoms Providers' networks, one of the greatest challenges may be ensuring that security teams are aware of the changes being made by operational teams. Before any decision is made that could impact the network, its

39 NCSC CAF guidance: A.1 Governance (NCSC, 2025)

40 NCSC CAF guidance: B.1 Service protection policies and processes (NCSC, 2025)

operation, or management, the risks should be assessed with the support of the security team. Ideally this should be part of an automated process.

Learning from incidents

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

The Cyber Assessment Framework (CAF)

10. Public Telecoms Providers should have regard to the NCSC's Cyber Assessment Framework CAF in order to ensure that they have appropriate business processes in place.[40] In order to achieve this, providers shall have regard to implementing the parts of the CAF which 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.
11. Any references in the CAF to essential functions' should be considered as security critical functions' for the purpose of this Code of Practice.
12. Should any differences arise between the interpretation of the CAF, and the guidance in the main body of this Code of Practice, this Code of Practice shall take precedence.

10. Reviews

1. This chapter provides guidance for Public Telecoms Providers on the measures to be taken in accordance with Article 11 of the Order to ensure that regular reviews of their security measures are undertaken.
2. Article 11 is set out below.

Key concepts for understanding the requirements

Clarifying any other relevant information' in Article 11(b)(vii) of the Order

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

Risks to be considered within risk assessments

4. Public Telecoms Providers should refer to the NCSC advice on risk management.[41] The risk assessment that Public Telecoms Providers must carry out as a part of the reviews process under Article 11 of the Order should be looking at not only the risks to the Public Telecoms Provider's business and network, but also the risks to end users. This includes, but is not limited to, the risks of loss of availability and of personal data leaks.

11. Patching and updates

1. This chapter provides guidance for Public Telecoms Providers on the measures to be taken in accordance with Article 12 of the Order to deploy patches or mitigations (including software updates and equipment replacement) as well as the necessary security updates and equipment upgrades.
2. Article 12 of the Order is set out below.

Key concepts for understanding the requirements

Guidance on the appropriate patching period for network equipment

3. Article 12(a) of the Order requires Public Telecoms Providers to take appropriate and proportionate measures to deploy any relevant patch or mitigation which becomes available "within such period as is appropriate in the circumstances having regard to the severity of the risk of security compromise which the patch or mitigation addresses". Figure 9 contains guidance on which time periods for patching network equipment are appropriate in different situations, based on how critical the vulnerabilities are and whether they are internally or externally exposed interfaces. These timeframes are

intended to ensure that patches are deployed in a way that is proportionate with the risk of the threat that the patch addresses. They also seek to counter the risks posed by threat actors who regularly target vulnerabilities soon after patches are made available, often by using easy, cheap and commercially available tools. Public Telecoms Providers should act swiftly to close these vulnerabilities and in all cases should look to implement patches for network equipment as soon as is practicable and no later than the timeframes in Figure 9.

Figure 9: Criticality and exposure-adjusted maximum timeframes for application of patches (from supplier release date)

Guidance

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 Providers 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.
5. Where relevant patches justifiably need more time than 14 days to be deployed (as outlined in Figure 9), Article 12(c)(i) of the Order requires Public Telecoms Providers to arrange for any such decisions to be taken at an appropriate governance level and recorded in writing. Public Telecoms Providers should ensure that these decisions are based on a rigorous risk assessment process and that robust alternative mitigations are put in place until the relevant patch has been deployed.

Governance for decisions about routine maintenance

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 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), as in Article 12(c)(ii) of the Order.

12. Competency

1. This chapter provides guidance for Public Telecoms Providers on the measures to be taken in accordance with Article 13 of the Order to ensure that the persons who have been given security-related tasks can appropriately discharge their duties.
2. Article 13 of the Order is set out below for reference.

In-house competency

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

Guidance

4. Where a Public Telecoms Providers is using a third party supplier, in-house staff of that Public Telecoms Providers 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.
5. Public Telecoms Providers must ensure that those involved in the security and resilience of networks and services have the appropriate level of qualifications and experience necessary to mitigate the risks to networks, services and data. Public Telecoms Providers should put in place and maintain processes for determining and verifying the competency of those involved in network or service security, for example,  through registration with the Cyber Security Council.[42]
6. Public Telecoms Providers should also ensure that adequate, appropriate and relevant security training is undertaken by anyone who interacts with security critical functions or sensitive data. For those involved in the security of security critical functions, focussed cyber security training and evaluation should be carried out, including providing staff with an understanding of how a telecoms network is compromised. Further advice on staff training can be found in NCSC advice.[43]

13. Testing

1. This chapter provides guidance for Public Telecoms Providers on the measures to be taken in accordance with Article 14 of the Order to carry out, or arrange for a suitable person to carry out, appropriate tests.
2. Article 14 of the Order is set out below.

Key concepts for understanding the requirements Penetration testing

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.

Guidance

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

testers or red teams should not be unnecessarily constrained;

defensive teams should not be tipped-off in advance;

monitoring teams should not know the testing is happening (to test their capabilities);

defensive mechanisms should not be modified based on tester's plans;

testing should be done by sufficiently skilled persons who are fully independent from the team that built and maintain the system under test, and should not be used for routine testing (and compliance); and

[44]  scope, tests and results are transparent to JCRA.

5. An example of this type of testing is Ofcom's TBEST scheme 4647. In considering threat intelligence-led penetration testing schemes, Public Telecoms Providers should have regard to appropriateness of those schemes and providers.

Tests against equipment locations

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

Guidance

7. Testing should ensure that the physical security of the buildings, server rooms and network equipment that provide services into Jersey meet best-practice standards. Advice produced by the National Protective Security Authority (NPSA) should be consulted for physical and personnel-related security.[45]
8. This Code of Practice does not cover safety planning such as fire drills, as these should be covered by the general planning and health and safety requirements for buildings.

14. Assistance

1. This chapter provides guidance for Public Telecoms Providers on the measures to be taken in accordance with Article 15 of the Order to reduce the risk of security compromise by seeking and providing appropriate assistance.
2. Article 15 of the Order is set out below.

3. could cause a connected security compromise in relation to service provider B's public electronic communications network or public electronic communications service.

(5)  A network provider or service provider must, if necessary to reduce the risks of a security compromise occurring in relation to the provider's public electronic communications network or public electronic communications service, request another person to give any assistance that paragraph (3) or (4) requires the other person to give.

Key concepts for understanding the requirements Sharing information

14.3 In certain circumstances it is appropriate for different Public Telecoms Providers to receive information from Public Telecoms Providers serving the British Islands which would help to reduce the risk of security compromises occurring (Article 15(1) of the Order). Whilst not required by Article 15 of the Order, Public Telecoms Providers may also consider whether it is appropriate in certain circumstances to share information with other types of bodies/organisations such as:

educational institutions;

UK and Jersey security organisations;

JCRA;

JCSC; and

UK and Crown Dependency government cyber security experts.

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

Guidance

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

Section 3: Technical guidance measures

Specific technical measures to be taken by Public Telecoms 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 Order, including Articles 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 Article of the Order will depend on the facts of each case. The mapping of measures to Articles of the Order in this section is therefore only indicative and non-exhaustive.

for SS7 networks, and equivalent messages  8(6) shall be blocked for other signalling

protocols such as Diameter[52], GTP[53]

Interconnect[54] and SS7/SIGTRAN[55].

M7.02  When sent over signalling networks, the  4(1)(a),(b)

external exposure of customer data,  4(2)(a),(b) customer identifiers and network topology  4(4)(a) information shall be minimised.  4(4)

6(1)

8(1) 8(2)(f) 8(5)(a)

M7.03  Public Telecoms Providers shall have in  3(3)(e) place the means for recipients of their BGP  4(2)b

routing updates to validate the BGP routing  4(4)(b) update originated from the legitimate owner. 6(1)

6(2)(a) 8(1)

M7.04  Where the necessary information is  3(3)(e) available, Public Telecoms Providers shall  4(1)(a)(b)

validate that any BGP route updates they  4(2)(a)(b) receive have originated from the legitimate  4(4)(b) owner.  6(1) 6(2)(a)

8(1)

Third party supplier measures 2

M8.01  During procurement of equipment, prior to  3(3)(a),(b),(d),(e)

contract award, Public Telecoms Providers  3(5)

shall ensure the security functionality of all  7(1)

equipment has been tested.  7(4)(a)(i)

10(1)

10(2)(a)(b)

10(4) 13(2)(d)(i)(ii) 14(1)

M8.02  During procurement of equipment, prior to  3(3)(a),(b),(d),(e)

contract award, Public Telecoms Providers  3(5)

shall ensure negative testing and fuzzing of  7(1)

equipment interfaces has been performed.  7(4)(a)(i)

13(2)(d)(i),(ii)

14(2)

Customer Premises Equipment

M9.01  Once the CPE has been configured at the  4(4)(c)

customer site, it shall only contain  8(5)(c) credentials that are both unique to that CPE,

and not guessable from CPE metadata.

M9.02  The Public Telecoms Provider shall ensure  4(4)(c)

that all CPEs provided to customers are still  12 supported by the network equipment

supplier. For any Public Telecoms Provider - provided CPEs that go out of third party

supplier support, customers shall be

informed prior to, and once the equipment

goes out of support, and proactively offered

a replacement as soon as reasonably

practicable. This shall apply only whilst the

Public Telecoms Provider provides the

associated service.

M9.03  WAN CPE management interfaces shall  3(3)(a)

only be accessible from specified  4(4)(c) management locations (e.g. URL or IP

address).

M9.04  Management of the CPE shall use a secure  3(3)(a)

protocol (e.g. TLS 1.2 or newer)  4(4)(c) M9.05  By default, the CPE's customer-facing  3(3)(a)

management interfaces shall only be  4(4)(c)

accessible from within the customer's

network.

M9.06  By default, all unsolicited incoming  3(3)(a)

connections towards the customer's network  4(4)(b),(c) shall be blocked by the CPE.  9(2)(c)(iii)