In a telecoms operator, the identities that matter most are not customer logins but the engineers, store staff, vendors and machines that can change the network or move a phone number. A single valid login on a router, a manager's credentials in a retail system or a vendor's always-on remote session can expose subscribers at national scale. This guide treats telecoms security as an identity programme: who holds access to network elements, how shared and default accounts are retired, how vendor and managed service access is brokered, how staff access to customer accounts is constrained against SIM swap and port-out fraud, and how lawful intercept access is governed. It is for operator IAM, PAM and security architecture teams, MVNOs and the MSPs that run networks for them; signalling, core hardening and 5G are covered in companion guides.
Key takeaways
- Map identity populations before buying tools. Network operations engineers, field technicians, care and retail staff, vendor and MSP engineers, and machine identities in OSS, BSS and automation each need a different control set.
- The network has its own identity plane. Joint CISA, NSA, FBI and Five Eyes guidance from December 2024 asks for a central AAA service with MFA kept separate from the corporate identity store, with local device accounts reserved for emergencies.
- Third-party administrators are held to your standard. The UK Telecommunications Security Code of Practice expects the provider to control and monitor third-party management access independently, not rely on the supplier's word.
- Retail and care staff are a privileged population. FCC rules adopted in November 2023 bar staff handling inbound contacts from seeing customer CPNI until the customer is authenticated, and insiders with manager rights have been prosecuted for performing SIM swaps for payment.
- Lawful intercept is an access governance problem. US rules require a named senior officer, both legal and carrier authorisation, and a signed record naming the employee who oversaw each interception.
Identity populations in a telecoms operator
Start with an inventory by population, the systems each can reach and the damage a compromised account can do.
| Population | Typical access | Main risk | Priority controls |
|---|---|---|---|
| Network operations (NOC, core, transport engineers) | CLI and element managers on routers, switches, core functions, OSS | Valid accounts used for long-term espionage; configuration theft | Separate network AAA, phishing-resistant MFA, privileged access workstations, session recording |
| Field and site engineers | Local console, craft terminals, site controllers, shared site credentials | Shared and default passwords on cabinets and radio equipment | Per-device unique credentials from a vault, check-out per job ticket |
| Care, retail and dealer staff | CRM and billing (BSS), SIM change and porting functions | SIM swap and port-out fraud, bribery of insiders, social engineering | Authenticate-before-access, role scoping, approval for high-risk changes, transaction monitoring |
| Vendors and managed service providers | Remote maintenance of RAN, core and IT platforms, sometimes outsourced NOCs | Trusted-relationship intrusion, standing access, shared vendor logins | Brokered, time-bound, recorded access with named accounts; contractual controls |
| Lawful intercept administrators | LI mediation and provisioning platforms | Exposure of who is under investigation; unauthorised intercepts | Small named group, dual control, reconciliation against authorisations |
| Machine identities | SNMP, TACACS+ and RADIUS secrets, SSH keys, API clients, orchestration and automation accounts | Secrets harvested from configurations and reused across thousands of devices | Inventory with owners, unique secrets, rotation, non-privileged automation accounts |
Identity churn is high: dealers, contact centre agencies and contractor field crews come and go faster than corporate joiner-mover-leaver processes expect, so revocation must reach dealer portals and vendor accounts. See the Joiner-Mover-Leaver Guide. Many network elements cannot federate, so TACACS+, RADIUS and element managers must be governed as their own identity system.
Privileged access to network elements
The December 2024 joint guidance from CISA, NSA, FBI and partner agencies in Australia, Canada and New Zealand, written in response to the PRC-affiliated compromise of telecommunications networks, sets the practical baseline for network administrator identity:
- Phishing-resistant MFA for all administrative access: the guidance asks for MFA on every account and names hardware-based PKI or FIDO as the phishing-resistant method. The UK Code of Practice (paragraph 2.21) adds that the second factor should be on a separate device and that SMS is not appropriate. See the Phishing-Resistant MFA Guide.
- Separate network AAA: route routine device management through a centralised AAA server with MFA that is separate from the primary corporate identity store, so a compromised office directory does not hand over the network.
- Local accounts for emergencies only: keep local device accounts as break-glass, change the password after each use and confirm every use was authorised. See the Break-Glass Account Guide.
- Strong password storage on devices: on Cisco IOS, the guidance asks for Type 8 hashes where supported, avoidance of deprecated Type 5 and Type 7, and Type 6 encryption for the TACACS+ key.
- Dedicated administrative workstations and out-of-band management: allow device management only from a physically separate management network and block lateral management between devices. The UK Code (paragraphs 2.16 and 2.17) rules out "browse-up" designs where an internet-facing workstation reaches the management plane.
- Time-bound, ticketed elevation: the UK Code (paragraph 2.20) expects every administrative access to be authorised, time-limited, monitored and linked to a purpose or ticket. Just-in-time access through a PAM broker is the usual way to meet this. See the Privileged Access Management Guide and the Privileged Session Management Guide.
The live Telecom Network Security Guide covers the machine credentials held on each device (SNMP strings, AAA shared secrets, SSH keys, peer certificates) and the Salt Typhoon persistence methods; this guide does not repeat that inventory.
Shared, default and generic accounts
Shared accounts persist in telecoms longer than in most sectors because equipment ships with vendor maintenance users, field teams share site passwords, and element managers were built before per-user AAA. The UK Code (paragraph 2.22) expects insecure defaults, including default credentials, to be removed or changed, and the joint guidance says to change defaults on first use and never reset a password back to its default.
| Account type | Where it hides | Remediation | Residual control if it must stay |
|---|---|---|---|
| Vendor default or maintenance users | RAN baseband units, optical transport, element managers, CPE fleets | Change on commissioning; build the check into acceptance testing | Vaulted, unique per device, alert on any login |
| Shared site or cabinet passwords | Field engineer handbooks, spreadsheets, team chat | Per-device credentials issued from a vault against a work order | Rotate after each visit; log check-out to a named engineer |
| Generic NOC logins ("noc", "operator") | Legacy element managers, monitoring consoles | Move to named accounts through AAA or SSO | Session broker that records the named human behind the shared login |
| Shared vendor support accounts | Vendor remote access tools, outsourced NOC tooling | Named accounts per vendor engineer, created on request | Time-bound enablement, recorded sessions, approval per session |
| Automation and service accounts with admin rights | Orchestration, configuration backup, provisioning scripts | Least-privilege accounts; the UK Code (paragraphs 2.70 and 2.71) says automated processes should not run as privileged users and need a named business and operational owner | Vaulted credentials, rotation, source restriction, behaviour baselines |
The attacker technique is mapped in MITRE ATT&CK as T1078.001 Default Accounts under T1078 Valid Accounts. Machine accounts in the last row are covered in more depth in the Service Account Security Guide.
Vendor and managed service access
Vendors and MSPs often have deeper network access than most employees. ATT&CK tracks this route as T1199 Trusted Relationship, alongside T1133 External Remote Services for the remote access paths themselves.
- Same principles as your own staff: the UK Code (paragraphs 2.25 to 2.27) expects third parties with management plane access to meet the provider's own security principles, to be bound by contract, and to be controlled and monitored by the provider independently of the supplier.
- Reduce third-party reach into oversight functions: for the functions the Code calls Network Oversight Functions, it points to reducing the number of administrative users and removing third-party access, with enhanced and real-time monitoring of changes (paragraphs 1.9, 1.13 and 1.14).
- Broker every session: vendor engineers connect through a provider-owned access gateway with their own named identity, phishing-resistant MFA, approval per session and recording. No vendor-installed remote tools with their own authentication.
- No standing access: vendor accounts are disabled by default and enabled per change window. Measure how many vendor accounts are enabled outside an approved window.
See the Third-Party Access Guide for the generic access model and the Third-Party Access Policy Template for contract and policy wording.
Staff access to customer accounts: SIM swap and port-out
From the operator side, SIM swap and port-out fraud are workforce identity problems: the request is completed by a care agent, a store employee or a dealer using an internal role. The customer-facing controls (locks, PINs, notifications) are in the SIM Swap Fraud Guide and the Telecom Network Security Guide; this section covers the staff side.
The FCC Report and Order FCC 23-95 (WC Docket 21-341), adopted on 15 November 2023, requires wireless providers to authenticate customers securely before SIM changes and port-outs, handle failed authentication attempts, notify customers immediately of SIM change and port-out requests, offer a free account lock, train staff, keep SIM change records for at least three years, and stop employees who handle inbound contacts from accessing CPNI until the customer is authenticated. In July 2024 the FCC waived compliance with all of the order's rules until the Office of Management and Budget completes its review and the Commission publishes a compliance date; the current eCFR text of 47 CFR 64.2010(h) and 52.37 still states that compliance is not required until a compliance date is added. Treat them as the design target and check current status before citing them as binding.
- Authenticate before access: design the CRM so the customer record, including CPNI, stays masked until the customer has passed authentication.
- Scope roles narrowly: separate the right to view an account from the right to perform a SIM change or port-out. Store managers and dealers should not hold override rights by default.
- Remove manager overrides as a silent path: in a March 2024 US Department of Justice case, a former telecommunications store manager admitted using managerial credentials to swap SIMs on several customer accounts onto devices controlled by another person, and was paid in Bitcoin. Overrides should need a second person and generate an alert.
- Bind staff sessions to strong authentication: retail and dealer staff should sign in with phishing-resistant MFA on managed devices, not shared store logins.
- Monitor staff behaviour: alert on agents or stores with unusual SIM change volume, changes on locked or high-value accounts, changes outside shift hours and changes shortly after a password reset. ATT&CK for Mobile tracks the resulting attack as T1451 SIM Card Swap.
- Protect the support channel: attackers phone care centres posing as colleagues or customers (T1566.004 Spearphishing Voice). Apply the controls in the Account Recovery and Help Desk Security Guide to internal help desk resets for retail staff.
Lawful intercept system access
Lawful intercept platforms combine some of the most sensitive data an operator holds with a small administrator population, which makes them suited to the strictest identity controls. In the US, 47 CFR 1.20003 requires a carrier to appoint a senior officer or employee responsible for ensuring that interceptions are activated only with a court order or other lawful authorisation and with the affirmative intervention of a carrier employee, and to have written policies requiring both legal authorisation and carrier authorisation. It also requires carriers to report compromises of interceptions to the affected law enforcement agencies. Section 1.20004 requires a signed certification for each interception recording the line or circuit identifiers, start date and time, the law enforcement officer who presented the authorisation, the person who signed it, the interception type and the carrier employee who oversaw it.
Those rules translate into identity requirements:
- Named individuals only: no shared LI administrator accounts, because the record must name the overseeing employee. Vet and list the group, and keep it small.
- Dual control for provisioning: one person enters the intercept, another approves it against the authorisation register. The provisioning platform should enforce this, not a procedure document.
- Isolated identity store: LI administration should not authenticate through the corporate directory or the general network AAA. A compromise of either should not reach intercept provisioning.
- Reconciliation: regularly reconcile active intercepts and LI account activity against authorisations; unexplained intercepts or logins are an incident.
The Salt Typhoon Threat Actor Profile explains why LI systems became a public concern after the 2024 intrusions, and the Telecom Network Security Guide covers network isolation of the LI environment.
UK Telecoms Security Act: identity measures
For UK public network and service providers, the Telecommunications (Security) Act 2021, the Electronic Communications (Security Measures) Regulations 2022 and the Telecommunications Security Code of Practice turn much of this guide into expected practice. Version 1.1 of the Code was issued in July 2026. The identity-relevant guidance includes:
| Code paragraph (v1.1) | Identity expectation | How to evidence it |
|---|---|---|
| 1.9, 1.13, 1.14 | Fewer administrators and no third-party access to Network Oversight Functions; enhanced, real-time monitoring of changes | Admin counts per oversight function; change alerts reviewed |
| 2.16, 2.17 | No browse-up; administrative workstations separate from office and internet-facing systems | PAW inventory; management plane firewall rules |
| 2.20 | Administrative access authorised, time-limited, monitored and tied to a ticket | PAM logs showing ticket IDs and session expiry |
| 2.21 | MFA where administrators can affect the network; separate device; not SMS | MFA method report per admin account |
| 2.22 | Default credentials removed or changed | Commissioning checklist; default credential scans |
| 2.25 to 2.27 | Third-party administrators meet provider principles, are contracted and are independently controlled and monitored | Contract clauses; provider-owned access gateway logs |
| 2.28 | Read-only access also least privilege and role based | Role definitions and review records |
| 2.70, 2.71 | Automation not run as privileged users; named business and operational owner | Service account register with owners |
The Code's numbered technical measures, including the privileged access workstation measures and the service account and API security measures added in 2026, are mapped in the UK Telecommunications Security Act Guide.
Implementation roadmap
- Inventory (months 0 to 3): list every identity population, every authentication path to network elements (AAA, local, element manager, vendor tool) and every shared, default and vendor account.
- Quick wins: disable Telnet and other plaintext management, change default credentials, move device password storage to strong hash types, and disable dormant vendor accounts.
- Separate the network AAA: stand up or harden a network AAA service with phishing-resistant MFA, independent of the corporate directory. Run it in parallel with existing authentication, migrate device groups in rings and keep a documented local break-glass path for rollback if AAA becomes unreachable.
- Broker privileged and vendor access: route NOC and vendor sessions through a PAM gateway with approval, recording and time limits. Start in monitor-only mode, then enforce once session failure rates are understood.
- Constrain retail and care roles: implement authenticate-before-access in CRM, split SIM change and porting rights from view rights, and add second-person approval for overrides. Pilot in a subset of stores and measure handling time before national rollout.
- Govern lawful intercept access and automate review: isolate the LI identity store, enforce dual control, and feed dealer, agency and vendor rosters into quarterly entitlement reviews.
Decision guidance
- Network AAA separate from, or federated to, corporate SSO: the joint guidance favours separation. Federation simplifies administration but couples network safety to corporate directory hygiene. Large operators should separate; small operators and MVNOs may federate if the corporate IdP enforces phishing-resistant MFA and has a separately protected admin tier.
- Federated MSP identities versus provider-issued accounts: provider-issued accounts give control and clean revocation; federation scales for large outsourced NOCs. If you federate, require phishing-resistant MFA claims and enforce your own session controls.
- MVNOs and small operators: you may have no network elements, but you still have care staff with SIM change rights, BSS access and host network portals. Prioritise retail and care controls and contractual evidence from the host operator.
Detection and measurement
Log centrally: network AAA authentications and command accounting, local account logins on devices, PAM session starts with ticket IDs, vendor gateway sessions, CRM events for SIM change and porting with the staff identity, and LI provisioning actions. The joint guidance asks for monitoring of user and service account logins for anomalies and central logging of AAA activity.
| Metric | What good looks like |
|---|---|
| Share of network element logins through central AAA with phishing-resistant MFA | Rising towards all logins; local logins only during declared incidents |
| Devices with default or shared credentials | Zero on new commissioning; falling trend on legacy estate |
| Vendor accounts enabled outside an approved change window | Zero |
| Privileged sessions without a linked ticket | Zero, with exceptions reviewed weekly |
| SIM changes and port-outs performed via override, per store or agent | Low and stable; outliers investigated within days |
| Time to revoke leaver access across dealer, vendor and network AAA accounts | Same business day for privileged roles |
Common failure patterns
- Network admins authenticating through the corporate directory: one phished office account reaches routers. The Salt Typhoon telecom intrusions were largely carried out with legitimate credentials, then sustained through harvested device secrets.
- Manager override as a fraud channel: store or dealer managers can complete SIM changes without a second person or alerting, which turns one bribed employee into a fraud service.
- Vendor access that never switches off: standing VPN accounts for equipment vendors, often shared by a support team, outlive the contract and the people.
- Read-only access treated as harmless: monitoring and backup accounts can read configurations containing shared secrets for the whole estate.
- Help desk resets for retail staff by phone: attackers impersonate staff to reset credentials for CRM access, the same pattern seen in the Twilio breach, where SMS phishing of employees opened access to customer data.
Framework mapping
| Area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | MITRE ATT&CK v20 |
|---|---|---|---|
| Network administrator identity and MFA | PR.AA-01, PR.AA-03 | IA-2, IA-5 | T1078 Valid Accounts |
| Shared and default accounts | PR.AA-01 | AC-2, IA-5 | T1078.001 Default Accounts |
| Least privilege and time-bound elevation | PR.AA-05 | AC-6 | T1098 Account Manipulation |
| Vendor and MSP access | GV.SC-07 | AC-17, PS-7, SR-6 | T1199 Trusted Relationship, T1133 External Remote Services |
| Staff access to customer accounts | PR.AA-05, DE.CM-03 | AC-6, AC-2(12) | T1451 SIM Card Swap (Mobile), T1566.004 Spearphishing Voice |
| Monitoring of privileged and LI activity | DE.CM-03 | AU-6, AC-2(12) | T1040 Network Sniffing (secret capture on management traffic) |
Practitioner checklist
- Inventory identity populations and every authentication path to network elements, including local and vendor accounts.
- Run network device administration through a central AAA with phishing-resistant MFA, separate from the corporate directory.
- Reserve local device accounts for emergencies, vault them and rotate after every use.
- Remove default and shared credentials at commissioning and track the legacy backlog to zero.
- Broker vendor and MSP access with named accounts, per-session approval, recording and time limits.
- Mask customer CPNI until authentication, separate SIM change rights from view rights and require a second person for overrides.
- Alert on SIM change and port-out outliers by agent, store and dealer.
- Limit lawful intercept administration to a named, vetted group with dual control and regular reconciliation.
- Give every automation account a named owner and remove its privileged rights where possible.
Standards and references
- CISA, NSA, FBI and partners: Enhanced Visibility and Hardening Guidance for Communications Infrastructure
- UK Department for Science, Innovation and Technology: Telecommunications Security Code of Practice
- Federal Communications Commission: Protecting Consumers from SIM Swap and Port-Out Fraud (FCC 23-95)
- eCFR: 47 CFR 64.2010, Safeguards on the disclosure of CPNI
- eCFR: 47 CFR 52.37, Number portability fraud protections
- eCFR: 47 CFR Part 1 Subpart Z, Communications Assistance for Law Enforcement Act
- US Department of Justice: Former Telecommunications Company Manager Admits Role in SIM Swapping Scheme
- MITRE ATT&CK: Trusted Relationship
Related NHI Mgmt Group resources: Telecom Network Security Guide · 5G Security Guide · UK Telecommunications Security Act Guide · Salt Typhoon Threat Actor Profile · SIM Swap Fraud Guide