How to approve factory firmware and software
Approve an exact release package, including firmware, software and settings, against recorded checks on the intended hardware. Give the factory written approval tied to that package, then verify production records and packed goods before authorising shipment. Coordinate these checks through Cambridge China Bridge.

Define exactly what you are approving
Ask the factory for distinct release identifiers for device firmware, companion software and any update package. Record the hardware revision, supported app version and cloud service dependency where relevant. Avoid approving descriptions such as “latest version”. Obtain the actual release files and a file hash, a fingerprint used to check that the file has not changed.
Require a readable version screen or diagnostic export from the device. Match it to the release files and programming record; a screenshot alone cannot prove which code was installed. Keep an approved sample with its release record. Use our repeat-order change guide for the wider factory change process.
Keep a configuration and approval record
Create a release record containing the order, model, hardware revision, release identifiers, file hashes, settings profile, release notes and known limitations. Include language, regional settings, calibration, enabled functions and update channel. Record credential provisioning arrangements without putting passwords or signing keys in a shared approval file.
Name the buyer's approver and the factory person responsible for installation. Record the approval date, covered batches and attached test results. State whether approval covers trial production, bulk production or shipment. Ask for a new approval whenever code, settings or a dependency changes, even if the visible version label stays the same.
Run regression checks on the proposed release
Regression checks confirm that a change has not broken previously accepted behaviour. Test the proposed release on the intended hardware with the intended settings. Check normal operation, startup, power loss, network loss, reconnection, factory reset and update recovery where relevant. Repeat checks for previous defects and safety-related functions. Record expected behaviour, actual results and unresolved failures.
For connected devices, UK government security guidance recommends securely updateable software and updates that preserve device functioning. Test the update path as well as fresh installation. Record the app and service environment used, because compatibility can change separately. Use our test-report coverage guide when checking which hardware and release a laboratory report assessed.
Make shipment release depend on version evidence
Put the approved release package and configuration on the factory's production instruction. Restrict access to programming files and withdraw superseded files from use. Ask for installation and verification records tied to serial numbers or batches, including reworked goods. Agree a hold rule for any unidentified or unapproved version before production starts.
Before authorising dispatch, compare production records with the approval record and read versions from inspector-selected packed goods. Check the settings too. If a mismatch appears, hold the affected shipment, establish its extent, correct it and repeat the relevant checks. Keep the evidence with the shipment record using our batch traceability guide.
Control changes after approval
Agree who can publish remote updates and change cloud settings. Require a change description, affected releases, regression evidence and a recovery plan before deployment. Set an urgent security-fix approval route so shipment controls do not become an indefinite block on patches. Keep a history of installed and deployed versions, and do not assume rollback is safe or supported.
For UK consumer connectable products, ask the relevant authority to confirm which security documentation and importer duties apply alongside release approval. Use our connectable-product security guide to prepare that enquiry. Confirm whether a statement of compliance and declared security support period are required, and keep any applicable documents linked to the product record; a buyer's firmware approval should not be treated as a substitute for required documentation.
Frequently asked questions
Is a firmware version screenshot enough?
Use it as supporting evidence. Also match the device reading to the release file hash, hardware revision, configuration and installation record.
Can the factory ship a newer firmware version?
Require written approval of the changed release before shipment. Ask what changed, repeat relevant regression checks and update the production instruction.
What if the factory cannot export the firmware?
Ask for a controlled release identifier, supplier-held file hash and verifiable installation records. If you cannot distinguish approved code from other code, hold release pending a workable check.
Do app and cloud changes need approval?
Include them when they affect the product's operation. Record the tested app and service environment, who controls changes and how compatibility will be checked.