Factory firmware changes: can I reuse the statement?
Hold approval of the changed reorder until the manufacturer explains the firmware changes, supplies security regression evidence and confirms that the Statement of Compliance accurately covers the shipment. Approve the exact hardware and software combination in writing. Cambridge China Bridge can coordinate these checks with its staff in China.
Treat the reorder as a changed configuration
For an in-scope product, PSTI security requirements apply to hardware and associated software. A familiar enclosure and unchanged model name are therefore poor reasons to accept changed firmware without review. Use our PSTI guide for scope and importer duties; this guide addresses the reorder approval decision.
Ask the factory to identify the previously approved build, proposed build, hardware revision, app and cloud dependencies, and reason for each change. Request a change log covering security fixes, removed functions and component substitutions. Put the proposed shipment on an approval hold while you assess that evidence.
Request evidence that security has not regressed
Ask for comparative test results from the previously approved and proposed configurations. Include password behaviour during setup and factory reset, account access, update installation and continued access to vulnerability-reporting information. Request the test method, tested build, hardware identity, expected result, actual result and unresolved defects. A demonstration that the app still connects is insufficient for this review.
Extend testing to the changed areas: authentication, network services, stored credentials, update verification and recovery after an interrupted update. These are suggested acceptance checks, not a prescribed statutory test programme. Ask a security specialist to assess gaps that the factory cannot explain, and keep the underlying logs rather than accepting a pass summary alone.
Check whether the existing statement remains accurate
Confirm with OPSS how the Statement of Compliance should accompany your in-scope product. Compare its product and batch identification, manufacturer details, compliance declaration, declared support period, any standards relied on and signing details with the proposed shipment. Our statement checklist covers the document review.
Do not assume either that a firmware change automatically requires a new statement or that the old statement remains suitable. Ask the manufacturer for a written assessment linking the changed configuration and regression evidence to its declaration. If the existing statement does not accurately describe the shipment or its claims cannot be supported, request a corrected statement before release. An unchanged support promise also needs a credible delivery plan.
Approve what production will actually ship
Record approval against the hardware revision, firmware build identifier and file fingerprint, app compatibility, relevant cloud configuration and batch. Retain the approved device and firmware file. Make the order prohibit unapproved substitutions or reflashing after approval, using our firmware approval guide to organise the version record.
Ask your inspector to read firmware identifiers from production devices and compare them with the approval record. Check setup, reset and update behaviour on shipment samples, and reconcile the batch with the accompanying statement. Decide in advance who can authorise release and what evidence they need. Keep commercial release approval distinct from the manufacturer's compliance declaration.
Working out your own order? Send us the product on WhatsApp and we reply the same working day: WhatsApp us
Resolve gaps before releasing the batch
If logs are missing, build identities differ or the manufacturer cannot explain its declaration, keep the changed batch on hold. Ask for a corrected build and repeat the affected checks. Reverting to the earlier build is only a sensible option after reviewing why it was replaced, including any security defects it leaves unresolved.
If you know or believe the manufacturer has failed to comply, keep supply on hold and confirm your obligations with OPSS, using our PSTI guide to prepare your questions. If the evidence suggests earlier supplied goods may also be affected, consult that guide and ask OPSS what investigation and notification steps are needed. Keep the change request, test evidence, statement assessment and shipment approval together so the decision can be reconstructed.
Frequently asked questions
Can I reuse the Statement of Compliance after a firmware change?
Assess whether it still accurately covers the shipment and whether its declaration remains supported. Ask the manufacturer to document that assessment; request a corrected statement where the existing document is inaccurate.
Does every firmware change need a new security test?
Use the change log to choose regression checks and review affected security functions. Request results tied to the proposed build and hardware. Seek specialist review where the impact is unclear.
Is the same model number enough to approve a reorder?
No. For your release decision, identify the hardware revision, firmware build and relevant app or cloud dependencies. Compare production devices with the configuration you approved.
Can I ask the factory to restore the old firmware?
Yes, as a proposed remedy, but review why it was replaced first. The old build may retain security defects. Approve the resulting configuration only after checking its evidence and statement.