Taking over a Qorvo-based product: a 90-day plan for sustaining engineering, fixes and SDK updates

Facts checked on 16 October 2026

Short answer

A takeover of a product built on Qorvo silicon is safe when you reproduce before you change. First rebuild the exact firmware that ships, stand up hardware-in-the-loop tests, and record the SBOM, the signing flow and known vulnerabilities. Only then take ownership of releases.

A realistic plan is 30 days to get in, 30 days to ship the first maintenance or security release through the new pipeline, and 30 days to deliver the first feature or upgrade milestone together with a 12-month roadmap.

When a takeover is the right move

Products outlive the teams that built them. A takeover of firmware maintenance, by a new internal team or an external partner, usually starts with one of these triggers:

• The original team or vendor is leaving, or its key engineers have already moved on.
• Vendor priorities are shifting. Qorvo narrowed its UWB focus to automotive, industrial and enterprise markets in November 2025 and joined Skyworks in October 2026. Products outside those markets should expect to carry more of their own engineering.
• Updates are piling up. New Qorvo SDK releases, RTOS versions and toolchains arrive while the product stays on old ones.
• Security obligations have started. Under the EU Cyber Resilience Act, reporting obligations apply from 11 September 2026 and manufacturers must handle vulnerabilities over a support period of at least five years.
• Parts are ageing. The DW1000 is Not Recommended for New Designs and the DW3120 and DW3220 have an end-of-life notice. Each change of part means re-validation.

What sustaining engineering covers

The 90-day plan

Days 0–30: get in

The aim of the first month is to reproduce the product as it ships, without changing it.

• Access and ownership. Repositories with full history, build scripts, CI configuration, issue trackers, signing keys and their custody rules, and licences for vendor SDKs. Some licences restrict use: Qorvo’s QM35 SDK licence, for example, allows use only with Qorvo integrated circuits.
• Reproducible build. Rebuild the firmware that is in the field, bit for bit where possible, and document any difference. If you cannot rebuild what ships, you cannot patch it.
• Test environment. Reproduce the hardware-in-the-loop environment: devices, phones, anchors, RF set-up and test scripts. Run the existing test suite and record the baseline.
• SBOM and vulnerability baseline. List every component, including binary vendor libraries, and check each against known vulnerabilities.
• Shared priorities. Agree the backlog, the risk register and the release calendar with the product owner.
• Knowledge transfer. Hold recorded walkthroughs of architecture, radio configuration, calibration and manufacturing flows.

Exit criteria: the shipped image is rebuilt or its differences documented, the bench reproduces the baseline, every binary in the SBOM has a version and hash, and a test image has been signed through the production flow.

Days 31–60: take over

The second month proves the new pipeline on a real release.

• First maintenance or security release built, tested and shipped by the new team.
• Release pipeline and regression tests running: CI builds, static analysis and hardware-in-the-loop regression on every change.
• Backlog ownership moves to the new team, with an agreed process for field issues and on-call support.

Exit criteria: the release went out with no step performed by the outgoing team, and a backport to an older shipped version has been rehearsed.

Days 61–90: move forward

The third month shows that the product can move again.

• First feature or upgrade milestone, such as a Qorvo SDK upgrade behind a regression gate or an assessment of a DW1000 migration.
• Certification plan wherever upcoming changes affect FiRa, CSA, Bluetooth or CE/RED status.
• Roadmap for the next 12 months, covering features, SDK and RTOS updates, part lifecycle risks and CRA obligations.

The first 30 days in practice

Five pieces of work decide the first month. Each ends with a check that passes or yields a written list of differences.

Reproduce the shipped build

Start from what ships: collect the files that production programs and the OTA server distributes, record their SHA-256 hashes and find the tag that produced them. Then:

1. Pin the container by digest. A tag can move; a digest names one image, and Docker accepts image@sha256:… in docker pull and in a Dockerfile FROM line. Qorvo’s QPG6200 IoT SDK dev container names its image by tag (qpg6200-iot-sdk:2.0.1), so record the digest it resolved to.
2. Pin the toolchain. For the DW3_QM33 SDK, Qorvo staff give the requirement as arm-none-eabi-gcc 10.3-2021.10 and warn that a newer or different version will most probably give compile errors. The QM35 SDK’s Zephyr adaptation pins nRF Connect SDK v2.6.0 in west.yml, and Zephyr’s CONFIG_BUILD_OUTPUT_META records the revisions used and flags a dirty workspace.
3. Remove time and paths. GCC takes __DATE__ and __TIME__ from SOURCE_DATE_EPOCH when it is set; -Wdate-time finds those macros, and -ffile-prefix-map makes recorded paths location-independent.
4. Build twice and compare with each other and with the shipped file. If hashes differ, compare the linker map files, which show where each object was placed, and run diffoscope on the ELF files.

The check passes when the hashes match or every difference, such as a version string or signature block, is explained in writing. Illustrative commands:

IMG=registry.example.com/fw-build@sha256:<digest>
git worktree add ../b1 v2.3.1 && git worktree add ../b2 v2.3.1
export SOURCE_DATE_EPOCH=$(git -C ../b1 log -1 --pretty=%ct)
for d in ../b1 ../b2; do
  docker run --rm -e SOURCE_DATE_EPOCH -v "$(realpath "$d")":/src -w /src \
    "$IMG" ./scripts/build_release.sh
done
sha256sum ../b1/out/app.bin ../b2/out/app.bin shipped/app-2.3.1.bin
diff ../b1/out/app.map ../b2/out/app.map
diffoscope ../b1/out/app.elf ../b2/out/app.elf

Stand up a minimum hardware-in-the-loop bench

The bench can be small, but it must run unattended and log its conditions.

For ranging, collect the same number of ranges at several measured distances, enough that a repeat run gives the same result, and record mean error and standard deviation as the baseline. Qorvo staff explain on the forum that an error that stays nearly constant across distances points to antenna delay. Log temperature and supply: for the DW1000, Qorvo’s FAQ quotes range changes of 2.15 mm per °C and 5.35 cm per volt of VBATT. Add a long soak; one developer reported two coordinator hangs in 8,871 ranging blocks over 30 minutes on SDK v1.1.1.

The DW3_QM33 SDK’s CLI and Python API (UWB Qorvo Tools) can drive sessions from a test host. On Zephyr hosts, Twister runs tests through a hardware map, with fixtures for wiring-specific tests (illustrative):

# run: west twister --device-testing --hardware-map map.yml -T tests/uwb
- connected: true
  id: "<probe serial>"
  platform: nrf52840dk/nrf52840
  product: J-Link
  runner: nrfjprog
  serial: /dev/ttyACM0
  fixtures:
    - uwb_peer_3m

Record the SBOM and vulnerability baseline

Build one SBOM per shipped version, with supplier, version and licence for each component and a SHA-256 hash for every binary. Vendor binaries need the most care. In build logs quoted on the forum, the stack archive names carry the stack build: R12.7.0-00288-gb8203d558863 in SDK 1.0.2 and R12.7.0-00405-gb33c5c42726c in 1.1.1. The QM35 SDK 3.0.0 release notes list the firmware, Cherry, Linux drivers and Zephyr adaptation at R13.1.0 and QSoC-Flash at v4.1.0.

On Zephyr, west spdx writes SPDX documents for application and Zephyr sources, build outputs and module dependencies, with SHA-256 and SHA-1 per file. Zephyr 3.7 needs west spdx --init before the build; current documentation drops that step and needs only CONFIG_BUILD_OUTPUT_META. Set -n, or each run gets a random namespace UUID. CPE and PURL entries under security: external-references in module.yml let tools match modules against vulnerability databases. Illustrative, for Zephyr 3.7:

west spdx --init -d build
west build -d build -b <board> app -- -DCONFIG_BUILD_OUTPUT_META=y
west spdx -d build -n https://sbom.example.com/product/2.3.1
sha256sum vendor/lib/*.a > build/spdx/vendor-binaries.sha256

The check passes when every binary has a version and hash and every known vulnerability is triaged. Report vulnerabilities in Qorvo components to psirt@qorvo.com, encrypted, with the part number, hardware and SDK versions and reproduction steps; Qorvo aims to respond within three business days.

Take over the signing keys

Find out which keys the fleet trusts first, because that cannot be changed from the bench.

• MCUboot. The bootloader embeds only public-key bytes; in Zephyr, CONFIG_BOOT_SIGNATURE_KEY_FILE accepts a public-only PEM, so the private key can stay with the release team. The sysbuild defaults point at MCUboot’s sample keys, such as root-ec-p256.pem, whose private keys are public; check that the shipped bootloader did not use them.
• QPG6200. The device stores a digest of the Manufacturer Public Key programmed in production. The manufacturer signs Developer Certificates, and developers sign firmware with their key and certificate. Secure Boot and Secure Debug cannot be disabled once enabled.

MCUboot’s documentation keeps the production private key in an HSM, used by the release team in a signing ceremony; its Zephyr port can embed up to eight verification keys of one type, which allows a planned rotation. NIST’s code-signing guidance adds separate roles, two-person approval, audited key use and development keys that do not chain to production roots. Both imgtool (--vector-to-sign, --fix-sig) and Qorvo’s appuc-firmware-packer (--get_hash, --inject_signature) support signing a digest outside the build machine.

The check passes when a test image signed through the production flow boots on a production-configured unit:

imgtool getpubhash -k prod_pub.pem            # SHA-256 of the public key
imgtool verify -k prod_pub.pem app.signed.bin # "Image was correctly validated"
imgtool dumpinfo app.signed.bin               # header, TLV area and trailer

On the QPG6200, the application bootloader logs “Secure boot Enabled” and “Application validate correctly”.

Run knowledge transfer as working sessions

Recorded walkthroughs help, but transfer is proven when the new team does each task while the outgoing team watches.

On the DWM3001CDK, Qorvo staff note that modules are calibrated in production with values in OTP, readable with the CLI command GETOTP, and that the FiRa stack reads calibration through the keys the CALKEY command sets. Ask which values the product overrides.

Branches and backports for shipped versions

Fixes must reach the versions customers run without forcing them onto the newest code.

1. Tag every shipped version and branch each maintenance line from its tag.
2. Merge the fix on main, then backport it with git cherry-pick -x, which adds “(cherry picked from commit …)” to the message.
3. Raise every version the device checks. MCUboot stores major.minor.revision+build in the image header and can derive a security counter from it (-s auto) for hardware rollback protection; its software downgrade prevention works only with overwrite-only updates. Qorvo’s Matter OTA guide notes that an image whose software version matches the running one is ignored, so CHIP_DEVICE_CONFIG_DEVICE_SOFTWARE_VERSION must increase.
4. Run the full regression gate on the maintenance branch.

git switch -c maint/2.3 v2.3.1
git cherry-pick -x <commit-on-main>
git tag -a v2.3.2 -m "Maintenance release 2.3.2"

Treat vendor fixes the same way. QPG6200 IoT SDK 2.0.2 fixes devices on 2.0.1 that could not be added to Google Home by raising CHIP_IM_MAX_REPORTS_IN_FLIGHT from 2 to 4 in CHIPProjectConfig.h, but the release also changes the OTA mechanism and removes examples. For a product on 2.0.1, that change is a backport candidate; the SDK upgrade is a separate milestone behind the gate.

Takeover scenarios on Qorvo silicon

Every takeover follows the same 90-day logic, but the first risks differ by platform.

A UWB product that grew out of Qorvo’s DW3_QM33 SDK examples

Many DWM3001C and QM33 products start from Qorvo’s examples on FreeRTOS and keep that structure in production. The FiRa stack in the SDK ships as a pre-compiled library, and the SDK has moved from version 1.0.2 to 1.1.1. First steps:

• find the SDK version the product was built from and compare the product code with the untouched examples, so you know what was changed and why;
• separate product logic from example code before you upgrade anything;
• pin the SDK version and add ranging regression tests on hardware before the first upgrade;
• check Bluetooth LE and UWB timing on the nRF52833 host, because coexistence problems often appear only under load.

A Matter or Zigbee product on Qorvo QPG chips

On the QPG6200L, Matter, Zigbee and Bluetooth LE can run concurrently through Qorvo’s ConcurrentConnect technology, and the chip includes a secure element. First steps:

• collect the CSA certification records and test reports for each device type, and check the CSA rules on re-testing before changing the Matter SDK version. Qorvo’s OTA guide says full recertification may be advised in most cases, with the CSA’s rapid recert programme possibly covering a bootloader-only or Secure Element-only update;
• reproduce the OTA pipeline end to end, including image signing, from every shipped version;
• confirm which Matter SDK version and which Qorvo platform release the product uses, and plan the update path;
• record the ROM bootloader and Secure Element firmware versions, which Qorvo’s device acceptance checklist compares with the SDK release notes.

A QM35825 product with a Linux or MCU host

The QM35825 runs Qorvo’s pre-compiled firmware; the product’s own logic lives on the host. First steps:

• record the firmware version on the chip and the versions of the host software: the Linux kernel driver or Zephyr port, the Cherry API and your application;
• check licence obligations, because the QM35 SDK’s Linux driver is dual-licensed under GPLv2 and a Qorvo commercial licence;
• plan how firmware updates reach the QM35825 through the host, and test that path on hardware. On Linux, qm35_spi flashes /lib/firmware/qorvo/qm35.bin at load if it differs from the running firmware; otherwise the chip starts from its own non-volatile memory. Bit 2 of debug_flags forces the update and bit 3 disables it;
• collect chip coredumps from sysfs, where the driver keeps up to 32 by default (at most 2 MB of RAM).

An illustrative first check on Linux:

dmesg -C && modprobe qm35_spi && dmesg | grep -i "firmware"
# expect "Running firmware version: ..." and "Loaded firmware version: ..."
sha256sum /lib/firmware/qorvo/*.bin

What to agree in the contract

A takeover contract should make the next handover easy too:

• Scope and service levels, with response and resolution targets defined separately for critical, major and minor issues.
• Access and ownership of code, documentation and test assets, including what happens to them when the contract ends.
• Signing keys: who holds them, how they are stored and who may use them.
• Security responsibilities under the CRA: who monitors vulnerabilities, who triages and who prepares the 24-hour and 72-hour reports for the manufacturer.
• Knowledge transfer obligations for the outgoing team or vendor, with dates.
• An exit plan, so that a future handover starts from documentation instead of archaeology.

The handover checklist

Download the handover checklist as a two-page PDF

Risks that sink takeovers

• Lost or unclear signing keys. Without them, no update reaches the field.
• Builds that cannot be reproduced. Teams discover this only when an urgent fix is needed.
• Vendor binaries without matching versions. A library that does not match the shipped one changes behaviour silently.
• Undocumented calibration. Ranging accuracy drops after a “harmless” production change.
• No hardware in the loop. Radio regressions reach customers instead of the test bench.
• Knowledge held by one person. Their departure ends the handover.
• Changing too much too early. A refactor in week two makes it impossible to tell new bugs from old ones.
• Certification invalidated by a small change. Some changes need re-testing; plan them, do not stumble into them.

Failure modes: symptom, cause, check, fix

How to tell the takeover is healthy

Track a handful of measures from day one:

• time to reproduce the shipped build;
• share of test cases automated and running on hardware;
• time from a field report to a triaged issue;
• age of open vulnerabilities in the SBOM;
• release cadence against the agreed calendar.

Regression gates for every release

From our engineering work

For Qorvo, needCode onboarded five specialised engineers onto a time-critical project in under six weeks, and only four engineers left our Qorvo teams in more than five years. Our engineers also build Qorvo’s public QM35 SDK.

How needCode helps

needCode takes over Qorvo-based products with the 30/60/90-day plan described above. The Sustain & Secure retainer covers maintenance under SLA, bug fixes and backports to the version you ship, Qorvo SDK, RTOS and toolchain updates gated by hardware-in-the-loop tests, CVE monitoring and security releases, and field diagnostics. For products that need continuous development, a long-term team works inside your release process, the model we have run with Qorvo for more than eight years. needCode is certified to ISO 9001:2015 and ISO/IEC 27001:2022.

Frequently asked questions

How long does it take to take over an embedded firmware product?

Plan around 90 days for full ownership: about 30 days to reproduce the build and test environment, about 30 more to ship the first release through the new pipeline, and a further 30 to deliver the first feature or upgrade milestone with a roadmap. Complex products with many variants take longer.

What should we ask our current firmware vendor before switching?

Ask for full repositories with history, tags for every shipped version, build and CI scripts, toolchain versions, vendor SDK versions and patches, signing keys and their custody rules, calibration and production test procedures, certification records, open issues and field logs. Agree a knowledge-transfer schedule before the contract ends.

Can a new team maintain firmware built on Qorvo’s binary SDK libraries?

Yes, with clear limits. The team can update, test and ship everything around a binary library, track its version and report defects or vulnerabilities to Qorvo, as the CRA expects. Fixes inside the library itself depend on Qorvo releasing a new version.

Do we need to re-certify after a takeover?

Not because of the takeover itself. Certification follows the product, not the team. Changes made afterwards, such as new radio parts, new SDK versions or new features, can trigger re-testing for FiRa, CSA, Bluetooth or CE/RED, so plan them with the certification records in hand.

What does a sustaining retainer include?

Typically maintenance under SLA, bug fixes and backports, SDK, RTOS and toolchain updates, security releases with CVE monitoring, regression testing on hardware for every release and field diagnostics. The exact scope and response times are set per product.

How do we prove that a rebuilt image matches the firmware in the field?

Rebuild from the shipped tag in a container pinned by digest, with the SDK’s required toolchain and SOURCE_DATE_EPOCH set from the commit, and compare SHA-256 hashes with the shipped file. For signed images, compare the payload and verify the shipped signature with the fleet’s public key, for example with imgtool verify. Explain any remaining difference in writing.

What if nobody can find the signing keys?

Then no update can reach the field. MCUboot accepts only images signed with a key whose public part the bootloader embeds, and a QPG6200 with Secure Boot, which cannot be turned off, accepts only firmware that chains to the Manufacturer Public Key programmed in production. Settle custody and a rotation plan in the first 30 days.

Sources

1. Qorvo Q2 FY2026 earnings call transcript (3 Nov 2025)
2. Qorvo: “Skyworks completes combination with Qorvo” (5 Oct 2026)
3. European Commission: Cyber Resilience Act implementation
4. EUR-Lex: Regulation (EU) 2024/2847, consolidated text
5. Qorvo Tech Forum: “Qorvo DW1000: Recommended for New Designs?”
6. Qorvo DW3120 product page (PCN 26-0105)
7. Qorvo QM35 SDK repository on GitLab
8. Qorvo Tech Forum: DW3_QM33 SDK v1.0.2 release and QM33120WDK1 product page (SDK v1.1.1)
9. Qorvo Tech Forum: FiRa coordinator scheduler thread (SDK v1.1.1 library names)
10. New Electronics: Qorvo QPG6200L
11. Qorvo Tech Forum: “QM35825 Application development”
12. Reproducible Builds: SOURCE_DATE_EPOCH specification
13. GCC manual: Environment variables (SOURCE_DATE_EPOCH)
14. GCC manual: Overall options (-ffile-prefix-map)
15. GCC manual: Warning options (-Wdate-time)
16. GNU ld manual: Command-line options (-Map, –print-memory-usage)
17. Docker documentation: docker image pull (pull by digest)
18. diffoscope
19. Git documentation: pretty formats
20. Git documentation: git cherry-pick
21. Qorvo Tech Forum: “Is firmware build and flashing on macOS supported for DWM3001CDK?” (toolchain requirement)
22. Qorvo Tech Forum: “DW3_QM33_SDK_1.0.2 build” (SDK 1.0.2 library names)
23. Qorvo QPG6200 IoT SDK: dev container definition
24. Qorvo QPG6200 IoT SDK: release notes (2.0.2)
25. Qorvo QPG6200 IoT SDK: Security user journey (secure boot, signing)
26. Qorvo QPG6200 IoT SDK: Matter OTA device firmware upgrade
27. Qorvo QM35 SDK: Release Notes 3.0.0
28. Qorvo QM35 SDK: Linux Kernel Driver Guide
29. Qorvo QM35 SDK: Zephyr adaptation west.yml
30. Zephyr documentation: west spdx
31. Zephyr v3.7.0 documentation source: west spdx
32. Zephyr Kconfig.zephyr: BUILD_OUTPUT_META
33. Zephyr documentation: Modules (vulnerability monitoring)
34. Zephyr documentation: Twister (device testing and fixtures)
35. Zephyr documentation: Optimization tools (ram_report, rom_report)
36. Zephyr sysbuild bootloader Kconfig (BOOT_SIGNATURE_KEY_FILE)
37. MCUboot documentation: imgtool
38. MCUboot: imgtool command-line source (verify, getpubhash, dumpinfo)
39. MCUboot: Building and using MCUboot with Zephyr (keys and custody model)
40. MCUboot documentation: Bootloader design (downgrade prevention)
41. NIST CSWP 5: Security Considerations for Code Signing (2018)
42. Qorvo: Product Security Incident Response Team
43. Qorvo: Ultra-wideband FAQs
44. Qorvo Tech Forum: “How to reduce distance d_cm error” (calibration values in OTP)
45. Qorvo Tech Forum: “Calibration issues with UWB” (constant offset and antenna delay)
46. Qorvo Tech Forum: “Factory-calibrated xtal_trim overridden by default in SDK build? (DWM3001CDK)”
47. Nordic Semiconductor: nRF Sniffer for Bluetooth LE

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 does not represent Qorvo. All trademarks belong to their respective owners.