Building automation security, taken as seriously as IT security

Operational technology has different threats and different weaknesses than a corporate network. xSERVA treats OT/IoT security as a first-class requirement of the platform — segmented at the network level, encrypted at the protocol level, and governed at the access level — rather than an afterthought layered on once a deployment is already live.

Book a Demo

OT/IoT cybersecurity, protocol by protocol

Every protocol xSERVA speaks has its own security model, and treating them all the same would leave gaps. xSERVA starts with network segmentation, isolating BAS/BMS traffic from general IT networks so a compromise on one side does not automatically expose the other. Field-level VLANs and firewall rules keep controllers, sensors, and meters on a dedicated operational segment, with tightly scoped gateways where data needs to cross into IT or cloud systems.

For BACnet, xSERVA supports BACnet Secure Connect (BACnet/SC), the protocol’s native secure transport standard, which encrypts BACnet traffic over TLS and authenticates devices before they join the network — closing the plaintext exposure that legacy BACnet/IP deployments carry.

For KNX, xSERVA supports KNX Secure, which encrypts and authenticates KNX telegrams at the bus level, protecting room-level automation and access-adjacent functions like lighting and blinds from tampering or eavesdropping on the same bus that legacy unencrypted KNX installations leave exposed.

For Modbus, a protocol with no native encryption, xSERVA applies encrypted Modbus tunneling — wrapping Modbus TCP and RTU traffic in an encrypted transport layer so meters, generators, and industrial equipment gain the same confidentiality and integrity protection as BACnet/SC and KNX Secure provide natively, rather than being left as the weakest link in a mixed-protocol deployment.

Access control & data security

Every xSERVA user operates under role-based access control, seeing and acting on only the sites, zones, and functions their role permits. Actions are logged with a full audit trail, so any change to a schedule, override, or configuration is attributable and reviewable after the fact. Data at rest is encrypted, and every connection between field devices, the core engine, and user-facing dashboards runs over encrypted transport.

PDPA & standards compliance

xSERVA is built around data minimization, encrypted storage and transport, and role-based access — the practical controls that Malaysia’s Personal Data Protection Act (PDPA) expects for any system handling operational and access-related data. For government and institutional deployments, the same controls support the audit and compliance evidence procurement teams typically require.

AI-driven intrusion detection

The same machine learning layer that flags equipment anomalies also watches network and protocol-level behavior for patterns that don’t belong — unexpected device enumeration, traffic from an unrecognized source, or protocol commands outside normal operating patterns. That gives security teams an early signal grounded in the building’s actual behavior, not a generic signature list built for IT networks.

See how the AI/IoT layer works →

Security as an ongoing discipline, not a one-time checklist

Security in a building automation deployment does not end at commissioning. xSERVA is designed to keep protocol-level protections, access policies, and anomaly detection current as a building changes — new devices added, new tenants onboarded, new integrations connected. Every new BACnet, KNX, MQTT, or Modbus device inherits the same segmentation and encryption posture as the rest of the deployment by default, so security does not quietly erode as a site grows or turns over operations staff.

For procurement and compliance teams evaluating xSERVA against internal security requirements, this protocol-by-protocol approach — BACnet/SC, KNX Secure, and encrypted Modbus tunneling each addressed on its own terms — is documented and available to review as part of the demo and evaluation process.

Frequently asked questions

Does xSERVA secure each protocol differently?

Yes. BACnet, KNX, and Modbus each have different native security capabilities, so xSERVA applies the strongest available mechanism to each — BACnet/SC, KNX Secure, and encrypted Modbus tunneling — rather than a one-size-fits-all wrapper.

How is user access controlled in xSERVA?

Access is role-based, so users see and control only the sites, zones, and functions their role permits, with every action logged for audit purposes.

Is xSERVA compliant with PDPA?

xSERVA is designed with data minimization, access control, and encrypted storage and transport in line with Malaysia's Personal Data Protection Act (PDPA) principles for the operational data it handles.

How does AI intrusion detection fit into xSERVA security?

The same AI/ML layer that detects equipment anomalies also flags anomalous network and protocol behavior, giving security teams an early signal for potential intrusion attempts, not just equipment faults.

See the full FAQ →

Talk through your site’s security requirements

Book a Demo with Patrick