Solace Message VPN and Security: Tenants, Access Control and IT/OT Zones

A Solace Message VPN is a virtual broker inside a Solace Event Broker: its own topic space, its own client usernames, its own queues and its own security settings. Solace describes Message VPNs as the mechanism that lets “many separate applications to share a single” broker “while still remaining independent and separated”. Despite the name, it has nothing to do with a network VPN. This page explains what a Message VPN isolates, how Solace authenticates and authorises clients, and, most importantly for a plant, how to place brokers, VPNs and bridges across IT and OT zones so that an event mesh does not quietly become a flat network.

It belongs to the event mesh overview in the Solace cluster.

What a Solace Message VPN isolates

According to Solace’s documentation, each Message VPN is a “fully separate messaging domain”. Messages published in one VPN are only visible to clients of that VPN, and each client connection belongs to exactly one VPN. A great deal of configuration hangs off the VPN:

Scoped per Message VPN	What it means in practice
Topic space	site/a/oee in one VPN and site/a/oee in another are unrelated
Client usernames and authentication	Each VPN chooses its schemes: basic, certificate, Kerberos or OAuth
ACL profiles and client profiles	Who may connect, publish and subscribe, and with what limits
Queues and spool quota	One tenant cannot fill another tenant’s disk
Replay log	Solace keeps the replay log per VPN
DR replication	Replication to a standby site is configured per VPN
Bridges	A Message VPN bridge links one VPN to another, on the same or another broker

How many you get depends on the edition. On the self-managed software broker, Solace’s edition table lists one user Message VPN on the free Standard Edition and five on Enterprise, as of October 2026. Every broker also has a VPN called default that cannot be deleted; it is enabled on software brokers and disabled on appliances. Disable it on a production software broker unless you mean to use it. See Standard vs Enterprise for the other edition limits.

Solace message VPN authentication and authorisation

Authentication is set per VPN. Solace’s authentication overview lists four schemes:

1. Basic authentication, against the broker’s internal database, LDAP or RADIUS, or LDAP after internal. Broker release 10.26.0 calls the last one a “hybrid client identity chain”.
2. Client certificate authentication, with X.509v3 certificates (mutual TLS).
3. Kerberos.
4. OAuth 2.0 and OpenID Connect, with JWT or opaque tokens.

Several schemes can be enabled on one VPN, but each client uses one. There is also a “None” option; Solace states it “strongly recommends against” it. In a plant we would add: an anonymous broker is how test configurations reach production.

Authorisation uses profiles. An ACL profile controls whether a client may connect and which topics it may publish and subscribe to. A client profile sets what a client is allowed to do and how much it may consume, such as connections and queues. Authorisation groups map LDAP or OAuth groups onto those profiles, so access follows the directory rather than a list of broker usernames. These are standard Solace constructs; read the current docs for the exact settings before designing around them.

Topic design is security design. ACLs are written as topic patterns, so a hierarchy with a site and area level lets you write “this MES client may publish site/a/> and nothing else”. A flat or inconsistent hierarchy makes least-privilege ACLs impossible. See topics and wildcards.

Encryption and the management plane. Solace states that TLS is available for all protocols. Release 10.26.0 lets administrators disable basic authentication for SEMP (the management API) and Broker Manager, which closes a common gap: strong client authentication with a password-protected admin interface beside it. Solace Cloud adds encryption at rest through cloud KMS and, per Solace, holds SOC 2 Type 2 and ISO/IEC 27001:2022. Solace does not claim FedRAMP.

Message VPNs, the Purdue model and IT/OT zones

This is the section that matters most for a plant. The Purdue model and ISA/IEC 62443 both separate a plant into zones (control, site operations, a DMZ, the enterprise) and allow traffic between zones only through defined conduits. An event broker is, by its nature, a conduit: it accepts connections from many places and forwards data between them. Placed carelessly, a single broker reachable from the enterprise and from the control network bridges the two zones with no firewall rule written for it.

A Message VPN does not fix that. Two VPNs on one broker are separated logically, but they share the broker’s hardware, its network interfaces, its operating system and its administrators. If one broker has an interface in the OT zone and another in the enterprise zone, the firewall is no longer the boundary; the broker is. That may be acceptable after a risk assessment, but it should be a decision, not an accident.

A pattern that respects the zones:

1. A plant broker in level 3, inside the site operations zone, serving MES, SCADA and the plant’s unified namespace. VPNs separate tenants, such as line systems and quality.
2. A DMZ broker in level 3.5, the only broker reachable from both sides of the plant firewall. Solace’s own June 2026 article describes an edge broker as “the controlled meeting point” between OT and IT, at what Purdue practitioners call level 3.5.
3. A Message VPN bridge from the plant broker to the DMZ broker. A bridge delivers only the topics configured on it, and Guaranteed messages need a bridge queue on the remote VPN. Solace documents that a bi-directional bridge runs over a single TCP connection, with TLS on port 55443 by default. Configure the bridge on the plant side so the connection is initiated outward, which is the firewall rule plant networks usually accept.
4. A link from the DMZ broker to the enterprise, either another bridge or a DMR external link if the enterprise side should see subscriptions dynamically.
5. Nothing from levels 0 to 2 connects to the mesh directly. PLCs and HMIs reach it through SCADA or an edge gateway in level 3.

Zone	Broker role	Typical VPNs	How traffic leaves the zone
Levels 0 to 2	None	n/a	Through SCADA or an edge gateway in level 3
Level 3, site operations	Plant broker or plant UNS	Per line, per function	Bridge to the DMZ, fixed topic list, initiated outward
Level 3.5, DMZ	Boundary broker	Per plant	Bridge or DMR link to the enterprise
Level 4 and cloud	Enterprise mesh	Per business domain	DMR across sites and clouds

Why a bridge at the plant boundary rather than DMR? DMR propagates subscriptions automatically, which is its strength inside the enterprise. At the OT boundary, automatic is the problem: a new subscriber in the cloud can change what leaves the plant without anyone at the plant agreeing. A bridge with a fixed topic list makes every new outbound stream a change request. ACLs on the plant broker can enforce the same limits if you use DMR, but they must be maintained with the same discipline.

Our brownfield OT segmentation guide covers how to get a plant that was never designed for zones into this shape, and the OT networks page covers the network layer underneath.

Where it gets hard

• Plants that are flat today. You cannot place a broker in a DMZ that does not exist. Segmentation usually comes first, and it is the larger project. An OT network assessment tells you how far the plant is from a zone model.
• One broker, two interfaces. Under budget pressure it is tempting to give the plant broker an enterprise interface “temporarily”. Record it as a risk acceptance with an end date, or do not do it.
• The default VPN and anonymous access. A software broker ships with the default VPN enabled. Disable it, or lock it down, before go-live.
• Edition limits. Five user VPNs per Enterprise software broker, one on Standard, as of October 2026. A design with a VPN per line can hit that quickly; tenants per broker may need to be per function instead.
• Certificates at scale. Mutual TLS across twenty plants means certificate issuance, rotation and revocation for every client and every link. Decide who runs that before the first plant goes live.
• Wildcard ACLs. An ACL that allows subscription to > makes the rest of the ACL design irrelevant. Review every broad pattern.
• Admin access across zones. SEMP, the CLI and Broker Manager reach every VPN on a broker. Restrict management interfaces to the management network and disable basic authentication where 10.26.0 allows it.

For how the mesh carries these events across sites and clouds, see hybrid and multi-cloud. For the plant-level design, see multi-site edge to cloud.