Versa Messaging Service (VMS) is a Kubernetes-based, scalable message-streaming headend component that ingests real-time data – user identity events, threat feeds, device risk scores, endpoint posture – from external sources and distributes it to VOS devices and SASE gateways across a Versa deployment.
Key takeaways
- VMS streams real-time identity, threat, and risk data across Versa devices.
- Built on Kubernetes microservices, with northbound and southbound interfaces.
- Deploys standalone or HA, with ADC failover between primary and backup nodes.
- Configured entirely from Versa Director through a VMS connector, per tenant.
- Powers SASE for SIM, SCIM, UEBA, third-party auth, and threat intelligence.
On this page: Why it mattersHow it worksVMS deployment modelsVMS & the VersaONE platformFAQ
Why is VMS important?
Modern SASE and SD-WAN deployments depend on data that changes constantly – who just logged in, which IP address a device now has, what a threat feed flagged, how risky an endpoint currently looks. Config-template push, the model Versa Director uses for policy and device settings, is the wrong tool for that: it is deliberate and versioned, not built for continuous streams. VMS fills that gap as a dedicated real-time data plane, so security enforcement on VOS devices can react to identity and risk changes as they happen, not on the next configuration push.
VMS also matters because it centralizes integration work. Rather than every VOS device separately connecting to Active Directory, a RADIUS server, Panorama, or an EDR platform, VMS ingests from these external sources once, normalizes the data, and fans it out to the whole estate over an authenticated channel. That is what makes capabilities like clientless third-party authentication, device risk scoring, and live threat intelligence practical at fleet scale.
What is VMS?
VMS runs as a Kubernetes-based microservice cluster with two main interfaces. The northbound interface faces external sources – a WMI agent watching Active Directory, a RADIUS accounting server, a SCIM identity provider, Panorama, or a threat-feed source – and normalizes their data. The southbound interface is a gRPC channel that VOS branches and SASE gateways use to subscribe to and stream that data, and that also forwards logs and exceptions to Versa Analytics. An elastic (floating) IP address load-balances the northbound side across cluster nodes.
Administrators install VMS as a node (bare-metal, or a VM image for AWS, VMware, or KVM), then configure it in two places: locally via the vsh CLI, which stands up the Kubernetes control plane and certificates, and from Versa Director, where a VMS connector links the cluster to tenants and services.
VMS deployment models
VMS deploys in two shapes. Standalone is a single VMS cluster and control plane node – adequate for labs and smaller estates. High availability (HA) pairs a primary VMS cluster with a secondary one, often split across a primary data center and a disaster-recovery site; VOS devices reach the active node through an application delivery controller (ADC), which health-probes both clusters and redirects southbound gRPC sessions on failover.
Within either shape, VMS’s capabilities are modular: services such as SASE for SIM, SCIM, third-party authentication, UEBA, the VOS aggregator, XIP EIP (Panorama HIP-to-EIP conversion), threat intelligence, Kafka MirrorMaker, ASC, and device risk score (DRS) are each enabled independently, per tenant, from the VMS connector in Director.
VMS & the VersaONE platform
VMS is a headend component alongside Director, the Controller, Analytics, and Concerto, and it depends on each of them for a different function. Versa Director is where administrators create the VMS connector, onboard tenants, and turn services on or off. Versa Concerto handles user and group orchestration for VMS-backed services such as SASE for SIM and SCIM. The Controller carries the ADC and the southbound gRPC sessions that connect VOS devices to VMS, and Versa Analytics receives VMS’s start, stop, and exception logs for reporting and troubleshooting.
Enabling a service end to end – for example third-party authentication or SASE for SIM – touches all of these: a connector on Director, a messaging server profile on the VOS device, and often an ADC configuration for HA failover, as detailed in Versa’s HA-based VMS deployment guidance.
Frequently asked questions
What external data sources does VMS integrate with?
VMS ingests from Active Directory (through a WMI agent), RADIUS accounting servers, SCIM identity providers, Palo Alto Panorama, Kafka brokers, and threat-intelligence feeds. It normalizes each source’s data and republishes it to subscribed VOS devices and other Versa components.
How does VMS communicate with VOS devices?
VOS devices and SASE gateways establish a long-lived gRPC connection to VMS’s southbound interface and subscribe to one or more services. VMS pushes updates over that channel as the underlying data changes, rather than devices polling for it.
What is VMS’s role in third-party authentication?
VMS lets Secure SD-WAN CPE devices verify user identity without a captive portal. A WMI agent watching Active Directory notifies VMS of login and logoff events, and VMS distributes the resulting user-to-IP mapping to every subscribed VOS device.
How is VMS deployed for high availability?
An HA VMS deployment runs a primary and a secondary cluster, typically in separate data centers, each with its own control plane node and synchronized certificates. VOS devices connect through an ADC that health-probes both clusters and fails over the active session if the primary becomes unreachable.
Which services can be enabled through VMS?
Per tenant, Director’s VMS connector can enable SASE for SIM, SCIM, third-party authentication, UEBA, the VOS aggregator, XIP EIP, threat intelligence, Kafka MirrorMaker, ASC, and device risk score – each configured and toggled independently.
More on VMS
If you want to learn more, these are sources we trust.
| Versa Networks: platform | Versa Networks: secure SD-WAN | Versa Academy |
|---|---|---|
| The vendor’s product pages for the platform VMS’s real-time data services support. | How the SD-WAN and SASE services VMS feeds are packaged and delivered, from the vendor. | Versa’s training portal: courses and labs covering headend components including VMS. |
Related terms
If you’re reading about VMS, these are worth looking at next.
| Headend | SASE Gateway | Versa Director |
|---|---|---|
| The centralized management and control components VMS belongs to, alongside Director, Analytics, and Controller. | The gateway type that subscribes to VMS streams to enforce identity- and risk-aware security policy. | The console where administrators create the VMS connector and enable services per tenant. |