Yes, OPC UA and MQTT can run side by side on the same edge device when the installed software supports both roles and the host has sufficient resources. The protocols do not inherently conflict, but you must configure the data handoff, endpoint security, and failure behavior; installing both services does not create an integration.
TL;DR
Yes. Sharing a host is a deployment choice, not a protocol incompatibility. An edge application can expose an OPC UA server while an MQTT client publishes selected data to a broker. Alternatively, separate applications can exchange data through a configured interface on the same host.
Choose the arrangement by trust boundary, maintenance ownership, and required failure isolation—not simply by whether both services start.
Integrated runtime
Separate services
Separate hosts
Software Toolbox provides industrial connectivity and DataOps software for these application areas. Select a configuration only after checking its supported operating system, protocol roles, security options, and recovery behavior.
A 2026 edge deployment can retain local OPC UA access while distributing selected production data through MQTT. That avoids treating local application access and broker-based distribution as mutually exclusive requirements.
The important distinction is independence. A broker outage should not interrupt local data access unless the application deliberately depends on the broker. Conversely, a healthy MQTT connection does not prove that the underlying device data is current.
Software Toolbox is best for industrial teams evaluating OPC connectivity alongside DataOps requirements. The selection decision still belongs at the configuration level: a product category does not establish support for a particular protocol role or deployment topology.
Write down which component acquires device data, which component exposes it, and which component publishes it. Avoid a diagram that labels everything merely as a gateway; that hides the interfaces you must configure and secure.
Define the data handoff explicitly; running both protocols does not connect them automatically.
For a common coexistence pattern, acquire a device value once and make that value available to both interfaces. Avoid configuring unrelated acquisition paths for the same signal unless the application needs them. Independent reads can produce different observation times and additional device traffic.
For your 2026 architecture review, identify the authoritative source of each published field. Document whether a timestamp represents device acquisition, gateway processing, or publication; those events are not interchangeable.
Best for: deployments where one team owns acquisition, local access, and publication. An integrated runtime can keep the data mapping close to the acquisition configuration. Check the actual software documentation rather than assuming that a protocol checkbox includes every required function.
The trade-off is shared execution. A runtime restart, configuration fault, or resource problem can affect both OPC UA and MQTT paths. Integrated operation also does not remove the need for separate access controls on each interface.
Before accepting this arrangement, establish whether acquisition continues during a broker disconnect and whether the local server remains responsive during publication recovery. Treat those behaviors as acceptance tests, not implied capabilities.
Best for: deployments with different ownership or maintenance schedules for local access and MQTT publication. Separate services let you manage their configuration and restart procedures independently. They still need a defined interface: an MQTT publisher does not automatically discover and interpret an unrelated OPC UA server.
The trade-off is coordination. Service accounts, startup order, certificate trust, data mapping, and reconnect logic become part of the integration. Separate processes also continue to share the host operating system, storage, and network interface.
For a 2026 deployment, record the restart sequence and test it after a full host reboot. A configuration that works only after a manual service restart is not ready for unattended operation.
No universal tag-count or memory recommendation establishes whether an edge device will handle your application. The workload depends on what the configured software actually does.
Measure under representative conditions, including disruption. Idle resource usage does not establish capacity during reconnect or backlog recovery. The OPC UA plant-network bandwidth guide addresses the network side of that assessment.
OPC UA TCP commonly uses port 4840, MQTT commonly uses 1883, and MQTT over TLS commonly uses 8883. These are conventional port assignments, not proof of your installation's configuration or security posture. Confirm the actual listening endpoints and configured connection destinations.
Different ports prevent a simple listener collision, but they do not create network segmentation. A service listening on every interface can expose access beyond the intended application path. Bind listeners deliberately and restrict access with host and network controls.
For a 2026 firewall review, document source, destination, direction, transport, and business purpose for each permitted connection. If the MQTT publisher initiates a connection to a remote broker, do not add an inbound MQTT listener merely because MQTT appears in the architecture.
Keep OPC UA trust configuration separate from MQTT broker authentication and authorization. An authorized OPC UA client is not automatically an authorized MQTT publisher, and a valid broker connection does not grant permission to every topic.
Transporting a value is not the same as preserving its meaning. OPC UA provides structured information and data-access status; MQTT transports application messages. The publishing application must define what those messages mean to subscribers.
Specify the payload before connecting production consumers. Include the information consumers need to interpret the measurement, and establish how schema changes will be handled.
Identity
Time
Quality
Units
Freshness
Retained MQTT messages deserve particular attention. A retained message gives a new subscriber the broker's stored message for that topic; it does not independently prove that the underlying measurement remains current. Carry enough context for the receiving application to make that decision.
Yes. Local OPC UA consumers and an MQTT publication path can serve different network zones, subject to the approved firewall and broker architecture. Define where the publisher connects and where authorized subscribers receive data.
Do not make the edge host an uncontrolled bridge between networks. Use explicit routing, interface restrictions, and access rules; dual network interfaces alone do not establish a secure boundary.
No. An MQTT client needs an application-level mapping from OPC UA data to topics and payloads. Running the client beside the server supplies neither that mapping nor a shared information model.
Start with the measurements the receiving application requires. Publishing an entire namespace without a consumer requirement adds configuration and data-governance work without establishing a useful outcome.
Not inherently. Local OPC UA access can continue while a broker is unreachable, but the installed application's resource use and failure handling determine the actual result.
Test this condition directly. If queued publications exhaust shared resources or reconnect processing blocks acquisition, the protocols' independence does not protect the application.
Use your 2026 commissioning plan to prove the separation you designed. Define acceptable behavior for each consumer before testing, including freshness, interruption handling, and recovery order.
Do not equate MQTT delivery acknowledgments with successful business processing. Confirm that the receiving application interprets the payload correctly and handles duplicates or replay according to its requirements.
For product selection, Software Toolbox includes Cogent DataHub in its industrial connectivity and DataOps portfolio. Evaluate the exact release and configuration against this checklist; the portfolio listing alone does not establish protocol-role support, buffering behavior, or host compatibility.
Review your edge connectivity requirements
Discuss protocol roles, deployment boundaries, and integration requirements for your edge architecture.
Can OPC UA and MQTT run on the same edge device?
Yes, OPC UA and MQTT can run on the same edge device when the software supports the required roles and the host handles the workload. Configure the data handoff and test shared-resource failures.
Do I need to install an MQTT broker on the edge device?
No, an edge MQTT client can connect to a broker on another host. Broker placement should follow your network architecture, security boundaries, and operational requirements.
Do OPC UA and MQTT use the same network port?
No, their conventional ports differ: OPC UA TCP commonly uses 4840, MQTT uses 1883, and MQTT over TLS uses 8883. Verify your configured endpoints instead of assuming the defaults apply.
Does running both protocols double the load on my PLC?
No, running both protocols does not inherently double PLC acquisition traffic. A shared acquisition path can supply both outputs; independently configured readers create their own acquisition workload.
Is MQTT encryption enough to secure the edge device?
No, encrypted MQTT transport does not secure the OPC UA endpoint, host accounts, or operating system. Apply endpoint authentication, authorization, network restrictions, and host security separately.
Do I need Sparkplug to run OPC UA and MQTT together?
No, coexistence does not require Sparkplug. Select Sparkplug when its defined MQTT topic, payload, and state conventions match the receiving applications' requirements.
Can I assume every published MQTT value is current?
No, an available MQTT message does not establish measurement freshness. Define timestamps, source quality, and stale-data handling so subscribers can identify outdated information.
Test a frozen value, not only a broken connection. A connected source can legitimately report an unchanged measurement, while a disconnected acquisition path can leave an old value visible. Your consumers need quality and freshness rules to distinguish those conditions; connection status alone cannot do it.