Jersey’s New Telecoms Security Law: What It Means and Why Privileged Access Is at the Heart of It?

Why Jersey Acted Now

Jersey’s move is not isolated. The UK Telecommunications Security Act 2021, the EU NIS2 Directive, and a wave of national telecoms security frameworks have all reached the same conclusion over the past five years: the management plane - the layer through which engineers configure, monitor, and control network infrastructure - is the most dangerous attack surface in a modern telecoms network.

The Code of Practice makes this explicit by citing real incidents. A 2021 breach at a major US carrier was traced to the management plane of the core network being directly exposed to the internet. From a single test device left attached to the operational network, an attacker was able to brute-force passwords and access customer data for nearly 50 million accounts within weeks. The vector was not an exotic zero-day. It was poor management-plane hygiene.

The Code also points to the structural risk of ‘browse-up’ architectures, where the same workstations engineers use for email and web browsing are used to administer live network equipment. Phishing a privileged user in this configuration can yield credential theft, remote code execution, and lateral movement - all without triggering traditional perimeter defences.

Structure of the Order: What PTPs Are Required to Do

The Order is implemented through fourteen Articles, each targeting a distinct risk domain. The Code of Practice adds technical depth and implementation guidance to each. The table below provides a high-level orientation before we explore the PAM-relevant articles in detail.

The Management Plane: The Highest-Value Target

Articles 3 and 4 of the Order address what the Code describes as the most dangerous attack surface in a telecoms network: the management plane. This is the set of systems, protocols, and interfaces through which engineers configure routers, provision services, manage network functions, and monitor performance. Its compromise is, in the Code’s own words, likely to have ‘a significant impact upon both the Public Telecoms Provider and Jersey.’

The ‘Browse-Down’ Requirement

The Code mandates a ‘browse-down’ architecture. Administrative workstations must be logically or physically separated from those used for general corporate functions. Engineers cannot use the same device for email and for configuring live network equipment. This is not a best-practice recommendation - it is a legal obligation.

The practical implication is significant. PTPs must either provision separate physical devices for administrators, or implement a robust virtualised separation that provides equivalent security guarantees. Any single device serving dual purposes must be treated as already compromised for the purposes of risk assessment.

Privileged Access Workstations (PAWs)

The Code explicitly references the NCSC’s March 2025 guidance on Privileged Access Workstations and the ETSI technical specification on PAWs. PTPs are required to apply NCSC’s principles in the design and operation of management devices used for high-risk administration.

A PAW is not simply a ‘clean’ machine. The NCSC’s framework covers hardware integrity, boot security, network isolation, application allow-listing, and monitoring. The management plane can only be as secure as the devices that administer it.

Where PAM Fits

A PAM solution is the operational control layer that enforces these architectural requirements at the access level. It provides:

• A jump-server or session proxy that acts as the single point of entry to the management plane, eliminating direct workstation-to-device connectivity
• MFA enforcement at the point of management plane access, not at the individual device level
• Session recording of every administrative action, creating an immutable audit trail
• Time-limited, ticket-linked sessions that expire automatically and cannot be reused
• Agentless connectivity that requires no software installed on target devices

Mandatory MFA, Dual-Control, and Least Privilege (Article 8)

Article 8 is arguably the most operationally demanding article in the Order. It directly legislates specific technical controls around how administrative access is granted, exercised, and recorded. For any PTP that has not already implemented a modern PAM framework, Article 8 will require significant change.

Multi-Factor Authentication: No Exceptions

Article 8(2)(b) requires MFA for any account capable of making changes to security critical functions. The Code adds important nuance: MFA should be applied at the management platform level (the jump server, orchestrator, or PAM console) rather than at each individual host. The second factor must be delivered via a device separate from the one being used for the administrative action. Public channels such as SMS are explicitly called out as ‘not appropriate’ for this use case.

This means PTPs need an MFA solution that is integrated with their PAM platform and that supports secure second-factor channels: TOTP authenticator apps, hardware tokens, or push notifications to a trusted mobile application. SMS-based OTP, while better than nothing, does not meet the Code’s standard for management plane access.

Dual-Control for Significant Changes

Article 8(2)(c) introduces a dual-control requirement: significant or manual changes to security critical functions must be proposed by one authorised person and approved by another before the change is made. This is the ‘four-eyes principle’ applied as law.

In practice, this means PTPs need a workflow-integrated approval mechanism. An engineer wanting to modify a routing configuration or change a firewall rule must raise a request; a second, independently authorised person must approve it before any action is taken on the live network. The Code envisions this as an automated process wherever possible.

Least Privilege: A Legal Requirement

Article 8(4) requires PTPs to limit, so far as is consistent with operation, the number of persons with security permissions and the extent of those permissions. Article 8(5)(e) requires that each user’s access is limited to what is ‘strictly necessary’ for their authorised activities.

This is the principle of least privilege elevated to statute. It has direct consequences for how PAM policies are designed:

• Administrators should have access only to the specific devices and commands their role requires
• Read-only roles should not have the ability to escalate privileges at the device level
• Privileged accounts should be managed, rotated, and revoked by the PAM system, not by the individual
• Temporary or contractor access must be time-bounded and automatically expired

Credential Management

Articles 8(5)(a–c) set out detailed credential obligations: passwords must be managed, stored, and assigned securely; they must be unique per user; they must be revoked when no longer needed; and they must not be capable of being anticipated. The Order explicitly requires avoiding common credential creation processes.

A PAM Password Vault addresses these requirements directly: credentials for privileged accounts are generated by the PAM system to meet complexity requirements, stored in an encrypted vault, never visible to the requesting user in plain text during sessions, and automatically rotated after use or on a scheduled basis.

Geo-Restrictions: A New Dimension

Article 8(6) introduces a geographic restriction that has no precedent in most enterprise PAM deployments: no security permission may be granted to, or exercised by, a person while they are in a country listed in Schedule 2 to the Order. This means PTPs must know where their privileged users are when they authenticate and must be able to enforce access denial based on that location.

Monitoring, Logging, and the 13-Month Obligation (Article 6)

Article 6 is the monitoring and audit article. It requires PTPs to maintain a comprehensive, tamper-resistant record of all access to security critical functions. The obligations are specific and demanding:

• Record who logged in (account or user ID), what they did, when, from where, and why (linked to the specific authorising ticket)
• Identify and record all cases where a person’s access exceeds their security permission
• Produce immediate alerts for all manual amendments to security critical functions
• Analyse all activity promptly for anomalous behaviour
• Retain all relevant data securely for at least 13 months
• Take measures to prevent any activity that would restrict the required monitoring

The 13-month retention period is deliberate. It ensures that changes made on an annual cycle - year-end processes, annual access reviews, seasonal configuration changes - are retained long enough to be correlated with incidents identified later. Attackers who move slowly and quietly can maintain persistence for months before detection; 13 months of logs provides the forensic depth to reconstruct those timelines.

Tamper-Resistant Logs: A Specific Requirement

The Code is explicit that logging data must be protected. Regular administrative users must not be able to alter log collection without triggering high-priority alerts. Administrators who are not responsible for log systems must not be able to view or affect already-collected log data. Monitoring information must be exported from devices as quickly as possible, ideally in real time.

This is a direct challenge to any logging architecture where the same administrator who configures a device also has access to the logs that record their actions. PAM platforms address this by centralising log storage outside the administrative access path, ensuring that session logs are written to a separate, access-controlled repository that the administrator cannot modify.

Linking Sessions to Tickets

Article 6(3)(a) requires PTPs to maintain a record of all access to security critical functions, including the persons obtaining access. The Code adds that monitoring data should ‘link administrative actions to network administrators and on to tickets.’ This is not just a logging requirement - it is an architecture requirement. The PAM system must capture and preserve the chain of: user identity → approval workflow → session → commands executed → network change.

Third-Party Administrators: The Highest-Risk Vector (Article 7)

The Code is unambiguous about the threat posed by managed service providers (MSPs) and third-party administrators (3PAs): they are ‘prize targets for attackers, as they will often have privileged access to multiple networks.’ A single compromised MSP can provide an attacker with a foothold across dozens of PTPs simultaneously.

Same Standard, No Exceptions

Article 7 requires PTPs to ensure that third parties with access to the management plane meet the same security principles as the PTP itself. The Code adds that 3PAs should ‘ideally use the same methods’ - meaning the same PAM platform, the same MFA controls, the same session recording, the same approval workflows.

This has contractual implications. PTPs must have arrangements in place that oblige 3PAs to meet these standards. They must have audit rights that allow spot-checks and ongoing monitoring. And they must be able to fully control and monitor third-party access ‘independently of the third party’ - meaning the PTP’s own PAM system must be the control point, not a system operated by the 3PA.

Multi-Provider PAW Architecture

The Code provides a specific architectural pattern for 3PAs who administer multiple PTPs: trusted PAWs that access securely segregated management environments for each provider. Crucially, the segregation between providers must be maintained at all times - a 3PA administrator must not be able to see or access Provider A’s management environment while working on Provider B’s.

This is the multitenancy use case for PAM. A robust multitenancy model allows a single PAM deployment to serve multiple organisational tenants with complete isolation between them: separate session logs, separate credentials, separate policy configurations, and separate audit trails - while a host administrator retains the ability to manage the platform on behalf of any tenant when needed.

Protection of Monitoring and Analysis Tools (Article 5)

Article 5 addresses a specific but critical requirement: monitoring and analysis tools - including real-time network oversight functions and any tools that can access signal content - must not be accessible from, or stored in, countries listed in Schedule 2 to the Order.

The practical consequence for PAM is data sovereignty. Session recordings, keystroke logs, and administrative audit trails generated by a PAM platform are precisely the kind of sensitive operational data that falls within Article 5’s scope. If a PTP’s PAM platform is cloud-hosted in a jurisdiction not covered by the British Islands, the PTP must conduct a risk assessment and may need to remediate.

The Code identifies several risk factors PTPs should assess:

• Security analysis and anomaly detection performed outside the British Islands
• Network operation centre (NOC) functions hosted offshore
• Privileged access that grants potential access to real-time network information from non-British Islands locations
• Interaction with network probes or virtualisation fabric from restricted locations

8. Resilience, Recovery, and Break-the-Glass (Article 9)

Article 9 addresses what happens when things go wrong. PTPs must be able to identify a security compromise promptly, assess its severity, take mitigating action, and recover - all without creating the risk of a further compromise. The Code sets a 14-day window for resolving compromises, with a written remediation plan required if that window cannot be met.

For PAM specifically, Article 9 raises a challenge that is often overlooked: the break-the-glass scenario. If the PAM system itself is unavailable - whether due to a cyberattack, infrastructure failure, or disaster - administrators may need emergency access to network equipment. How is that access provided, controlled, and audited?

Break-the-Glass Without Breaking Security

The Code explicitly recognises the need for break-the-glass procedures and requires that credentials can be restored without requiring a full system restore. This means:

• Emergency credentials must be pre-positioned in a secure, offline store that is physically accessible even when network connectivity is lost
• The process for accessing those credentials must itself be controlled and audited
• After a break-the-glass event, all emergency credentials used must be immediately rotated
• The PAM system must be capable of granular restoration - restoring specific credential sets without rebuilding the entire platform

A mature PAM implementation for a telecoms environment will have tested break-the-glass procedures as part of its disaster recovery plan, with documented runbooks and regular tabletop exercises. Article 9 makes this a legal expectation, not just a best practice.

9. Supply Chain and Vendor Governance (Articles 7 & 12)

The Order’s supply chain provisions reflect a hard-learned lesson from incidents like SolarWinds and the broader wave of supply-chain attacks on critical infrastructure: your network is only as secure as the least secure vendor with access to it.

Article 12 (Patching) adds a time-dimension requirement. Patches for critical vulnerabilities in externally exposed interfaces must be deployed within 14 days of release. High-severity patches for internally exposed interfaces must be deployed within 30 days. These timelines require PTPs to have a controlled, audited patching process that can be exercised quickly without disrupting operations.

PAM plays a supporting role in patch governance: all patch deployment activities should be performed through the PAM session layer, creating an audit record of who deployed what, when, and from which device. Automated privileged task execution - scripted patching workflows that run under PAM control - can accelerate deployment while maintaining governance.

The Practical Compliance Journey: Where to Start

For most PTPs, full compliance with the Order will require a phased programme of work. The good news is that a well-implemented PAM platform addresses a substantial portion of the Order’s technical requirements from a single deployment. The following sequence reflects both the legal prioritisation in the Order and the practical dependencies between controls.

Phase 1: Foundation (Months 1–3)

• Inventory all accounts with access to security critical functions - internal, external, human, and machine
• Deploy a PAM platform as the single entry point to the management plane
• Enforce MFA for all management plane access (Article 8(2)(b))
• Implement session recording and centralised, tamper-resistant log storage
• Establish ITSM integration so every session is linked to an approved ticket

Phase 2: Control (Months 3–6)

• Implement least-privilege role profiles; remove standing privileged access
• Deploy dual-control approval workflows for changes to security critical functions (Article 8(2)(c))
• Enrol all third-party administrators in the PAM platform; remove direct management plane access
• Configure credential rotation for all vaulted accounts
• Begin 13-month log retention programme (Article 6(3)(e))

Phase 3: Assurance (Months 6–12)

• Deploy User Behaviour Analytics against PAM session data
• Implement geofence-aware authentication controls (Article 8(6))
• Test break-the-glass procedures and document runbooks (Article 9)
• Conduct first annual privileged access risk assessment (Article 11)
• Commission penetration testing of management plane and PAM controls (Article 14)

A Note on Telecoms-Specific PAM Requirements

General enterprise PAM platforms were designed for IT environments - Windows servers, databases, cloud workloads. Telecoms networks introduce a different set of challenges that not all PAM solutions are equipped to handle.

The management plane of a telecoms network includes network elements - routers, switches, base station controllers, core network functions - that use specialist protocols. TACACS+ (Terminal Access Controller Access Control System Plus) and RADIUS are the authentication and authorisation protocols native to network equipment. A PAM solution without built-in TACACS+ and RADIUS support requires additional infrastructure and introduces integration complexity.

Beyond protocol support, telecoms-specific PAM requirements include:

• NMS/EMS integration: policy synchronisation with Network Management Systems such as Nokia 5620 SAM, Huawei U2000, and Juniper Management so that PAM access policies are reflected in the underlying element management layer
• Context-aware CLI command filtering: the ability to allow the same command in one operational context while blocking it in another - a requirement driven by the command-line nature of network element administration
• Carrier-grade availability: the PAM platform itself must meet the reliability standards of the networks it protects; active-active redundancy and 99.999% uptime expectations are not negotiable for a control plane component
• Multi-domain TACACS: large telecoms operators manage multiple network domains, each with their own authentication requirements; the PAM platform must support multi-domain TACACS authentication natively

Conclusion: Compliance as an Architecture Decision

The Jersey Telecommunications (Security Measures) Order 2026 is, at its core, a mandate to treat privileged access as critical infrastructure. The management plane is not a back-office IT concern - it is the control layer of national communications infrastructure, and the Order now reflects that reality in law.

Privileged Access Management is not the only answer to the Order’s requirements, but it is the most direct one. A purpose-built PAM platform, properly deployed and integrated, addresses the majority of the Order’s technical obligations - from MFA and dual-control through to session recording, anomaly detection, credential management, and third-party governance - through a single, auditable control layer.

The compliance question is not whether PTPs will need PAM. It is whether they will implement it as a compliance checkbox or as a genuine security architecture. The Order’s requirement to link every administrative action to a specific ticket, record every session, detect every policy violation, and retain that evidence for 13 months is not a checkbox. It is a transformation in how network administration is governed.

PTPs that treat this as an opportunity - to rationalise their privileged access estate, eliminate standing permissions, integrate their change management and access control processes, and build a forensic capability that can reconstruct any administrative event - will be in a stronger security position, not just a more compliant one.

About Kron PAM

Kron PAM, developed by Kron Technologies, is a Privileged Access Management platform purpose-built for telecommunications, finance, and critical infrastructure environments. It includes a built-in TACACS+ and RADIUS server, native NMS/EMS policy synchronisation, context-aware CLI command filtering, carrier-grade active-active redundancy, and a multitenancy model designed for managed service providers. Kron PAM is deployed on-premise or as a private cloud appliance, meeting data sovereignty requirements under frameworks including the Jersey Telecommunications (Security Measures) Order 2026.

To discuss how Kron PAM addresses your compliance obligations under the Order, contact us at kron.com.tr or request a demonstration.

Disclaimer: This blog post provides an overview of the Jersey Telecommunications (Security Measures) Order 2026 and Code of Practice for informational purposes. It does not constitute legal advice. Public Telecoms Providers should consult the official Order and Code of Practice, and seek independent legal and technical advice as appropriate.