The Cyber Resilience Act for devices on Qorvo UWB and QPG: SBOM, vendor SDK libraries and the 24 h/72 h reporting duty

Facts checked on 16 October 2026

Short answer

Since 11 September 2026, manufacturers of products with digital elements sold in the EU must report actively exploited vulnerabilities and severe incidents: an early warning within 24 hours and a notification within 72 hours. The full Cyber Resilience Act (CRA) applies from 11 December 2027.

The device maker is responsible for the whole product, including the chip vendor’s SDK and its binary libraries. List them in an SBOM with versions and hashes, handle their vulnerabilities over the support period and report those actively exploited in your product.

Key dates

Does the CRA cover a UWB tag, a Matter sensor or a BLE module?

The CRA covers products with digital elements made available on the EU market in the course of a commercial activity, and the Commission notes that it also covers components “such as chips and operating systems”. Most products fall in the default category and can be self-assessed. The Commission’s examples are “household appliances, computer games or mobile applications”.

Some categories common in UWB, Bluetooth LE and Matter products sit higher. Annex III, class I, lists among others:

• smart home products with security functionalities, “including smart door locks, security cameras, baby monitoring systems and alarm systems”;
• internet-connected toys;
• personal wearables with a health-monitoring purpose, such as tracking;
• routers, modems and switches;
• microcontrollers with security-related functionalities.

A UWB smart lock or a Matter alarm sensor is therefore likely to be an important product of class I. For class I, the Commission notes that self-assessment is possible “only if it has applied harmonised standards”; otherwise a third party is involved. Integrating an important or critical component, such as a secure element, does not by itself move your product into that component’s class (Article 7(1); Article 8(1) likewise ties critical products to their core functionality).

What the reporting duty requires

Reports go “simultaneously to the CSIRT designated as coordinator” and to ENISA, through the single reporting platform that opened on 11 September 2026. ENISA’s FAQ says you generally report to the coordinator in the member state of your main establishment in the EU. You must also inform affected users (Article 14(8)).

Two clarifications from ENISA’s FAQ help with planning. The obligation covers products placed on the market before 11 December 2027, so your installed base is in scope. It is not retroactive: you do not have to report exploitation you already knew about before 11 September 2026.

When the clock starts

An actively exploited vulnerability is one “for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner” (Article 3(42)). The Commission’s July 2026 guidance says you become aware when an initial assessment, started immediately, gives you “a reasonable degree of certainty” of active exploitation or a severe incident (paragraph 213). A zero-day from your bug bounty programme with no evidence of malicious use needs no mandatory report (Commission FAQ, section 5.2), and reporting continues after support ends (guidance, paragraph 210).

What each report must contain

Article 14 sets the minimum; ENISA’s SRP glossary (version 1.5) marks the mandatory platform fields.

Field limits: 255 characters for the title, 4,000 for the summary. A vendor library goes in the optional “Component name” field.

Filing through ENISA’s single reporting platform

Notifications are filed at portal.cra-srp.enisa.europa.eu by assigned representatives (ARs) with personal EU Login accounts and multi-factor authentication; a manufacturer has one Primary AR and up to 20 Secondary ARs. ENISA advises registering only when needed, which takes “just a few minutes” once an EU Login account exists, so create those accounts now. Drafts are visible only to their author, there is no API yet, the 72-hour counter currently shows a due time 48 hours after the early warning, and choosing the wrong CSIRT can invalidate a notification.

Why vendor SDKs make this harder

A typical firmware image on a Qorvo-based device is mostly code you did not write:

• the chip vendor’s SDK: drivers, radio configuration and protocol stacks;
• an RTOS, such as FreeRTOS or Zephyr;
• protocol stacks such as Bluetooth LE, Thread, Zigbee and Matter, partly open source;
• a bootloader and cryptographic libraries;
• your application.

Some of those components arrive as binaries. In Qorvo’s DW3_QM33 SDK, for example, the FiRa UWB stack ships as a pre-compiled library, according to file names developers have posted on Qorvo’s forum. On the QM35825, Qorvo states that you “must use the pre-compiled software from Qorvo on the device”. You cannot patch what you cannot see, yet the CRA holds you accountable for the product as a whole.

The regulation spells out what that accountability means for components:

• Due diligence (Article 13(5)). Manufacturers must “exercise due diligence when integrating components sourced from third parties”, including open-source components. Recital 34 gives examples: checking whether a component bears the CE marking, verifying that it receives regular security updates, and checking that it is free of vulnerabilities registered in the European vulnerability database.
• Upstream reporting (Article 13(6)). If you identify a vulnerability in a component, you must report it to the person or entity that manufactures or maintains it, and recital 34 adds that you should share any fix you applied.
• Your own report. Ireland’s NCSC states that if an actively exploited vulnerability “occurs in a third-party component”, the final product manufacturer must report “once you confirm your product is affected”. The Commission’s guidance narrows this (paragraph 218): a component vulnerability that “cannot be exploited” in your product, “e.g. because the vulnerable code is not reachable”, or has not been exploited in it, needs no mandatory report from you. A component placed on the market is also reported by its own manufacturer (Commission FAQ, section 5.4).

Reporting upstream to Qorvo and other maintainers

The guidance limits the upstream duty to the component version you integrate and waives it when you can confirm the maintainer already knows (paragraph 223). Qorvo’s PSIRT takes reports on its low power IoT and ultra-wideband products at psirt@qorvo.com, wants the part number, the hardware and SDK versions for development kits, reproduction steps and logs, and “aims to respond within 3 business days”. Zephyr embargoes security-sensitive reports for at most 90 days: 30 to fix, 60 for product makers to ship.

Building an SBOM for a Qorvo-based device

Annex I, Part II of the CRA requires an SBOM “in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products”. SPDX and CycloneDX are the two formats most teams choose. A workable process looks like this:

1. List every layer. Vendor SDK version and each library inside it, with versions and file hashes for binaries; RTOS version; protocol stack versions or commits; bootloader; crypto libraries; your own code. For QM35-based products, include the host side: the Linux kernel driver, the Cherry API and your host application.
2. Record the provenance. Note where each component came from (vendor download, GitLab tag, open-source repository) and under which licence. Qorvo’s QM35 SDK, for instance, uses a Qorvo licence for most files and a dual GPLv2 or commercial licence for its Linux driver.
3. Generate it in CI. Produce the SBOM automatically for every release build and store it with the release, so each firmware version in the field has a matching SBOM.
4. Map components to vulnerability sources. Watch the European vulnerability database, CVE and NVD records, vendor security advisories and the advisories of open-source projects such as Zephyr, FreeRTOS and the Matter SDK.
5. Go deeper than the minimum where it matters. Top-level dependencies are the legal floor. Your vulnerability handling is only as good as your knowledge of what is inside those dependencies.

Generating the SBOM from a Zephyr build

west spdx needs CONFIG_BUILD_OUTPUT_META and by default writes SPDX 2.3 tag-value documents with SHA-512, SHA-256 and SHA-1 hashes per file and a PURL and a CPE per package. Vendor libraries can be packaged as Zephyr modules whose module.yml records each blob’s SHA-256, type, version, licence and URL, plus CPE or PURL references. The module below is illustrative.

# prj.conf of the application
CONFIG_BUILD_OUTPUT_META=y

# Build with sysbuild, then point west spdx at the application image
west build --sysbuild -b <board> -d build <app-dir>
west spdx -d build/<app-name>                 # SPDX 2.3 tag-value (default)
west spdx -d build/<app-name> --spdx-version 3.0 -s build/<app-name>/spdx3
ls build/<app-name>/spdx/     # app, zephyr, build and modules-deps documents

# zephyr/module.yml (illustrative: names, URLs and hash are placeholders)
name: vendor-uwb
build:
  cmake: .
  kconfig: Kconfig
blobs:
  - path: lib/libuwbstack_fira.a
    sha256: <SHA-256 of the archive>
    type: lib
    version: "<SDK release>-<build ID from the file name>"
    license-path: LICENSE.txt
    url: https://artifacts.example.com/vendor-uwb/libuwbstack_fira.a
    description: "Pre-compiled FiRa UWB stack from the chip vendor SDK"
    doc-url: https://artifacts.example.com/vendor-uwb/RELEASE_NOTES.html
security:
  external-references:
    - <CPE 2.3 name or package URL, if the component has one>

# west blobs list -f '{module}: {type} {path}'
# west blobs fetch vendor-uwb

Recording pre-compiled vendor binaries

A binary cannot be scanned, so its record carries the evidence. In SPDX 2.3 that is a package with FilesAnalyzed: false, a PackageChecksum, a PackageSupplier and PrimaryPackagePurpose: LIBRARY or FIRMWARE, linked with STATIC_LINK or CONTAINS; in CycloneDX 1.6, a library or firmware component with supplier and hashes. Record build identifiers too: one developer’s DW3_QM33 SDK v1.1.1 report names the FiRa archive libuwbstack_bundle_fira_arm-cortex-m4-hard_floating_rtos_R12.7.0-00405-gb33c5c42726c.a. The entry below is illustrative, but its hash is the real SHA-256 of qm35825.bin at QM35 SDK tag 3.0.0.

PackageName: QM35825 firmware
SPDXID: SPDXRef-qm35825-fw
PackageVersion: 3.0.0
PackageFileName: qm35825.bin
PackageSupplier: Organization: Qorvo
PackageDownloadLocation: git+https://gitlab.com/qorvo_sdk/public/devkits/qm35-sdk@3.0.0
FilesAnalyzed: false
PackageChecksum: SHA256: 57405519d75fd36b894a919bd3de92265e95178639c1ad4afb80d21ffbc69938
PackageLicenseConcluded: NOASSERTION
PackageLicenseDeclared: LicenseRef-Qorvo-SLA
PackageCopyrightText: NOASSERTION
PrimaryPackagePurpose: FIRMWARE
PackageComment: <text>Version is the qm35-sdk release tag; 288828 bytes.</text>
Relationship: SPDXRef-product CONTAINS SPDXRef-qm35825-fw

Linux hosts and stricter SBOM profiles

On a Linux host, such as a QM35 design, Yocto generates SPDX by default through the create-spdx class, and the core/yocto/sbom-cve-check fragment adds a CVE report. The Commission may still set the SBOM format by implementing act (Article 13(24)). Germany’s BSI TR-03183-2 (version 2.1.0) is already stricter: CycloneDX 1.6 or SPDX 3.0.1 or later in JSON or XML, SHA-512 hashes and no vulnerability data in the SBOM, which rules out Zephyr’s default output.

Release checks for the SBOM

Pass/fail checks before each release:

1. Every linked or flashed vendor file has a component whose hash CI recomputes and matches.
2. The SBOM version matches the signed image header (imgtool dumpinfo).
3. Every component has a supplier and a CPE, a PURL or a reason for neither.
4. The version a device reports leads to exactly one archived SBOM.

Monitoring and triage: from CVE feeds to VEX

Feeds and queries

No single feed is complete. On 16 October 2026, the NVD query below returned 64 CVE records for Zephyr 3.7.0 and the OSV query 130, with only 51 in both. NVD matches CPE names and allows 5 requests per rolling 30 seconds without an API key, 50 with one; OSV takes a commit or git tag. ENISA’s European vulnerability database (EUVD), which the guidance names as a source that makes a vulnerability “known” (paragraph 233), has an exploited filter and a daily dump of CISA and EU known-exploited lists.

# NVD CVE API 2.0: the key goes in a header; date filters span at most 120 days
NVD=https://services.nvd.nist.gov/rest/json/cves/2.0
curl -s -H "apiKey: $NVD_API_KEY" \
  "$NVD?virtualMatchString=cpe:2.3:o:zephyrproject:zephyr:3.7.0"

# OSV: query by git tag, or by {"commit": "<sha>"}
curl -s -d '{"package": {"name": "https://github.com/zephyrproject-rtos/zephyr.git",
  "ecosystem": "GIT"}, "version": "v3.7.0"}' https://api.osv.dev/v1/query

# ENISA EUVD: exploited entries for a product, and the consolidated KEV dump
EUVD=https://euvdservices.enisa.europa.eu/api
curl -s "$EUVD/search?product=zephyr&exploited=true&size=100"
curl -s -o kev.json "$EUVD/kev/dump"

Triage step by step

1. Log the source, the evidence and the time in UTC, as the SRP expects.
2. Match the advisory to SBOM components by CPE, PURL, hash or library name; list affected firmware versions from archived SBOMs.
3. Check presence and reach: is the code compiled in (Kconfig, linker map, SPDX build document) and reachable over BLE, UWB, Thread or the host link?
4. Look for exploitation in your product: customer reports, telemetry, researcher evidence. A KEV or EUVD “exploited” flag shows exploitation somewhere, not necessarily in your product.
5. Act and close: early warning if reportable, upstream report, fix or documented not-affected status, user advisory, final report and public disclosure of the fix (Annex I, Part II, point 4).

Publishing VEX and CSAF advisories

Article 14(8) asks you to inform users “where appropriate in a structured, machine-readable format that is easily automatically processable”. CSAF 2.0, an OASIS standard, does this; its VEX profile marks each product known_affected, known_not_affected, fixed or under_investigation. A known_not_affected product needs an impact statement, such as the flag vulnerable_code_not_in_execute_path; a known_affected one needs a remediation. CycloneDX uses analysis.state and analysis.justification, for example not_affected with code_not_reachable. The CSAF document below is illustrative and abbreviated; a valid one also needs dates and a revision history.

{
  "document": {
    "category": "csaf_vex",
    "csaf_version": "2.0",
    "publisher": {"category": "vendor", "name": "Example Devices",
                  "namespace": "https://example.com"},
    "title": "CVE-2026-XXXXX in the Bluetooth LE host stack",
    "tracking": {"id": "EXD-2026-007", "status": "final", "version": "1"}
  },
  "product_tree": {"full_product_names": [
    {"name": "Smart lock firmware 2.4.1", "product_id": "LOCK-FW-2.4.1"}]},
  "vulnerabilities": [{
    "cve": "CVE-2026-XXXXX",
    "product_status": {"known_not_affected": ["LOCK-FW-2.4.1"]},
    "flags": [{"label": "vulnerable_code_not_in_execute_path",
               "product_ids": ["LOCK-FW-2.4.1"]}]
  }]
}

Vulnerability handling over the support period

The CRA sets a support period of at least five years, unless the product is expected to be in use for less (Article 13(8)). Each security update must stay available for at least ten years or for the rest of the support period, whichever is longer (Article 13(9)). Annex I, Part II, adds that security updates must be free of charge and, “where technically feasible”, provided separately from functionality updates, and that you need a coordinated vulnerability disclosure policy and a contact address for reports.

For embedded wireless products, those rules translate into engineering capabilities:

• Signed firmware and secure boot, so only your releases run on the device. Qorvo’s QPG6200L includes a secure element and is PSA Certified Level 2; the QM35825 offers secure boot, secure debug and a secure enclave.
• Robust OTA updates, with dual-slot images and rollback, so security fixes can reach the field without bricking devices.
• Reproducible builds, so you can rebuild and patch the exact version a customer runs, years later.
• Backports, so a fix reaches every supported release line, not only the latest one.
• Regression tests on real hardware, so a security release does not break ranging, pairing or certification.
• Field diagnostics, so you can detect exploitation and confirm whether your product is affected.

Setting the support period

Five years is a floor, not a default (Commission guidance, paragraph 126). Article 13(8) lets you weigh “the support periods of integrated components that provide core functions and are sourced from third parties”, so ask each supplier for its period and record the answers. A Zephyr LTS release is maintained for about five years, with only security and stability fixes after the first two; FreeRTOS LTS libraries get security fixes for two years. Show the end month and year at purchase (Article 13(19)). Article 13(10) allows fixing only the latest substantially modified version of software if users can move to it free of charge and without additional costs; a hardware revision that cannot run the latest firmware needs its own security releases.

Secure updates with MCUboot

Annex I requires security updates, protection of programs against unauthorised modification and secure update distribution. With Zephyr and MCUboot:

• Own signing key. Left at its default, SB_CONFIG_BOOT_SIGNATURE_KEY_FILE points to MCUboot’s sample keys, whose private halves are public. MCUboot’s documentation advises that production bootloaders embed only the production public key.
• Downgrade prevention. CONFIG_MCUBOOT_DOWNGRADE_PREVENTION compares versions but, its help text warns, does not stop JTAG; CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION compares a security counter held in trusted non-volatile storage.
• Test swaps. MCUboot reverts an image that does not confirm itself, so confirm after a self-test, as in the illustrative code below.

# sysbuild.conf
SB_CONFIG_BOOTLOADER_MCUBOOT=y
SB_CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y
SB_CONFIG_BOOT_SIGNATURE_KEY_FILE="/secure/release/fw-ec-p256.pem"

# sysbuild/mcuboot.conf (bootloader image)
CONFIG_MCUBOOT_DOWNGRADE_PREVENTION=y

# prj.conf (application)
CONFIG_MCUBOOT_BOOTLOADER_NO_DOWNGRADE=y

# Release checks on the signed application image
IMG=build/<app-name>/zephyr/zephyr.signed.bin
imgtool verify -k /secure/release/fw-ec-p256.pem $IMG        # must validate
imgtool verify -k bootloader/mcuboot/root-ec-p256.pem $IMG   # must fail
imgtool dumpinfo $IMG                # version must match the SBOM

#include <zephyr/dfu/mcuboot.h>

/* Illustrative: uwb_self_test() and ble_self_test() are your own checks */
void confirm_if_healthy(void)
{
	if (boot_is_img_confirmed()) {
		return;
	}
	if (uwb_self_test() == 0 && ble_self_test() == 0) {
		int err = boot_write_img_confirmed(); /* 0 or negative errno */

		if (err) {
			printk("image confirm failed: %d\n", err);
		}
	}
	/* Left unconfirmed, MCUboot swaps back to the previous image on reset. */
}

On each hardware revision, test that the device rejects foreign-key and older images, survives a power cut mid-swap and reverts a failed image.

A 24-hour and 72-hour reporting playbook

Prepare the templates, contacts and decision rights before you need them. The deadline runs from the moment the initial assessment gives you reasonable certainty, and that assessment should start immediately (guidance, paragraphs 213 and 214). Rehearse with a fictitious advisory for a vendor SDK library: pass when affected versions come from archived SBOMs, the exploitation decision rests on evidence and a second person can submit.

Typical failures and how to confirm them

What to do in the next 90 days

1. Classify each product: default, class I or higher, and record your reasoning.
2. Produce an SBOM for every product line and every supported release, generated in CI.
3. Map binary vendor components, the vendor’s channel for security fixes and its support period.
4. Write the reporting playbook, assign owners and run a tabletop exercise.
5. Publish a coordinated vulnerability disclosure policy and a security contact.
6. Check that secure boot, signed OTA updates, downgrade prevention and rollback work on every product.
7. Decide the support period per product and how you will deliver updates through it.

From our engineering work

needCode runs the engineering behind CRA obligations for products in production: SBOMs covering the Qorvo SDK, protocol stacks, RTOS and bootloader; a 24 h/72 h reporting playbook; signed firmware with dual-slot OTA and rollback; and field diagnostics for remote troubleshooting. Our quality and security processes are certified to ISO 9001:2015 and ISO/IEC 27001:2022.

How needCode helps

A 2–4 week Product Assessment produces a CRA and RED gap list for each product, an SBOM baseline and a 90-day plan. The Sustain & Secure retainer then covers maintenance under SLA, CVE monitoring and triage, security releases, backports and regression testing on hardware for every release.

Frequently asked questions

When do the CRA reporting obligations start?

On 11 September 2026. From that date, manufacturers must report actively exploited vulnerabilities and severe incidents through ENISA’s single reporting platform: an early warning within 24 hours and a notification within 72 hours of becoming aware.

Do the reporting obligations apply to products already on the market?

Yes. Article 14 applies to all products with digital elements, including those placed on the EU market before 11 December 2027. ENISA’s FAQ adds that you do not have to report exploitation you already knew about before 11 September 2026.

Are we responsible for vulnerabilities in our chip vendor’s SDK?

As the manufacturer of the final product, you are responsible for the product as a whole. You must exercise due diligence when integrating third-party components, report vulnerabilities you find to the component’s maintainer and notify an actively exploited vulnerability in a component when it is exploited in your product (Commission guidance, paragraph 218).

Do we have to report a vendor SDK vulnerability that is exploited elsewhere?

Only if it is exploited in your product. Otherwise it is not reportable for you, but you must still handle it and report it to the component’s maintainer; voluntary notification under Article 15 remains possible.

When does the 24-hour clock start?

When an initial assessment, which should start immediately, gives you a reasonable degree of certainty that a vulnerability in your product is being actively exploited or that a severe incident has compromised its security.

What format should the SBOM use?

The CRA requires “a commonly used and machine-readable format covering at the very least the top-level dependencies”. SPDX and CycloneDX are the common choices. Generate the SBOM in CI for every release so that each firmware version in the field has a matching record.

How do we record a pre-compiled vendor library in the SBOM?

As its own component with supplier, file name, version or build identifier and a hash: in SPDX 2.3, a package with FilesAnalyzed set to false, a PackageChecksum and a STATIC_LINK relationship; in CycloneDX, a library component with supplier and hashes.

How long must we provide security updates?

For the support period, which must be at least five years unless the product is expected to be in use for less. Each security update must remain available for at least ten years or for the rest of the support period, whichever is longer, and security updates must be free of charge.

Is a UWB smart lock an important product under the CRA?

Likely yes. Annex III lists “smart home products with security functionalities, including smart door locks” in class I. Class I products can be self-assessed only when harmonised standards have been applied; otherwise a third-party conformity assessment is needed.

What are the fines for non-compliance?

For breaches of the essential requirements or of Articles 13 and 14, fines can reach EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher. National rules set the procedure. Micro and small enterprises cannot be fined for missing the 24-hour early warning deadline.

Does the RED cybersecurity regulation still apply?

Yes, until the CRA takes over. RED Delegated Regulation (EU) 2022/30 has applied to radio equipment since 1 August 2025, with EN 18031-1, -2 and -3 as harmonised standards. Delegated Regulation (EU) 2026/339 repeals it with effect from 11 December 2027.

Sources

1. European Commission: Cyber Resilience Act implementation and CRA summary
2. EUR-Lex: Regulation (EU) 2024/2847, consolidated text and Official Journal text
3. ENISA: Single reporting platform and FAQ
4. European Commission: CRA conformity assessment, CRA and manufacturers and CRA and open source
5. European Commission: guidance on CRA implementation (July 2026)
6. CRA Annexes I, III and IV (unofficial copy); Article 64 on penalties (unofficial copy); Article 69 on transitional provisions (unofficial copy)
7. NCSC Ireland: Cyber Resilience Act
8. EUR-Lex: Delegated Regulation (EU) 2023/2444 (RED application date), Implementing Decision (EU) 2025/138 (EN 18031) and Delegated Regulation (EU) 2026/339 (repeal)
9. Freshfields: CRA reporting obligations take effect on 11 September 2026
10. Qorvo Tech Forum: FiRa coordinator scheduler thread (DW3_QM33 SDK v1.1.1 library names)
11. Qorvo Tech Forum: “QM35825 Application development”
12. Qorvo QM35825 product brief and New Electronics: Qorvo QPG6200L
13. Qorvo QM35 SDK repository on GitLab
14. European Commission: guidance on the application of the CRA, C(2026) 5252 annex
15. European Commission: FAQs on the CRA implementation and CRA reporting obligations
16. ENISA: CRA SRP glossary and AR notification submission and update
17. ENISA: Vulnerability services, EUVD and EU KEV and EUVD API documentation
18. Qorvo: Product Security Incident Response Team
19. Zephyr: west spdx, modules and module.yml and sysbuild
20. Zephyr: security vulnerability reporting and release process and LTS
21. Yocto Project: Creating a Software Bill of Materials and Checking for vulnerabilities
22. SPDX 2.3.1 specification: package information and relationships
23. CycloneDX 1.6 JSON reference and schema
24. OASIS: Common Security Advisory Framework (CSAF) 2.0
25. BSI TR-03183-2: Software Bill of Materials, version 2.1.0
26. NVD: Getting started with the APIs and CVE API
27. OSV: POST /v1/query and data sources
28. MCUboot: design, imgtool, Zephyr port and Zephyr Kconfig
29. Zephyr: sysbuild bootloader Kconfig, Kconfig.mcuboot and dfu/mcuboot.h
30. FreeRTOS LTS

About needCode

needCode is an independent embedded engineering company from Kraków, Poland, and an official UWB business partner of Qorvo. Its engineers have worked inside Qorvo’s wireless programmes for more than eight years, including on the public QM35 SDK. needCode is certified to ISO 9001:2015 and ISO/IEC 27001:2022 and is a member of the UWB Alliance. This article is not legal advice and does not represent Qorvo. All trademarks belong to their respective owners.