Johnson Controls Metasys Security Guide: Hardening accounts, engines, certificates and remote access

Metasys controls heating, cooling, lighting, fire interfaces and access systems in hospitals, campuses, data centres and government buildings, and a weak account or an unpaired engine can hand an attacker control of the building. The platform spans Windows application and data servers, network engines on the building network, configuration tools used by integrators and an API used by analytics and integration products. This guide explains how identity and access work in Metasys, which roles and accounts hold the most power, how to handle API users and the default system account, what to log, and how to apply Johnson Controls' own hardening guidance in a sensible order. It is for building owners, facilities and OT security teams, and the integrators who commission and maintain Metasys sites. Settings and values come from the Metasys Release 14.1 Hardening Guide and CISA advisories; check the guide for your installed release, as defaults change between releases.

Key takeaways

• Change MetasysSysAgent and kill shared logins. The default system account is the one shared account Johnson Controls tolerates, and only during multi-installer deployments with the password in a password manager; everyone else, including vendor technicians, gets a named account.
• Use the directory for people, local accounts for exceptions. Servers, the Metasys UI and SCT support Active Directory over LDAP or LDAPS and OAuth providers including ADFS, with group-to-role mapping from Release 14.0; engines do not, so engine access needs its own controls.
• Pair every engine and enable Advanced Security. From Release 10 engines pair with the Site Director using unique credentials, and the Advanced Security Enabled setting rejects unpaired engines.
• API access is privileged. The API Access permission should never sit on an account that also holds the Administrator role, and integration accounts belong in an NHI inventory with an owner.
• Logs are useless if they stay on the server. Forward audit and alarm data to up to three Syslog servers and watch the Cyber Health Dashboard for failed and locked logins.

How identity and access work in Metasys

A Metasys site has a management tier of Application and Data Servers (ADS, ADX) or an Open Application Server (OAS), network engines such as the NAE and SNE families on the building network, field controllers on BACnet and other buses, the System Configuration Tool (SCT) used to build and commission the system, and the Metasys UI and Site Management Portal used by operators. One server or engine acts as the Site Director that holds the site's security database. For the general BMS architecture and protocol risks, see the Building Management System Security Guide.

Roles, categories and permissions

Metasys uses role-based access control. The default roles are User, Operator, Maintenance and Administrator, and the permission types are Standard, Tenant and API Access. Access can also be narrowed by data category: the hardening guide describes up to 163 categories, such as HVAC, Fire and Security, and 10 functional levels from view-only to database configuration. That means a fire panel technician can be given control of fire-related objects and nothing else, and a tenant can be limited to their own floors.

• Login hours: accounts can be restricted to set times and days, which suits contractors and day-shift operators.
• Session timeout: inactive sessions close after a configurable period (the default is 30 minutes, and the guide's hardened value is 5 minutes for interactive users); unsaved changes are discarded and the timeout is audited.
• Keep Me Signed In: with ADFS this sets a 24-hour cookie, so users must sign out of Windows at the end of each session if it is enabled.

Admin roles and privileged access

Johnson Controls' guidance is explicit: no shared accounts, least privilege, and separation of duties so that no single user holds full administrative rights across the site. Duties can be split by site, subsystem or function.

Treat these rules as the fallback for accounts that cannot use the directory. For people, centralise in Active Directory or another LDAP directory (the guide's own recommendation) so that leavers are disabled once and MFA applies through the identity provider. Administrator accounts should be separate from daily operator accounts, held by a small named group, and reviewed with the Dormant Account User Report, which can lock or alarm on inactive accounts. The PVT also lists accounts with no login in the last six months and accounts holding administrator privileges, which makes a quarterly review straightforward. For wider OT privileged access patterns, see the OT and ICS Identity and Access Guide.

Vendor and integrator access

The hardening guide states that Johnson Controls technicians should also have named accounts. Commissioning often involves several installers, and this is the only situation where the guide accepts a shared MetasysSysAgent login, stored in a password manager. Change it at handover, and make removal of temporary commissioning infrastructure part of acceptance. See the OT Third-Party and Integrator Access Guide.

Integrations, API tokens and service accounts

Modern Metasys sites expose a REST API used by analytics platforms, digital twins, energy dashboards and the vendor's own cloud services. The hardening guide lists internal web and API services on ports 9505 to 9507 and RabbitMQ on 5672 and 25672. Each integration authenticates as a Metasys user, which makes it a non-human identity that is easy to forget.

• One account per integration: give each consuming system its own account with API Access, a description naming the system and its owner, and the narrowest categories and functional level that work. Never combine API Access with the Administrator role.
• Prefer read-only: most analytics only read points and trends. Write access through the API should be the exception and approved through change control.
• Store and rotate the secret: integration passwords belong in a vault, not in a dashboard's configuration file. Rotate on staff change at the integrator and after any suspected exposure.
• Kiosk and display accounts: no session timeout makes them convenient and risky; keep them view-only and on locked-down display hardware.
• Directory bind and SNMP: LDAP bind credentials and SNMP community strings are also non-human secrets; use LDAPS and restrict SNMP to the site's network management system.

Credential exposure through the API has been reported before: CISA ICSA-23-012-06 described ADS, ADX and OAS servers in versions 10 and 11 that could expose plaintext credentials through API calls to unauthenticated users (CVE-2021-36204, CWE-522, CVSS 7.8), fixed in 10.1.6 and 11.0.3. See the Service Account Security Guide and the API Key Management Guide for lifecycle controls.

Network exposure, engines and certificates

The hardening guide says to close any port not in use. Johnson Controls does not recommend placing any Metasys equipment in a DMZ, and recommends either an Airwall Gateway or a customer-managed VPN for remote access, noting that Metasys does not support SSL VPN. The network engine firewall is enabled by default.

• TLS: from Release 8.1, SCT, servers, engines and clients use HTTPS with TLS 1.3. Disable TLS 1.0 and 1.1; on the ADX, cipher and protocol settings come from Windows SChannel and must be hardened separately.
• Certificates: replace the default self-signed certificates, which only provide encryption, with certificates from a trusted CA (organisation or extended validation, or the customer's own IT CA). Wildcard certificates are not supported. Engine certificates are managed in SCT Certificate Management.
• Renewal alarms: the default certificate expiry warning is 60 days, configurable from 1 to 180; the guide recommends at least 120 days to allow for a 90-day renewal process.
• Engine pairing: pair engines with the Site Director using unique credentials and turn on Advanced Security Enabled so unpaired engines are rejected. Reset reused or test engines to factory defaults before deployment.
• FIPS 140-2 mode: optional from Release 11.0 for sites that require it, licensed as M4-FIPS-0 on ADX, ADS, NAE8500 and LCS8500.

Logging and detection

Metasys keeps local event and audit repositories, an audit log, a last-login view in User Management and the Cyber Health Dashboard with Security Analysis, System Status and User Activity widgets. None of that helps an investigation if the server is lost, so forward events and audits to up to three Syslog servers (UDP 514, RFC 3164 format).

If a warning banner is enabled (DoD, GSA and DOT/FAA banners are available), the client IP address can be captured at login, which helps investigations. Network monitoring of BACnet write traffic adds the view that application logs cannot; see the OT Network Security Monitoring Guide.

Metrics:

• Share of interactive users authenticating through the directory or identity provider rather than local accounts.
• Number of accounts with Administrator role, and number of accounts holding both API Access and Administrator (target zero).
• Accounts with no login in six months still enabled (target zero after each review).
• Engines paired and Advanced Security Enabled across the site (target 100%).
• Days to apply a Johnson Controls advisory rated critical for your release.
• Certificates within the renewal window without a ticket raised.

Hardening baseline

Johnson Controls structures its guide as planning, then hardening, then maintenance. A practical rollout order, tested first on a non-production server or a restored SCT archive and then on one building, is:

1. Plan trust boundaries: decide on an isolated LAN or a connected network with firewalls between zones of different trust; no Metasys equipment in the DMZ. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
2. Back up first: SCT archive and security database for engines and servers, server HTTPS certificates through Windows certificate management, and Historian and Audit databases with the Metasys Database Manager. This is your rollback.
3. Update to a supported release: critical fixes ship for the current release, so old releases miss them.
4. Change MetasysSysAgent and run the PVT: confirm the default password is gone.
5. Disable TLS 1.0 and 1.1 and unused ports: close port 80, TFTP, discovery and debug ports outside commissioning.
6. Configure user management: directory or OAuth for people, group-to-role mapping, named accounts for technicians, password and timeout settings from the table above, separation of duties.
7. Load trusted certificates and pair engines: enable Advanced Security once all engines are paired; test with one engine first and keep a rollback path in SCT.
8. Turn on monitoring: Syslog forwarding, dormant account alarms and the Cyber Health Dashboard.
9. Optional web server hardening: the guide's step reduces maxQueryStringLength from 32768 to 4096 in the IIS web.config files on ADS, ADX, NAE85 and LCS85; back up the files and plan a restart.
10. Maintain: review advisories, remove former and inactive accounts, update roles, test backups and check certificate expiry on a fixed schedule.

Small sites and large estates

• Single building with one engine or server: local accounts may be realistic. Apply the 15-character rule, a 5-minute timeout, named accounts and Syslog to an existing collector, and put remote access behind a customer-managed VPN with MFA.
• Campus or multi-site: directory or OAuth integration with group-to-role mapping, central certificate issuance, and separation of duties by site and subsystem become essential.

Common misconfigurations

• Default or shared MetasysSysAgent after handover: the commissioning password stays known to every installer who worked on the site.
• Integrator remote access left always on: unmanaged remote desktop tools or SSL VPNs (which Metasys does not support) used instead of a managed path.
• Old releases kept running: CVE-2021-36207 let an authenticated user gain administrator privileges in versions 10 and 11 (ICSA-22-118-01, CVSS 8.8), and CVE-2022-21936 let an AD user perform validated actions without a valid password on ADX 12.0 running MVE (ICSA-22-277-01).
• Self-signed certificates and click-through warnings: users learn to ignore the orange and red shield indicators.
• Admin role on integration accounts: an analytics vendor's credential becomes full control of the building.
• Unpaired or reused engines: engines moved between projects without a factory reset carry old credentials and configuration.

Framework mapping

Practitioner checklist

• Change the MetasysSysAgent password at handover and confirm with the Performance Verification Tool.
• Move interactive users to Active Directory over LDAPS or an OAuth identity provider with MFA and group-to-role mapping.
• Give every technician, including vendor staff, a named account with login hours and least privilege.
• Create one API account per integration, never with the Administrator role, with its secret vaulted.
• Pair all engines with the Site Director and enable Advanced Security Enabled.
• Replace self-signed certificates with trusted CA certificates and set renewal alarms to at least 120 days.
• Disable TLS 1.0 and 1.1, close port 80 and commissioning-only ports.
• Forward audit and alarm events to Syslog and review failed, locked and out-of-hours logins.
• Run the Dormant Account User Report and PVT account lists every quarter.
• Track Johnson Controls advisories and keep the site on a supported release.

Standards and references

• Johnson Controls: Metasys Release 14.1 Hardening Guide
• Johnson Controls: Product Security Advisories
• CISA: ICS Advisory ICSA-23-012-06 Johnson Controls Metasys
• CISA: ICS Advisory ICSA-22-118-01 Johnson Controls Metasys
• CISA: ICS Advisory ICSA-22-277-01 Johnson Controls Metasys ADX Server
• CISA: Primary Mitigations to Reduce Cyber Threats to Operational Technology
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK for ICS: Valid Accounts

Related NHI Mgmt Group resources: Building Management System Security Guide · BACnet and BACnet Secure Connect Guide · KNX and LonWorks Building Protocol Security Guide · OT Remote Access Guide