Buildings used to be just bricks and mortar, but not any more. Modern facilities run on layers of interconnected hardware, such as HVAC controllers, lighting nodes, energy meters, access control panels, and cloud gateways that tie it all together. That connectivity is exactly what makes smart buildings valuable. It is also what makes them a target.
For OEMs developing BAC products, this means a security incident in the field is no longer an IT problem. It can look like lost uptime for customers, a safety risk to occupants, a hit to brand trust, and a long, expensive tail of patching and support. Regulators have noticed, and so have buyers. Procurement teams, specifiers, and systems integrators now treat security posture as a selection criterion rather than a nice-to-have.
So security has become a differentiator. The OEMs that can demonstrate secure design, a clean software bill of materials, and a credible update strategy will win specifications that less prepared competitors lose. The good news is that this is a solvable engineering and supply chain problem, provided it is addressed early.
What is at risk in modern BAS
In a building automation system, a cyber breach can move from the network into the physical world. Risks include loss of safety and life-safety functions, operational disruption to heating, cooling, and access control, theft of occupancy and usage data, breach of privacy and compliance obligations, and lasting reputational damage.
The consequences are financial, regulatory, and physical all at the same time.
Common vulnerabilities in BAC devices and networks
Most weaknesses are predictable, which means they are preventable. The recurring cybersecurity problems across BAC products and networks are:
- Legacy protocols with no native security. BACnet/IP and Modbus/TCP were designed for openness, not protection. Migration to BACnet/SC, which adds encrypted and authenticated transport, closes a large gap that has existed for decades.
- Weak authentication and default credentials. Shipping a device with a shared default password, or no enforced password policy, is one of the most exploited flaws in connected products.
- Insecure firmware and boot. Without verified boot and signed firmware, an attacker can run modified code that the device trusts completely.
- Poor key management. Hard-coded or shared keys undermine every other control. Keys need to be unique per device and properly protected.
- Insecure remote access. Maintenance backdoors, exposed management ports, and flat VPNs are common entry points.
- Unmanaged third-party libraries. Open-source and commercial components carry their own vulnerabilities, and you cannot patch what you have not catalogued.
- SBOM gaps. Without a software bill of materials, OEMs cannot answer the basic question that regulators and buyers now ask: “What is actually inside this product?”
- Physical port exposure. Unprotected debug, USB, and serial interfaces give physical attackers an easy foothold.
- Inadequate segmentation. When the building network is flat, one compromised sensor can reach the controllers that matter.
Global standards and regulations OEMs should know
Standards give OEMs a defensible baseline, and an increasing number are becoming mandatory rather than voluntary. The frameworks worth knowing are:
1. ISA/IEC 62443
The core standard for industrial and operational technology security, ISA/IEC 62443, specifically parts 4-1 and 4-2, is most relevant to product makers, covering the secure development lifecycle and the technical security requirements for components.
2. ISO/IEC 27001
The information security management standard that governs how an organisation protects data, intellectual property, and processes, ISO 27001 is a strong signal of supply chain maturity.
3. UL 2900 and ETSI EN 303 645
Both UL 2900 and ETSI EN 303 645 set testable security requirements for connected and consumer IoT products.
4. NIST guidance
The National Institute of Standards and Technology provides a practical, widely referenced baseline, including the NIST Cybersecurity Framework and NISTIR 8259 for IoT device manufacturers.
5. SBOM guidance
Originally driven by NTIA work in the United States, SBOM is now embedded in regulations, making component transparency a baseline expectation.
6. The EU Cyber Resilience Act (CRA)
This is the one to plan around now. The EU Cyber Resilience Act applies to nearly every product with digital elements sold in the EU, including products made outside the EU.
Vulnerability and severe incident reporting obligations begin in September 2026, and full requirements, including secure-by-design, conformity assessment, CE marking, and SBOMs, apply from December 2027.
7. The UK PSTI regime
The PSTI regime is a useful regional example of the direction of travel. In force since April 2024, it sets minimum security requirements, including a ban on universal default passwords, for consumer connectable products sold in the UK.
The common thread across all these and other standards is that, whatever the region, the expectation is now for secure-by-design, transparent components and a credible plan to manage vulnerabilities throughout the product's life.
Secure by design for OEMs across the product lifecycle
Security that is added late is expensive and brittle. Designed in from the start, it becomes a strong product differentiator.
On the architecture side, the building blocks are well established: a hardware root of trust or secure element to anchor device identity, secure and verified boot, signed firmware and code signing, encrypted storage and communications, least-privilege and zero-trust principles applied to every interface, secure over-the-air updates so devices can be patched throughout their support period, and secure logging and telemetry so incidents can be detected and investigated.
The process side matters just as much. Threat modelling at the design stage surfaces risks while they are still cheap to fix. Secure coding standards, an accurate SBOM paired with VEX advisories, a managed vulnerability process backed by a PSIRT, coordinated disclosure, and independent penetration testing all turn good intentions into evidence. That evidence is what compliance documentation and the buyers who read it will demand.
How an EMS partner like ESCATEC reduces building automation cybersecurity risk
Secure products are not designed in isolation. They are sourced, built, provisioned, and supported, and each of those stages is a place where security is either protected or lost. This is where the right electronics manufacturing services partner can instil confidence and ease the pressure points OEMs feel:
- Secure, traceable sourcing. Counterfeit and tampered components are a real supply chain threat. ESCATEC's component traceability and strong supplier relationships reduce the risk of unverified parts reaching the line and support the bill-of-materials transparency that the CRA now requires.
- Information security you can audit. ESCATEC is certified to ISO/IEC 27001:2022, the international standard for information security management. For OEMs, that means designs, firmware, keys, and intellectual property are handled inside an audited, certified framework rather than on trust alone.
- Secure provisioning and device identity. Unique credentials and keys need to be injected in a controlled production environment, not improvised. An EMS partner can build provisioning and key injection into the manufacturing flow so every unit ships with a strong, unique identity.
- Trusted, controlled production. Working to ISO 9001, ISO 13485, IATF 16949, and IPC-A-610 class 2 and class 3 standards, ESCATEC brings the process discipline, change control, and documentation that regulated and safety-critical BAC products demand.
- Lifecycle support. Security does not end at shipment. From design for manufacture through to aftermarket support and end-of-life, a long-term partner like ESCATEC helps OEMs sustain updates, repairs, and secure decommissioning across the product's life.
Our global, multi-site footprint across Malaysia and Europe also gives OEMs a choice of where products are built, supporting near-shoring, co-shoring, and off-shoring strategies without compromising on control.
Practical checklist for ensuring building automation cybersecurity
Some practical steps your team can act on now:
- Run threat modelling at the concept stage, before the architecture is fixed.
- Specify a hardware root of trust or secure element for device identity.
- Enforce secure boot and signed firmware on every device.
- Eliminate default and shared passwords. Require unique credentials per unit.
- Plan secure over-the-air updates and commit to a defined support period.
- Migrate from legacy BACnet/IP and Modbus/TCP towards BACnet/SC where you can.
- Generate and maintain a machine-readable SBOM, and keep it current.
- Track third-party and open-source components for known vulnerabilities.
- Set up a vulnerability-handling and disclosure process with a PSIRT.
- Protect physical interfaces by disabling or locking down debug and USB ports.
- Design for network segmentation rather than assuming a flat building network.
- Map your products to ISA/IEC 62443 and prepare for CRA obligations early.
Conclusion
Building automation cybersecurity has moved from a technical detail to a commercial decision. It affects which specifications you win, how you meet the CRA and similar rules, and what your products cost to support over their lifetime.
The OEMs that treat it as a design principle, rather than a late patch, will build products that buyers trust and regulators accept. Doing that well requires secure design, transparent components, and a manufacturing partner that can demonstrate the chain of custody from sourcing to shipment.
Ready to build security in from the first design review? Download our guide to smart BAC partnerships, or speak with our engineering team now.
FAQs
1. How does ISA/IEC 62443 apply to building automation products?
ISA/IEC 62443 is the leading standard for securing industrial and operational technology, and BAC products sit squarely within its scope. For OEMs, the two most relevant parts are 4-1, which defines a secure product development lifecycle, and 4-2, which sets technical security requirements for the components themselves. Aligning to 62443 gives you a structured, internationally recognised way to design, document, and demonstrate security. It also makes conversations with integrators and asset owners far easier, because many of them already use the same framework to evaluate the products they specify and install.
2. What is BACnet/SC and why should we migrate to it?
BACnet/SC, or BACnet Secure Connect, is a secure data link layer for BACnet that adds encrypted, authenticated, TLS-based communication. Traditional BACnet/IP was designed for openness and has no native security, which leaves traffic readable and devices easy to spoof on a shared network. BACnet/SC also works more cleanly across modern IT networks and firewalls, which removes some of the awkward workarounds integrators rely on today. Migrating protects building data and control traffic, and signals to specifiers that your product is built for current network security expectations rather than legacy assumptions.
3. What should an SBOM include for a BAS device?
A software bill of materials should list every software component in the product, including firmware, operating system elements, and third-party and open-source libraries, with names, versions, suppliers, and dependency relationships. It needs to be machine-readable, in a common format such as SPDX or CycloneDX, and kept current as the software changes. Paired with VEX advisories, which state whether a known vulnerability actually affects your product, an SBOM lets you respond quickly when new issues emerge. Under the EU Cyber Resilience Act, this transparency is becoming a baseline expectation rather than an optional extra.
4. How can an EMS partner help with security and compliance?
A strong EMS partner protects security across stages that OEMs do not always control directly, such as component sourcing, production, and provisioning. That means traceable, authenticated component sourcing, secure key injection and device identity on the line, and production handled within an audited information security framework. The partner should also provide documentation, traceability, and change-control records that conformity assessments and customers increasingly demand, thereby shortening OEMs’ path to compliance.
