The telecoms security code of practice 2026 is a revised technical and organisational rulebook under the Telecommunications (Security) Act 2021, published as a draft on GOV.UK (GOV.UK, 2026 draft). The draft tightens cloud, API and signalling controls, explicitly references eSIM and the GSMA Security Accreditation Scheme (SAS), and fixes compliance tranche windows in the published draft (Draft Revised Telecommunications Security Code of Practice - GOV.UK PDF), which operators should use for programme and capital planning.
- Key change: PAW principles become explicit duties requiring evidence, named roles and board attestations across networks and suppliers.
- Cloud and API: New controls demand auditable secure configuration, vendor assurance and API lifecycle controls for operators and suppliers.
- Signalling and eSIM: SS7, Diameter and 5G signalling protections are prescriptive, and the GSMA Security Accreditation Scheme (SAS) expectations are referenced for eSIM assurance.
- Tranche dates: The draft sets compliance tranches and target windows in the published document (Draft Revised Telecommunications Security Code of Practice - GOV.UK PDF), which operators should use for capital and programme planning.
What changed in the 2026 revised Telecoms Security Code of Practice?
The revised Telecommunications Security Code of Practice is a reworked technical and organisational rulebook issued under the Telecommunications (Security) Act 2021, clarifying PAW principles, cloud and API controls, signalling duties and new tranche dates; the draft revision is published on GOV.UK. The telecoms security code of practice 2026 tightens supplier and cloud requirements and adds explicit controls for eSIM and GSMA Security Accreditation Service (SAS) integration.
The 2026 revision refocuses the Code on practical controls: PAW principles, detailed cloud and API guidance, signalling protections, eSIM/GSMA SAS expectations and corrected tranche dates to 2028 and 2029.
Summary of headline changes
PAW (Protect, Authenticate, and Work) principles are formalised as core design requirements, cloud guidance expands sections 6.22 to 6.30 to require evidence of secure configuration and vendor assurance, and API security receives new prescriptive controls in sections 7.11 to 7.26. The Code now names eSIM and GSMA SAS expectations and makes automation a standard control function. These changes are explicit in the draft revised Code on GOV.UK, which is the authoritative text for implementers (GOV.UK).
Corrected tranche dates and signalling updates
The draft replaces the floated December 2026 and March 2027 dates with confirmed tranches in March 2028, December 2028 and December 2029; that matters for tiered compliance planning and capital cycles. Signalling plane protections are expanded (see sections 2.79 to 2.82) to require stronger injection controls and opcode filtering for SS7, Diameter and 5G signalling, aligning Ofcom evidence expectations with operational monitoring and logging.
How we sourced and checked each change
At CyPro, we mapped every clause of the draft revised Code against the Telecommunications (Security) Act 2021 and the published draft PDF on GOV.UK, plus sector-level threat context from ENISA. ENISA’s Threat Landscape 2025 helps explain why signalling and cloud controls are emphasised in the draft (ENISA, 2025). Our comparison reconciles the Code text changes, the consultation notes and the corrected tranche timetable published with the draft.
The practical implication for UK operators is that security programmes must now include auditable cloud configuration evidence, API lifecycle controls, verified eSIM supplier assurance and signalling hardening plans before the 2028 and 2029 compliance tranches. For a focused read of the full change set, see our detailed breakdown of "What changed in the 2026 revised Code of Practice" service page.
What are the PAW principles and how did the 2026 revision change them?
The PAW principles are Protect, Assure and Where Appropriate, and the 2026 revision turns PAW from high-level aims into testable outcomes that operators must support with documented controls, artefacts and risk-based decisions.
The Draft Revised Telecommunications Security Code of Practice 2026 specifies the evidence Ofcom expects for each PAW pillar: Protect, which focuses on technical baselines, access controls and configuration records; Assure, which focuses on monitoring, testing and remediation records; and Where Appropriate, which covers risk assessments and formal exception approvals. The draft states regulators will seek artefacts rather than policies alone when assessing compliance (Draft Revised Telecommunications Security Code of Practice - GOV.UK, 2025).
ENISA’s NIS Investments 2025 highlights that many organisations face staffing and budget pressures when building assurance programmes, which is consistent with the Code’s emphasis on a focused set of demonstrable artefacts rather than exhaustive prescriptive lists (ENISA, 2025).
What operators must do now
At CyPro, we translate the telecoms security code of practice 2026 PAW outcomes into an evidence map so teams can show the exact artefacts inspectors will expect. An evidence map links each Protect, Assure and Where Appropriate outcome to specific items: network diagrams and configuration baselines for Protect, SIEM or monitoring logs and penetration-test reports for Assure, and recorded risk decisions and exception approvals for Where Appropriate. Our approach reduces rework during inspections and clarifies who owns each artefact.
Practical next steps
- Run an evidence gap analysis mapping existing artefacts to PAW outcomes, prioritising configuration baselines, patch logs and supplier attestations.
- Update procurement and contract templates to require supplier evidence and audit rights, and centralise artefact storage for rapid reviewer access.
- Focus initial assurance on a short list of high-risk services, then expand as capability and budget allow. For detailed changes, see our guide on What changed in the 2026 revised Code of Practice.
How does the revised Code change cloud security requirements (clauses 6.22 to 6.30)?
Clauses 6.22 to 6.30 add explicit cloud requirements: shared responsibility evidence, data residency signalling, hardened API controls and supplier assurance evidence for third‑party cloud services.
The revised clauses require operators to show how responsibilities are split with cloud providers, to signal where data is held and processed, and to demonstrate continuous assurance over cloud configurations and APIs. This affects supplier contracts, incident reporting and audit evidence under the Telecommunications (Security) Act 2021. The telecoms security code of practice 2026 makes assessorable expectations explicit rather than advisory, so a policy statement alone will not suffice.
What Ofcom will expect from operators using third‑party cloud providers
Ofcom will expect operators to hold contractual evidence that maps shared responsibilities, plus technical evidence that configuration baselines and IAM controls are enforced. Operators should be ready to show access logs, API change records and data residency flags tied to customer flows. The NCSC annual review 2025 emphasises that visibility into cloud APIs and logs is a recurring gap for infrastructure sectors.
How supplier contracts and assurance need to change
Operators must update supplier contracts to require continuous evidence: configuration reporting, attestation of encryption in transit and at rest, and notification times for incidents. Contracts should mandate proof of secure CI/CD pipelines for cloud-native functions and API hardening. Where a supplier cannot produce continuous evidence, operators will need compensating controls or migration plans under the telecoms security code of practice 2026.
Practical steps to close gaps before tranche deadlines
Start by mapping cloud services to responsibilities, then add data residency flags to asset inventories and enforce API allowlists and schema validation. Run automated configuration scans and store tamper‑evident attestation artefacts for audits. Given the rise in intrusions against communications infrastructure reported in the 2025 industry data, operators should prioritise API monitoring and log retention policies now, not later; see the 2025 Data Breach Investigations Report for trends affecting telecoms.
For practical alignment, see our explainer on what the Telecommunications (Security) Act actually requires and how the Code maps to those duties: What the Telecoms Security Act actually requires.
What new API security duties appear in clauses 7.11 to 7.26?
Clauses 7.11 to 7.26 require operators to treat APIs as first-class assets: maintain an inventory, enforce strong authentication and authorisation, apply rate limiting and schema validation, run pre-production and runtime testing, and keep supplier assurance evidence.
Inventory and classification
The draft revised Telecommunications Security Code of Practice 2026 makes inventories mandatory for APIs, including purpose, data sensitivity, and hosting location. Ofcom expects inventories to flag APIs that process personal data subject to UK GDPR, and to record whether APIs are managed in-house or by suppliers. The draft Code itself notes that operators must show evidence of these inventories to Ofcom on request (Draft Revised Telecommunications Security Code of Practice - GOV.UK).
Authentication, authorisation and runtime controls
Clauses 7.14 to 7.18 require multi-factor or equivalent strong authentication, role-based authorisation (RBAC), and default-deny behaviours for APIs. The NCSC and ICO expectations are reflected in the wording: log authentication failures, retain provenance data, and ensure tamper-evident records for audits. Operators must implement rate limiting and anomalous-traffic detection so that abuse is visible and measurable at runtime.
Schema validation, testing and supplier assurance
The draft Code places explicit duties on schema validation, fuzzing and contract tests before production deployment, plus continuous runtime validation after deployment. Clauses 7.21 to 7.26 extend supplier assurance: operators must obtain evidence that third-party APIs meet the same controls, and record vulnerability management SLAs. Industry incident reporting shows API weaknesses are a frequent exploitation path, so these controls align with ENISA and vendor advisories (VHR20250724 - Mandiant).
In our experience, implementing the telecoms security code of practice 2026 API clauses requires changes across development, procurement and assurance teams: add API entries to asset inventories, update procurement contracts to demand supplier test evidence, and bake schema and contract testing into CI pipelines. That practical shift is what Ofcom will examine during compliance checks.
For practical help mapping these clauses to deliverables, see our Signalling security: SS7, Diameter and 5G duties guidance for related controls and evidence types.
What does the revision say about signalling (2.79 to 2.82) and eSIM/GSMA SAS controls?
Clauses 2.79 to 2.82 require explicit signalling plane protections, including controls to prevent message injection and opcode manipulation, and they introduce concrete expectations for eSIM and the GSMA Subscription Authentication Scheme (SAS). Mobile network operators, MVNOs, signalling vendors and roaming providers must prioritise these controls.
Signalling plane protections added in 2.79 to 2.82
Clauses 2.79 to 2.82 require operators to implement controls that detect and block unauthorised signalling messages, apply opcode filtering, and record tamper‑evident logs of signalling transactions. The revision places emphasis on preventative controls, not just detection, so operators must show opcode whitelists, ingress filtering and integrity checks for SS7, Diameter and 5G signalling gateways. The draft revision aligns these measures with evidence requirements that Ofcom is likely to request during assurance checks, and operators should be prepared to provide configuration snapshots and test evidence on demand.
eSIM and GSMA SAS expectations
The revision clarifies vendor obligations for eSIM management and the GSMA Subscription Authentication Scheme, expecting suppliers to support Subscriber Identity Module provisioning with cryptographic authentication, and requiring documented supplier assurance for SAS implementations. Operators must map eSIM lifecycle controls into asset and supplier inventories, enforce secure provisioning APIs, and retain authentication logs that support forensic review. For guidance on sector analysis and evidence formats, see the NCSC summary of security analysis for the UK telecoms sector and the ICO data security incident trends for recent incident patterns relevant to signalling and subscriber data.
At CyPro, we treat these clauses as a combined technical and contractual task: signalling controls need network rules and evidence, and eSIM/SAS needs supplier assurance and API governance. The telecoms security code of practice 2026 raises the bar on demonstration of compliance, so teams should prioritise configuration baselines, supplier test evidence and retained authentication logs. The practical steps are to add signalling assets to inventories, request GSMA SAS test artefacts from vendors, and build opcode filtering into gateway configurations.
How does the Code treat automation as part of Security Control Functions (SCF)?
Automation is treated as a Security Control Function when it enforces, monitors or reports security controls without continuous human intervention.
The revised Telecoms Security Code of Practice 2026 requires that any automated SCF includes human oversight, auditable logs, fail-safe defaults and formal change control so operators can demonstrate safe, accountable behaviour.
What the Code requires
The Code expects automated SCFs to be auditable, reversible and subject to governance. The Telecoms Security Code of Practice 2026 emphasises recording decisions, retaining tamper-evident logs and keeping a named human approver for enforcement rules. Ofcom and the wider UK regulatory community will look for evidence that automation does not remove operator accountability.
Practical controls to implement
Implement four practical controls: clear human-in-the-loop policies, conservative default actions, immutable logging, and strict change control tied to a configuration management process. The Telecoms Security Code of Practice 2026 also expects roll-back procedures and automated alerts when enforcement thresholds are hit, so humans can intervene before service-impacting actions proceed.
ENISA guidance on secure automation highlights the same risks and mitigation patterns, useful for designing safe automation (ENISA publications). The revised Code links automation governance to supplier assurance and service design, so include automation in supplier contracts and testing evidence, not just internal change records (Draft Revised Code, GOV.UK).
At CyPro, we recommend starting with a pilot: convert one manual enforcement rule into an automated SCF, run it in monitor-only mode for 30 days, then enable enforcement after independent audit and documented rollback plans. That sequencing reduces operational risk and builds the evidence Ofcom will expect when assessing compliance with the Telecoms Security Code of Practice 2026.
Who needs to act and when under the corrected tranche dates (Mar 2028, Dec 2028, Dec 2029)?
This timeline lists the corrected tranche dates and who they affect, with practical next steps for each tier: gap analysis, supplier notices, contractual changes and evidence collection plans.
- , Draft Code published for consultation: Government released the revised Telecoms Security Code of Practice for consultation, setting new controls and later tranche dates, prompting early gap assessments by operators (GOV.UK, 2025).
- , Final Code issued and clarified: Ofcom and the Department for Science, Innovation and Technology confirmed the Code content, removing the floated 2026/2027 tranche dates and signalling later compliance windows for each tier (see CyPro guidance on the Code: Telecoms Security Act hub).
- , Pre-tranche evidence collection begins: Tier 3 and smaller Tier 2 providers should start collecting supplier attestations, eSIM and API artefacts, and signalling inventories to build Ofcom evidence packs.
- , March 2028 tranche deadline: Designated providers in the March 2028 tranche must have completed mandatory baseline controls, including PAW principles and signalling protections, with documented evidence ready for audit.
- , December 2028 tranche deadline: Larger Tier 2 and impacted Tier 1 suppliers must implement advanced supplier assurance, GSMA Security Accreditation Service related controls, and API governance measures.
- , Final tranche and full compliance: All remaining operators must demonstrate full Code compliance, with Ofcom able to assess enforcement and require remediation where evidence is incomplete.
Start evidence collection now: run a rapid gap analysis by tier, notify critical suppliers and schedule contractual updates so evidence aligns to March 2028, December 2028 and December 2029 deadlines.
| Tier / Size | Suggested next-step | Estimated cost range (2026) |
|---|---|---|
| Small Tier 3, local operators | Quick gap analysis, supplier attestations, basic signalling inventory | £6k to £18k one-off |
| Mid-market Tier 2 providers | Full evidence pack, API governance changes, GSMA artefact requests | £25k to £120k phased |
| Large Tier 1 operators | Supplier assurance programmes, independent audits, telemetry upgrades | £150k to £1m+ multi-year |
Plan immediate next steps by tier: run a rapid gap analysis, notify key suppliers and update contracts, then create an evidence collection schedule aligned to the March 2028, December 2028 and December 2029 tranches. Early evidence gathering reduces transitional risk and avoids last-minute remediation.
Frequently asked questions
What is the Telecoms Security Code of Practice and why was it revised in 2026?
Key fact: the Telecoms Security Code of Practice is guidance under the Telecommunications (Security) Act 2021, revised in 2026 to address new risks from cloud, APIs, eSIM and signalling. The 2026 revision reflects Ofcom consultation responses and clarifies obligations for UK telecoms providers, sitting alongside the Act and the Regulations that give it legal force.
Do I need to change supplier contracts because of the 2026 revision?
Key fact: you will probably need contract changes where suppliers handle cloud, API, signalling or eSIM functions. The revision creates new assurance duties in clauses 6.22 to 6.30 (cloud), 7.11 to 7.26 (APIs) and 2.79 to 2.82 (signalling). Start with a gap analysis, legal review and a supplier notice plan aligned to the tranche timetable.
How do the corrected tranche dates affect my compliance timeline?
Key fact: the corrected tranche dates push the first compliance deadline to March 2028 for the highest tiers. Organisations must reschedule projects, procurement and evidence-gathering to meet those dates. Prioritise high-risk signalling and eSIM controls first, then cloud and API updates, and map project milestones to the corrected tranche milestones for audit readiness.
Will Ofcom accept automated controls as evidence of compliance?
Key fact: Ofcom will accept automated controls where they are auditable and subject to human oversight and change control. Operators should provide logs, test reports, roll-back plans and records of supervisory checks. Treat automation as a named Security Control Function and include it in assurance packs so auditors can verify behaviour and governance.
Does the revised Code mandate GSMA SAS for all eSIM use cases?
Key fact: the revised Code expects GSMA Subscription Authentication Scheme (SAS) controls where eSIM provisioning and authentication are in scope, but it does not blanket-mandate SAS for every use case. Start vendor assessments, obtain proof of SAS compliance where relevant and update supplier contracts and evidence folders for functions that fall within the Code's scope.
