You cannot ship a product that uses the Bluetooth marks until it is qualified and listed with the Bluetooth SIG. The relief is that you inherit most of it from a pre-qualified module — the effort is proportional to what you add: a new profile, new RF, or a new Core feature such as Channel Sounding.
| Term | What it is | Why it matters |
|---|---|---|
| Pre-qualified component | A vendor’s already-qualified radio and stack | Most of your qualification is inherited, not repeated |
| ICS | The statement of which features you support | Decides which test cases apply to your product |
| Test-case reference list | The map from features to required tests | You only run the tests your declared features pull in |
| Test facility | An authorised lab for RF and PHY testing | Needed when the radio or PHY is genuinely new |
| Declaration and listing | Recording the end product with the SIG | The legal prerequisite to ship and use the marks |
| Interoperability testing | Cross-vendor events and lab testing | Catches the failures conformance tests do not |
Bluetooth qualification is often mistaken for a testing formality. It is closer to a trademark licence: any product that uses Bluetooth wireless technology and carries the Bluetooth marks has to be qualified and listed with the Bluetooth SIG, and shipping without doing so is a compliance problem rather than a quality one. That is why it belongs in the project plan from the start, not at the end.
The reason it is survivable at all is that qualification is layered and reusable. A design is qualified as separable subsystems — the controller with the radio and link layer, the host with the protocol stack, and the profiles and services on top — and each can be inherited from something already qualified. Build on a pre-qualified module and most of the controller and host come for free; what you genuinely add — a custom service, a new profile, a changed RF front end — is what you actually have to qualify. The effort is proportional to the new surface, not to the whole product.
Two things decide how big that new surface is. The first is discipline in the implementation conformance statement: declare only the features you really implement, because every feature claimed pulls its test cases in. The second is the Core version and its features. A product that adopts a new capability — Channel Sounding for secure distance measurement, or LE Audio — is exercising parts of the stack that were not there before, so more of it counts as new and the test and interoperability burden grows. The process itself is also evolving; the SIG has revised how qualification and listing work, so the current requirements are worth confirming rather than assuming.
You inherit most of the controller and host from the module’s qualified design, so you do not repeat that work. But you still have to declare and list the end product with the SIG, and you still qualify anything you added on top — a custom service, a new profile or a changed RF front end. Inheritance reduces the work; it does not remove the obligation.
A new Core feature exercises parts of the stack that were not previously implemented, so more of the design counts as new rather than inherited. That increases both the conformance test surface and the interoperability testing, and because the feature and its test material are still maturing, the requirements move. It is the added surface, not the product as a whole, that drives the extra effort.
If your declared features are all covered by pre-qualified components, much of the testing can be self-declared without an external lab. An authorised test facility is needed when the radio or PHY is genuinely new — a new front end, a new antenna arrangement, or RF behaviour the module did not already cover.
Written for engineers. Share it with one.
Tell us the specification, the constraint and the deadline. Programmes that cross silicon, radio, embedded and AI are where Faststream is strongest.