LoRa Alliance: LoRaWAN end-device certification
Guide - LoRaWAN certification
LoRaWAN certification, operated by the LoRa Alliance, is a private interoperability and trademark programme that complements, without replacing, the radio regulatory obligations applicable to a wireless device. It covers the behaviour of the LoRaWAN MAC layer, compliance with regional parameters, and interoperability with network servers, but it does not address either the LoRa modulation itself (intellectual property of Semtech) or national spectrum requirements. This page sets out the principles of the programme, the membership tiers, the specification versions and their discontinuities, the device classes, the test tooling and the classic pitfalls of incomplete commercialisation.
Why certification is separate from radio
Section titled “Why certification is separate from radio”The LoRa Alliance, founded in 2015, brings together the LoRaWAN ecosystem: public network operators (Actility ThingPark, Senet, Orange, KPN...), gateway manufacturers, integrators and device makers. The Alliance maintains the LoRaWAN specifications, the regional parameters and the end-device certification programme. It owns the LoRaWAN and LoRaWAN Certified trademarks, and licenses their use to its members through the programme.
The Alliance is not a regulator. Radio obligations (power, duty cycle, band, harmonics, measurement methods) are set by national authorities: European spectrum bodies through the RED directive, the FCC in the United States, ANATEL in Brazil, MIC in Japan, and so on. LoRaWAN certification comes after radio compliance: it does not waive any regulatory obligation and does not substitute for any radio test report.
Two objectives coexist within the programme:
- Network interoperability. Ensuring that a certified device communicates correctly with any LoRaWAN network server compliant with the same specification, without client-specific customisation.
- Trademark protection. Ensuring that the LoRaWAN Certified mark and logo are only applied to products that have passed Alliance testing.
The commercial stake is significant: most public LoRaWAN network operators require Alliance certification as a condition for admission on their infrastructure. A non-certified device may technically operate on a private network built around Chirpstack or community The Things Network, but will generally be refused by commercial operators.
LoRa, physical layer versus LoRaWAN, MAC layer
Section titled “LoRa, physical layer versus LoRaWAN, MAC layer”A common confusion conflates LoRa modulation with the LoRaWAN protocol. The two belong to different ownership and governance regimes.
| Layer | Name | Owner | Status |
|---|---|---|---|
| PHY (radio) | LoRa | Semtech Corporation | Private intellectual property, licensed via purchase of SX12xx transceivers |
| MAC (access) | LoRaWAN | LoRa Alliance | Specification open to members, maintained by the Alliance |
| Logo / mark | LoRaWAN Certified | LoRa Alliance | End-device certification programme |
Every LoRaWAN device integrates a Semtech transceiver or a licensed derivative (Murata Type ABZ, STMicro STM32WL with Semtech radio subsystem, Nordic Sidewalk LoRa, and so on). The modulation is patent-protected; as of late 2025, there is no royalty-free implementation of LoRa at the physical layer. The LoRaWAN specification, by contrast, can be obtained free of charge by any Adopter member of the Alliance and implemented in open-source software (LMIC, Semtech LoRaMac-node, ST stack on STM32WL).
This distinction shapes the development effort: there is no flexibility on the modulation, the LoRa component is dictated by the choice of transceiver; on the other hand, the LoRaWAN software can be brought in from a reference stack, which makes certification accessible even to small teams.
Three regimes to articulate
Section titled “Three regimes to articulate”A LoRaWAN device placed on the market in Europe or the United States must therefore satisfy three stacked regimes:
| Aspect | Radio layer (RED / FCC) | Modulation layer (LoRa) | MAC layer (LoRaWAN) |
|---|---|---|---|
| Nature | Public regulatory framework | Component choice (Semtech patent) | Alliance private programme |
| Issuing body | National spectrum authorities | Semtech via the transceiver | LoRa Alliance |
| Subject matter | Spectrum, power, duty cycle, harmonics | Chirp spread modulation | MAC behaviour, regions, interoperability |
| Reference | EN 300 220, FCC Part 15.247, Part 15.249 | SX1261 / SX1262 / SX1276 / SX1303 datasheets | LoRaWAN L2 1.0.4 or 1.1, RP002 |
| Documents | RED DoC, FCC ID, test reports | Component specification | LoRaWAN Certified certificate |
| Sanction | Market withdrawal | N/A (flows from sourcing choice) | Mark revocation, operator refusal |
For the European radio regime, see RED pillar and applicable RED standards. For the FCC regime, see FCC pillar. For a combined programme, see EU + US dual certification.
Membership tiers
Section titled “Membership tiers”Access to the certification programme starts with LoRa Alliance membership. The Alliance offers four main tiers.
Adopter
Section titled “Adopter”Entry-level tier with a moderate annual fee. An Adopter can submit devices for certification, access the published specifications and regional parameters, and use the LoRaWAN Certified logo on certified products. Adopters do not participate in the elaboration of future specifications.
Contributor
Section titled “Contributor”Intermediate tier. Contributors access the technical working groups (Technical Committee, Regulatory Committee, Certification Committee...), participate in the drafting of future versions and in the definition of regional parameters. Higher annual fee than Adopter.
Sponsor
Section titled “Sponsor”Premium tier. Sponsors hold a seat on the Board of Directors, orient the overall strategy of the Alliance, and benefit from commercial visibility (event sponsorship, priority listing). Adopted by major operators and strategic silicon vendors.
Institutional
Section titled “Institutional”Tier dedicated to academic institutions, public authorities and non-profit organisations. Specific conditions, without commercial purpose.
| Tier | Vote | Working groups | Product certification | Board |
|---|---|---|---|---|
| Adopter | No | No | Yes | No |
| Contributor | On selected committees | Yes | Yes | No |
| Sponsor | Full | Yes | Yes | Yes |
| Institutional | Per agreement | Per agreement | Per agreement | No |
For a device maker integrating a pre-certified module and using the Semtech reference stack, Adopter status is generally sufficient. Moving to Contributor is justified when the company develops its own stack, contributes to the specification or wishes to influence future regional parameters.
Specification versions
Section titled “Specification versions”The LoRaWAN specification has had two main lineages, with significant technical discontinuities.
| Version | Main contribution | Compatibility |
|---|---|---|
| 1.0.0 | First stable version, classes A/B/C defined | Historical |
| 1.0.1 | Corrections, initial regional parameters | Compatible with 1.0.x |
| 1.0.2 | Adjustments, extended regions | Compatible with 1.0.x |
| 1.0.3 | Class B refined, regions completed | Compatible with 1.0.x |
| 1.0.4 | Backwards compatibility with the 1.0 branch, last 1.0 revision | Compatible with 1.0.x |
| 1.1 | New key derivation scheme (AppSKey / FNwkSIntKey / SNwkSIntKey / NwkSEncKey), reinforced security, separation of application and network server roles | Not compatible with 1.0.x without rekey |
The 1.0.x to 1.1 discontinuity is principally about security and key separation. In 1.0.x, the device derives a network session key (NwkSKey) and an application session key (AppSKey) from a single root key (AppKey). In 1.1, the model becomes more layered: a network root key (NwkKey) and an application root key (AppKey) are distinct, and the network server can be operationally separated from the application server without sharing application keys in clear.
The practical consequence: a 1.0.x device cannot join a 1.1 network in 1.1 mode, and a 1.1 device must be configured in backwards-compatibility mode to operate on a 1.0.x network. Moving from one family to the other requires a stack upgrade, and potentially re-certification.
The reference specification is explicitly mentioned on the certificate: a LoRaWAN 1.0.4 certificate and a 1.1 certificate are not interchangeable.
Device classes A, B, C
Section titled “Device classes A, B, C”LoRaWAN defines three behaviour classes for end-devices. All certified LoRaWAN end-devices support class A; classes B and C are optional and subject to additional testing.
| Class | Mode | Initiative | Reception | Typical consumption |
|---|---|---|---|---|
| Class A | Device-initiated uplink | Device | Two windows after each uplink (RX1, RX2) | Very low, compatible with multi-year battery |
| Class B | Uplink + scheduled reception | Device for uplink, gateway for beacon | Windows synchronised on beacon (gateway emits a multicast beacon) | Intermediate, battery-compatible with reduced latency |
| Class C | Continuous | Device for uplink, network for downlink | Reception open continuously outside transmission | High, generally mains or large battery |
The choice of class depends on the use case. An agricultural humidity sensor with hourly upload remains in class A. A remotely controlled water valve with acceptable latency of a few seconds can adopt class B. A connected lock or an industrial actuator commanded in real time requires class C, with its energy cost.
The class declared on the certificate conditions the tests executed by the laboratory: a device certified class A only cannot be commercialised as class B or C, even if the firmware technically supports it.
Regional parameters
Section titled “Regional parameters”The RP002 (Regional Parameters) document of the LoRa Alliance specifies, for each region of the world, the usable bands, the frequency plans, the maximum powers, the authorised data rates and the operational constraints (duty cycle or listen-before-talk).
| Pack | Typical region | Band | Particularity |
|---|---|---|---|
| EU868 | European Union | 863-870 MHz | Regulatory duty cycle (1 % on most channels) |
| US915 | United States, Canada | 902-928 MHz | 64 uplink channels, 8 downlink channels |
| AS923 | Singapore, Japan, Indonesia, Brazil, Philippines per sub-band | 915-928 MHz per national plan | Variants AS923-1, -2, -3, -4, distinct national plans |
| AU915 | Australia, New Zealand | 915-928 MHz | Plan derived from US915 with adjustments |
| IN865 | India | 865-867 MHz | Restricted band, limited power |
| CN470 | Mainland China | 470-510 MHz | Specific plan, local constraints |
| RU864 | Russia | 864-870 MHz | Local plan, specific allocation |
The LoRaWAN certificate carries the explicit list of regional packs supported by the device. A product certified EU868 only cannot be sold in the United States under the LoRaWAN Certified logo without additional US915 certification. Manufacturers targeting the whole world generally submit several configurations, or a selectable multi-band firmware, and declare all supported packs.
The AS923 case is worth noting: the AS923 mention on a certificate can be ambiguous if it does not specify the sub-band. The AS923-1 sub-band (Singapore, Japan in certain uses, Hong Kong) is not identical to AS923-2 (Brazil in certain deployments) or AS923-3. Read the certificate in detail.
The test laboratory and the LCTT tool
Section titled “The test laboratory and the LCTT tool”End-device certification goes through an Authorized Test Lab (ATL) accredited by the LoRa Alliance. The public list is maintained on the Alliance website. ATLs are distinct from classic radio certification laboratories (even though they may be operated by the same entity): their accreditation covers the LoRaWAN programme, not radio standards.
The reference test tool is the LoRaWAN Certification Test Tool (LCTT). It is an automated test environment, capable of running a sequence of test cases defined by the Alliance for each specification version, each class and each regional pack. The LCTT communicates with the device under test via a dedicated gateway and a network simulator.
The scope of LCTT tests covers:
- Activation. OTAA (Over-The-Air Activation) and ABP (Activation By Personalization) procedures, depending on the version.
- Class behaviour. Respect of RX1, RX2 windows for class A; beacon synchronisation for class B; continuous reception for class C.
- Regional parameters. Compliance with frequency plans, data rates, powers and duty-cycle or LBT constraints of the declared pack.
- MAC commands. Responses to server commands (LinkADRReq, DutyCycleReq, RXParamSetupReq, DevStatusReq, NewChannelReq, RXTimingSetupReq, and others).
- Security. Correct key derivation per version, message integrity, frame counter handling.
The LCTT report, accompanied by a descriptive dossier (Test Application Note, product fiche, identifiers), is submitted to the LoRa Alliance, which issues the certification.
Reuse of pre-certified modules
Section titled “Reuse of pre-certified modules”The LoRaWAN ecosystem has built a dense offering of pre-certified modules, which substantially simplifies the effort. The principle is analogous to qualified Bluetooth modules: a module maker obtains a reference certification, and integrators use it as a base for their products.
Typical examples:
- Murata Type ABZ. Module integrating an STM32L0 and an SX1276 transceiver, ST/Semtech LoRaWAN stack, certified for several regions.
- STMicro STM32WL series. SoC combining a Cortex-M4 and a Semtech radio subsystem, official ST LoRaWAN stack.
- Nordic / Semtech reference designs. Validated configurations for development acceleration.
- Third-party modules (RAK, Seeed, Pycom, and others). Modules with baseline stack and certification, generally EU868 and US915 at minimum.
Integrating a pre-certified module reduces LCTT test scope, but does not waive submission of the finished product:
- If the stack is unmodified and the module is used as is (same LoRaWAN parameters, same version), the manufacturer can rely on the parent certificate and submit a reduced dossier, mostly administrative and configuration-related.
- If the stack is modified (custom MAC commands, energy management adjusting RX timings, additional regional profile), additional LCTT tests are required.
- If the radio is modified (external antenna with different gain, reworked RF stage), national radio certification (RED or FCC) is impacted but LoRaWAN certification remains valid as long as the MAC layer is unchanged.
Choosing a pre-certified module is generally the right trade-off for a first-generation product, except in cases of aggressive optimisation on power consumption or cost at high volume.
Step-by-step process
Section titled “Step-by-step process”- Joining the LoRa Alliance. Subscribe at least as Adopter. Access to the member portal, the specifications and the LCTT.
- Choice of stack and module. Decide between integrating a pre-certified module and developing on a Semtech transceiver with a reference stack. This decision strongly affects certification effort.
- Choice of version and class. Select the target LoRaWAN version (1.0.4 or 1.1) and the supported classes (A mandatory, B and C optional). This decision conditions the test cases executed.
- Choice of regional packs. List the markets of commercialisation. Each pack adds tests and must be consistent with the corresponding national radio certification.
- Internal pre-tests. Use the LCTT in development mode to validate behaviour before formal testing. Critical step to avoid costly discrepancies in the external laboratory.
- Submission to an ATL. Engage an Authorized Test Lab accredited by the LoRa Alliance for the test campaign. Reports must follow the LoRa Alliance format.
- Review by the Alliance. The Alliance examines the LCTT report and the descriptive dossier. Requests for additional information are possible.
- Issuance of the certificate. The product is published in the LoRaWAN Certified database and can carry the logo. The precise scope (version, classes, packs) appears on the certificate.
- Maintenance. Any modification of the LoRaWAN stack or of the regional configuration triggers an amendment, or even a new certification.
This process runs in parallel, not in place of, radio certification. The EN 300 220 report in Europe and the Part 15.247 or Part 15.249 report in the United States are produced separately. See RED tests and FCC pillar.
Common pitfalls
Section titled “Common pitfalls”Conflating LoRa and LoRaWAN
Section titled “Conflating LoRa and LoRaWAN”The most widespread conceptual error. LoRa modulation is a component-level matter, purchased from Semtech through the transceiver. The LoRaWAN protocol is a software layer, certifiable by the Alliance. Claiming a product is LoRa-compatible has no network interoperability value; only a LoRaWAN Certified certificate attests to that compatibility.
Assuming a 1.0.x device runs on a 1.1 network
Section titled “Assuming a 1.0.x device runs on a 1.1 network”The key derivation scheme changes between the two families. A 1.0.x device can join a 1.1 network if the latter accepts backwards compatibility mode, but it then does not benefit from the security properties of 1.1. To operate fully in 1.1, a stack upgrade and a rekey are needed. This migration must be traced in the certification dossier.
Forgetting the target regional pack
Section titled “Forgetting the target regional pack”LoRaWAN certification only covers declared packs. A device certified EU868 only, shipped to the United States, cannot carry LoRaWAN Certified for the US915 market without additional certification. Furthermore, FCC radio compliance is independent: even with a LoRaWAN-certified US915 firmware, the device must obtain its own FCC ID.
Neglecting AS923 sub-bands
Section titled “Neglecting AS923 sub-bands”The AS923 pack is split into several sub-bands per national allocation. An AS923-1 certification does not cover AS923-2 or AS923-3. Read the certificate in detail, and align it with target markets. A product intended for the Brazilian market under AS923-2 must be certified for that sub-band.
Modifying the LoRaWAN stack delivered by the module maker
Section titled “Modifying the LoRaWAN stack delivered by the module maker”A pre-certified module relies on a frozen stack. Any internal patch (custom retransmission management, custom MAC commands, adjusted timings) invalidates the reuse assumption and forces additional LCTT tests. The modification must be traced and submitted.
Believing LoRaWAN certification covers radio
Section titled “Believing LoRaWAN certification covers radio”A recurring mistake. The Alliance is not a regulator. No LCTT report covers EN 300 220, Part 15.247 or Part 15.249. Both dossiers must be prepared in parallel. The product schedule must reflect this from the design phase.
Skipping the declared class
Section titled “Skipping the declared class”A firmware can technically support class C without the certificate mentioning it. Activating class C on a device not certified class C does not respect the scope of the certificate and exposes the manufacturer to logo revocation, without considering potential inconsistencies with radio constraints (the EU868 duty cycle becomes awkward in class C).
Underestimating internal pre-validation
Section titled “Underestimating internal pre-validation”The LCTT is a demanding tool. A dossier submitted to an ATL without internal pre-validation regularly leads to costly discrepancies. Investing in an internal LCTT instance, even for a single campaign, generally pays back quickly.
Cross-references and support
Section titled “Cross-references and support”See also glossary for OTAA, ABP, class A/B/C and ADR definitions, and the guides RED standards, FCC pillar, and EU + US dual certification for a dual programme.
Sources & references
- LoRa Alliance , LoRa Alliance lora-alliance.org/
- LoRaWAN specifications, 1.0.4 and 1.1 , LoRa Alliance lora-alliance.org/resource_hub/lorawan-specifications/
- LoRaWAN regional parameters RP002-1.0.3 , LoRa Alliance lora-alliance.org/resource_hub/rp002-1-0-3-lorawan-regional-parameters/
- LoRaWAN certification programme , LoRa Alliance lora-alliance.org/lorawan-certification/
- ETSI EN 300 220, short range devices in the 25 MHz to 1000 MHz range , ETSI www.etsi.org/deliver/etsi_en/300200_300299/30022002/
- 47 CFR Part 15.247, operation in 902-928 MHz, 2400-2483.5 MHz and 5725-5850 MHz bands , FCC www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-15/subpart-C/section-15.247