PTCRB pitfalls: 12 errors the PPMD and NAPRD03 catch

Hugues Orgitello updated 7 Oct 2026 13 min read

Twelve recurring PTCRB errors, and the clause that catches each one. Every pitfall below rests on a numbered section of the documents in force on October 7, 2026: the Program Management Document PPMD V4.2 and the technical requirements NAPRD03 V6.26, both dated October 2026, plus the band list PVG.11 V5.24.0. Three families: scoping, radiated performance and module integration, and life after certification. Earlier versions of this page gave dB penalties, PCB dimensions and capacitor values that no PTCRB document contains; they have been removed, and the last section lists them.

The twelve pitfalls at a glance

#	Pitfall	Clause that catches it
1	Treating PTCRB as the US approval, or FCC as optional	PPMD 1.1, 11.3.1.8
2	Designing on a technology PTCRB no longer covers	PPMD 1.1, Revision History V4.0
3	Submitting an IoT device down the wrong route	PPMD 11.3.1.3, Certified Chipset definition
4	Picking bands from hearsay instead of PVG.11	NAPRD03 2.8, 2.11
5	Assuming the module covers the radiated performance	NAPRD03 2.9, 2.9.1, 2.9.2
6	One receive antenna on an LTE Category 1 or higher device	NAPRD03 2.9.4
7	Changing the antenna after certification	PPMD 11.6.4, 11.6.4.2
8	Swapping the module revision without a review	PPMD 11.6.4.1, 11.6.4.2
9	Getting the IMEI and TAC rules wrong	PPMD 8.1 to 8.6, 11.4.3.8
10	Shipping firmware without an ECO or a new SVN	PPMD 8.2.1, 11.3.2, 11.6.1, 10.1
11	Adding bands or features by software as if it were free	PPMD 11.6.10
12	Letting the NAPRD03 version drift	PPMD 5.2.1, 5.2.2, 11.7, 11.11.2

Family 1: Scoping errors

1: Treating PTCRB as the US approval, or FCC as optional

PTCRB is an industry certification administered by CTIA Certification, not a government rule: PPMD 1.1 calls the process "recommended" for manufacturers whose devices are expected to operate on the networks of the participating operators. The legal requirement in the United States is FCC equipment authorization under 47 CFR Part 2, Subpart J (ISED in Canada).

The two are linked in one direction. PPMD 11.3.1.8 requires an FCC Grant covering all technologies and frequency bands supported by the device, under the applicable rule parts (the PPMD names Parts 22H, 24E, 27, 90 and 30), and the FCC ID must be entered in the PTCRB submission before PTCRB certification is received. Canada works the same way with an ISED Technical Acceptance Certificate.

How to avoid it: start the FCC and ISED grants early enough that their IDs exist when the PTCRB file closes, and make sure the grant covers every band the device will have enabled.

2: Designing on a technology PTCRB no longer covers

PPMD V4.2 covers UTRA, E-UTRA (including LTE-M and NB-IoT), NTN and NR devices (Section 1.1). GSM requirements were removed in PPMD V4.0 (October 2025), and GERAN and UTRA radiated spurious emission requirements in V4.1 (December 2025). UTRA Bands II and V are still PTCRB bands in NAPRD03 V6.26. On the network side, T-Mobile states that it retired its 3G UMTS network on July 1, 2022 and set the retirement of its 2G GSM network for August 3, 2026.

How to avoid it: build a long-life product on E-UTRA (LTE-M, NB-IoT or higher categories) or NR, and check each target operator's own network roadmap before relying on a legacy RAT.

3: Submitting an IoT device down the wrong route

Since PPMD V4.0, "with the exception of Notebooks and Tablets, devices incorporating a Module or Embedded Modem will be submitted for IoT Network Certified certification" (PPMD 11.3.1.3). An embedded modem is always submitted as an IoT Device. Planning a "reduced PTCRB device certification" for an IoT product on a certified module plans for a route that no longer exists.

Two related traps:

• Certified Chipset results can be leveraged only in an LTE-M or NB-IoT module, or in an IoT device supporting NB-IoT or LTE-M. They cannot be leveraged for smartphones, feature phones, notebooks, tablets or LTE Category 1 and higher IoT devices (PPMD, Certified Chipset definition).
• An FR2 module runs FR2 protocol test cases only; FR2 RF, performance and RRM testing moves to the end product (PPMD 11.9.2).

How to avoid it: decide the route from the device type before booking the lab. The procedure page has the route and fee table.

4: Picking bands from hearsay instead of PVG.11

The PTCRB bands are those of NAPRD03 V6.26 Table 2.8-1, and PVG.11 is the normative source: in case of conflict, PVG.11 prevails (NAPRD03 2.8). Band lists copied from older guides are often wrong:

Common shorthand	What PVG.11 V5.24.0 and NAPRD03 V6.26 say
"AT&T uses B17"	Band 17 is not a PTCRB band; Band 12 is, supported by AT&T, Bell, EchoStar, FirstNet, Rogers, Telus and T-Mobile
"B13 at Verizon"	Band 13 is supported by Bell, Eastlink and Telus; Verizon is not named on any single band
"B71 at T-Mobile"	Band 71 is supported by Eastlink, Rogers and T-Mobile, and PVG.11 Table 5 marks it standardised for NB-IoT but not for LTE-M
"n66 multi-operator"	Correct: n66 is supported by AT&T, Bell, Eastlink, EchoStar, FirstNet, Rogers, Telus and T-Mobile

A second band trap is at test time: certification "shall be conducted with all frequency bands enabled according to its capabilities", and devices "shall not be reconfigured for any testing purposes" (NAPRD03 2.11). A band left enabled in firmware is a band that gets tested.

How to avoid it: take the band set from PVG.11 for your target operators, check the LTE-M and NB-IoT columns if you build an LTE-M or NB-IoT product, and freeze the enabled bands before testing. The full band and operator tables are on the scope page. Operator programs on top of PTCRB (AT&T, Verizon, T-Mobile) are a separate check: the ptcrb.com "Get Certified" page asks manufacturers to verify whether the device needs additional operator-specific testing.

Family 2: Radiated performance and module integration

5: Assuming the module covers the radiated performance

"RF Performance Evaluation is a mandatory requirement for all device types going through PTCRB or IoT Network Certified certification" (NAPRD03 2.9). The test plan is the version of the CTIA Certification Test Plan for Wireless Device Over-the-Air Performance in effect when the request is submitted. The module certificate does not carry over your housing, antenna placement or enclosure.

NAPRD03 sets no TRP or TIS figure of its own. What it does set:

• For non-IoT devices, the manufacturer "shall consult with the Target Operator(s) to determine whether they have unique OTA test requirements" (2.9.1).
• For IoT devices, three questions in Table 2.9.2-1 (more than 100 Kbytes per transaction, more than 24 transactions a day on average, fixed orientation relative to the horizon) decide the OTA test scope. With three "No" answers, TRP runs on all channels and TIS on the mid channel above 1 GHz and on low, mid and high channels below 1 GHz; a fixed-orientation device runs NHPRP and NHPIS ±30° instead (2.9.2).
• An IoT device is tested in its highest-order RAT, in every band of that RAT (2.9.2).

How to avoid it: answer the three Table 2.9.2-1 questions at design time, ask the target operators for their OTA requirements, and run pre-scans on the final enclosure before the formal OTA session.

6: One receive antenna on an LTE Category 1 or higher device

NAPRD03 2.9.4 recalls that, per 3GPP TS 36.306, LTE Category 1 and higher devices are required to support two antennas, with the exception of Category 1bis. A device that cannot support the secondary antenna must submit a waiver request; if approved, the Primary lab checks the "LTE Single-Antenna Receiver" box. This check applies to all devices, whether or not they go through OTA testing.

How to avoid it: decide the antenna count with the LTE category. A single-antenna design fits LTE-M, NB-IoT or Category 1bis; for Category 1 and above, budget the second antenna or the waiver.

7: Changing the antenna after certification

For any ECO with an antenna change, the Primary lab decides whether TRP, C-TIS, TIS, RSE, NHPRP or NHPIS testing is required, and whether full OTA testing or spot-checks are enough (PPMD 11.6.4). For an IoT Device ECO, a laboratory review is always required if "the antenna used in the ECO has changed in any way from the antenna used in the Parent" (11.6.4.2).

If radiated testing is required, the 2 dB rule applies: the ECO TRP may be no more than 2 dB below the Parent TRP, and its TIS or C-TIS no more than 2 dB above the Parent figure; the same rule applies to NHPRP and NHPIS where they replace TRP and TIS (11.6.4.2). This is the only dB figure the PTCRB documents attach to an antenna change.

How to avoid it: treat any antenna change (part number, cable, placement, matching) as an ECO, and compare pre-scan results against the Parent before submitting.

8: Swapping the module revision without a review

When a module goes through an ECO, its Primary lab assesses whether IoT devices using previous versions of the module need testing to use the new one (PPMD 11.6.4.1). On the IoT device side, a laboratory review is always required if any module revision after the one in the Parent indicates that testing is required, or if the ECO uses an earlier module revision than the Parent (11.6.4.2). Only a change limited to the IoT device software that does not affect the test requirements of 11.10.3 needs no lab review.

How to avoid it: track the module revision in each product build, read the module ECO assessment when the supplier changes it, and never fall back to an older module revision without a lab review.

Working on integrating a PTCRB-certified cellular module into an IoT product for a real product? AESTECHNO can audit your design and certification plan. Get in touch

Family 3: Post-certification errors

9: Getting the IMEI and TAC rules wrong

The IMEI is "a unique 15-digit code" (PPMD 8.1). The Reporting Body allocates the TAC, the manufacturer assigns the six serial digits to individual units, and the check digit uses the Luhn formula over the first 14 digits (3GPP TS 23.003). The rules that trip projects:

Rule	PPMD V4.2
A test IMEI (Reporting Body Identifier 00) is for prototype testing only, "could be blacklisted after testing" and cannot be used for final certification	8.1, 8.3.2
The final hardware in the test report must carry a production IMEI	11.4.3.8
A production TAC starts with 01 and covers 1,000,000 units; beyond that, an additional TAC	8.1, 8.2.10
A TAC cannot be shared across model numbers, except when operators allow it for models marketed as one, told apart by the SVN	8.2
A TAC request is reserved for 120 days, then revoked if the device is not certified	8.6
Module makers keep a mapping of the manufacturer or distributor each IMEI was shipped to; notebook and tablet integrators keep a model number to IMEI mapping; both available to operators on request	8.2.2.2

How to avoid it: request the production TAC close to the test campaign, since the reservation lapses after 120 days without certification, record every assigned serial in a production database that rejects duplicates, compute the Luhn digit automatically, and never ship a unit with a test IMEI.

10: Shipping firmware without an ECO or a new SVN

An ECO is required for any change to the hardware or hardware version, any radio or protocol stack change that changes the software version or SVN, and any recompilation of the radio or protocol stack (PPMD 11.6.1). The SVN must be updated when the radio or protocol software changes or is recompiled "for any reason", and revised in ascending, sequential order (8.2.1). Security-only patches to the radio stack component, and MMI-only changes that do not affect radio or protocol functions, do not need a unique SVN (11.6.1, examples 3 and 4).

Software loaded by FOTA must bit-match the certified software; otherwise it must itself be certified (11.3.2). Knowingly changing a certified device in a way that affects its certification requirements or network performance without recertifying is a certification violation, and CTIA Certification may revoke the certification (10.1).

How to avoid it: tie the release process to the SVN: any build that touches the radio or protocol stack gets a new SVN and an ECO request before it is pushed by FOTA.

11: Adding bands or features by software as if it were free

PPMD 11.6.10 limits what an ECO can change:

• bands and features can be added or removed through an ECO only if they are enabled by a software update, with an updated SVN;
• voice capabilities (circuit switched voice, VoLTE, VoNR) can never be enabled or disabled through an ECO;
• a band or feature change that needs a matching hardware change goes through the Variant process, with a new model name or number;
• enabling a new technology (3G, 4G, 5G) is a new platform and needs an Initial Certification.

This section does not apply to IoT Devices: their band and feature change rules are in the How to Get IoT Network Certified guide.

How to avoid it: decide the voice and RAT set at the first certification; plan a later band unlock as a software-only ECO, and check the IoT Network Certified guide if the product is an IoT Device.

12: Letting the NAPRD03 version drift

"NAPRD03 will be released four times per year" (PPMD 5.2.1). A device must complete the applicable tests of one of the two most recent NAPRD03 versions (5.2.2), judged on the date the test reports are uploaded (11.7). A campaign that runs past two releases has to move to a newer version. On October 7, 2026 the current version is NAPRD03 V6.26. The PPMD itself may be released at any time, and each new version supersedes all previous ones on release (5.3).

The PPMD sets no expiry date for a device certification. Its only three-year rule concerns modules in notebook and tablet platforms: the NAPRD03 version used to certify the module stays valid for new platforms for three years from the module's last certification that required testing, if the module software is unchanged; after that the module must re-certify to the latest NAPRD03 (11.11.2).

How to avoid it: note the NAPRD03 version in the test plan, track the quarterly releases while testing runs, and treat recertification as change-driven (ECO), not calendar-driven.

Claims the texts contradict

Claim (including on earlier versions of this page)	What the documents say
"B12/B17 for AT&T, B13 for Verizon"	Band 17 is not in NAPRD03 V6.26 Table 2.8-1 or PVG.11. PVG.11 lists Bell, Eastlink and Telus for Band 13; Verizon is named on no single band
"A compact PCB antenna degrades TRP and TIS by 3 to 6 dB"	No PTCRB document gives such a figure. The only dB figures are the IoT Device ECO 2 dB rule against the Parent (PPMD 11.6.4.2) and the ±1 dB conducted power threshold for skipping OTA on an ECO (NAPRD03 2.9.3)
"Respect the antennas listed in the module Integration Guide" as a PTCRB rule	Neither PPMD V4.2 nor NAPRD03 V6.26 mentions an Integration Guide; the end product is judged by its own OTA results (NAPRD03 2.9)
"Plan a PCB of at least 60 mm for low bands" and "100 µF + 10 µF + 100 nF + ferrite" filtering	No PTCRB document sets ground plane, PCB size or supply filtering rules. EVM is a 3GPP conducted RF test (TS 36.521-1, 6.5.2.1) run on the device like any other
"Modules dissipate 2 to 5 W and throttle"	No PTCRB document contains thermal requirements or figures; the claim has been removed
"NAPRD03 evolves several times a year"	Four times a year, according to the PTCRB Working Group meeting schedule (PPMD 5.2.1)
"A certification older than three years may need recertification"	No device certification expiry exists in the PPMD; the three-year rule is the NAPRD03 validity of a module used in new notebook or tablet platforms (11.11.2)
"Many FCC and PTCRB tests are shareable"	No PTCRB document provides for such reuse; PTCRB relies on 3GPP conformance specifications and CTIA test plans, FCC on the 47 CFR rule parts
"PTCRB is only the first step before every operator"	PTCRB is recommended (PPMD 1.1); any further program is each operator's choice, and IoT devices on a module now go through IoT Network Certified
Maturity targets such as "ECO request within 8 weeks" or "operator incident resolution within 30 days"	No PTCRB document sets these targets; they have been removed, along with the operator incident procedure, which has no PTCRB clause

In summary

The twelve PTCRB pitfalls break down into three families:

1. Scoping (1 to 4): FCC ID required before the award, a technology PTCRB no longer covers, the wrong route for an IoT device, bands not taken from PVG.11.
2. Radiated performance and integration (5 to 8): OTA mandatory for every device type, two antennas from LTE Category 1, the 2 dB rule on antenna changes, module revision reviews.
3. Post-certification (9 to 12): IMEI and TAC rules, SVN and ECO discipline, software-only band changes, the quarterly NAPRD03 cycle.

For practical implementation, see PTCRB procedure and Tests. The technical file lists what goes in the submission, the scope has the band tables and the FAQ the common questions.

See also

• Component substitution rules: how BOM swaps trigger PTCRB delta retesting.
• Change management and FCC class II permissive: keeping FCC and PTCRB in sync when the design moves.
• Antenna design and impedance matching: typical antenna mistakes behind PTCRB OTA failures.
• Recall and Safety Gate response: handling a post-market cellular incident on operator networks.
• NTT DOCOMO, KDDI, SoftBank Japan operator acceptance: operator-side pitfalls to anticipate beyond PTCRB.
• PTCRB overview: who certifies, documents in force, official fees.
• FCC ID, grantee and TCB: the FCC ID that must be in the PTCRB request.

Sources & references

1. PTCRB, Get Certified (process and requirements documents), PTCRB / CTIA www.ptcrb.com/get-certified/
2. PTCRB Program Management Document (PPMD) V4.2, October 2026, CTIA Certification www.ptcrb.com/wp-content/uploads/2026/10/PTCRB-PPMD-V4.2.pdf
3. PTCRB NAPRD03 V6.26, October 2026, CTIA Certification www.ptcrb.com/wp-content/uploads/2026/10/NAPRD03-V6.26.pdf
4. PVG.11 V5.24.0, PTCRB bands and supporting operators (XLSX), CTIA Certification www.ptcrb.com/wp-content/uploads/2026/10/PVG-11-V-5.24.0.xlsx
5. IoT Network Certified, CTIA Certification iotnetworkcertified.com/
6. eCFR, 47 CFR Part 2 Subpart J, Equipment Authorization Procedures, US Government (eCFR) www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-2/subpart-J
7. 3GPP TS 23.003, Numbering, addressing and identification, 3GPP www.3gpp.org/ftp/Specs/archive/23_series/23.003/
8. T-Mobile network evolution (key dates), T-Mobile www.t-mobile.com/support/coverage/t-mobile-network-evolution