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 rather than an afterthought layered on once a deployment is already live. This page separates what is running in the product today from what is designed and on the roadmap, because a security page that blurs the two is worse than no security page at all.
Shipping today: role-based access control, an attributed audit trail, encrypted credential storage, and mutually authenticated readers that fail closed. On the roadmap: the protocol integration layer and everything built on it, including per-protocol encryption and anomaly detection. Ask us for current status before writing any roadmap item into a specification or tender response.
Protocol-level security — the design, and where it actually stands
None of this section describes shipping functionality. Protocol integration is an unbuilt module: open the console today and the Protocol Integration page says “Not built yet”. What follows is the security model the field-bus layer is being designed to, published so that specifiers can evaluate the approach and tell us early if it will not satisfy their requirements — not so it can be quoted as a delivered capability.
The starting point is 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 are intended to keep controllers, sensors, and meters on a dedicated operational segment, with tightly scoped gateways where data needs to cross into IT or cloud systems. Segmentation is largely a property of how a site is designed and cabled, so this part is something we specify with your network team rather than something software can assert on its own.
For BACnet, the intended transport is 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, the intended mechanism is 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 of any kind, the intent is to wrap Modbus TCP and RTU traffic in an encrypted tunnel so meters, generators, and industrial equipment are not left as the weakest link in a mixed-protocol deployment. Note that this is a wrapper around an unauthenticated protocol, not a fix for it: anything already on the operational segment can still speak plain Modbus to those devices, which is why segmentation carries as much weight here as encryption does.
Access control & data security — running today
This is the part of the platform that is built and in use. Every xSERVA user operates under role-based access control, with roles assembled from a catalogue of individually granted permissions, so a user sees and acts on only the sites and functions their role permits. State-changing actions are written to an audit trail that records who did it, when, and from where — including remote door unlocks, which are logged before the door is asked to move rather than after it succeeds. Credentials and device secrets are encrypted at rest with authenticated encryption, and traffic runs over TLS. Beyond the transport, each reader holds its own key: it signs every request it makes to the platform, and every command the platform sends back — a remote unlock above all — is individually signed and verified by the reader before anything moves. A command whose signature does not verify is refused and recorded as a security event, because a bad signature on a door command is either a clock fault or an attack and both need to be visible. TLS is deliberately not treated as sufficient on its own here: it can authenticate a server to a device, but not an instruction.
PDPA alignment
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. We describe this as alignment with PDPA principles rather than as certified compliance, because compliance depends on how an organization configures, operates and retains data in a system, and no vendor can certify that on a customer’s behalf. For government and institutional deployments, the audit trail and access-event record are the evidence procurement teams usually ask for, and both can be exported.
AI-driven intrusion detection — on the roadmap, not in the product
There is no machine-learning or intrusion-detection component in xSERVA today. We are stating that plainly because it is the kind of capability that gets written into a tender requirement, and discovering at commissioning that it does not exist helps nobody.
The intent is that the same anomaly layer that flags equipment faults also watches network and protocol-level behavior for patterns that do not belong — unexpected device enumeration, traffic from an unrecognized source, or protocol commands outside normal operating patterns — giving security teams a signal grounded in the building’s actual behavior rather than a generic signature list built for IT networks. That work depends on the protocol integration layer landing first, since there is no protocol traffic to model until then.
What exists today is deterministic rather than statistical: a signature failure on a door command is recorded as a security event on the reader, every access decision is written to the event log with the reason it was granted or denied, and every operator action lands in the audit trail. Those are reviewed by people.
Security as an ongoing discipline, not a one-time checklist
Security in a building automation deployment does not end at commissioning. In the access-control product today, that shows up concretely: access rights are granted through pass types and roles rather than one at a time, so a person’s access can be withdrawn in one place instead of being hunted down door by door; a reader that loses its connection keeps enforcing the last policy it was given rather than falling back to letting anyone in; and configuration pushed from the platform is acknowledged by the reader, so the console can distinguish a change a device has actually taken from one still queued for a device that is offline. What a reader does once an outage runs past its grace period is a deliberate per-site choice rather than a hidden default, and the shipped default is to keep admitting known holders, on the view that a building which locks everyone out because a WAN link dropped is usually the worse failure. Egress is never affected either way: refusing to let somebody out of a building because the internet is down is a life-safety problem, not a security posture.
The same discipline is the design intent for the protocol layer — a new BACnet, KNX, MQTT, or Modbus device inheriting the deployment’s segmentation and encryption posture by default, rather than each addition being a fresh decision somebody has to remember. That layer is not built yet, so treat it as intent.
For procurement and compliance teams evaluating xSERVA against internal security requirements: we would rather have the conversation about what is built and what is planned before a specification is written than after. Ask us for the current status of any item on this page, and we will tell you which side of that line it is on.
Frequently asked questions
Does xSERVA secure each protocol differently?
That is the design, not a shipped capability today. BACnet, KNX, and Modbus each have different native security capabilities, and the protocol integration layer is being built to apply the strongest available mechanism to each — BACnet/SC, KNX Secure, and an encrypted tunnel for Modbus, which has none of its own — rather than a one-size-fits-all wrapper. Protocol integration is on the roadmap and is not available yet, so ask us for the current status before writing any of it into a specification.
How is user access controlled in xSERVA?
Access is role-based and this is live today. Roles are built from a catalogue of individually granted permissions, users see and act on only the sites and functions their role permits, and state-changing actions are written to an audit trail that records who did what, when, and from where.
Is xSERVA compliant with PDPA?
xSERVA is designed around data minimization, role-based access control, and encrypted storage and transport, which are the practical controls Malaysia's Personal Data Protection Act (PDPA) expects. Compliance is a property of how an organization deploys and operates a system, not something a vendor can certify on its own, so we describe this as alignment with PDPA principles rather than as certified compliance.
How does AI intrusion detection fit into xSERVA security?
It does not yet. Anomaly detection over network and protocol behavior is a roadmap item, and no machine-learning or intrusion-detection component ships in the platform today. What exists now is the audit trail and the access-event record, which are reviewed by people rather than scored by a model.