As we head towards the next round of regulatory returns being sent to providers of Public Electronic Communications Networks and Services (PECN and PECS) by Ofcom, you can guarantee that supply chain assurance will be a key focus.
Providers with relevant turnovers within their PECN and PECS of more than £50m p.a. will very likely have been sending questionnaires, contracts (or perhaps both) to their suppliers, with varying requirements within them requesting areas which are intended to equal ‘TSA compliance’.
The question remains, however, whether the level of effort required from suppliers in answering different questions and meeting varied commitments being sent via multiple providers is proportionate.
What are the requirements placed on providers regarding their supply chain?
In short, technical guidance measure M2.06 within the Code of Practice makes it clear that the burden on complying with the obligations of the Code of Practice sits with the provider themselves.
The infrastructure used to support a provider’s network shall be the responsibility of the provider, or another entity that adheres to the regulations, measures and oversight as they apply to the provider (such as a third party supplier with whom the provider has a contractual relationship). Where the provider or other entity adhering to the regulations has responsibility, this responsibility shall include retaining oversight of the management of that infrastructure (including sight of management activities, personnel granted management access, and management processes).
This is backed up by key concept 6.7, which states that
It should also be noted that public telecoms providers are ultimately responsible for the security of their networks and cannot outsource this responsibility to third parties. Where providers do outsource aspects of operations to a third party, responsibility to comply with the obligations contained within new sections 105A-D of the Communications Act 2003, and the obligations set out in the regulations, remain with the provider. The provider therefore needs to have sufficient internal capacity to meet those obligations.
Note the points above, highlighted in bold. The provider still needs to retain sufficient internal resources to meets its own obligations (this is a point missed by many who think they can outsource key controls to external parties without showing they are ultimately in control).
What is expected when managing the supply chain?
Within the regulations, regulation 7(1) is a key point of reference
A network provider or service provider must take such measures as are appropriate and proportionate to identify and reduce the risks of security compromises occurring in relation to the public electronic communications network or public electronic communications service as a result of things done or omitted by third party suppliers.
Regulation 7(2) provides further clarity when looking at what is a third-party supplier, stating:
In this regulation, “third party supplier”, in relation to a network provider or service provider, means a person who supplies, provides or makes available goods, services or facilities for use in connection with the provision of the public electronic communications network or public electronic communications service.
Again, the point highlighted in bold is a crucial one, whereby it’s only where the supplier is engaged in connection with PECN/PECS that the requirement is to manage them in conjunction with the provider’s TSA obligations.
This point is further made within key concept 6.37, which states
Where a network provider supplies its services to a different provider in a higher tier, it is expected that only the part of the network or service that is being supplied needs to meet the security standards of the provider in the higher tier. Where this is the case, providers also need to ensure that the relevant parts of the network or service are sufficiently segregated from the rest of their operations. This will avoid the risk of bringing the wider operations of the provider in a lower tier into the scope of regulation 7(4)(a)(ii) where the third party supplier is itself a network provider and is given access to the primary provider’s network or service or to sensitive data, takes appropriate measures…which are equivalent to the measures that the primary provider is required to take in relation to the primary provider’s network or service and having to hold more of their operations to the security standards of a higher tier.
I’ve taken the liberty of highlighting the key parts above again, and this is important – third-party suppliers only need to comply with the requirements of a higher tier provider in the parts of the suppliers network and service which are involved in the support of the provider’s PECN and PECS (where they can show they have segmented their other networks/services).
Scoping is important for third-party suppliers
It’s obvious then than the third-party suppliers who take the time to scope what they provide to their customers, will be able to constrain the compliance requirements of the Code of Practice (and therefore burden) to where they provide services to their providers (where it impacts their PECN and PECS) – if they have shown they can show they have segregated it.
It’s important to understand the services which are provided to customers, including the key assets which underpin them. In the event that these services aren’t understood to this level, there is a danger that any compliance activity is much greater in terms of effort than required.
By taking the time to look beyond the services being bought and looking at the types of suppliers, you really do start to look at the correct challenges (as shown in Figure 1 below).
We see a number of providers asking their MSP suppliers to assess vendors using the NCSC Vendor Security Assessment (VSA), when the reality is that these vendors are often used by the providers themselves. It’s much easier to pool resources when asking vendors to respond to compliance requests.
Equally, when looking at Cloud Service Providers (CSPs) providing SaaS services, it’s likely that those providers are being hosted within larger CSPs such as Google, AWS and Microsoft. Looking at this allows the CSPs (who are some times also vendors), to look at the ‘security in the Cloud’ as per figure 2 below (more details on managing risks in the Cloud are in my article here):
Also, vendors can have multiple types of supplier within them – it’s typical that vendor could also have a 3PA line of business. The key point to be made is that a supplier can have multiple personas and assessment of them should take these into account when scoping the compliance activities.
For more details on scoping, and the key assets, I’ve covered this in more detail in a previous article I have written at this link.
Once you have defined your scope, you need to implement your governance, which is detailed here.
What are the types of third-party suppliers which are impacted?
The different types of third-party suppliers can be defined as follows:
- Vendors – suppliers who make hardware/develop software for providers to use (this includes physical and virtual functions, regardless of where they are hosted). These suppliers will provide services such as network equipment/applications which are Security Critical Functions (SCFs) and/or Network Oversight Functions (NOFs), virtual network functions (if SCF/NOF), CPEs and SIM cards.
- Third-party Administrators (3PAs) – suppliers who provide professional services to assist providers with maintaining the PECN and PECS (this could also be 2nd/3rd line support of services which vendors provide to their customers). These suppliers will provide services such as 2nd/3rd line support, design and implementation and other professional services – more details on specific compliance requirements to 3PAs is at my article here.
- Managed-Service Providers (MSPs) – suppliers which deliver services (such as networks, applications, infrastructure and security) via ongoing and regular management, support and active administration on customers’ premises, in their MSP’s data centre (hosting), or in a third-party data centre. These suppliers will deliver services such as wholesale networks, Neutral Host data centres for mobile networks, managed SOC and vulnerability scanning.
It is possible to get into the weeds with the above definitions, but collecting them into these areas allows for third-party suppliers to get a feel for what they are likely going to have to do.
What are providers expected to do to show they are managing their third-party suppliers?
The requirements from the Code of Practice are mainly structured in four phases for supply chain assurance, linked to the evidence timescales within the Code as shown below:
We’ll now look at each phase in turn, and detail how this impacts providers, vendors, 3PAs and MSPs.
Phase 1 – Risk identification and scoping suppliers and equipment
Phase 1 sets the foundation for managing third-party supplier risks. Providers of PECN/PECS (providers) must demonstrate governance over their supply chains by performing and documenting a structured risk assessment before entering into contracts with third-party suppliers (the later phases look at other stages of the contract lifecycle).
The following outcomes are expected to be delivered by providers within phase 1.
This includes identifying risks related to unauthorised access, offshoring, resilience, and procurement oversight – particularly in relation to Security Critical Functions (SCFs), Network Oversight Functions (NOFs), and sensitive SIM data. An important component in assessing the risks will be working out the dependencies between the assets and also the user and network data which flows across connections between them. These dependencies and data very much link into the later phases.
In parallel, providers must assess the risks associated with equipment and software, ensuring that vendors (e.g. those supplying CPEs, SIM cards, or physical/virtualised network functions) can demonstrate secure lifecycle practices. These include clear support policies, patching capabilities, secure development environments, product hardening, and transparency around vulnerability management.
SIM suppliers are specifically expected to provide assurance over cryptographic key handling and security algorithm use, with providers reviewing SIM risk at least annually and maintaining a plan to phase out insecure SIMs. This phase is regarding the ability of providers of PECN/PECS (providers) to show they have the governance to manage their supply chains.
Phase 1 part one – Review if the risk of using all third-party suppliers is assessed and controlled
Providers must assess the risks of using all third-party suppliers (vendors, MSPs, and 3PAs) in relation to the PECN/PECS before contract award (the following phases look at other stages of the contract lifecycle). These risks include:
Risks from unauthorised access:
- Risks from unauthorised access by third parties to Security Critical Functions (SCFs) and Network Oversight Functions (NOFs).
- Risks from unauthorised access by third parties to sensitive SIM card data.
- Risks from unauthorised changes to SCFs and NOFs by third parties.
Offshoring risks
- Risks from SCFs and NOFs being operated from insecure or poorly controlled locations.
- Risks from holding large volumes of UK customer data (more than 100,000 users) outside of the UK.
- Risks from operating key network management or service operations outside of the UK.
- Risks from keeping network security and audit logs outside of the UK
Resilience risks
- Risks from the loss of availability or access to SCFs and NOFs due to third-party failure or disruption.
- Risks to end users caused by the loss of SCFs and NOFs if third parties fail.
- Risks from suppliers/vendors no longer being able to support SCFs and NOFs (e.g., end of life, supplier failure).
- Risks from over-reliance on staff, equipment, or data that are located outside the UK, leading to potential security, operational, or resilience issues.
- Risks from the loss of first and second line support where offshored technical expertise becomes unavailable (e.g., political issues, market exit)
Procurement risks
- Risks arising from procurement decisions about UK networks’ hardware and software being approved by overseas staff, without proper security oversight.
Providers must retain documented evidence of all risk assessments undertaken.
Phase 1 part two – Review if the risk of using vendors is assessed and controlled
Providers must assess the risks posed by vendors of equipment (including virtual functions, SIMs, and hardware) and ensure they align with expectations of secure product development and lifecycle management suggested by the NCSC Vendor Security Assessment (VSA). Vendors will likely be required to provide a response to these areas (or at least work out how their existing compliance is equivalent).
Key risk areas from the VSA include:
Product lifecycle management
- Products must have clear support timelines and end-of-life (EOL) policies.
- Software must be properly maintained throughout its lifecycle with timely security updates.
- Version-controlled code repositories must log all code changes, including who made them and why.
- Providers should verify that third-party components (e.g. libraries) are inventoried, patched, and supported throughout product life.
Product Security Management
- Products must be developed “secure by default” using a Secure Development Lifecycle (SDL).
- Only supported and safe libraries should be used, with no unsafe functions.
- Codebases must be simple, well-commented, and free of hidden debug features.
Product Development and Build Environments
- Development and build systems must be segregated from corporate networks and hardened against external threats.
- Access to the internal code base must be strictly controlled by role.
- Code must be independently reviewed before acceptance.
- Builds must be automated and reproducible over time.
Exploit Mitigations
- Modern memory protections (e.g. DEP, ASLR, heap protections) must be implemented.
- Code must run with the least privilege required.
- Vendors must maintain a roadmap for future security enhancements.
Secure Updates and Software Signing
- Software/firmware must be digitally signed and verified before execution.
- Updates must use secure, mutually authenticated channels.
- Secure boot and hardware root of trust must be implemented.
- Debug ports must be disabled in production.
Security testing
- Products must undergo rigorous security testing (positive, negative and fuzzing).
- Testing must be automated and part of the build process.
- Independent external testing is required on major releases.
Secure management and configuration
- Products must default to secure configurations and support hardening.
- Only secure protocols (e.g. SSH, HTTPS) should be enabled by default.
- No hidden administrator accounts or hardcoded credentials.
- Vendors must document security controls and deployment guidance.
Vulnerability and issue management
- Vendors must maintain transparent, efficient vulnerability management processes.
- Security patches must be deployed rapidly, with root cause analysis performed.
- A Product Security Incident Response Team (PSIRT) must be in place.
In addition to the VSA, additional areas are to be considered for SIM card vendors to ensure that:
- SIM key protection is be verified and secured in storage and transit.
- Providers conduct annual reviews of SIM security profiles, cryptographic algorithms, and supply chain handling practices.
- Plans are in place to retire SIMs using deprecated security mechanisms.
Phase 2 – Secure procurement and configuration of equipment
Phase 2 builds on the phase 1 assessments by requiring providers to implement technical and procedural controls to manage the risks previously identified.
For providers, this includes ensuring that testing (i.e. positive, negative, and fuzz testing) of all equipment interfaces is conducted before procurement is finalised, prioritising security in purchasing decisions, removing default credentials, hardening device configurations, and ensuring effective logging and patching regimes are in place. SIM card security requirements also deepen, requiring strict controls over credential storage, secure OTA management, and vendor audits.
The following outcomes are expected to be delivered in phase 2 by providers.
For vendors, phase 2 sets clearer expectations around evidence provision. Vendors must support repeatable, independent security testing, provide timely security patches separate from feature upgrades, and offer products that can be securely deployed by default. SIM vendors in particular must ensure that their manufacturing, credential handling, and OTA processes meet or exceed industry best practices such as those in the GSMA SAS.
Phase 2 part one – assuring services
Providers must:
Validate security before procurement
Providers must ensure that equipment (physical and virtual) undergoes robust security testing prior to contract award. This includes:
- Positive security functionality testing.
- Negative testing and fuzzing of equipment interfaces.
- Independent third-party testing that is repeatable and directly applicable to the provider’s deployment.
- Documenting how test results inform procurement decisions, especially for SCFs.
Prioritise security during procurement
Security must be a significant factor in determining procurement outcomes for Security Critical Functions. This must include:
- Consideration of measurable improvements to network security based on available security evidence.
- Avoiding over-reliance on equipment or suppliers where support is limited or uncertain.
Track and manage deployed equipment
Providers must:
- Maintain accurate records of all deployed equipment.
- Conduct annual assessments of exposure if suppliers are unable to support that equipment.
- Maintain plans for equipment refresh or replacement based on support status and associated risks (building on phase 1 resilience risks).
Apply secure defaults and logging
Providers must:
- Remove or change all default passwords and disable unencrypted management protocols wherever possible.
- Where unencrypted protocols cannot be disabled, implement mitigating controls.
- Ensure all security-relevant logs are enabled and forwarded to logging systems.
Prioritise patching over features
Security patches must be prioritised over functionality upgrades, particularly where vulnerabilities affect externally facing or critical systems.
Ensure secure SIM card assurance
Providers must:
- Include SIM-related risks in procurement assessments (as initiated in phase 1).
- Store SIM credentials and transport keys only in secure systems.
- Ensure all SIM data is protected throughout its lifecycle, whether in fixed-profile or modifiable formats.
- Limit SIM OTA (Over-The-Air) updates to trusted sources.
- Ensure that new SIM profiles (e.g. K/Ki) are introduced within the first year where possible, and that default algorithm parameters are not used.
- Independently audit the security of SIM vendors (e.g. via GSMA SAS) and maintain annual reviews of SIM security.
Phase 2 part two – implications for suppliers (mainly vendors)
Vendors must expect to provide evidence or implement the following as a result of provider obligations:
Security testing and transparency
Vendors must support independent testing of their equipment and be able to demonstrate the repeatability and relevance of those tests for each deployment. They should also expect requests to support fuzzing and negative testing.
Support and lifecycle clarity
Vendors must clearly define the support lifecycle for all products and be able to demonstrate ongoing support, particularly for EOL equipment still in service. They must be transparent about any risks that may arise from unsupported products.
Secure configuration expectations
Vendors should ensure their products:
- Come pre-configured securely (‘secure-by-default’).
- Allow easy removal of default accounts and passwords.
- Warn about, or block, the use of insecure protocols.
- Provide clear documentation to help providers maintain secure operation.
Logging and hardening
Equipment must support:
- Full logging of security-relevant activity.
- Easy integration with provider logging systems.
- Secure hardening processes and documentation to support enforcement by the provider.
SIM security controls
SIM vendors must:
- Adhere to strong lifecycle protections for sensitive SIM data.
- Demonstrate secure management of cryptographic keys and OTA update mechanisms.
- Undergo independent audits and provide secure profile management capabilities.
Phase 3 – Implementing agreements and effective oversight
Phase 3 transitions the focus from initial supplier assessment and technical control to formalising accountability, enabling continuous oversight, and safeguarding operational resilience. It divides into two key areas: provider responsibilities (including contractual governance) and supplier obligations.
The outcomes expected from providers in this phase are shown below.
While many providers assume these measures only apply from 2027, that’s a common misconception. As outlined in my earlier article, these obligations come into scope as soon as a contract becomes ‘new’ or 2027 (whichever is the sooner) – ‘new’ including material changes to existing services (e.g. the service expands, the equipment changes, or the supplier relationship materially evolves).
Providers must get their house in order before that happens. The areas below completes the progression from risk identification (Phase 1), through technical controls (Phase 2), towards formal governance.
This is the challenge which providers responding to the latest regulatory return will face as they will now be asked to provide evidence of activities which should already be in place. Tier 1 providers were expected to have these activities in place for Q1 2024 and tier 2 by Q1 2025.
Phase 3 part one – Providers can’t just rely on contracts – they have to manage what their suppliers do
It’s commonplace for providers to solely rely on contracts but they have things they have to within this area too (which cannot be outsourced within a contract). Before any contractual agreements can be relied upon, providers must show they have direct control over their network, data, and suppliers by:
- Maintain an accurate inventory of third-party suppliers, their personnel with access, and the scope of access granted.
- Control all privileged access through provider-owned mediation points and tightly monitored interfaces.
- Limit and monitor third-party access to only what is essential for their function.
- Log all privileged access events and retain records of third-party activity.
- Safeguard shared operational data – only allow encrypted, authenticated, and auditable transfers, with deletion once no longer required.
- Retain sufficient in-house expertise and technical capability to re-tender services or bring them in-house if required.
- Review, authorise and monitor all data held offshore and be prepared to repatriate critical functions to the UK if needed.
- Integrate supplier responses into broader incident response planning, as required under later compliance phases.
- Ensuring that all assets remain secure and compliant throughout their life – continuing to meet procurement, support for patches, secure configuration and hardening requirements.
These responsibilities make it clear that providers cannot outsource accountability (although I would hope that would be clear to you now). Even with outsourced operations, providers remain fully responsible for compliance under the TSA.
Phase 3 part two – Setting agreements with suppliers
Once providers are confident in their own oversight capabilities, they must setup agreements with their third-party suppliers. The types of agreements to be met must consider how the supplier provides a service (in some cases they may provide more than one of the roles below).
The agreements in general must:
- Define a shared responsibility model that sets out who secures what – and what good looks like. We have created one in figure 8 later on in this article
- Require incident disclosure within 48 hours, cooperation during investigation, and root cause analysis within 30 days.
- Include break clauses to enable contract exit if the supplier fails to address security issues.
- Ensure that the sub-contractors of suppliers are assessed by them to see if they are compliant where they need to be.
- Mandate cooperation with audits, and require suppliers to adopt controls equivalent to the provider’s (where they are relevant to the providers PECN/PECS).
For vendors supplying equipment, software, physical/virtualised functions, or SIMs, providers must contractually ensure:
- Security declarations are shared, signed at board level, and aligned with the NCSC’s Vendor Security Assessment (VSA) framework (this can be achieved using GSMA SAS for SIM vendors).
- Up-to-date secure deployment guidance is provided, with segregated patches for security vs. features.
- Disclosure of all significant third-party components and their support timelines, including open-source libraries.
- Adherence to modern development, testing, and update practices, as covered in phase 1 and reinforced in phase 2 (e.g., fuzz testing, secure boot, signed updates).
For 3PAs (e.g. design and support partners with access to the management plane), contracts must enforce the following:
- Strict per-provider segregation – including logically isolated PAWs, admin domains, and management environments. NB – PAWs are very much a work in progress at the moment, so whilst ‘browse-down’ is a concept worthy of inclusion it’s important to not be too specific in this regarding PAW.
- Security enforcement at the boundary between the 3PA and provider, with mediation and monitoring in place.
- Controls to prevent cross-provider impact – even within the same umbrella company.
- Audibility of privileged activity, including log provision related to any access into the provider’s network.
- Participation in TBEST or equivalent assessments, where required.
For MSPs delivering supporting networks, platforms, or core functions the agreements will have to ensure:
- Contractual enforcement of provider-level security obligations – including equivalence with the relevant areas of the Code of Practice where MSPs themselves act as operators.
- Full transparency and cooperation with security operations, including patching, threat detection, and response.
- Rigorous onboarding, off-boarding, and oversight of MSP staff accessing sensitive functions.
- Assurance of ongoing access and resilience – including fallback plans where overseas operations may be disrupted.
Phase 4 – Making the supply chain resilient
Earlier phases dealt with assessing, controlling, and governing third-party risk. Phase 4 builds on previous requirements to identify and manage assets which are no longer supported, providing the specific conditions in which provider may continue to use them.
The final outcomes for phase 4 are shown below.
Managing Risk When Equipment Becomes Unsupported
Providers must maintain control and security throughout the entire lifecycle of their network assets, and when end of life (or in the recent case of DZSi, when the vendor is no longer operating) must only continue operating the assets under specific conditions where:
- Configurations remain stable, with rare, reviewed changes.
- Interfaces are monitored and their use explainable, or else present no realistic threat to the broader network.
- Exposure is limited to the minimum and over secure networks.
This builds on previous lifecycle and vendor controls from phases 1 and 2 – but now moves into ensuring the live service is resilient. Keeping the assets in operation is only acceptable if you can prove it won’t hurt you.
SIM Security in Live Operation
Another challenge is the exposure of SIMs in customer devices. After deployment, providers must safeguard SIMs by blocking and recording all OTA messages to SIMs, except those from explicitly allowed sources.
This continues the SIM key protection and lifecycle management requirements first introduced in phase 1 and extended in phase 2, reinforcing ongoing security after deployment.
The unintended consequences of failing to prepare
Unfortunately I see some providers looking to place everything in their agreements even though they don’t apply to their suppliers (or respect the staged approach they have been given). Even worse is where the provider implements contracts which only stop at phase 3 (the M10.x measures).
This means that the provider hasn’t reviewed the entire Code of Practice, as there are a number of requirements planned for evidencing in Q1 2027!
The shared responsibility model of outcomes from our analysis is shown below, yet we still see providers thinking they can put everything into contracts. We are also seeing suppliers waiting for the provider to come to them and reacting rather than preparing.
By taking the time to understand where providers are responsible, and where they are reliant on their suppliers, the picture becomes clearer. Knowing what providers are having to comply to (and when), it becomes easier for suppliers to understand how their providers are reliant on them (remember in some cases, the supplier is also a provider).
Providers must start preparing their governance now, especially if contracts signed today will still be in place. Otherwise, they risk locking themselves into agreements which don’t cover them for the entire compliance journey (although this is equally true if they haven’t considered if their contracts apply to their suppliers).
These additional requirements include the following for providers:
Location-based access controls
- Monitoring and oversight tools (e.g. speech/data collection) must not be accessible from restricted countries listed in the Annex to the Electronic Communications (Security Measures) Regulations 2022.
In-house capability
- Retaining staff with the skills to identify and resolve issues, even when using third-party suppliers or administrators.
Management plane segregation
- Segregating access by third-party supplier, and between access/core network domains – even where a single orchestration platform is used.
Threat intelligence and monitoring
- Using dedicated resources to analyse network activity (in-house or independent).
- Avoiding outsourcing threat hunting or audit to those operating the network, to maintain impartiality.
Data risk management – when user or network data is stored offshore:
- Maintaining a list of storage locations.
- Managing the risks, including local data protection laws, as part of their formal risk management processes.
Operational fallback planning
- Being capable of bringing critical outsourced functions back into the UK if international links fail – requiring contingency arrangements from both operational and contract perspectives. NB – This point is more pertinent given recent threats to subsea cables and power outages across Portugal, Spain and Southern France in April 2025.
Summary – There is no ‘TSA compliance’ white knight coming to your rescue, the supply chain is a mutual responsibility!
Whilst this is a long and winding article, I’m hoping it’s clear that there are no benefits from providers taking generic approaches to contract and suppliers just signing up to these agreements.
Key Takeaways for Providers and Suppliers:
For Providers (PECN/PECS operators):
- You can outsource the work, not the responsibility
- Start early – “new” contracts are already in scope
- Contracts are part of the answer – not the whole answer
- Review your governance before you finalise contracts
- Think long-term resilience, not just short-term compliance
Let your agreements manage the right risks!
For Suppliers (Vendors, MSPs, 3PAs):
- Not confirming your scope means you cannot defend your position
- Tailor your compliance to what you do for your customers
- Prepare your compliance evidence now or prepare for the deluge of contracts and questions from your customers
- Doing it right sets you apart