A buyer-side checklist for distributors and system integrators assessing an OEM smart lock manufacturer for private-label supply or a defined project.

Price is only one part of supplier selection. Before approving an OEM smart lock manufacturer, review the exact hardware revision, test evidence, firmware responsibility, app route, quality records and support owner. The seven checks below are intended for a sourcing decision, not a generic supplier profile.

1Certification Evidence for the Exact Model

Do not accept a certificate image as proof for every configuration. Request the test report and confirm the product model, hardware revision, wireless module and firmware version covered. A report for an earlier platform may not support a revised PCB, antenna or radio module.

What to ask for specifically:

  • CE: Full test report from an EU-accredited Notified Body (TÜV Rheinland, SGS, Intertek, Bureau Veritas). Confirm which hardware revision and firmware version was tested. Confirm RED 2014/53/EU (for wireless models) and LVD 2014/35/EU are both covered.
  • FCC: FCC ID number and Grant of Authorization from the FCC database (publicly searchable at fcc.gov). Confirm this matches the exact module used in your product.
  • SASO (Saudi Arabia): Certificate of Conformity from a SASO-approved Conformity Assessment Body. Check the product scope matches smart locks and access control under IEC 60839-11.
  • ISO 9001: Factory certificate issued by an accredited body. Check the expiry date — some factories display lapsed certificates.
Procurement check: Ask for the issuing body, report reference, product revision and validity date. If those details cannot be provided, treat the document as unverified until the issuer or laboratory confirms it.

2MOQ by Customization Scope

MOQ (minimum order quantity) for OEM smart locks depends on what changes. Separate stock supply, private-label OEM and ODM development before comparing quotations:

  • Standard wholesale (stock products, your packaging): Standard supply starts at 200 units. Lead time and packaging details are confirmed for the selected configuration and written quotation.
  • OEM (logo, language, packaging or scoped app branding): OEM/private-label programmes start at 500 units. Scope, testing and lead time are confirmed in the project quotation.
  • ODM (custom hardware design): MOQ 1,000 units. Custom housing, PCB or firmware work is scoped and scheduled after technical review.

Match the first order to a documented rollout plan rather than a forecast alone. A higher MOQ may be justified by a confirmed project, but not by branding preference without an approved deployment schedule.

3Firmware Scope and Change Control

Separate visual branding from functional firmware work. Language packs, app labels and packaging are not equivalent to changes in unlock modes, access-control protocols, offline credentials or OTA behaviour. Record each requested change against the selected model before ordering.

Questions to qualify firmware capability:

  • Can the firmware language be changed to Arabic/French/German/Spanish at the factory? (Not via an after-market workaround.)
  • Is there an offline unlock mode for areas with poor mobile connectivity? How are tokens generated and validated?
  • What is the access log capacity? Can logs be exported via USB, API, or Bluetooth sync?
  • Does the firmware support OSDP v2 for connection to third-party access control panels?
  • What is the OTA (over-the-air) update mechanism? Can you push a firmware update to all deployed units remotely?
Review point: Request a recent firmware changelog, a version-identification method and the proposed escalation route. This establishes whether updates can be traced and who assesses a field issue after shipment.

4App Platform and Account Ownership

Tuya, TTLock and proprietary app routes have different device coverage, account ownership, API and data-handling boundaries. Decide the route before confirming a product configuration, then document the responsibilities for the app store, cloud account and support.

SDK-Based White Label (Tuya / TTLock)

A white-label SDK route can use the selected platform's device and cloud services under a branded application. Confirm the available device functions, app-store account owner, data region, user-role model and API scope for the exact product before committing.

  • Tuya / TTLock: Confirm the approved device model, required account type, supported access methods and project-specific connection requirements.
  • SDK route: Confirm the available API, audit trail, data-processing arrangements and deployment model before using it for managed-property or regulated applications.

Custom App + Proprietary Cloud

A proprietary application and cloud route requires a defined device interface, account model, data location, release process and support ownership. It should be treated as a separate engineering scope from the hardware supply programme, with acceptance criteria agreed before development starts.

5Factory Audit and Production Evidence

An audit should establish who makes the product, how quality records are controlled and where subcontracting may affect the agreed scope. Treat the visit as evidence collection, not a sales presentation.

Minimum audit checks for an OEM relationship:

  • Production line walkthrough: SMT assembly, reflow, AOI inspection, functional test bench, aging test rack.
  • ISO 9001 records: Incoming material inspection records, non-conformance reports (NCRs), corrective action logs.
  • NDA policy: Does the factory sign NDAs before sharing firmware source code or custom tooling? An unwillingness to sign a standard mutual NDA is a serious concern.
  • Subcontracting disclosure: Is any part of the assembly subcontracted? If so, who is the subcontractor and do they operate under the same QMS?
  • Capacity: What is the current monthly output? What is the lead time if you place a 1,000-unit order today?

6After-Sales Support and Escalation

Agree how a field issue is logged, diagnosed, assigned and closed before shipment. The relevant support boundary includes the device, firmware, app, cloud account and any approved third-party interface.

  • Support channels: Confirm the WhatsApp and email contacts, escalation path and support scope for your project.
  • Language support: Confirm the working language, named technical contact and escalation owner for the target market.
  • Remote diagnostics: Confirm which logs, version records or device evidence can be reviewed remotely and when a returned sample is required.
  • Warranty terms: Record the warranty scope, DOA handling, evidence required for a claim and replacement route in the sales agreement.

7Market Documentation Package

Certification documents must be reviewed against the destination market, product revision and import route. The required package should be listed in the project scope instead of assumed from a prior shipment.

  • Europe (CE): Can they provide an editable DoC template in Word format? Will they support a re-test if you need to modify the product for a specific EU tender requirement?
  • Saudi Arabia (SASO): Do they have an existing SASO CoC or can they obtain one? Who is their approved Conformity Assessment Body? Can they provide bilingual English/Arabic documentation?
  • UAE (TRA): Do they have TRA Type Approval for Wi-Fi and Bluetooth models? Can they provide the TRA approval certificate for import clearance?
  • USA (FCC): Do they have FCC Part 15 authorization? Can they support a "Change in ID" application if you need to place the product under your own FCC Grantee ID?
Scope it in writing: List the required reports, declarations, manuals, labels and language versions against the selected model and destination. Confirm who prepares each item and when it is reviewed.

Apply the Checklist to the Selected Configuration

Review the seven criteria against the actual model, destination and supply route. Weight the evidence according to project risk: wireless approvals and local import documents may be decisive in one market; firmware change control and connection evidence may be decisive in another.

Do not approve a supplier on price alone where test evidence, firmware ownership or support responsibility remains undefined. Those gaps should be closed in the specification, sample record or written quotation before a purchase order is released.

Request an OEM scope review

Send the model reference, destination, branding scope, app route and required documents. We will identify the information needed for a quotation or sample review.

Review OEM/ODM options Send project details
FAQ

Frequently Asked Questions: OEM Smart Lock Manufacturing

For planning, Trudian uses standard supply 200 units, OEM/private label 500 units and ODM 1,000 units. Final quantities depend on the selected model, customization scope, testing requirements and target market.

OEM normally uses an approved product platform while adapting the agreed branding, packaging, language, interface or firmware options. ODM adds a new product brief or substantive mechanical, electronic or firmware changes. Confirm feasibility, validation, ownership and documentation in the written scope before quotation.

Lead time is confirmed after the model, customization scope, testing requirements and order details are reviewed. Request a written schedule with the quotation, including sample approval, app-store, compliance and shipping dependencies.

Compare each platform's device coverage, user roles, connection requirements, data handling and deployment model. For European or other regulated deployments, confirm storage, access and retention arrangements for the selected software before committing.

Yes, and you should. Legitimate OEM manufacturers welcome factory audits — resistance to auditing is a significant red flag. Request an in-person visit covering production lines, QC processes, component storage and ISO 9001 documentation. If travel is not feasible, ask an independent audit provider for its current written scope and quotation. Minimum documentation to request before signing: ISO 9001 certificate, CE test reports for the specific SKUs you intend to brand and a sample NDA/OEM agreement for legal review.

Agree the app account owner, firmware version control, OTA update route, issue escalation path, audit-log or interface requirements and named technical contacts. For managed-property projects, record the support boundary, response process and responsibilities in the project documentation.

Review test reports and declarations for the selected model and hardware revision, the factory quality certificate, sample record, firmware/version evidence, draft branding artwork, requested manuals and market-specific requirements. Verify each document with its issuer or authority where possible; a label alone is not sufficient evidence.