Are PTCRB and GCF enough to activate a product on Deutsche Telekom networks?

No. GCF is the European counterpart of PTCRB for 3GPP radio conformance, and any cellular product targeted at Europe must obtain a GCF certification (or PTCRB depending on the module) before any discussion with a carrier. Deutsche Telekom (DT) then adds its own IoT acceptance programme (often called T-IoT acceptance) which verifies interoperability with DT core networks, conformance of nuSIM or eUICC provisioning, attach profiles, T-IoT APNs and intra-group roaming policies. Without this acceptance, a module can transmit but will not be listed in the T-IoT catalogue, and the commercial qualification of a turn-key product is refused.

What is the difference between nuSIM and a standard SGP.32 eUICC?

nuSIM is the integrated SIM (iSIM) solution developed by Deutsche Telekom with its silicon partners. Instead of a discrete SIM card or a dedicated eUICC chip, the SIM application sits in a secure zone of the cellular SoC (typically a certified secure enclave). Provisioning runs through a DT-specific channel with a profile pre-loaded at factory, without a standard SGP.22 LPA. An SGP.32 eUICC remains a dedicated chip that follows the IoT RSP model (SM-DP+, eIM, IPA). Both approaches coexist in the DT catalogue but are not interchangeable: nuSIM is a closed DT product, SGP.32 is an open GSMA standard.

Does the DT programme cover T-Mobile US?

No. T-Mobile US is legally and technically separate from the Deutsche Telekom group, especially after the merger with Sprint and the resulting changes in shareholding. Although DT remains a significant shareholder, T-Mobile US operates its own acceptance programme with its own requirements (aligned with North American PTCRB, B66/B71 bands, n41, n71). A DT acceptance dossier is not automatically usable on T-Mobile US, and vice versa. Multi-market products must plan two distinct acceptance dossiers.

Which cellular technologies are covered by DT IoT acceptance?

The programme covers technologies currently active in the T-IoT catalogue: LTE-M (Cat-M1), NB-IoT (Cat-NB1, Cat-NB2), LTE Cat-1bis for single-antenna modules, LTE Cat-4 and above for gateways and high-throughput terminals, and 5G NR on DT commercial bands (notably n78 in C-band). 2G remains available in some markets during the retirement window but is no longer an acceptance target for new products. Each technology has its own acceptance test base, and a multi-tech product must be tested on each.

How does NB-IoT roaming work across the DT footprint?

NB-IoT roaming has long been absent from most inter-carrier agreements. Deutsche Telekom is one of the promoters of the GSMA NB-IoT Roaming Initiative, which aims to establish a mesh of NB-IoT roaming agreements between participating operators, including DT subsidiaries in Europe. In practice, NB-IoT roaming availability depends on country, on the SIM/eUICC used, and on the bilateral DT agreement with the visited operator. DT-operated zones (DE, AT, CZ, HU, GR) take priority; the rest of Europe varies. An international IoT product that assumes systematic NB-IoT roaming will fail.

How should a product choose between nuSIM, SGP.32 eUICC and physical SIM for DT?

The choice depends on the commercial model and volume. nuSIM offers the lowest BOM cost and the best integration for single-operator products tightly bundled with DT (turn-key with a T-IoT subscription). SGP.32 eUICC keeps multi-operator portability with a GSMA standard, recommended for international, long-lifecycle products. Physical SIM remains valid for pilot markets and low volumes but is losing ground. A decision matrix based on volume, lifetime and country count is documented by DT in its T-IoT catalogue.

Is Cloud of Things mandatory to use DT IoT connectivity?

No. Cloud of Things (CoT) is the DT application IoT platform, built on Cumulocity (Software AG). It simplifies fleet management, OTA, telemetry collection and device management. T-IoT connectivity can be used independently with any third-party platform (AWS IoT, Azure IoT Hub, proprietary platform). CoT integration is bundled in some combined packages but does not condition acceptance of a module or product on the DT cellular network.

What are the most frequent pitfalls of DT IoT acceptance?

Recurring ones: misconfigured nuSIM provisioning (key not aligned between factory and DT orchestrator), untested inter-subsidiary roaming scenarios (especially T-Mobile CZ and Magenta AT, which have distinct APN policies), underestimated Cat-1bis throughput (a single antenna penalises cell edge), NB-IoT layer tested only in the lab without real roaming verification, non-conformant SGP.32 LPA on eUICC products, and the false assumption that T-Mobile US accepts the DT dossier.

Deutsche Telekom IoT: acceptance, nuSIM and Cloud of Things

Author Hugues Orgitello Last updated 27 May 2026 ~13 min read

Guide · Deutsche Telekom IoT

Deutsche Telekom (DT) is one of the European telecom operators most engaged in cellular IoT, with a strategy combining a multi-country footprint, a proprietary acceptance programme, the Cloud of Things application platform, and a specific innovation: nuSIM, its integrated SIM (iSIM) hosted inside the cellular SoC. For a manufacturer aiming at the European market with a cellular product, 3GPP conformance through GCF is not enough: passing T-IoT acceptance conditions listing in the DT catalogue and eligibility for carrier offers. This page describes the DT footprint relative to T-Mobile US, the T-IoT acceptance programme, the nuSIM versus SGP.32 eUICC trade-off, the positioning of Cloud of Things, the CamControl module qualification flow, the cellular technologies covered, and the pitfalls that delay listing.

Deutsche Telekom footprint and demarcation from T-Mobile US

The Deutsche Telekom group operates mobile networks in several European countries under distinct brand names. Its American subsidiary T-Mobile US, although historically related, now operates as an independent entity for certification matters and must be addressed in a separate dossier.

Country	Brand	Network	T-IoT acceptance coverage
Germany	Telekom (T-Mobile DE)	2G (in retirement), LTE, LTE-M, NB-IoT, 5G NR	Primary market, programme reference
Austria	Magenta Telekom	LTE, LTE-M, NB-IoT, 5G NR	Aligned acceptance, own APNs
Czech Republic	T-Mobile CZ	LTE, LTE-M, NB-IoT, 5G NR	Aligned acceptance, NB-IoT roaming agreements
Hungary	Magyar Telekom	LTE, LTE-M, NB-IoT, 5G NR	Aligned acceptance
Greece	Cosmote (OTE subsidiary)	LTE, LTE-M, NB-IoT, 5G NR	Aligned acceptance, distinct Cosmote scope
United States	T-Mobile US	LTE, 5G NR, n41/n71 bands	Separate programme, outside DT scope

For European manufacturers, the key point is that DT IoT certification does not open T-Mobile US. The US programme is independent, aligned with PTCRB and its own requirements. A product targeting both geographies must plan two distinct acceptance dossiers.

Within the European DT footprint, subsidiaries share a common technical structure but retain local APN policies, IMSI numbering plans and roaming agreements. A module accepted in Germany is not automatically testable without complementary verifications in the Czech Republic or Greece, particularly on NB-IoT chains.

The T-IoT acceptance programme, scope

The T-IoT acceptance programme rests on two foundations: 3GPP conformance via GCF or PTCRB depending on the module, and a DT-specific test plan covering interactions with its networks and its provisioning systems.

Comparison with PTCRB and GCF

Criterion	PTCRB / GCF	T-IoT acceptance
Nature	Cross-carrier 3GPP radio conformance	Deutsche Telekom IoT proprietary programme
Reference	3GPP TS 36.521, TS 38.521	Superset: 3GPP baseline + DT network tests, nuSIM/eUICC, APNs, intra-group roaming
Scope	Generic radio conformance	DT network interoperability, nuSIM profile, optional Cloud of Things integration
Granted by	PVG / GCF Steering Committee	Deutsche Telekom IoT, acceptance team
Identifier	PTCRB EPC or GCF FFS / DTP	T-IoT reference, T-IoT catalogue listing
Required for DT catalogue eligibility	Yes	Yes, in addition to GCF/PTCRB

PTCRB and GCF are prerequisites but not sufficient. Without valid 3GPP certification, DT does not open the acceptance phase. With PTCRB or GCF only, the product remains functional on the network but is not eligible for turn-key T-IoT offers, and certain scenarios (nuSIM, intra-DT NB-IoT roaming, Cloud of Things profiles) cannot be validated.

Portals and entry points

DT IoT exposes several portals depending on the entry angle:

T-IoT catalogue for plans and accepted modules, accessible to DT IoT customers;
Cloud of Things platform for application-side management;
CamControl workflow for cellular module qualification (see below);
nuSIM portal for SoC and product manufacturers embedding the iSIM;
DT acceptance back-office for final-product submission, generally via a commercial contact at DT IoT assigned to the manufacturer account.

Opening an acceptance dossier is not self-service: it follows a prior commercial qualification, which evaluates expected volume, target geography, object type and chosen SIM solution.

CamControl, cellular module qualification

CamControl is the internal Deutsche Telekom flow that drives qualification of a cellular module for the T-IoT catalogue. It is aimed at module manufacturers (Quectel, u-blox, Telit, Sierra Wireless, Murata, Sequans, Fibocom, Cinterion-Telit, Wirepas and others) who wish to list their module as a pre-accepted building block.

Typical steps:

Technical submission by the module manufacturer: datasheet, GCF report, PTCRB report where applicable, nuSIM support statement where applicable, SGP.32 eUICC support.
Documentary review by the CamControl team: coverage of European DT bands (B1, B3, B7, B8, B20, B28, B40; n1, n28, n78), LTE-M and NB-IoT support where applicable, minimum 3GPP Release.
Test campaign in a DT-recognised laboratory: network interoperability for DE and a representative subset of subsidiaries, nuSIM behaviour where applicable, eUICC profile handling, NB-IoT in the lab and under partner roaming conditions.
Validation and listing in the T-IoT catalogue as an accepted module.

Once a module is accepted through CamControl, downstream integrators can use it in their products with a faster and cheaper device-level acceptance. The module becomes a pre-validated brick, much like Verizon's AML or other carriers' approved-module lists (see Verizon OPC for a comparable North American logic).

Note: the CamControl module list evolves. Before a project, manufacturers must ask the module supplier for the current T-IoT reference, not only the GCF status, to avoid surprises at device acceptance.

nuSIM, the Deutsche Telekom iSIM

nuSIM is Deutsche Telekom's technical signature in cellular IoT. It is an iSIM in the GSMA sense, that is to say a SIM application hosted directly in a secure zone of the cellular SoC, without a card or a dedicated eUICC chip.

nuSIM, SGP.32 eUICC and physical SIM compared

Criterion	Physical SIM	SGP.32 eUICC	nuSIM (DT iSIM)
Form factor	SIM card or MFF2	Dedicated chip	Secure zone inside the cellular SoC
Standard	ETSI TS 102 221	GSMA SGP.32	DT proprietary specification, GSMA-aligned
Provisioning	Physical exchange or classical OTA	IoT RSP: SM-DP+, eIM, IPA	Factory pre-load via silicon partner, DT nuSIM orchestrator
Operator portability	Possible with a new card	Multi-operator via GSMA profiles	Turn-key DT, limited portability
BOM cost	Highest (card + holder)	Mid-range (chip + integration)	Lowest (no external component)
Volume target	All volumes	Mid and large IoT volumes	Very large mono-operator DT volumes
Expected lifetime	Short to medium	Long (10 years and beyond)	Long, tied to the SoC
LPA / IPA	Not applicable	Required on the device	Not applicable (DT-side orchestration)

The nuSIM commercial model assumes a three-way partnership: the cellular SoC vendor that integrates the nuSIM application, the product manufacturer that selects this SoC and signs a T-IoT agreement, and Deutsche Telekom which drives provisioning. Current partner SoCs cover several LPWAN and LTE-M vendors (the list evolves, to be checked directly with DT at the start of any project).

The main benefit of nuSIM lies in integration cost and the removal of a hardware failure point: no SIM holder, no extra eUICC chip, no re-soldering if a card loosens. For a high-volume product deployed within a single operator ecosystem (DT and its roaming partners), it is economically the most rational option.

The downside is its relative closure: the nuSIM profile is bound to DT and its orchestrator. If commercial strategy shifts (operator change, international distribution outside the DT footprint), portability is less immediate than with a standard SGP.32 eUICC. The decision must therefore be made during commercial scoping, not mid-development.

nuSIM provisioning pitfalls

Three recurring pitfalls:

Misaligned root key between the SoC manufacturing chain and the DT orchestrator: the product ships with a profile that DT does not recognise. Detection is late (first customer activation) and remediation is expensive (RMA or in-field re-flashing).
Incomplete personalisation at end-of-line test: the nuSIM IMSI or ICCID is not correctly injected into the secure zone, the module attaches but does not authenticate.
No re-provisioning channel planned in case of error: unlike an SGP.32 eUICC with LPA, nuSIM cannot be reconfigured via a standard SM-DP+ flow. Without a DT-specific channel, the error is terminal.

T-IoT acceptance includes an audit of the nuSIM provisioning flow, generally on-site or through sample review. It is a frequent non-conformity for first-time submitters.

Cloud of Things, application platform

Cloud of Things (CoT) is Deutsche Telekom's application IoT platform, built on Cumulocity IoT (Software AG, with portfolio evolutions following IBM-related integration of the SAG business). It offers:

multi-device, multi-vendor fleet management;
telemetry collection and storage;
rules, alerts, dashboards;
firmware OTA campaign management;
integration with T-IoT connectivity for billing and SIM management.

CoT is not mandatory to use DT IoT connectivity. A T-IoT object can integrate with AWS IoT Core, Azure IoT Hub, Google Cloud IoT, or a third-party platform without interfering with network acceptance. CoT is positioned as an option in some turn-key plans bundling connectivity + platform + SIM/nuSIM in a single contract.

For a product whose application strategy is already committed to a hyperscaler, CoT is not a blocking matter. For a product in scoping that seeks an integrated partner, CoT and T-IoT form a quick vertical offer with no multi-vendor contracts.

Cellular technologies covered

DT IoT drives its acceptance on technologies actively listed in the catalogue. Others remain operable on DT networks (because the radio is conformant) but are not commercially promoted.

LTE Cat-M (LTE-M)

LTE-M (Cat-M1, and Cat-M2 in some cases) is DT's preferred LPWAN technology for moderately mobile objects with moderate throughput and potential VoLTE. Coverage spans almost the entire DE/AT/CZ/HU/GR footprint. LTE-M acceptance verifies PSM and eDRX support, RAI (Release Assistance Indication) behaviour and attach with an IoT-M T-IoT APN.

NB-IoT

NB-IoT is the ultra-low-power technology for stationary or barely mobile objects. DT is one of the pillars of the GSMA NB-IoT Roaming Initiative, which aims to establish NB-IoT-specific roaming agreements between participating operators. NB-IoT acceptance verifies attach, PLMN-locking support, long-session stability and behaviour during intra-DT roaming (across group subsidiaries). It is also the scenario where pitfalls are most frequent.

LTE Cat-1bis

Cat-1bis (LTE Cat-1 throughput with a single antenna) is positioned by DT as an alternative to LTE-M where LTE-M coverage is still uneven and where the product needs higher throughput than LTE-M offers. Cat-1bis acceptance highlights the cell edge issue: without antenna diversity, sensitivity is lower, and a product assuming nominal throughput in real conditions can be deeply disappointing. DT recommends real-world testing beyond lab testing for this category.

LTE Cat-4 and above

For gateways, POS terminals and high-throughput medical devices, DT acceptance covers LTE Cat-4, Cat-6 and Cat-7+. VoLTE and IMS requirements then become stricter, and integration with Telekom DE voice services may be required for some categories.

5G NR

DT is rolling out 5G NSA and progressively 5G SA on European commercial bands (mainly n1, n28, n78, with n40 or n258 mmW in some industrial cases). 5G NR acceptance for IoT primarily targets gateways, FWA and industrial terminals. For low-bandwidth objects, staying on LTE-M and NB-IoT remains preferable.

2G

2G (GSM) is in progressive retirement across the DT footprint, on a schedule specific to each subsidiary. DT no longer accepts new 2G-only products in the catalogue. Multi-tech modules (for instance 2G + LTE-M) are accepted to ease the transition, but 2G is no longer a commercial argument in any roadmap.

Pan-European roaming and MVNO arrangements

Beyond the DT footprint, two dimensions of roaming deserve attention.

Classic MNO roaming. DT has roaming agreements with most European operators for 2G, 3G (in retirement), 4G LTE and 5G. LTE-M and NB-IoT coverage in roaming is not guaranteed by default, even where LTE is. An international IoT product must clarify the LPWAN coverage country by country, referring to the T-IoT roaming table.

MVNO activity. DT IoT distributes its connectivity through MVNO partners (T-IoT MVNO programme) and integrates some MVNOs through specific agreements to address markets outside its direct footprint. This is notably the route for France, Italy, Spain and the UK, where DT does not operate its own network. The quality and reach of LPWAN services via an MVNO vary with the local host operator, which can create asymmetries in the behaviour of the same product across countries.

For manufacturers with broader targets, see also the Verizon OPC programme for the United States, and the multi-operator logic documented in the certification timeline and certification costs.

eUICC, profiles and orchestration

For products that do not use nuSIM, DT IoT acceptance enforces current GSMA standards.

GSMA SGP.22 remains the Consumer RSP standard, used for products with a UI (gateways, M2M terminals with a screen, for instance). DT supports SGP.22 for compatibility but steers new IoT deployments towards SGP.32.
GSMA SGP.32 is the IoT RSP standard, expected on all new headless products. It introduces the eIM (eSIM IoT Manager) for fleet management without user intervention. DT operates a compatible eIM and requires a correctly implemented IPA on the device side.
SGP.02 (the historical M2M architecture) is being progressively retired. DT continues to accept SGP.02 products already deployed but no longer accepts new SGP.02 submissions beyond a defined Release threshold. Schedules are published in the T-IoT acceptance back-office.

The LPA or IPA must talk to the DT SM-DP+, with root certificates published in the acceptance portal. An incomplete TLS chain or an outdated cipher suite is a recurring rejection cause, and the root cause is often an embedded TLS stack that is no longer maintained.

APNs and IP addressing plan

DT publishes a set of target APNs: public IPv4 APN, public dual-stack IPv4/v6 APN, private APN with customer VPN attach, NB-IoT-dedicated APN, LTE-M-dedicated APN, Cloud of Things APN for pre-integrated objects. APN choice affects:

IP addressing (public, private, RFC 1918, IPv6 range);
latency and routing (DT apex direct, or through an MVNO);
application integration (Cloud of Things, AWS IoT Core via private link, other);
billing (volumes, plans, tariff profiles).

Acceptance verifies that the module attaches to the target APN without falling back to a wrong default APN, negotiates the IP stack correctly (including IPv6 where required), and handles disconnects and restarts without leaking orphan PDP sessions (a classic cause of quota leakage and network-firewall blocking).

Frequent pitfalls

1. Confusing DT acceptance with T-Mobile US acceptance

This is the strategic pitfall. A successful DT IoT dossier does not waive T-Mobile US's programme, and vice versa. Any product schedule must separate these two geographies from the very start of scoping.

2. Over-trusting NB-IoT roaming

Many IoT programmes assume NB-IoT roams like LTE. In 2026, that is false in most cases. Any promise of international NB-IoT coverage must be validated country by country, operator by operator, leaning on the T-IoT roaming table and the GSMA NB-IoT Roaming Initiative.

3. nuSIM scoped poorly on the commercial side

Choosing nuSIM purely for BOM savings, without validating long-term commercial strategy (volume, geography, operator portability), is a frequent mistake. If reselling the product to an international customer is on the horizon, SGP.32 eUICC keeps more options open.

4. Idealised Cat-1bis

Nominal Cat-1bis throughput is never reached in real conditions when the signal is moderate. A product whose use case depends on bounded latency (payment, telemedicine, industrial control) must not rest on Cat-1bis without real mobility and cell-edge testing.

5. Lab testing only

DT IoT acceptance covers network scenarios that lab testing does not fully reproduce, in particular inter-subsidiary roaming and real APN attach. Skipping field testing leads to failures uncovered after commercial signing.

6. eUICC without SGP.32 IPA verification

A GSMA-certified eUICC is not enough if the IPA on the device side is not SGP.32-conformant. IPA integration is as much a software-product topic as a hardware one, and SGP.22 / SGP.32 confusion remains common.

7. Confusing Cloud of Things with a network obligation

Cloud of Things is an optional application platform. No T-IoT acceptance step requires its use. Conversely, signing for CoT does not waive network and SIM acceptance.

8. Ignoring T-IoT bulletins

Like all carrier programmes, T-IoT evolves: newly accepted bands, gradual 2G retirement per subsidiary, APN updates, nuSIM profile evolutions. A long-cycle project must plan a periodic review of the T-IoT back-office.

Project sequencing and timing

The recommended order for a cellular IoT product targeting DT:

T-IoT commercial scoping: volume, countries, technologies, SIM choice (nuSIM, SGP.32 eUICC or physical), CoT or third-party platform.
Module selection: verify the candidate module's presence in the CamControl catalogue or schedule its submission. Cross-check against PTCRB (if US also in scope) and GCF.
Hardware design: antenna tuned to European DT bands, choice of an SoC compatible with nuSIM if retained.
Pre-validation: network testing on DE and CZ (representative sample), NB-IoT behaviour in the lab, simulated eUICC RSP or nuSIM provisioning.
T-IoT acceptance: back-office submission, campaign in a recognised lab, firmware iterations, catalogue listing.
Commercial activation: nuSIM SIM enrolment, APN opening, CoT integration if applicable.
Lifecycle tracking: declaration of firmware changes affecting radio or provisioning, monitoring of T-IoT bulletins.

For the broader EU view on RED, see CE vs FCC EMC and EU + US dual certification. For terminology (LPA, IPA, eUICC, eSIM, IMSI, ICCID, APN, NB-IoT, Cat-M, Cat-1bis), see the spilma glossary.