Public Sector Is Rewriting the Rules on Open, Multi-Vendor Smart Buildings

Public-sector building owners are increasingly transitioning from proprietary building management systems (BMS) to open, certified, multi-vendor architectures. Procurement regulations in Europe, North America, and Asia now commonly require open standards such as BACnet and Thread, device-level interoperability testing, and cybersecurity baselines like BACnet/SC and IEC 62443.

This article examines how regulation, procurement guidance, and certification programs are converging into a de facto multi-vendor connectivity framework for smart buildings, and the implications for specifiers, system integrators, and facilities teams tasked with managing complex, legacy BMS estates.

Regulatory Pressure: Open, Smart, and Interoperable by Design

Public-sector demand for interoperable smart buildings increasingly results from regulation, not just operational preference.

Energy and Automation Mandates

The recast EU Energy Performance of Buildings Directive (EPBD) mandates building automation and control systems in non-residential buildings with HVAC capacities above 290 kW by the end of 2024. A lower 70 kW threshold will be phased in later in the decade.

National policies reflect this shift:

• Germany's Building Energy Act (GEG 2024) requires large new non-residential buildings with heating/AC output above 290 kW to achieve automation level B and to guarantee cross-system and cross-manufacturer communication between technical building systems.
• EPBD transposition guidance directly ties compliance to automation and energy monitoring, making building automation and control systems (BACS) a prerequisite for operating large public buildings.

Operationally, facilities must implement automation that coordinates HVAC, lighting, and other subsystems across vendors to optimize energy and comfort.

Smart Readiness and Interoperability

The EU Smart Readiness Indicator (SRI) introduces further requirements. The SRI framework, defined through Commission Delegated Regulation (EU) 2020/2155, assesses a building's capability to use smart technologies, explicitly highlighting interoperability and open standards as prerequisites for smart-ready services.

As member states pilot SRI schemes in public portfolios, typical high-scoring criteria include:

• Cross-vendor data sharing among HVAC, lighting, blinds, and on-site generation
• IP-based communications supporting standardized analytics and fault detection
• Integration capability for third-party demand-response and grid-interaction services

Closed, proprietary protocols make these requirements difficult to meet, favoring open, certified ecosystems that reliably connect devices from multiple manufacturers.

Interoperable Public-Sector IT as a Policy Goal

Beyond buildings, the Interoperable Europe Act, effective since April 2024, establishes interoperability as a foundational principle for EU public-sector digital services and explicitly promotes open standards and open-source solutions across administrations.

Although the Act is technology-agnostic at field level, it reinforces procurement trends: public authorities are expected to avoid lock-in, prefer open specifications, and justify any use of non-interoperable solutions. Smart building platforms, now closely linked to IT and data governance, are subject to similar oversight.

From Proprietary BMS to Certified, Multi-Vendor Architectures

While open protocols have a long history in building automation, public organizations increasingly require documented evidence of interoperability and security.

BACnet, BTL, and AMEV: The Backbone for Public Buildings

BACnet is now the predominant integration layer for commercial and public buildings. BACnet holds over 60% of the global building automation protocol market, and more than 1,300 products have achieved formal BACnet Testing Laboratories (BTL) certification.

BTL certification establishes a shared interoperability baseline by verifying:

• Compliance with ASHRAE 135 and 135.1 test standards
• Support for defined device profiles and BACnet Interoperability Building Blocks (BIBBs)
• Public listings that specifiers use to pre-qualify products

Germany's AMEV guidelines adapt this into a framework specific to the public sector. The AMEV "BACnet in public buildings" recommendation (BACnet 2017) specifies requirements for BACnet systems in public projects and introduces AMEV and BIOP attestations, which are issued only for devices both BTL-certified and compliant with AMEV BACnet profiles.

This approach establishes a layered assurance chain:

• BTL certification provides protocol conformance
• AMEV attestation confirms compliance with public-sector BACnet profiles
• BIOP attestation documents multi-vendor device interoperability within projects

For design teams and integrators, these certifications serve as essential documentation in public tenders.

BACnet/SC as the Cybersecurity Baseline

Cybersecurity regulations are driving adoption of secure-by-default solutions.

• BACnet Secure Connect (BACnet/SC) introduces a secure datalink to BACnet, using TCP, WebSockets, and TLS 1.3 encryption with certificate-based authentication.
• Vendors position BACnet/SC as the native means to satisfy IT and public security requirements without custom VPNs.

Procurement increasingly specifies such baselines. A recent building automation tender for a large public university campus mandated BACnet/SC support for building management and automation stations, required devices to be BTL-certified, and called for compliance with IEC 62443-4-2 secure product development.

What started as an optional security feature is rapidly becoming standard in public projects linking BAS networks to IT or cloud services.

Procurement Guidance: Open Protocols and Exit Strategies

Procurement guides now formalize open, multi-vendor connectivity.

The California State University Building Automation Systems Procurement Guide defines open protocols as those with published characteristics and names BACnet and LonWorks as principal open BAS protocols. It recommends limiting manufacturers to those using open protocols to ensure "exit strategies" and avoid lock-in.

Further recommendations:

• BACnet is widely adopted and available from all major BAS vendors
• Open protocols facilitate phased migration between manufacturers without major rewiring
• Use of third-party tools for trending, alarming, and analytics across vendors is encouraged

Along with AMEV and similar European guidelines, these documents demonstrate a shift from ad-hoc protocol selection to policy-driven open connectivity.

Wireless IP Standards: Thread and Matter Enter Commercial Smart Buildings

While BACnet leads at management and fieldbus layers, wireless IP standards are maturing as certified, multi-vendor options for edge devices.

Thread as an IP Backbone for Commercial Devices

Thread delivers low-power, IPv6 mesh networking for building devices such as sensors, actuators, and luminaires.

Thread is positioned as an application-neutral IPv6 mesh capable of hosting multiple building automation protocols-including KNX IoT, DALI+, and Matter-within a single wireless infrastructure.

Recent commercial enhancements include:

• Improved credential management and network diagnostics
• Demonstrations of KNX-IoT and DALI+ on Thread at Light + Building trade events
• Architectural models where Thread augments Ethernet and Wi-Fi for dense device connectivity, with full enterprise IT management

Matter Certification as a Multi-Vendor Device Layer

Matter, led by the Connectivity Standards Alliance (CSA), adds an application layer and certification process for IP-based devices running over Thread or Wi-Fi.

• The CSA's Matter certification program requires conformance testing and lists certified devices in a Distributed Compliance Ledger (DCL) for controller authentication.
• Matter 1.2 expanded certified device categories, including white goods and additional sensors, with ongoing roll-out expected through 2024 and beyond.

Matter's direct impact on public-sector projects is still evolving, but the trend is toward discoverable, certified, multi-vendor devices. As Thread and Matter expand in professional lighting, room control, and small power, they are poised to operate alongside BACnet backbones, using gateways or native IP integration at the BMS level.

How Specifications Are Changing: From Protocol Names to Certification Clauses

Procurement specifications increasingly move beyond protocol listings to require demonstrable interoperability and security.

Old vs. Emerging Specification Patterns

For system integrators, protocol support alone no longer suffices. Success depends on proven conformance with recognized certification schemes and operation within mixed-vendor topologies.

Example: Public-Campus BACnet Specification

The previously referenced IIT Delhi tender exemplifies this new approach:

• BACnet and BACnet/SC are mandated as primary BMS communication protocols
• Building automation stations must have BTL-tested BACnet/IP and BACnet/SC communication
• Stations must meet AMEV profile AS-A (at minimum) and support BACnet/SC migration without hardware replacement
• BACnet/SC devices must be BTL-tested, with manufacturers demonstrating IEC 62443-4-2 compliance

This reflects the multi-vendor, multi-layer certification approach now adopted by European government projects.

Implications for System Integrators and Vendors

New Baseline Obligations

System integrators working with public-sector clients should anticipate requirements to:

• Use only BTL-certified BACnet devices, with AMEV attestations in some regions
• Support BACnet/SC, including certificate lifecycle management and integration with corporate public key infrastructure (PKI)
• Provide evidence of IEC 62443-aligned secure development practices
• Deploy wireless devices based on certified, IP-based stacks (Thread/Matter, KNX IoT, DALI+ over Thread), not proprietary solutions

Vendors lacking certification strategies may be excluded from tenders despite technical capability.

Design and Commissioning Complexity

Open, multi-vendor architectures require careful planning. The CSU guide notes that while open protocols provide exit strategies, they can increase complexity if multiple toolchains are involved.

Integrators are adopting approaches such as:

• Standardized BACnet device profiles and BIBB sets for public buildings
• Template-based engineering with uniform naming conventions and semantic tags
• Automated test scripts, based on conformance declarations and AMEV profiles, for onsite device verification

Open connectivity shifts the focus from proprietary integration to orchestrating a predictable multi-vendor ecosystem.

Managing Legacy BMS Estates: Risks and Migration Strategies

Legacy BMS systems dominate public-sector portfolios. Migrating to open, certified, multi-vendor architectures introduces both risks and opportunities.

Key Risks

• Partial interoperability: Older BACnet devices lacking current profiles or BTL certification may be unreliable when combined with new systems.
• Security gaps: Unsecured BACnet/IP, with broadcast traffic and no encryption, is unacceptable to current IT and cybersecurity standards.
• Gateway sprawl: Maintaining closed subsystems via gateways can result in fragmented integration and unclear responsibilities.

Practical Migration Patterns

Recent public projects use approaches such as:

• Overlay BACnet/SC hubs: Deploy hubs that also route BACnet/IP, enabling phased migration and securing management traffic
• Segmentation by criticality: Prioritize migration of life-safety and critical HVAC first; maintain non-critical systems with defined gateways
• Certification-driven refresh cycles: Align replacement cycles with certification targets (e.g., "all AHU controllers BTL-listed and AMEV-certified by year X")
• Data abstraction layers: Implement IP-based data integration (e.g., via OPC UA or REST) to normalize semantics across legacy and new systems for analytics and regulatory reporting

Actionable Next Steps for Facilities and Project Teams

For those preparing upcoming public-sector projects, the following steps support alignment with open-connectivity requirements.

1. Map Your Current Protocol and Certification Landscape

• Inventory existing BMS, fieldbus, and wireless protocols
• Identify devices with BTL or relevant certifications
• Assess gaps in BACnet/SC support, AMEV attestations, or IEC 62443 documentation

2. Define a Target Multi-Vendor Architecture

• Standardize on BACnet/IP and BACnet/SC for management and control layers
• Plan for IP-based wireless (Thread, Wi-Fi) for edge devices
• Decide where Matter, KNX IoT, or DALI+ over Thread are appropriate, and define their integration strategy

3. Embed Certification Requirements in Specifications

Include clauses to:

• Require BTL certification for all BACnet devices and AMEV attestations where applicable
• Mandate BACnet/SC, certificate handling, and PKI compatibility
• Reference IEC 62443-4-2 or equivalent security standards
• Specify wireless standards and demand evidence of Thread/Matter or similar certification

4. Align with SRI and EPBD Objectives

• Ensure BMS specifications address SRI domains relevant to the building
• Design data models and logging for EPBD reporting (energy use, comfort, faults) to avoid future retrofits

5. Build an Organizational Certification Roadmap

• Coordinate targets with procurement, IT security, and sustainability teams
• Pilot multi-vendor interoperability and commissioning before scaling across portfolios

Frequently Asked Questions

How is BACnet/SC different from using VPNs or firewalls to secure BACnet/IP?

BACnet/SC embeds security into the protocol, employing TLS encryption and certificate-based mutual authentication between devices. Each session is encrypted and authenticated end-to-end. VPNs and firewalls secure the network layer, but do not standardize device authentication or certificate management at the application level. BACnet/SC directly addresses these within the BAS standard, hence its growing inclusion in public-sector specifications.

Is BTL certification mandatory for BACnet devices in public projects?

While BTL certification is not universally legal requirement, it is a de facto standard in many public tenders and guidelines. Documents such as AMEV "BACnet in public buildings" and various university and government specifications explicitly call for BTL-listed devices to minimize integration risk. Even where not required, BTL certification strengthens competitive positioning.

How do AMEV attestations relate to BTL certification?

BTL certification verifies correct implementation of BACnet functions to standard and test procedures. AMEV attestations confirm that a device, already BTL-certified, supports BACnet functions and profiles suitable for German public buildings. BTL asks, "Is this a conformant BACnet device?"; AMEV, "Is this device suitable for public buildings under AMEV profiles?" Both are often required in government projects in the DACH region.

Where do Thread and Matter fit into a BACnet-based smart building?

Thread and Matter typically operate at the device and room-control layer, offering low-power IP connectivity and multi-vendor interoperability. In an open architecture:

• Thread connects sensors, actuators, and luminaires
• Matter, KNX IoT, or DALI+ serve as application layers over Thread or Ethernet
• BACnet/IP and BACnet/SC integrate subsystems with the BMS

Gateways or IP interfaces translate device data to BACnet objects for cross-vendor system coordination.

What should facility teams prioritize first: interoperability or cybersecurity?

Both must be addressed together. Interoperability without security exposes systems to risk; security without interoperability can create vendor lock-in. A practical sequence is:

1. Establish standardized open protocol and certification requirements (BACnet/IP, BACnet/SC, BTL, AMEV)
2. Implement network segmentation and BACnet/SC for critical systems with phased migration of legacy segments
3. Align procurement with cybersecurity standards, such as the EU Cyber Resilience Act, and internal policies

In this approach, cybersecurity initiatives help support the transition to open, multi-vendor smart building ecosystems.