In an OEM Connected Product, firmware, app, cloud and cybersecurity responsibilities are usually shared between several parties—but they should never be left undefined. The OEM factory may develop or integrate the hardware, PCBA and embedded firmware; a module supplier may provide the Bluetooth or Wi-Fi stack; an external software company may develop the mobile app or backend; and the brand may own the product, app-store accounts, cloud services and long-term security obligations. If the product is sold under the brand’s own name or trademark, the brand may also be the legal manufacturer under applicable regulations even when a Chinese OEM physically manufactures the product.

The practical answer is therefore:

Do not ask only, “Can the factory develop this connected product?” Ask who owns, controls, updates and supports every digital layer after the product ships.

For an OEM Connected Product, buyers should assign responsibility for:

• Hardware
• PCBA
• Firmware
• Firmware source code
• Bluetooth or Wi-Fi module
• Mobile app
• App-store accounts
• Backend and cloud
• OTA updates
• Security updates
• Software dependencies
• Vulnerability handling
• Technical documentation
• Post-sale support

This responsibility map should be agreed before the PCBA, wireless module, firmware architecture and app scope are locked.

If you are still defining the complete connected-product specification, our Connected Character Products buyer checklist explains what UK and EU buyers should confirm for Bluetooth, Wi-Fi, microphones, apps, cloud services, batteries, testing and technical documentation before manufacturing.

OEM Connected Product Responsibility at a Glance

This table should become part of the OEM Connected Product RFQ and development agreement.

1. First Identify Every Party in the OEM Connected Product

One of the biggest mistakes in smart product OEM manufacturing is treating “the supplier” as one company responsible for everything.

An OEM Connected Product may actually involve:

Brand
↓
OEM Factory
↓
PCBA Engineering Team
↓
Bluetooth/Wi-Fi Module Supplier
↓
Firmware Developer
↓
App Developer
↓
Cloud Provider

Sometimes the factory coordinates several of these parties.

Sometimes the buyer does.

Sometimes a PCBA supplier provides both hardware and firmware but does not own the mobile app.

Sometimes the app company controls the backend but has no access to device firmware.

Before development begins, buyers should identify who performs each role.

A useful supplier map includes:

This sounds administrative, but it determines whether the product can still be maintained two or five years after launch.

2. Firmware Responsibility in OEM Manufacturing

For many buyers searching for firmware responsibility OEM, the real concern is not who writes the first firmware version.

The real question is:

Who can fix the firmware after 20,000 units have already shipped?

Firmware may control:

• Power management
• Bluetooth
• Wi-Fi
• LEDs
• Buttons
• Touch sensors
• Audio
• Motors
• Alarm functions
• Display
• Charging behavior
• Communication with the app
• OTA updates

For every OEM Connected Product, buyers should record:

• Firmware developer
• Current firmware version
• Source-code owner
• Source-code location
• Build environment
• Third-party SDKs
• Update method
• Signing-key owner
• Release approval process
• Maintenance period

Three Common Firmware Ownership Models

Model A — Supplier-Owned Firmware

The PCBA or OEM supplier owns the code.

The buyer receives the finished device and the right to use the firmware.

This may be acceptable for simple products, but the contract should define:

• How long updates are supported
• Update cost
• Response time
• What happens if the supplier stops supporting the chipset
• Whether source code can be transferred under defined conditions

Model B — Brand-Owned Firmware

The brand owns the source code and appoints the OEM manufacturer to produce the hardware.

This gives the buyer more control but usually requires stronger internal technical capability.

Model C — Licensed Third-Party Firmware

The firmware belongs to a third-party engineering or chipset company.

The brand and factory use it under a license or development agreement.

This is common when a product uses existing Bluetooth, Wi-Fi or IoT platforms.

None of these structures is automatically wrong.

The dangerous structure is:

“The supplier takes care of the software.”

That is not a responsibility plan.

3. Firmware Source Code Is Different From the Firmware Binary

Buyers should understand this distinction.

A factory may have a firmware file that can be flashed into the MCU without owning or controlling the underlying source code.

For example:

production_v1.3.bin

is not the same thing as having:

• Source repository
• Libraries
• Compiler environment
• Configuration files
• Signing keys
• Build documentation

If a vulnerability or compatibility problem appears later, having only the production binary may not be enough to make a new version.

For an OEM Connected Product, buyers should therefore ask:

Can you modify the firmware?

Who can compile a new firmware version?

Who owns the source repository?

What happens if that developer leaves?

Can another engineering team maintain the product?

This is particularly important for long-life connected products.

4. OEM App Development: Who Actually Owns the App?

OEM app development is another area where responsibility becomes unclear.

A buyer may ask a smart product OEM manufacturer:

“Can you make the app?”

The supplier says yes.

But “yes” can mean very different things.

It might mean:

1. The factory has an in-house app team.
2. The factory subcontracts an app company.
3. The Bluetooth module supplier already has a generic app.
4. The factory uses a white-label IoT platform.
5. The buyer must provide the app developer.

These models have very different long-term implications.

Buyers Should Confirm App Ownership

For an OEM Connected Product with a mobile app, confirm:

• Who develops the iOS app?
• Who develops the Android app?
• Who owns the source code?
• Who owns the Apple developer account?
• Who owns the Google Play account?
• Who owns signing certificates and credentials?
• Who maintains the app?
• Who updates the app when iOS or Android changes?
• Who fixes security vulnerabilities?
• Who pays ongoing maintenance?
• Who controls analytics or user accounts?
• Who owns backend APIs?

An app should not be treated as a free accessory to the hardware.

It is a separately maintained software product.

Industry security guidance such as the OWASP Mobile Application Security guidance recommends secure architecture and design from the beginning rather than adding security only after development.

5. Can the OEM Factory Use an External App Developer?

Yes.

In fact, many hardware manufacturers do not maintain a full internal iOS, Android, backend and cloud-development organization.

A connected product manufacturer China may be strong at:

• Industrial design
• Structural engineering
• Mold development
• Injection molding
• PCBA
• Firmware
• Assembly
• Functional testing

while working with an external partner for:

• Mobile app
• User accounts
• Cloud API
• Backend
• App-store maintenance

This can work well if responsibilities are transparent.

The buyer should know exactly where the factory’s responsibility ends and the software partner’s responsibility begins.

For example:

This is more realistic than searching for a “firmware and app development manufacturer” and assuming one supplier must perform every task internally.

A good supplier should explain the supply chain clearly.

6. Bluetooth Product Manufacturer Responsibility

A Bluetooth product manufacturer must coordinate more than simply purchasing a Bluetooth chip.

A character Bluetooth speaker, alarm clock, light or interactive device may require:

• Bluetooth module
• Antenna
• Firmware
• BLE or Classic Bluetooth profiles
• Device naming
• Pairing behavior
• Mobile communication protocol
• RF testing
• Product qualification

The factory can integrate the Bluetooth hardware, but the buyer should still know which module and Bluetooth design are being used.

The official Bluetooth Qualification Process states that Bluetooth products must complete the applicable qualification process before being marketed. Bluetooth SIG also states that another supplier cannot simply qualify the buyer’s branded product on the buyer’s behalf; the relevant company needs to complete the process under its own membership account according to the applicable product scenario.

For an OEM Connected Product, ask the Bluetooth product manufacturer:

• Which Bluetooth chip or module is used?
• Which company provides it?
• What design is being referenced?
• Has the design been qualified?
• Which firmware version is used?
• Who will complete the final product qualification?
• What product name and model will be listed?
• Can the module be replaced later?
• What happens if the chipset becomes obsolete?

Our custom Bluetooth speaker manufacturer guide explains how character design, acoustic structure, Bluetooth modules, PCBA, battery, antenna, molding and packaging must be coordinated in one product.

7. Cloud and Backend Responsibility

An OEM Connected Product becomes significantly more complex when its functions depend on remote servers.

Examples include:

• User login
• Cloud alarm settings
• Remote device control
• Voice processing
• Cloud content
• Device profiles
• Push notifications
• Remote configuration
• Analytics
• OTA updates

The buyer should create a data-flow map such as:

Device → App → API → Cloud → Database

Then assign an owner to every layer.

Questions Buyers Should Ask

• Who hosts the server?
• Which cloud provider is used?
• Whose account is it?
• Who pays the hosting bill?
• Who controls API keys?
• Who backs up data?
• Who monitors uptime?
• Who maintains the API?
• Who patches the server?
• What happens if the app developer stops working?
• Can the brand migrate to another provider?

If the cloud account belongs entirely to an external supplier, the brand may become dependent on that supplier for the lifetime of the product.

For important products, account ownership and migration rights should be considered before launch.

8. Who Is Responsible for Cybersecurity?

Cybersecurity responsibility should be separated into two concepts:

technical responsibility and legal responsibility.

The engineering company may identify and fix a firmware vulnerability.

The app developer may patch the mobile application.

The module supplier may publish a Bluetooth-stack security update.

But the company legally responsible for putting the product on a market may still have obligations that cannot simply be transferred by saying, “our OEM handles cybersecurity.”

For the EU Cyber Resilience Act, a manufacturer includes a person or company that develops or manufactures a product with digital elements—or has it designed, developed or manufactured—and markets it under its own name or trademark.

That means a European or global brand selling its own OEM Connected Product may itself be the CRA manufacturer even when a connected product manufacturer China physically makes the device.

The factory can provide:

• Hardware documents
• Firmware details
• Software-component information
• Test data
• Engineering investigation
• Security patches

But legal obligations depend on the actual economic-operator role.

This distinction should be discussed with qualified compliance professionals for the target market.

9. Security Updates Must Have an Owner

One of the most important OEM Connected Product questions is:

Who will create and deliver a security update after shipment?

Possible firmware update methods include:

• Bluetooth OTA
• Wi-Fi OTA
• Mobile-app update
• USB update
• Service tool
• Factory reflashing

A product may technically need a security update but have no practical way to update devices already in customers’ homes.

That risk should be identified before production.

The EU CRA requires manufacturers to handle vulnerabilities during the support period and address vulnerabilities, including through security updates where relevant. It also requires manufacturers to determine and communicate a support period; the regulation generally establishes at least five years unless the product is reasonably expected to be used for less.

For each OEM Connected Product, record:

“Supplier will support if needed” is too vague.

10. Support Period Must Match the Supply Chain

A smart product OEM manufacturer may be able to manufacture a device for six months.

The connected product itself may remain in customers’ homes for five years.

Those are two completely different timelines.

Before launch, buyers should check whether all critical suppliers can support the intended product lifetime:

• MCU supplier
• Bluetooth/Wi-Fi module supplier
• Firmware developer
• App developer
• Cloud provider
• OTA provider

Imagine the brand promises five years of support but the Bluetooth module becomes unsupported after two years.

The brand may face an expensive redesign or unsupported security problem.

For this reason, component lifecycle and software lifecycle should influence supplier selection—not only unit price.

11. Third-Party Modules Create Third-Party Dependencies

Very few OEM Connected Product projects develop every hardware and software component from zero.

A product may rely on:

• Bluetooth SDK
• Wi-Fi SDK
• RTOS
• Encryption library
• MCU libraries
• Cloud SDK
• App framework
• OTA library
• Voice service
• Analytics SDK

Each dependency can become a future maintenance dependency.

Under the CRA, manufacturers need to identify and document vulnerabilities and components, including drawing up a software bill of materials covering at least top-level dependencies.

For procurement, buyers should request a software-component record such as:

This is different from the hardware BOM.

The hardware BOM tells buyers what is physically installed.

The software BOM helps explain what code and dependencies are inside the digital product.

12. Vulnerability Reporting Cannot Start After a Problem Happens

Every OEM Connected Product should have a vulnerability escalation path.

For example:

Customer / Researcher
↓
Brand Security Contact
↓
Product Team
↓
Firmware / App / Cloud Supplier
↓
Technical Investigation
↓
Patch
↓
Validation
↓
Release / Reporting

The buyer should define:

• Public security contact
• Internal owner
• Factory technical contact
• Firmware contact
• App developer contact
• Module supplier contact
• Severity-assessment process
• Patch approval
• Customer communication
• Regulatory reporting

This is particularly relevant in the EU because the CRA’s Article 14 reporting obligations are already applicable as of 11 September 2026. Manufacturers must report actively exploited vulnerabilities and severe security incidents through the CRA reporting system, with an early warning generally required within 24 hours and a fuller notification within 72 hours.

The official EU CRA reporting obligations guidance provides the current reporting framework.

The OEM supplier can support the investigation.

But the product owner should know who is responsible for making the actual report.

13. What Should the OEM Factory Manage?

For a typical OEM Connected Product, a capable hardware manufacturer may manage or coordinate:

• Industrial design
• Structural engineering
• Mold development
• Plastic injection
• PCBA
• SMT
• Bluetooth/Wi-Fi module integration
• Embedded firmware
• Battery integration
• Speaker / LED / sensor integration
• Device protocol
• Assembly
• Functional testing
• Aging tests
• Production flashing
• Firmware version control
• Packaging
• Production QC
• Technical manufacturing documents

The exact scope depends on the project.

Our Character Electronic Gift Manufacturer OEM guide explains how electronics, PCBA, structural engineering, character design, molding, assembly and packaging fit into an OEM product-development workflow.

14. What Should the Brand Manage?

Even when the OEM factory provides extensive technical support, the brand usually needs to make several product-owner decisions.

These include:

• Target market
• Product positioning
• Intended use
• Product specification
• Account ownership
• Firmware ownership agreement
• App ownership agreement
• Cloud ownership
• Support-period decision
• User communication
• Cybersecurity contact
• Compliance strategy
• Post-sale support
• Product discontinuation plan

For a branded OEM Connected Product, the buyer should avoid becoming completely dependent on one supplier account.

Where commercially practical, the brand should consider controlling critical assets such as:

• App-store accounts
• Cloud accounts
• Product domain
• Security contact
• Source-code access arrangements
• Signing credentials

The exact structure depends on the project and contractual model.

15. Responsibility Matrix Buyers Should Put in the OEM Agreement

Before tooling or mass production, buyers should create a formal matrix.

The exact responsibilities can differ.

The important point is that every row needs an owner.

16. When Should Responsibilities Be Locked?

Do not wait until mass production.

A practical OEM Connected Product development timeline looks like this:

A tooling PO should not be the first point at which the buyer asks who owns the firmware.

17. Example: Bluetooth Character Speaker Without an App

Consider a character speaker with:

• Bluetooth
• Rechargeable battery
• LED
• Embedded firmware
• No app
• No cloud

This is a relatively simple OEM Connected Product.

Responsibility may look like:

Factory

• Structure
• Mold
• PCBA
• Bluetooth integration
• Production
• Functional testing

Firmware supplier

• Device firmware
• Bluetooth logic
• LED logic
• Firmware patches

Brand

• Product specification
• Bluetooth qualification
• Target-market compliance
• Support policy
• Customer communication

Even without an app, the buyer should still know who can update Bluetooth-related firmware if a problem appears later.

18. Example: App-Controlled Character Alarm Clock

Now consider a product with:

• Bluetooth
• Wi-Fi
• Mobile app
• User account
• Cloud API
• OTA update
• Alarm schedules
• Remote configuration

This OEM Connected Product contains several separate systems:

**Device Hardware

• Embedded Firmware
• Wireless Module
• Mobile App
• API
• Cloud
• OTA Infrastructure**

A single hardware factory may coordinate the project, but responsibility must be divided.

Before production, the buyer should know:

• Who owns every source-code repository
• Who controls app-store accounts
• Who hosts cloud services
• Who maintains APIs
• Who develops firmware patches
• Who pushes OTA updates
• Who pays server fees
• Who supports the product after launch

A connected character product manufacturer should help map these relationships, not simply provide a unit price.

19. How to Choose a Connected Product Manufacturer China

When buyers search for a connected product manufacturer China, they should evaluate much more than molding capability.

Ask whether the supplier can support:

Hardware

• Industrial design
• Structural engineering
• PCBA
• SMT
• Wireless modules
• Batteries
• Sensors
• Speakers
• LEDs

Firmware

• Embedded software development
• Firmware version control
• Production flashing
• BLE/Wi-Fi protocols
• Update mechanism
• Debugging

App Integration

• Communication protocol
• API definition
• External app-developer coordination
• Device/app testing

Manufacturing

• Tooling
• Injection molding
• Painting
• Assembly
• Aging
• Functional QC
• Packaging

Lifecycle Support

• Component traceability
• Firmware records
• Third-party module information
• Engineering contacts
• Change control

A reliable smart product OEM manufacturer should be able to explain which capabilities are in-house and which are provided by partners.

That transparency is more valuable than claiming that everything is “one-stop.”

20. How Jiahong Creative Supports OEM Connected Product Development

Jiahong Creative supports character electronic and smart-product projects across product design, structural engineering, tooling, injection molding, PCBA assembly, embedded electronic functions, firmware coordination, painting, assembly, functional testing, packaging and mass production.

For an OEM Connected Product, our core manufacturing scope can include:

• Character/product design review
• 3D development
• Structural engineering
• Mold development
• Injection molding
• PCBA assembly
• SMT
• Embedded hardware
• LED and sensor functions
• Bluetooth/Wi-Fi module integration where required
• Embedded firmware and device-function coordination
• Product assembly
• Functional testing
• Aging testing
• Packaging
• QC

For projects requiring a full mobile app, backend or cloud platform, app development may be coordinated with an external software development partner rather than handled entirely by our in-house hardware engineering team.

This distinction is important.

We do not believe buyers should be told that the hardware factory automatically owns every part of the software ecosystem.

Instead, the project should clearly identify:

Jiahong Manufacturing Scope + Firmware Scope + External App Scope + Brand Responsibility

That approach makes responsibility easier to manage before mass production.

Brands developing character-based connected products can also review our Character Figure vs Character Electronic Product guide to understand how connectivity and electronics change product complexity compared with a static collectible.

If you are preparing an OEM Connected Product, share your product concept, character artwork, required functions, Bluetooth/Wi-Fi requirements, app requirements, target market, expected quantity and launch timeline through our connected product project inquiry.

Final Thoughts

An OEM Connected Product is not one product made by one supplier.

It is a system.

That system may include:

Hardware + PCBA + Firmware + Wireless Module + App + Cloud + OTA + Security Support

The OEM factory may manufacture the physical product and support firmware.

A specialist software partner may build the app.

A module supplier may maintain the Bluetooth or Wi-Fi stack.

A cloud provider may host backend infrastructure.

But the brand still needs to know who owns and maintains every layer.

The most important procurement rule is therefore:

Do not leave responsibility inside the word “OEM.”

Before manufacturing, define firmware ownership, source-code access, app ownership, cloud accounts, Bluetooth qualification, update mechanisms, support periods, third-party software, vulnerability reporting and post-sale engineering support.

When those responsibilities are written down early, an OEM Connected Product is much easier to manufacture, maintain and support.

When they are not, a small software problem after launch can become a supply-chain problem involving four companies that each believe someone else is responsible..

FAQ