How Overlay Works

Secure BMS access, without making users operate the network.

Overlay gives BMS teams a controlled way to reach building resources without defaulting to broad, site-wide VPN access. Customers get a clearer access model. Engineers get a consistent workflow.

The result is easier governance across mixed estates, stronger auditability, and a rollout approach that fits how building portfolios actually operate.

Book a Demo See the access model

The Overlay model

A session-based access model for BMS estates.

The same operating model works across estates and vendors.

Policy checks (e.g. MFA) happen before access is opened.

Named users request a specific building resource.

Session activity is easy to attribute and review.

Access is convenient for users but secured to exacting enterprise standards.

How Access Works

Access begins with the user,
not the tunnel.

Overlay keeps the workflow straightforward for engineers while centering the access decision on identity, policy, and the requested resource.

User signs in

The engineer or operator authenticates as a named user instead of starting from a site VPN profile.

Policy is enforced

Overlay checks organisation requirements such as access scope and MFA before the session starts.

A specific target is chosen

The user requests the exact head-end, controller, or machine they need rather than broad site presence.

A session is brokered and recorded

Overlay opens the requested session and produces evidence that the action was initiated by that named user.

Example Deployments

The same connectivity model can fit very different BMS estates.

These examples are grounded in the capabilities described in the docs: connector-brokered sessions, support for existing VPN-style connectivity, and an Overlay-managed connectivity option where a suitable site path does not already exist.

Example 1

Teltonika RUT on site, forwarding to the BMS

Overlay keeps the model the same whether the site uses Overlay-managed connectivity or the operator's own network path.

Overlay-managed connectivity: the site router is configured to join an Overlay-managed WireGuard path, and Overlay brokers sessions to the defined building resources behind it.

Operator-managed connectivity: the BMS operator uses its own network path, and an Overlay connector links that operator network to the Overlay control plane so users still start from named-user, resource-based sessions.

Example 2

Head-end on a site PC

The same two connectivity options apply even when the head-end is on a local PC and no Teltonika router is required.

Overlay-managed connectivity: the site PC or gateway joins the Overlay-managed connectivity layer, giving Overlay a path to broker access to the hosted head-end.

Operator-managed connectivity: the operator uses its existing site networking approach, and the Overlay connector brokers named-user sessions through that established path.

Example 3

Head-end hosted in the BMS operator cloud

Overlay also fits hosted environments where the head-end already sits in the operator's cloud estate rather than on site.

An Overlay connector runs in the operator cloud and brokers access to the hosted head-end over the operator's VPN or private network path to Overlay.

The access workflow does not change: users sign in, policy is checked, they select the hosted resource, and the resulting session is attributable and auditable.

From broad tunnels to controlled sessions

Convenience for users, enterprise-level controls for IT teams.

This is the model behind Overlay's identity-based connectivity approach. A named user signs in, policy is checked, a specific resource is selected, a session is created for that request, and the connector brokers the path to the target.

The operational outcome is concise: access is attached to identity, scope, and session context instead of general network presence. That is what makes the model easier to govern across mixed BMS estates.

Control And Auditability

Built to give customers clearer control,
evidence, and consistency.

The objective is not to make every estate identical underneath. It is to make access control, session brokering, and auditability more consistent above that variation.

Named-user access

Access begins with an identified person, which reduces dependence on shared VPN or controller credentials.

Scoped to the requested resource

Users ask for the building system or device they need, rather than inheriting general site network reach.

Policy before connectivity

The access decision happens before the session is created, helping teams enforce MFA and role boundaries consistently.

Session-level evidence

A clearer record of who initiated access, in what context, and when.

Consistent workflow across mixed estates

The operator experience stays stable even when the underlying estate uses different site connectivity methods.

Connectivity included when needed

Where a site does not already have a suitable path, Overlay can provide the connectivity layer without changing the access model.

Deployment Fit

Designed for real BMS estates,
by former BMS industry pros.

Overlay is intended for portfolios where site connectivity, devices, and operational practices vary from customer to customer. The user workflow remains consistent even when the underlying estate does not.

Supports mixed estates with existing remote-access patterns already in place
Fits teams supporting head-ends, controllers, and engineering endpoints
Reduces the need for engineers to learn a different access process per customer
Focused on governance and operating consistency

See rollout approach →

Overlay compatibility view for mixed BMS estates

Managed Connectivity

Overlay can provide the connectivity layer when the site does not already have one.

Some customer estates already have a suitable path for secure access. Others do not. Overlay can extend the same session-based access model to those sites by providing the underlying connectivity layer as well.

Managed Wireguard VPN is easy to install on routers and site PCs
Keep one operating model across sites with and without existing connectivity
Avoids turning special-case sites into a different governance process

See rollout approach →

Overlay managed connectivity for customer estates

Rollout

Adopt the model in four practical steps.

Overlay uses a familiar rollout process: confirm the estate fit, connect the sites, onboard the right users, and move into governed day-to-day access.

Review the estate

Map the current mix of customers, site connectivity, and remote-access requirements with Overlay.

Connect what is already there

Use existing site connectivity where suitable, or layer in Overlay-managed connectivity where it is missing.

Define user access

Onboard engineers, operators, or contractors with the right access boundaries for the buildings they support.

Operate with evidence

Run day-to-day remote access through a model that is easier to review, explain, and scale.

Review The Model

See whether Overlay fits your security,
operations, and rollout requirements.

The key question is simple: can remote access become easier to govern without making the field workflow harder to operate? Overlay is designed to do exactly that.

Book a Demo See rollout steps

BMS-centric access model. Loved by IT teams.