NIS2 pentest for telecom: scoping resilience testing for digital infrastructure

Telecom operators sit at the top of the NIS2 enforcement list. Annex I, sector 8 (Digital Infrastructure) names providers of public electronic communications networks and publicly available electronic communications services as essential entities. The sectoral history of incidents (TalkTalk 2015, Optus 2022, recurring SS7 fraud cases) means national competent authorities arrived at NIS2 supervision with sharp priors. Every operator above the size thresholds faces the strictest enforcement track from day one.

This page lays out how to scope a NIS2 pentest programme specifically for telecom: what surfaces matter, where the signalling boundary sits, and what the competent authority will actually ask for.

What NIS2 expects from a telecom operator

NIS2 transposes into national law across EU Member States. The directive sets minimum security measures (Article 21) and incident reporting timelines (Article 23) but the testing programme specifics come from each national competent authority. For a French operator, that means ANSSI and ARCEP supervision overlap. For a German operator, BSI and BNetzA. For an Italian operator, ACN and AGCOM. The Article 21 baseline is uniform across all of them.

Article 21(2) lists ten categories of risk-management measures every essential entity must implement: risk-analysis policies, incident handling, business continuity and crisis management, supply-chain security, security in network and information systems acquisition and development, policies to assess the effectiveness of measures, cyber hygiene and training, cryptography, human resources and access control, and use of multi-factor authentication.

Concretely, every NIS2-essential telecom operator must:

• Maintain a risk-management framework covering IT, OSS/BSS, signalling, and the supply chain end-to-end
• Test the effectiveness of security measures under Article 21(2)(f) on a documented, periodic, risk-based cadence
• Document supply-chain security under Article 21(2)(d), including testing rights with core-network vendors and host MNOs (for MVNOs)
• Report significant incidents within 24 hours (early warning), 72 hours (incident notification), one month (final report) per Article 23
• Train staff and the management body, with the management body personally liable for governance failures under Article 20

Penetration testing fits inside Article 21(2)(f). Auditors expect a documented cadence, scope that covers critical functions (emergency services routing, subscriber data, billing, network management), a methodology aligned with ENISA telecom-sector guidance, and remediation evidence.

What the pentest scope looks like specifically

Telecom operators typically split NIS2 testing across four surfaces. Each has a different testing posture.

1. Customer-facing IT. The subscriber portal, mobile app, public APIs, dealer portals, online activation flows. Standard web application surface. This is where the cleanest continuous-pentest fit exists: high change rate, well-understood threat model, no operational risk to the network when tested.

2. OSS/BSS. Provisioning, billing, mediation, CRM, the order-management stack. Often a mix of legacy mainframe-adjacent systems (Oracle BRM, Amdocs CES, custom Java) and modern microservices. Internal-only mostly, but increasingly connected to the customer-facing IT through APIs. Testable continuously in pre-production. Production validation needs coordination with billing operations to avoid creating duplicate charges, false-fraud flags, or provisioning storms.

3. Signalling layer. SS7 (legacy 2G/3G), Diameter (4G/IMS), GTP (data plane), SIP/RTP (IMS voice and VoLTE), and increasingly 5G SBA (HTTP/2 service-based architecture). This is the specialist-only zone. SS7 attacks (location tracking, SMS interception, USSD fraud), Diameter attacks (subscriber profile manipulation), GTP attacks (data interception, billing fraud) require firms with carrier-grade test equipment and licensed signalling access. P1 Security, Positive Technologies, ERNW are the names that come up most often in EU procurement.

4. Supply-chain attestation. Article 21(2)(d) makes this a first-class testing requirement. Core-network vendors (Ericsson, Nokia, Huawei where still permitted, ZTE, Mavenir, Open RAN suppliers) must contractually accept testing rights on the modules they deliver. For MVNOs, the host MNO contract must include incident-sharing and joint-testing clauses. ENISA's 5G supply-chain risk assessment work is the reference point most competent authorities pull from.

For most mid-sized telecom operators, the practical pattern is: continuous AI pentest on customer-facing IT and OSS/BSS, an annual signalling engagement with a specialist firm, plus supply-chain attestation testing of any vendor with privileged access to the core network.

Two concrete examples make the pattern easier to picture.

A European MVNO with around 2 million subscribers, running on top of a Tier-1 MNO. NIS2 scope split into three lanes. Customer-facing IT and OSS/BSS (about 40 web and mobile properties, 120 internal APIs, a Salesforce CRM, an internally built billing layer) went to continuous AI pentest. The signalling layer was deferred to the host MNO under the wholesale contract, except for the MVNO's own HSS/UDM thin slice, tested annually by a signalling specialist. Supply-chain attestation was the hardest lane: the host MNO contract was reopened to add Article 21(2)(d) testing-rights language, the core-network supplier (a Mavenir-based evolved packet core operated by the MNO) had to attest to their own NIS2-compliant testing programme, and incident-sharing was negotiated with a 12-hour internal SLA so the MVNO could meet the 24-hour competent-authority deadline. The CISO described their budget as "60% continuous IT/OSS, 25% supply-chain legal and attestation, 15% signalling specialist." Defensible because the documented residual risks matched the architectural reality.

A regional fixed-network ISP serving a French region with municipal CNI dependencies. Around 300,000 subscribers, but the fibre backbone carries traffic for the water utility, two hospital groups, and the regional transport authority. Their supply-chain testing under Article 21(2)(d) flipped direction compared to a normal ISP scope. They were not just testing their own suppliers; they were the supplier being tested by their downstream CNI customers. The procurement contracts with the water utility and the transport authority included explicit clauses giving those entities the right to commission penetration testing of the ISP's customer-facing edge (the CPE management plane, the BNG configuration interface, the routing announcement integrity controls) on a yearly basis. The ISP CISO had to set up a coordinated-testing programme where the same Fleuret-style continuous pentest output could be packaged as evidence for three different downstream CNI customers without disclosing cross-customer findings. The internal scoping took longer than the testing itself: defining what an attestation package looked like for each downstream operator, what data was shareable, what stayed contractual.

Where continuous AI pentest fits

Continuous AI pentest is appropriate for the customer-facing IT and OSS/BSS layers. It is not appropriate for the signalling layer.

For the IT and OSS/BSS side, continuous pentest fits cleanly:

1. Subscriber portal and mobile app. Changes weekly. New tariffs, new bundles, new self-service flows, new APIs for retention campaigns. Continuous validation catches drift between annual deep tests.
2. Public and partner APIs. TMF Open APIs, eSIM activation endpoints, MVNO partner APIs, roaming-data APIs. High change rate, broadly exposed, well-suited to continuous AI testing.
3. OSS/BSS in pre-production. Provisioning flows, billing mediation, CRM. Testable continuously when isolated from production data. Cuts the cost of finding regression bugs late.
4. Corporate IT and identity. M365, Okta or Entra, VPN concentrators, the developer SSO. Standard surface, standard testing.

What continuous pentest is NOT appropriate for: the signalling plane and anything that touches emergency-services routing. SS7, Diameter, GTP, SIP/SS7 interworking, 112 call paths, IMS emergency bearers. Those require human specialists with carrier-grade tooling and explicit rules of engagement coordinated with the operations bridge.

Procurement checklist for telecom CISOs

If you are scoping NIS2 pentest for an essential telecom entity:

• Does the vendor's rules-of-engagement document explicitly exclude emergency-call paths (112, 116-117, 911 where applicable for inbound roamers)?
• Is the signalling layer clearly out of scope, or does the vendor pretend to cover SS7/Diameter/GTP they cannot actually test?
• For MVNOs: does the vendor handle the contractual chain with the host MNO cleanly, including testing-rights notification?
• Where is the pentest report data stored? CDR samples, subscriber identifiers, and any extract from OSS/BSS must stay in EU data residency for an essential-entity operator.
• Can the vendor produce evidence packages mapped to your national authority's NIS2 inspection format (ANSSI, BSI, ACN, NCSC-IE, AP)?
• Will the vendor coordinate with your signalling specialist on findings that cross the IT/signalling boundary (typically: API endpoints that touch HSS, UDM, AUSF, billing mediation)?

Where Fleuret fits

Fleuret runs continuous AI pentest on customer-facing IT, public and partner APIs, and OSS/BSS pre-production for telecom operators. We do not test the signalling layer. We coordinate with P1 Security, Positive Technologies, ERNW, and similar specialist firms for signalling-protocol engagements when our findings cross the boundary. We produce evidence packages mapped to ANSSI and BSI NIS2 inspection formats.

Fleuret data residency is EU only. CDR samples, subscriber identifiers, and any extract from OSS/BSS or billing systems stay in EU infrastructure. No CLOUD Act exposure on pentest findings from an essential-entity telecom operator.

If you are scoping NIS2 pentest for a telecom entity, book a demo.

Related compliance reading

• NIS2 pentest for energy: the sectoral parallel, where the IT/OT boundary plays the role the IT/signalling boundary plays for telecom.
• ISO 27001 pentest for SaaS: Annex A controls telecom IT vendors most often need evidenced when supplying essential-entity operators.
• DORA pentest for fintech: the financial-services parallel to NIS2 Article 21, relevant for telecom operators that hold a payment-services or e-money licence for mobile-money or carrier-billing products.