Skip to content
HiveMQ Release

What's New in HiveMQ 4.56?

by HiveMQ TeamSEP 29, 2026

The HiveMQ team is excited to announce the release of HiveMQ Enterprise MQTT Broker 4.56. This release introduces a new MQTT Add-on that lets you track client connection and disconnection events with standard MQTT subscriptions. HiveMQ 4.56 also adds PEM certificate support for broker TLS configuration, updates to the HiveMQ Enterprise Security Extension, Bridge Extension, and Control Center, along with new metrics and fixes.

Highlights

  • New Client Lifecycle Topic MQTT Add-on that tracks client connections and disconnections with standard MQTT subscriptions.
  • Native PEM certificate support for broker TLS configuration, with no keytool conversion required.

Client Lifecycle Topic MQTT Add-on

HiveMQ 4.56 introduces the Client Lifecycle Topic MQTT Add-on. This add-on helps you react when clients connect to or disconnect from the HiveMQ broker. The add-on publishes each client lifecycle event as an MQTT PUBLISH message. The message payload contains details about the event and the client.

The Client Lifecycle Topic MQTT Add-on lets you track the details of client connections and disconnections in an MQTT-native way. To receive event notifications, you simply subscribe to topics that start with $client-events.

The add-on gives you a new way to monitor client connection state in the HiveMQ broker. You can also query the connection state with the HiveMQ Control Center and the HiveMQ REST API.

How it works

To use the Client Lifecycle Topic add-on to track client connection events, enable the add-on in the config.xml of your broker:

<mqtt-addons>
<client-lifecycle-topic>
<enabled>true</enabled>
</client-lifecycle-topic>
</mqtt-addons>

If needed, you can filter out specific lifecycle notifications.

When the add-on is enabled, the broker sends a QoS 1 MQTT PUBLISH message for every client connection and disconnection. The JSON payload contains the type of the lifecycle event (CONNECTED or DISCONNECTED) together with basic information about the client.

The add-on publishes one notification for each connect or disconnect event. The notification topic starts with $client-events/all, followed by an identifier for the client. By default, the add-on uses the client ID. For example, $client-events/all/client-id/<SPECIFIC_CLIENT_ID>. You can configure the add-on to use the username from the CONNECT packet instead.

To receive the notifications, subscribe to the $client-events add-on topic:

  • Notifications for a specific client — Subscribe to a specific client ID, for example, $client-events/all/client-id/test-client.
  • Notifications for all clients — Subscribe with a wildcard, for example, $client-events/all/client-id/#. Then filter the events by inspecting payload fields such as Event type or Client ID.

The following example shows a client connect event:

{
  "Event type": "CONNECTED",
  "Timestamp": 1790335682186,
  "Client IP address": "127.0.0.1",
  "Client ID": "hmq_aTdtB_1_3b7f8484310340b889fb0dbe5ef88839",
  "Was client ID broker-assigned?": true,
  "Node IP address": "127.0.0.1",
  "Listener port": 1883,
  "Is secure connection?": false,
  "MQTT protocol version": "MQTTv5"
}

An example of a client disconnect event:

{
  "Event type": "DISCONNECTED",
  "Disconnect initiator": "CLIENT",
  "Disconnect reason code": 0,
  "Timestamp": 1790335702305,
  "Time elapsed since connect": 20119,
  "Client IP address": "127.0.0.1",
  "Client ID": "hmq_aTdtB_1_3b7f8484310340b889fb0dbe5ef88839",
  "Was client ID broker-assigned?": true,
  "Node IP address": "127.0.0.1",
  "Listener port": 1883,
  "Is secure connection?": false,
  "MQTT protocol version": "MQTTv5"
}

Notifications for secure connections contain additional TLS-related information. For detailed field descriptions, examples, and configuration information, see the documentation.

How it helps

The new Client Lifecycle Topic MQTT Add-on offers a unified, MQTT-native API to provide connect and disconnect events for clients. It also provides additional context to diagnose what caused a change in client state, including the reason code of a client disconnection.

PEM Certificate Support for TLS

HiveMQ 4.56 adds the ability to load TLS certificates and private keys directly from PEM files for the HiveMQ broker, Control Center, REST API, and HiveMQ Enterprise Bridge Extension. Previously, the broker read certificates only from a Java keystore, so you had to convert every PEM certificate with keytool before HiveMQ could use it.

How it works

Instead of a keystore file, you now reference the certificate and key files directly in the config.xml file of your broker:

<keystore>
<key-path>/path/to/certificates/server.key</key-path>
<cert-path>/path/to/certificates/server.crt</cert-path>
<ca-path>/path/to/certificates/server.ca</ca-path>
</keystore>

The CA path is optional. You can provide the certificate and the key as separate files or as one combined PEM bundle:

<keystore>
<key-path>/path/to/certificates/bundle.pem</key-path>
<cert-path>/path/to/certificates/bundle.pem</cert-path>
</keystore>

Hot reload works the same way as before for all PEM certificates except intracluster TLS certificates.

Note: You can use PEM certificates for TLS on MQTT listeners, the Control Center, the REST API, intracluster communication, and the HiveMQ Enterprise Bridge Extension. Hot reload is not available for intracluster TLS. PEM support does not include mutual TLS with client certificates. For mutual TLS with client certificates, continue to use a truststore.

How it helps

In Kubernetes environments, tools such as cert-manager issue certificates as PEM secrets. Without native PEM support, every certificate rotation requires a conversion step on every broker instance. This step is difficult to automate and can cause errors, such as an incorrect keystore password or an outdated file path.

HiveMQ now reads PEM files directly, so the conversion step is no longer necessary. Your brokers use the certificate files that your platform already manages. This makes short rotation cycles easier to automate across many brokers.

For the full configuration reference, see Secure TCP Transport with TLS, Bridge Extension Configuration Options, Secure TCP Listener, Control Center HTTPS Listener Configuration, and HiveMQ REST API Configuration.

More Noteworthy Features and Improvements

HiveMQ Enterprise MQTT Broker

  • Added com.hivemq.jvm.netty.* metrics to monitor the direct and heap memory that the Netty networking layer uses, which helps enforce hard memory limits in containerized deployments.
  • Fixed a rare issue in which HiveMQ did not correctly return message IDs for clients whose queues contained in-flight messages.
  • Fixed an issue in which some messages from a shared subscription were incorrectly returned to the queue when HiveMQ polled messages with mixed QoS levels for delivery.
  • Fixed an issue where a diagnostic archive was reported as complete before the final ZIP file was merged, which could lead to failed or corrupted downloads.
  • Added metrics to track message units, network traffic, and connections per MQTT listener:
    • com.hivemq.messages.incoming.message-units.count.<sanitizedListenerName>
    • com.hivemq.messages.outgoing.message-units.count.<sanitizedListenerName>
    • com.hivemq.networking.bytes.read.count.<sanitizedListenerName>
    • com.hivemq.networking.bytes.write.count.<sanitizedListenerName>
    • com.hivemq.networking.connections.<sanitizedListenerName>

HiveMQ Control Center

  • Updated the search functionality on all Data Hub pages to match the standard search behavior in the HiveMQ Control Center.
  • Improved the Dropped Messages Detail view to display up to 1000 entries per node for the last 72 hours.
  • Improved the Login attempt failed audit log event by removing the unknown username reason, which also appeared when the password was wrong.
  • Fixed an issue in the Data Hub views that displayed blank pages and left some script and module actions available when scripting was disabled.

HiveMQ Enterprise Security Extension

  • Improved the warning for failed database connections of SQL realms to show the underlying errors directly in the warning message.
  • Fixed token introspection requests being rejected by strict proxies by sending only the minimum headers required by the specification.
  • Added support for PostgreSQL versions 15 through 18 and aligned future certification with the PostgreSQL community support lifecycle.

HiveMQ Enterprise Bridge Extension

  • Fixed an issue where bridge clients could keep reconnecting and forwarding messages after the extension was stopped, and could leave a subscribed session on the remote broker.

HiveMQ Enterprise Extension for MongoDB

  • Updated the recommended MongoDB instance version to 7.0 or higher.
  • Fixed an issue in which an uncaught exception stopped the extension from consuming messages when all messages in a batch had parsing errors.

Get Started Today

To upgrade HiveMQ from a previous version, follow the steps in the HiveMQ Upgrade Guide and review the Known Issues.

To learn more about all the features the HiveMQ Platform offers, explore the HiveMQ User Guide.

Get HiveMQ 4.56 now