Verizon OPC: carrier homologation for cellular IoT after PTCRB

Author Hugues Orgitello Last updated 26 May 2026

Guide · Verizon OPC

You have obtained PTCRB certification and you thought the North American cellular chapter was closed. Verizon then adds a mandatory layer: Open Product Certification (OPC), driven from the Open Development (ODI) portal. PTCRB proves multi-carrier radio conformance, OPC proves interoperability with the Verizon network specifically. This page describes where OPC sits relative to PTCRB, how the ODI workflow operates, the two-tier module/device structure, the Verizon-specific tests, eUICC/LPA requirements, and the pitfalls that delay US market entry.

OPC vs PTCRB, the right separation

PTCRB and OPC are often conflated because they happen during the same project phase and share part of the testing effort. They do not, however, cover the same scope.

Criterion	PTCRB	Verizon OPC
Nature	Cross-carrier programme (AT&T, T-Mobile, Verizon, Bell, Rogers, Telus)	Verizon-specific programme
Reference	PTCRB test plans based on 3GPP TS 36.521 and TS 38.521	Verizon ODI test plan, superset of PTCRB + Verizon network requirements
Scope	Generic multi-carrier radio conformance	Verizon network interoperability, priority bands, eSIM, LPA, attach
Granted by	PVG (PTCRB Validation Group)	Verizon Wireless via ODI
Identifier	EPC (End Product Certification) or Modular Certification	Verizon OPC ID, IMEI added to the Verizon Approved database
Required for Verizon activation	Yes	Yes, in addition to PTCRB

PTCRB is a prerequisite but not sufficient. Without a valid PTCRB, Verizon does not accept OPC entry. With PTCRB alone, the product is rejected at Verizon activation. See PTCRB scope for the full list of carriers and covered bands.

A simple reading: PTCRB certifies that the radio respects 3GPP, OPC certifies that the product works on the Verizon network. The second requires the first; the first does not include the second.

The ODI portal, entry point

Open Development Initiative (ODI) is the Verizon portal any manufacturer must use to submit a cellular product. The ODI account is attached to the manufacturer's legal entity and provides access to:

• the Verizon Approved Module List (AML);
• the current OPC test plans for modules and devices;
• the certification project submission with tracking;
• the IMEI database once certification is granted;
• the lifecycle management (Class I/II/III change management);
• the Verizon technical bulletins (band changes, new eSIM requirements, CDMA retirement, 5G SA deployments and so on).

Opening an ODI account typically takes a few days, but the first certification submitted by a manufacturer entity goes through a deeper administrative review, especially for non-US manufacturers who must provide a US contact identity and a representation point.

Portal registration is free. OPC fees appear at the project submission stage and at each test session in an accredited lab.

Two-tier structure, module and device

Verizon OPC follows a two-step logic very similar to PTCRB. The major difference: the list of pre-approved Verizon modules is stricter than the PTCRB Modular Certification database, and a PTCRB-certified module is not automatically Verizon Approved.

Tier 1, OPC module

Applies to cellular module manufacturers (Quectel, u-blox, Telit, Sierra Wireless, Murata, Sequans, Fibocom and so on). The candidate module is tested for:

• radio conformance on Verizon priority bands: B2, B4, B5, B13, B66 in LTE, n5, n66, n77, n260, n261 in NR;
• attach behaviour, cell re-selection, PLMN locking;
• support for SGP.32-certified eSIM/eUICC;
• behaviour of the LPA (Local Profile Assistant), integrated or external;
• VoLTE / EPS Fallback per module profile;
• IMS and SMS-over-IP behaviour;
• LTE-M and NB-IoT power management (PSM, eDRX) for relevant modules.

On success, the module is added to the Verizon Approved Module List, making it usable as a pre-approved building block by integrators.

Tier 2, OPC device

Applies to the end product integrating a cellular module. Even with an AML-listed module, device OPC remains mandatory. The scope is integration, not the module radio itself:

• product antennas (gain, pattern, isolation, enclosure effects);
• power supply stability under network load;
• thermal management during long transmit sessions;
• application firmware and its interaction with the cellular stack;
• product-level eSIM/eUICC behaviour (LPA, profiles, OTA);
• end-to-end network behaviour (attach, dataflow, detach);
• resilience under real Verizon network conditions (handover, cell edge, signal loss);
• application-specific tests by product category (tracker, IoT gateway, POS terminal, medical device, industrial sensor and so on).

See PTCRB procedure for how this module-plus-device structure maps onto the project timeline.

The value of a Verizon-Approved module

Selecting a module already on the AML is the single most profitable optimisation in an OPC programme.

With a pre-approved module:

• the module OPC is already done, so faster and significantly cheaper on the module radio side;
• the module RF front-end is already validated on Verizon bands, reducing the risk of failure in RF Performance;
• the module's cellular stack is known to Verizon, accelerating firmware iterations if needed;
• the module LPA, if integrated, is typically already certified against Verizon SM-DP+.

Without a pre-approved module:

• OPC module must be conducted in addition to OPC device, in an accredited lab;
• the overall schedule extends by several weeks to a few months;
• the risk of failure on proprietary tests (for example fallback behaviour at cell edge) is higher.

This decision belongs in the design phase, not after the fact. Quectel BG770A-GL, u-blox SARA-R510M8S, Telit ME910G1, Murata 1SC, Sequans Monarch GM01Q are examples of modules regularly present on the AML in LPWAN segments. The list evolves; it must be checked at T0 of every project directly on the ODI portal.

OPC test categories

OPC tests group into five main families. For the equivalent PTCRB tests, see PTCRB tests.

RF Performance

The OPC RF test plan covers 3GPP TS 36.521-1 and TS 38.521-1 tests on Verizon priority bands, plus Verizon-specific tests not covered by PTCRB:

• measurements on Verizon-specific bands (B13 700 MHz, B66 AWS-3, n5, n66, n77, n260, n261);
• MaxPower per band requirements sometimes tighter than PTCRB;
• EVM and spurious emission checks under Verizon band configurations;
• carrier aggregation behaviour on common Verizon combos;
• C-V2X conformance for vehicular products (specific case).

These tests run on radio emulators (Anritsu MT8000A, Keysight UXM 5G, R&S CMX500) in a Verizon-accredited lab.

Network Performance and throughput

Verizon requires the product to demonstrate acceptable network performance beyond simple 3GPP conformance. Tests include:

• IP throughput under moderate and weak cellular conditions;
• handover behaviour between cells and between technologies (LTE to NR, 5G NSA to SA);
• re-selection behaviour at startup and after signal loss;
• initial attach time and re-attach after reset;
• stability of a sustained data session (multiple hours);
• PSM/eDRX behaviour for LPWAN modules, verified end-to-end, not only at modem level.

eUICC + RSP, specific requirements

Verizon has placed eSIM at the centre of the modern OPC programme, see the dedicated section below.

Application and data tests

Depending on product category, Verizon adds application tests. Examples:

• GPS/cellular tracker: location call behaviour, response time, power-saving mode;
• IoT gateway: multi-connection management, MQTT/HTTP/CoAP payload retransmission;
• POS: EMV encryption, transaction timeouts, behaviour under coverage loss;
• Connected medical device: timestamping, data chain integrity, behaviour on disconnect;
• IP camera: sustained upstream bandwidth, buffer management on signal loss.

These are not systematic but are requested at submission review based on the product description.

Security and provisioning

The product must demonstrate that it provisions its connectivity securely: default PIN, deactivation of non-Verizon profiles in test mode, credential encryption, SM-DP+ certificate management.

eUICC and RSP, the structuring topic for 2025-2026

Since the release of GSMA SGP.32 in 2023 and its gradual carrier adoption, Verizon has made eUICC and IoT RSP a central axis of its OPC programme. It is also the topic where manufacturers are most often caught out.

Two GSMA references, SGP.22 and SGP.32

Distinguish:

• GSMA SGP.22: Consumer RSP, consumer eSIM (smartphones, watches, tablets). The device has a local LPA (LPAd) that talks to a carrier SM-DP+ and SM-DS. Profile downloaded via QR code or application.
• GSMA SGP.32: IoT RSP, designed for the constraints of connected objects (no UI, large fleets, fleet management). Introduces the eSIM IoT Manager (eIM) role and redefines the split between IPAd (IoT Profile Assistant device) and IPAe (IoT Profile Assistant eUICC).

Verizon typically aligns OPC on SGP.22 for consumer products and SGP.32 for modern IoT products. Older devices on M2M Architecture (SGP.02) are end-of-life on Verizon, with a retirement window communicated via ODI.

LPA and IPAd requirements

Verizon requires a conformant LPA-Device (LPAd) or IPA-Device (IPAd) implementation on the product side:

• handshake with the Verizon SM-DP+ (specific URL and root certificate);
• ES9+ support for profile download;
• ES10b support for device-side eUICC management;
• enable / disable / delete profile operations without hardware reset;
• local API exposed to orchestrate these operations from the application firmware;
• behaviour on network failure during download (clean rollback, actionable error log).

On the eUICC chip side, the component must be GSMA SAS-UP certified and the eUICC OS must support the functions called by the Verizon LPA.

Verizon SM-DP+ acceptance

The Verizon SM-DP+ enforces TLS compatibility requirements (cipher suites, certificates), the LPA's ability to interpret profile metadata published by Verizon, and expected behaviour during profile activation. OPC testing includes a complete profile download session from the Verizon SM-DP+ under all network conditions foreseen in the test plan.

Frequent eUICC pitfalls

• eUICC not SGP.32-certified in a modern IoT product, Verizon refuses it at OPC.
• Proprietary LPA that does not implement ES9+/ES10b standards, incompatible with the Verizon SM-DP+.
• SGP.22 / SGP.32 confusion on the same product, the LPA does not correctly implement the intended scope.
• Profile metadata misread, the Verizon profile is downloaded but does not activate correctly.
• TLS on ES9+ too old (strict TLS 1.2), SM-DP+ connection refused.

These pitfalls are the most common cause of OPC failure on a modern cellular IoT product. They are not covered by PTCRB, which does not test the eUICC + LPA + SM-DP+ chain with a real carrier.

Accredited labs

Not every PTCRB lab is also OPC-accredited. Verizon publishes a list of labs recognised for its testing, which typically includes:

• Bureau Veritas Connectivity (formerly 7Layers);
• Element Materials Technology;
• DEKRA;
• Sporton International;
• PCTEST;
• some carrier-proprietary labs in North America.

The list evolves. It must be checked on the ODI portal before booking each campaign. A lab that produces valid PTCRB and FCC reports cannot, by default, submit OPC reports to Verizon without specific accreditation.

For European manufacturers, two labs are historically organised to run OPC campaigns from Europe (with equipment shipped to US OTA chambers when required). For logistics planning, see also certification costs and certification timeline.

Qualitative cost and schedule

Verizon does not publish a public rate card. OPC costs depend on:

• the product category (simple module, gateway, complex application device);
• the presence or absence of a Verizon-Approved module (the single biggest lever);
• the number of target Verizon bands;
• the eUICC/LPA complexity (LPA integrated in the module or re-implemented);
• the number of iterations to expect if the first campaign fails.

Qualitatively, OPC adds to PTCRB in both schedule and cost. For an IoT product with a pre-approved module, expect several additional weeks and a budget of a few tens of thousands of dollars in lab and OPC fees. Without a pre-approved module (so OPC module + OPC device), the additional schedule and budget may roughly double.

These figures are indicative. The final quote depends on the exact test plan Verizon retains at submission, and should be built with an OPC-accredited lab after scope definition.

Articulation with chipset pre-certification

Chipset vendors (Qualcomm, MediaTek, Sequans, UNISOC) produce pre-certification reports on their reference platforms. These reports typically cover:

• radio conformance on global bands;
• IMS and VoLTE behaviour;
• support for advanced 3GPP features (CA, MIMO, DAPS handover and so on);
• eSIM/LPA pre-validation on the reference chip.

These reports accelerate OPC but do not replace it. Verizon accepts them as prior evidence in the submission, which makes it possible to narrow the device-level test scope to the actual risk areas (antenna integration, application firmware, power management, product LPA). The Verizon PVG decides case by case what can be inherited from the chipset vendor and what must be redone.

Note: a chipset vendor report on a legacy platform may be ignored entirely if the current Verizon test plan has evolved since pre-certification. Confirming the test plan baseline version is a prerequisite.

Post-OPC lifecycle management

Verizon classes post-OPC modifications in three tiers:

• Class I: major change affecting radio or eSIM provisioning. Full OPC re-certification required.
• Class II: significant change (cellular stack firmware, power table, IMS features). Delta OPC with targeted testing.
• Class III: minor application change with no network impact. ODI notification only, no testing.

This logic is close to PTCRB and to the FCC framework on Class II/III changes (see FCC tests for the regulatory counterpart). Continuous ODI dossier management is part of the total cost of ownership, not only the initial certification.

Manufacturers sometimes forget this dimension and deploy a Class II firmware without declaration. The consequence: the delta is not validated, and the product can be deactivated by Verizon during an IMEI audit.

Common pitfalls

1. Assuming PTCRB is enough for Verizon

This is the structural error. A PTCRB-certified product without OPC will work temporarily on Verizon in test mode or via partner SIMs but will be blocked at commercial activation. The discovery often happens right before launch, when the commercial team attempts to activate the first Verizon SIMs.

2. Picking a non-Verizon-Approved module by default

Many teams select a module on PTCRB and cost criteria alone. If the project targets Verizon, the Verizon Approved Module List filter must be applied at module selection, not afterwards. Switching modules mid-project is costly in PCB redesign, antenna redesign, FCC re-validation, PTCRB re-test, and of course OPC.

3. eUICC without a conformant LPA

A standalone certified eUICC is not enough, the device-side LPA must also be conformant and certified. Many integrators buy a GSMA-certified eUICC but re-implement a proprietary LPA that does not pass OPC. Solution: use the module's LPA when integrated and certified, or a certified third-party LPA aligned on SGP.22/SGP.32.

4. SGP.02 / SGP.22 / SGP.32 confusion

SGP.02 is the legacy M2M architecture (push-mode, SM-SR/SM-DP), being retired by Verizon. SGP.22 is the consumer model (pull-mode), and SGP.32 is the modern IoT model. Trying to use SGP.02 on a new IoT product triggers a Verizon rejection. Conversely, using SGP.22 on a headless IoT product creates activation UX problems (QR code, no screen).

5. Late discovery of Verizon-specific requirements

The OPC test plan evolves. Verizon regularly publishes ODI bulletins announcing new requirements (for example n77 5G SA support, SGP.02 to SGP.32 migration, CDMA retirement, attach policies). Manufacturers who do not monitor these bulletins find themselves out of conformance at submission. A quarterly ODI review during the design phase is essential.

6. PTCRB lab picked by default

A PTCRB lab is not automatically Verizon OPC accredited. Launching the PTCRB campaign without first confirming the lab's OPC accreditation leads to a double bill: OPC tests have to be redone elsewhere. To be scoped upfront.

7. Underestimating the ODI administrative phase

Opening the ODI account, the administrative validation for non-US manufacturers, and the PVG Verizon review take time. For a first-time European submitter, plan several weeks of administrative work before the first test.

8. Mixing OPC with AT&T/T-Mobile homologation

Every carrier has its own programme (AT&T NDD, T-Mobile 5G SA Certification). OPC is Verizon-only. Trying to use an OPC report at AT&T (or vice versa) has no value. To target the three US carriers, plan three distinct programmes on top of PTCRB. See PTCRB pitfalls for the broader view.

Project timing, the right sequence

The recommended order for a cellular product targeting Verizon:

1. Module design phase: select a Verizon-Approved module, resolve the SGP.22/SGP.32 question, pick a certified LPA.
2. Hardware stabilisation phase: open the ODI account, identify the OPC-accredited lab, brief the Verizon PVG on the product category.
3. Pre-certification phase: RF pre-tests, OTA pre-tests, LPA + Verizon SM-DP+ pre-validation (often in a test SM-DP+ environment provided by GSMA or by the eUICC vendor).
4. PTCRB phase: Modular then End-Product submission, EPC granted.
5. OPC phase: ODI submission, accredited-lab testing, firmware iterations if needed, OPC ID granted.
6. Verizon activation phase: IMEI range registration, activation verification, commercial launch.
7. Lifecycle phase: ODI bulletin monitoring, Class I/II/III change declaration.

For the global EU + US sequence including CE/RED, see EU + US dual certification and certification timeline.

Connection with other US certifications

Verizon OPC scope is distinct from other US requirements:

• FCC, intentional and unintentional emitters: independent. FCC ID obtained via TCB, with no Verizon dialogue.
• FCC radio bands: overlap with Verizon bands but the test plans are disjoint, measurements can be shared but reports cannot.
• FCC tests: cover intentional emissions; OPC adds carrier network conformance.
• PTCRB tests: form the common multi-carrier baseline that OPC extends for Verizon.

A cellular product sold on Verizon in the United States therefore accumulates: FCC ID (regulator), PTCRB EPC (carrier consortium), Verizon OPC ID (Verizon-specific), and an IMEI activated in the Verizon Approved database.

For the vocabulary (PVG, EPC, LPA, IPAd, SM-DP+, eUICC, ODI), see the spilma glossary.

Verizon cellular IoT programme

Let's scope your PTCRB + OPC dossier in 30 minutes.

AESTECHNO designs the joint PTCRB and Verizon OPC campaign, selects a Verizon-Approved module compatible with your design, and secures the SGP.22/SGP.32 eUICC requirements, free, by video call.

Book a cellular audit

Sources & references

1. Verizon Open Development portal , Verizon opendevelopment.verizonwireless.com/
2. Verizon Open Development, certified devices and modules , Verizon opendevelopment.verizonwireless.com/devices
3. PTCRB Certification Program , PTCRB www.ptcrb.com/
4. GSMA eSIM specifications hub (SGP.22, SGP.32) , GSMA www.gsma.com/esim/
5. GSMA SGP.32, eSIM IoT Technical Specification , GSMA www.gsma.com/esim/iot-esim/
6. 3GPP TS 36.521 and TS 38.521, UE RF conformance specifications , 3GPP www.3gpp.org/specifications-technologies