What is the difference between AT&T NAF and NAFI?

NAF (Network Approval Facility) is the historical name of the AT&T carrier homologation programme for cellular terminals. NAFI (Network Approval Facility for IoT) is the evolved name, refocused on the constraints of connected objects, with explicit coverage of LTE Cat-1, Cat-M, NB-IoT and 5G NR. In current AT&T documentation both acronyms coexist and refer to the same approval framework. The active IoT test plans are branded NAFI.

Why is PTCRB not enough to activate a product on the AT&T network?

PTCRB covers 3GPP radio conformance shared across North American carriers, it is a necessary but generic cross-carrier foundation. AT&T adds its own NAF / NAFI programme to validate interoperability with its core network, application and network behaviour (attach, dataflow, fail-over), AT&T priority bands (notably B66, n66, n77, n5), eSIM requirements and conformance to carrier attach policies. Without NAFI, the product IMEI is not listed in the AT&T approved database.

What is the difference between AT&T module approval and device approval?

Module approval applies to the cellular module (Quectel, u-blox, Telit, Sierra Wireless, Murata, Sequans, Fibocom). When the module is already on the AT&T approved module list, that step has been completed at the supplier level. Device approval covers the final product integrating the module: antennas, power supply, thermal management, application firmware, end-to-end network behaviour. A pre-approved module significantly shortens device approval but does not eliminate it.

Which AT&T bands are specifically tested in NAFI?

AT&T concentrates its testing on its active deployment bands in North America. In LTE, typical coverage includes B2, B4, B5, B12, B14, B30 and B66. In 5G NR, AT&T focuses on n5, n66 (AWS-3 mid-band) and n77 (C-band). The exact active test plan is published via the AT&T IoT portal and evolves with the operator's deployment roadmap, so it must be checked at each submission.

Does eUICC change the AT&T homologation procedure?

Yes. AT&T aligns on GSMA SGP.22 (consumer RSP) and SGP.32 (IoT RSP) and requires the device-side LPA or IPA to be able to dialogue with the AT&T SM-DP+. Testing covers profile download, enable, disable, delete, error handling, and interpretation of AT&T profile metadata. An eUICC absent from the GSMA list or a non-compliant proprietary LPA is a common cause of rejection, exactly as it is at the other North American tier-1 carriers.

Is FirstNet covered by NAFI?

No. FirstNet (the dedicated network for US public-safety services on band B14) is a separate programme operated by AT&T but with its own security, priority, interference-prevention and IMEI-listing requirements. A NAFI-approved commercial terminal is not automatically FirstNet-approved, and vice versa. For a product targeting public-safety users, the FirstNet programme must be conducted in addition to NAFI.

What is the impact of AT&T 3G and 2G sunset on new approvals?

AT&T completed its 3G shutdown in 2022 and its 2G shutdown earlier. NAFI no longer approves products on these technologies, and a module relying on a 2G or 3G fallback no longer makes sense on the US AT&T network. New approvals concentrate on LTE Cat-1, LTE-M, NB-IoT and 5G NR, with strong attention to IPv6 readiness and to the ability to sustain a prolonged data session on LTE alone.

Which labs can perform AT&T NAFI testing?

AT&T publishes a list of labs recognised for its IoT programme that does not fully overlap with the PTCRB lab list. Labs commonly cited include Bureau Veritas Connectivity (formerly 7Layers), Element Materials Technology, DEKRA, Sporton International, PCTEST, plus AT&T internal labs for certain network tests. The current status of any given lab must be confirmed via the AT&T IoT portal before booking a campaign.

AT&T NAF / NAFI: carrier homologation, cellular IoT

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

Guide · AT&T NAF / NAFI

After PTCRB, a cellular IoT product targeting the US market encounters a second approval layer: carrier homologation. At AT&T, the process was historically called NAF (Network Approval Facility) and is now known as NAFI (Network Approval Facility for IoT), an evolution refocused on low-UI connected terminals, on IoT eSIM and on modern AT&T deployment bands. This page describes where NAFI sits relative to PTCRB, how the AT&T IoT portal and its approval workflow operate, the module vs device split, eUICC requirements, the specific place of FirstNet, and the pitfalls that delay durable service on the AT&T network.

NAF, NAFI, and the carrier scope

NAF (Network Approval Facility) historically named the approval framework for cellular terminals on the AT&T Mobility network. NAFI (the IoT-oriented evolution) keeps the framework but adapts it to connected objects: no screen, no end user manually triggering activation, strong power constraints, fleet management. Both acronyms coexist in AT&T documentation; "NAF" still appears in legacy pages while active IoT test plans carry the NAFI label.

The underlying idea is constant: AT&T, US tier-1 carrier, only allows on its commercial network products whose IMEI has been recorded in its database after a test campaign run against its test plan. Without that listing, network attach is refused, either immediately or during a later audit.

NAFI vs PTCRB, the right separation

PTCRB and NAFI are often conflated. They happen in the same project phase and share part of the radio testing, but their scope is distinct.

Criterion	PTCRB	AT&T NAFI
Nature	Cross-carrier programme (AT&T, T-Mobile, Verizon, Bell, Rogers, Telus)	AT&T-specific programme
Reference	PTCRB test plans based on 3GPP TS 36.521 and TS 38.521	AT&T IoT test plan, superset of PTCRB plus AT&T network requirements
Scope	Generic cross-carrier radio conformance	AT&T network interoperability, priority bands, throughput, eSIM, attach
Granted by	PVG (PTCRB Validation Group)	AT&T Mobility via the IoT portal
Identifier	EPC (End Product Certification) or Modular Certification	AT&T certification number, IMEI added to the AT&T approved database
Required for AT&T activation	Yes	Yes, in addition to PTCRB

PTCRB is a prerequisite, not sufficient. Without a valid PTCRB report, AT&T does not accept NAFI entry. With PTCRB alone, the product is filtered at commercial activation on the AT&T network. See PTCRB scope for the full list of carriers and covered bands.

Simple reading: PTCRB certifies that the radio respects 3GPP, NAFI certifies that the product works specifically on the AT&T network, in its priority bands, with its attach policies and with its eSIM scheme.

The AT&T IoT portal, entry point

The AT&T IoT portal (business.att.com/products/iot and iotdevices.att.com for the technical side) is the only submission route. The account is attached to the manufacturer's legal entity and provides access to the AT&T approved module list, the current NAFI test plans, the certification project submission with tracking, the IMEI database once approval is granted, AT&T technical bulletins and post-approval lifecycle management.

Opening the account is usually quick for a US manufacturer. For a European manufacturer submitting for the first time, plan for a longer administrative phase, with validation of a US point of contact. AT&T does not publish a fee schedule; fees appear at project submission and at each test session in a recognised lab.

Two-tier structure, module and device

NAFI follows the same logic as PTCRB and as the other North American carrier programmes: approval at module level and approval at end product level.

Tier 1, module approval

Applies to cellular module makers (Quectel, u-blox, Telit, Sierra Wireless, Murata, Sequans, Fibocom). The candidate module is evaluated for radio conformance on AT&T priority bands (B2, B4, B5, B12, B14, B30, B66 in LTE, n5, n66, n77 in NR), attach, cell re-selection and PLMN locking behaviour on AT&T, eSIM/eUICC support certified to SGP.32, module-side LPA / IPA behaviour, VoLTE / EPS Fallback, LTE-M and NB-IoT power management (PSM, eDRX), and IMS / SMS-over-IP behaviour. Once approved, the module is added to the AT&T approved module list.

Tier 2, device approval

Applies to the final product integrating a cellular module. Even when the module is on the AT&T list, device approval remains mandatory. The scope covers integration, not the raw radio behaviour: product antennas (gain, pattern, isolation, enclosure), power supply stability under network load, thermal management during long transmission sessions, application firmware and its interaction with the cellular stack, product-level eSIM / eUICC behaviour, end-to-end network behaviour (attach, dataflow, disconnect), throughput in AT&T bands, fail-over when the priority cell is unavailable, and application tests by category (tracker, IoT gateway, POS, medical device, industrial sensor).

See PTCRB procedure for project timeline and PTCRB tests for the cross-carrier radio foundation.

The benefit of an already-approved AT&T module

Selecting from the start a module already on the AT&T list is the most effective optimisation of a NAFI programme. Module approval is already done, the RF front-end is validated on AT&T priority bands, the cellular stack is known to AT&T (speeding up firmware iterations), the integrated LPA / IPA is typically already qualified against the AT&T SM-DP+, and the risk on AT&T-specific tests (for example B14 to B66 fallback behaviour) is lower.

Without a pre-approved module, module approval must be run in addition to device approval, in a recognised lab. The schedule lengthens and the iteration risk increases. A decision to make at module selection time, not afterwards.

AT&T bands, what is specifically tested

NAFI focuses on bands actively deployed by AT&T in North America. The table below summarises the typical categories, the exact active test plan being verified on the IoT portal at each submission.

Family	Typical AT&T bands	Primary usage
LTE low-band	B5 (850 MHz), B12 (700 MHz)	Rural coverage, indoor penetration
LTE PCS / AWS	B2 (1900 MHz), B4 (1700/2100 MHz)	Urban LTE capacity, legacy
LTE WCS	B30 (2300 MHz)	Additional AT&T capacity
LTE FirstNet	B14 (700 MHz)	Dedicated FirstNet band, see dedicated section
LTE AWS-3	B66 (1700/2100 MHz)	Major modern AT&T LTE band
5G NR low	n5 (850 MHz)	NR refarming on 850 MHz
5G NR mid	n66 (AWS-3)	NR on AWS-3, the 5G counterpart of B66
5G NR C-band	n77 (3.7-3.98 GHz)	AT&T mid-band 5G capacity

mmWave NR bands (n260, n261) remain a corner case in NAFI: mass-market IoT products on these bands are rare and the test plan is applied only on specific projects.

Radio testing is performed on emulators (Anritsu MT8000A, Keysight UXM 5G, R&S CMX500) in a recognised AT&T lab. See FCC tests for the regulatory counterpart, which shares the spurious emission and MaxPower measurements but does not cover network behaviour.

NAFI test categories

NAFI tests fall into families, several of which go beyond the strict PTCRB scope.

RF Performance. Radio conformance measurements on AT&T bands, tighter on certain priority bands than PTCRB thresholds. Includes MaxPower, EVM, spurious emission, carrier aggregation on the common AT&T combos.

Network Performance and throughput. Where NAFI adds the most compared to PTCRB. The product must demonstrate target IP throughput on LTE and NR in the network conditions defined by the test plan, prolonged session stability (several hours of continuous data), correct handover between cells and between technologies (LTE to NR, 5G NSA to SA), an attach time at first power-on and after reset compatible with the implicit AT&T SLA, and re-selection after signal loss without human intervention. Throughput configurations use carrier aggregation combinations that PTCRB does not explicitly validate.

Fail-over behaviour. For industrially deployed products (gateways, telematics, POS), NAFI evaluates behaviour when the priority cell becomes unavailable: fallback to a secondary cell, LTE to Cat-M fallback, application session preservation, network event logging. No direct PTCRB equivalent.

IPv6 readiness. AT&T deploys IPv6 broadly on LTE and NR. NAFI verifies that the product obtains an IPv6 address at attach, maintains the session, and interacts correctly with a dual-stack APN. Many IPv4-only IoT products fail here.

eUICC + RSP, application, security. eUICC detail in the dedicated section. Application tests are targeted by product category. On the security side, the product must demonstrate secure connectivity provisioning (PIN, credential encryption, SM-DP+ certificates, disabling non-AT&T profiles in test mode).

eUICC and RSP, the 2025-2026 structural topic

Following the progressive adoption of GSMA SGP.32, North American carriers have made IoT eSIM a central axis of their approval programmes. AT&T is no exception. Three architecture generations coexist: SGP.02 (legacy M2M, push-mode, being retired), GSMA SGP.22 (Consumer RSP, pull-mode, for smartphones, watches, tablets) and GSMA SGP.32 (IoT RSP, introduces the eSIM IoT Manager role and redefines the LPA for objects without UI).

Product-side, NAFI requires a GSMA SAS-UP-certified eUICC present on the GSMA list, an LPA or IPA compliant with ES9+ / ES10b certified to dialogue with the AT&T SM-DP+, correct handling of enable / disable / delete without hardware reset, clean rollback if the network fails during profile download, and correct interpretation of AT&T profile metadata (activation, priority, fallback).

Common pitfalls: eUICC not certified to SGP.32, proprietary LPA non-compliant with ES9+, outdated TLS on the LPA side, SGP.22 / SGP.32 confusion, profile metadata misinterpretation. Failures not detected by PTCRB, which does not test the eUICC + LPA + SM-DP+ triad against a real carrier.

FirstNet, a separate programme

FirstNet (First Responder Network) is the US public safety communications network. It runs on AT&T infrastructure but has its own regulatory framework and its own approved-device list, managed by the FirstNet Authority under federal oversight.

Criterion	AT&T NAFI (commercial)	FirstNet
Target network	Commercial AT&T Mobility	FirstNet, priority on band B14
Audience	Commercial IoT, telematics, B2B	Public-safety services (fire, police, emergency medical)
Authority	AT&T Mobility	FirstNet Authority plus AT&T
Key band	B66, n66, n77, plus low bands	B14 (700 MHz), with priority access and preemption
Additional requirements	None beyond NAFI	Hardened security, priority and preemption, ruggedisation often expected
Does NAFI approval imply FirstNet?	No	-

A product targeting public-safety users must therefore run a FirstNet programme in addition to NAFI. The logistics are similar (portal submission, recognised labs, IMEI added to a dedicated database) but the application and security requirements are significantly stricter. Conversely, a commercial IoT product has no reason to enter FirstNet.

3G and 2G sunset, practical implications

AT&T completed its 3G shutdown in 2022 and retired 2G even earlier. For any new NAFI project, no product relying on 2G or 3G fallback has operational value on US AT&T, legacy modules (UMTS-only, GSM-only) are no longer approvable, the LTE Cat-1 / Cat-M / NB-IoT stack must work without a circuit-switched voice fallback, and IPv6 readiness has become structural. For a European manufacturer still maintaining 2G/3G designs for non-US markets, this imposes variant management specific to the US market, a decision to take at product architecture stage rather than at AT&T submission time.

Process, from PTCRB to AT&T activation

Recommended order for a cellular IoT product targeting the AT&T network:

Module selection: pick a module already on the AT&T approved list, settle the SGP.22 / SGP.32 question, choose a certified LPA / IPA.
Hardware stabilisation: open the AT&T IoT portal account, identify the recognised NAFI lab, brief AT&T on the product category and target bands.
Pre-certification: RF pre-tests in an OTA chamber, LPA pre-validation against the AT&T SM-DP+ (test environment provided by the eUICC vendor or by GSMA), internal review of the application firmware.
PTCRB: Modular submission if necessary then End-Product, EPC obtained.
NAFI: project submission, testing in a recognised lab, firmware iterations as needed, AT&T certification number assigned.
AT&T activation: IMEI range registration in the AT&T approved database, verification on a real AT&T SIM, commercial launch.
Lifecycle: monitor portal bulletins, declare significant changes (cellular stack, antennas, power management, LPA, module).

For sequencing with CE/RED, see EU + US dual certification and certification timeline. FCC remains independent, obtained via a TCB with no AT&T dialogue.

Cost and lead time, qualitative

AT&T does not publish an official fee schedule for NAFI. Orders of magnitude depend on the product category (simple module, gateway, complex application device, FirstNet terminal), the presence of an already-approved AT&T module (primary lever), the number of target bands (in particular n77 and specific carrier aggregation combos), eUICC / LPA complexity, the number of iterations if the first campaign fails, and whether the FirstNet programme runs in parallel.

Qualitatively, NAFI adds to PTCRB in both lead time and cost. For a typical IoT product with a pre-approved module, expect several weeks to a few months after PTCRB. Without a pre-approved module, the additional schedule and budget can double. For a FirstNet terminal, add a complete supplementary programme. The final quote depends on the exact test plan retained at submission and is best built with a recognised lab once the scope is framed. For overall logistics, see certification costs.

Chipset pre-certification and lifecycle

Chipset vendors (Qualcomm, MediaTek, Sequans, UNISOC) produce pre-certification reports that accelerate NAFI but do not replace it. AT&T accepts them as supporting evidence, reducing the device-level test scope to the risk zones (antenna integration, application firmware, power management, product LPA). A pre-certification on a legacy platform can be ignored if the current AT&T test plan has evolved since.

On post-approval lifecycle, AT&T classifies modifications in three tiers: major changes (radio, eSIM provisioning) requiring full re-certification, significant changes (cellular stack, power table, IMS functions) leading to delta approval, minor application-only changes with portal notification but no testing. Many teams deploy a stack-impacting firmware without declaration and only later discover the product has been deactivated during an IMEI audit.

Common pitfalls

Assuming PTCRB is enough for AT&T. The structural mistake, identical to what is seen at Verizon (Verizon OPC) and T-Mobile. A PTCRB-certified product without NAFI works temporarily in test mode but is filtered at commercial activation. The discovery often happens just before launch.

Missing AT&T-specific band declarations. Many submissions forget to explicitly declare B14, B30, n66, n77 depending on the product, or declare them without having tested them. AT&T detects the gap during submission review and returns the dossier.

Throughput test misconfiguration. A NAFI throughput configuration is not a PTCRB configuration. Reusing the PTCRB bench as-is leads to out-of-spec results, often due to wrong carrier aggregation settings, a non-dual-stack APN, or a throughput measurement client not aligned with the AT&T test plan.

Module selected without AT&T filter. Picking a module solely on PTCRB and cost criteria leads to paying full price for NAFI when the module is not on the AT&T list. The filter must be applied at module selection time, in parallel with the Verizon-Approved and T-Mobile filters if the project targets several US carriers.

IPv6 missing or broken. AT&T deploys IPv6 on LTE and NR. An IPv4-only product, or one whose IPv6 stack is not operational, fails throughput and prolonged-session tests. Requirement not explicit in PTCRB.

eUICC without a compliant LPA. A certified eUICC is not enough; the device-side LPA / IPA must be compliant and certified. Many integrators re-implement a proprietary LPA that fails NAFI. Fix: use the module LPA when it is integrated and certified, or a certified third-party LPA aligned with SGP.22 / SGP.32.

Confusing NAFI and FirstNet. A NAFI-approved terminal is not FirstNet-approved. A FirstNet-targeted terminal must run NAFI and FirstNet in parallel. Promising FirstNet without having run the dedicated programme is a commercial risk.

Ignoring the 2G/3G sunset. Designing with 2G or 3G fallback for the US no longer makes sense. Historical designs intended to be sold in the US as well must be migrated before any new NAFI submission.

PTCRB lab selected by default. A PTCRB lab is not automatically recognised by AT&T for NAFI. Confirm upfront, or risk double billing. See PTCRB pitfalls for the broader picture.

Underestimating portal admin time. For a European manufacturer submitting for the first time, account opening, administrative validation and AT&T submission review take several weeks before the first test.

Connection with other US certifications

The AT&T NAFI scope is distinct from the other US requirements: FCC (intentional and unintentional radiator) remains independent, FCC ID obtained via a TCB with no AT&T dialogue; PTCRB tests form the cross-carrier foundation that NAFI extends for AT&T; Verizon OPC is a separate Verizon-specific programme; T-Mobile certification is a third separate programme not covered here.

A cellular product sold on AT&T therefore stacks FCC ID (regulator), PTCRB EPC (carrier consortium), NAFI number (AT&T-specific) and IMEI activated in the AT&T approved database. Targeting the three US carriers means planning three separate carrier programmes in addition to PTCRB. For vocabulary (NAF, NAFI, PVG, EPC, LPA, IPAd, SM-DP+, eUICC, eIM), see the spilma glossary.