Security Testing for UAE Telecom Operators

In the UAE a telecom operator is expected to run independent security testing with its work mapped to TDRA regulation, aligned with the UAE IAS, and coordinated with aeCERT where a national incident touches the network. The engagement is built to produce the evidence each of those bodies reads.

TDRA

The Telecommunications and Digital Government Regulatory Authority sets the licensing and security expectations a licensed operator answers to. We scope the test so its findings, owners and retest evidence map to the controls TDRA regulation expects, rather than leaving that mapping to the reader.

UAE IAS

The UAE Information Assurance Standards describe the controls a critical entity is expected to hold. We align each finding with the relevant control so a gap is traceable rather than asserted, and we say plainly where a control is out of scope for the test.

aeCERT

Where a tester finds an active compromise rather than a weakness, the path to the national CERT is settled in the rules of engagement before day one, so coordination happens on an agreed route and not during the incident.

A core and roaming network pentest covers the signalling and interconnect paths between operators, the segmentation between the core and the rest of the estate, and the trust an operator extends to a roaming partner. In this region that interconnect trust is where the serious findings sit.

Signalling abuse does not need a foothold on the handset. A request crafted against a poorly filtered interconnect can disclose a subscriber's location or intercept a one-time code, so we test the signalling plane directly rather than inferring it from the data plane.

We scope the core, the roaming interface and the hosts behind them separately, because a control enforced at the interconnect border is not the same as one enforced at the service, and an attacker reaches the service.

We test the self-care portals, the partner APIs and the OSS/BSS behind them per role and per object, so one subscriber or one partner cannot reach another's data, and so the SIM and eSIM provisioning path cannot be driven to issue or swap a profile without authority.

The most common high-severity finding we report on subscriber platforms is broken object level authorisation: changing an identifier in a request and receiving another subscriber's account, bill or usage record. A scanner cannot reason about it, so it is tested by hand, per role and per resource.

SIM and eSIM provisioning is tested as a path to account takeover, because a swap driven through a weak self-care or partner flow hands an attacker the number that receives a subscriber's authentication codes.

Yes. Production testing is agreed in writing first, denial-of-service techniques are excluded by default, and the rules of engagement fix the testing window, the excluded techniques and a deconfliction contact before any work starts, so nothing arrives as a surprise on a live network.

Where a test case would move a real subscriber between profiles or issue a real SIM, it runs against a production-equivalent environment instead. Where that environment differs materially from production, the report says so, because a test of a different configuration is a test of a different system.

A named contact on both sides handles the case where a tester finds an active compromise rather than a weakness. That path, including coordination with aeCERT, is settled before day one, not during the incident.

A UAE operator should test at least annually for anything internet-facing, before a significant release reaches production, and after any material change to the core, the signalling configuration, the provisioning path or the self-care channels. Where a regulator names an interval, treat it as a floor rather than a schedule.

A new roaming agreement, a new partner API or a rewritten self-care login are the changes most likely to introduce the flaws that matter, and each is a reason to test the affected area rather than wait for the annual cycle.

We run the same phases on every engagement so two reports a year apart are comparable, and you can see what changed rather than reading two unrelated documents.

Most operators start with an infrastructure pentest across the core and roaming networks and an API pentest of the partner and OSS/BSS interfaces, add web and mobile pentests for the self-care portals and operator apps, and run an objective-based Red Team and a social engineering test once the basics are covered.

The right mix depends on what you are protecting and what a regulator has asked for. We scope it with you rather than selling a fixed bundle, and we say where something is not worth buying yet.

Every engagement produces an evidence chain rather than a score: the scope, the written authorisation, each finding with a severity and a named owner, the order to remediate in, and a retest that confirms closure with evidence. The retest is priced at scoping, not sold afterwards once you have fixed what we found.

Findings are mapped to MITRE ATT&CK, so a defender can trace each one to a technique the SOC can detect and existing tooling already understands, rather than to a label that means nothing outside the report.

The work runs under a signed NDA and written rules of engagement, against named and vetted operators, with a direct line to the person who found the issue rather than a message routed through an account manager. For procurement or a regulator you also get an attestation that the testing was carried out, which you can pass on without releasing the technical detail.