Elevator and Lift Control System Security: Securing Remote Monitoring, Alarms and Dispatch

Modern lifts are networked control systems, and most building owners have no idea who can reach them remotely or how. A current installation typically has a controller and group controller, a remote monitoring gateway that reports faults to the maintenance company, an emergency alarm that dials a rescue service, a destination dispatch system wired into access control, and often a cloud API that lets apps and robots call cars. Each of those is a connection someone else installed, usually with credentials nobody on site owns. This guide covers how lift systems are connected, the codes and standards that now set cybersecurity requirements for them (ISO 8102-20 and ASME A17.1 Section 8.14), and how to inventory, segment, monitor and govern them. It is written for OT, facilities and security teams; the wider building automation picture is in the Building Management System Security Guide, which this page does not repeat.

Key takeaways

• Safety circuits are not the risk you manage; the mechanical and electrical safety chain stays independent of software, but availability, access control and alarm reliability all depend on networked components.
• There are now lift-specific security requirements: ISO 8102-20:2022 sets cybersecurity requirements for new lifts, escalators and moving walks, and ASME A17.1-2022/CSA B44:22 Section 8.14 covers controllers with an internet connection.
• Remote access is the main exposure: maintenance gateways, cellular modems and remote interaction features are installed and operated by the service company, so the owner must demand documentation and a means to disable them.
• The emergency alarm is a life-safety telecom link: analogue line retirement, SIM expiry and power loss break alarms silently unless line monitoring and test calls are watched.
• Destination dispatch and lift APIs create identities: access control integrations, service accounts and API clients that can place calls or open floors are non-human identities that need owners, scopes and rotation.

How a connected lift system is built

The parts and their connections matter more than the brand. Ask the maintenance contractor and installer for a diagram that shows every item below and every path off the lift network.

The design principle in every lift code is that the safety chain (overspeed governor, safety gear, door locks and their monitoring) is independent of the dispatch and communication layers. That independence limits what a network attacker can do to people in the car, but it does not protect availability: a group controller that is shut down, a lockdown that is lifted, or an alarm line that has failed are all reachable through software. ATT&CK for ICS describes the impact side as Manipulation of Control (T0831), Device Restart/Shutdown (T0816) and, in the worst case, Loss of Safety (T0880).

Codes and standards that now cover lift cybersecurity

Until recently lift security was left to general OT guidance. Two documents now set lift-specific requirements, and both put obligations on the supplier and integrator rather than the building owner, which is exactly why owners need to ask for the evidence.

Two points are easy to miss. ISO 8102-20 does not apply to equipment installed before its publication, so most existing lifts have no lift-specific baseline at all and must be assessed with general OT methods. And neither standard covers the external systems the lift connects to: the building network, the vendor cloud and the integration with access control remain the owner's problem. See the IEC 62443 Guide and the IEC 62443-2-1 Asset Owner Security Programme Guide.

Remote monitoring and maintenance access

Almost every maintained lift reports to its service company. The common patterns are a cellular modem in the machine room or controller cabinet, an outbound connection through the building internet, or a remote access tool on a monitoring PC. The owner rarely holds the credentials and often does not know the path exists.

• Find every path: walk machine rooms and controller cabinets (machine-room-less lifts put the controller in the shaft or landing door frame) and record modems, SIM cards, routers and antennas. Cellular links bypass the building firewall entirely; ATT&CK for ICS calls this exposure Internet Accessible Device (T0883) and External Remote Services (T0822). See the Cellular Router and Gateway Hardening Guide.
• Prefer outbound-only telemetry: fault reporting needs data to leave the site, not engineers to arrive. Ask the contractor to separate one-way monitoring from interactive access and to disable inbound services on the gateway.
• Broker interactive access: where engineers need remote sessions, route them through the organisation's OT remote access service with named accounts, MFA, approval per job and session recording, rather than a vendor tool left running. See the OT Remote Access Guide and the Privileged Session Management Guide.
• Know the off switch: ASME A17.1 Section 8.14 requires a means to disable remote interaction and internet connectivity, and documentation of how to use it. Make sure facilities staff know where it is and include it in incident playbooks.
• Service tools: handheld or laptop service tools connect locally and can change parameters. Contracts should state who holds them, how they are authenticated and how changes are logged.
• Contract terms: require notification of vulnerabilities and patches for controllers and gateways, a named security contact, removal of access at contract end, and handover of all credentials and documentation. See the Third-Party Access Guide.

Emergency phones and alarm communications

The lift alarm is the one connection that must always work. Under EN 81-28 a passenger pressing the alarm button gets two-way voice contact with a rescue service, normally run by the maintenance company, and the unit periodically checks its line. The migration away from analogue telephone lines is the biggest current risk to that path, and it is a security and resilience problem as much as a telecoms one.

• Treat alarm SIMs as assets: record the ICCID, carrier, contract owner and renewal date. A SIM moved to another device is both a fraud and an availability risk. See the SIM Swap Fraud Guide.
• Watch the line checks: the periodic test call is your detection control. A missed check should raise a ticket with a response time, not sit in a contractor portal.
• Keep alarms off shared networks where possible: an alarm that depends on the corporate router inherits every outage and change on that router. NIST SP 800-53 CP-8 (Telecommunications Services) is the control family to cite.

Destination dispatch, access control and lift APIs: where identity fits

Destination dispatch ties lift calls to who someone is. When a badge is presented at a terminal or turnstile, the access control system tells the group controller which floors that person may visit. That integration turns the lift into part of the physical access control boundary, and it brings identities that are rarely governed.

• Integration accounts: the access control system authenticates to the group controller or vendor cloud with a service account, certificate or API client. It can typically grant any floor. Give it an owner, store its secret in a vault, scope it to the buildings it serves and rotate it. See the API Key Management Guide.
• Cloud API clients: mobile call apps, visitor systems and service robots use client credentials to place calls. Keep one client per integration, never share a client across tenants or sites, and review which clients can call to secured floors.
• Secured floor logic: ASME A17.1 limits remote interaction to calls for unsecured floors. Confirm in testing that API and app calls cannot bypass floor security set in the access control system.
• Operator and engineer roles: lift management consoles and dispatch configuration tools should have individual accounts with separate operator, engineer and administrator roles. ATT&CK for ICS Valid Accounts (T0859) is the technique most lift compromises would use.
• Lockdown and fire recall: list who and what can change lockdown, independent service and recall states, and log every change. See the Physical Access Control Systems Security Guide and the OT and ICS Identity and Access Guide.

Segmentation, hardening and patching

• Own zone: place lift controllers, group controllers and dispatch servers in a dedicated zone, separate from the general BMS and corporate networks, with conduits only to the access control system, fire alarm interface and the approved remote access path (NIST SP 800-53 SC-7, IEC 62443-3-2 zones and conduits).
• Least functionality: disable unused services, web interfaces and default accounts on gateways and dispatch servers; change every vendor default password at commissioning (SC-7, CM-7).
• Dispatch kiosks: terminals are public-facing computers. Lock down operating system access, USB ports and network jacks behind them.
• Patching: controllers are patched by the manufacturer or contractor, often as part of planned maintenance. Ask for a list of firmware versions, a supported-until date per component and how security fixes are notified (SI-2). IEC TR 62443-2-3 covers patch management in OT.
• Software downloads: ASME A17.1 addresses downloading executable software to controllers; ask how downloads are authenticated and logged.

Detection, monitoring and metrics

Lift networks are small and predictable, which makes them good candidates for allow-list monitoring. Feed what you can into the OT monitoring or SOC tooling and agree with the contractor which events they will report to you.

• Network: new connections from the lift zone to the internet, any inbound session to gateways, new devices on the lift network (CSF DE.CM-01).
• Access: remote sessions outside approved tickets, logins to dispatch and management consoles, service tool connections where logged (AU-6).
• State changes: lockdown, independent service, out-of-service and recall changes, and floor permission changes in the access control integration.
• Alarm health: failed periodic test calls, SIM and signal alerts, battery faults on alarm units.

How to implement

1. Inventory (weeks 1 to 4): list every lift, controller, gateway, modem, SIM, dispatch server and integration. Get the contractor's connection diagram and verify it physically.
2. Assess: run a lift-focused risk assessment using IEC 62443-3-2 concepts: what each connection can do, who holds its credentials and what happens if it fails. See the OT Security Assessment Guide.
3. Quick wins: change default passwords, remove unused modems, move alarm SIMs to monitored contracts, and document the disabling means for remote interaction.
4. Pilot segmentation on one bank: put one lift group in its own zone with logging and an allow-list in monitor mode first, confirm dispatch, fire recall and alarms still work with the contractor present, then enforce.
5. Roll back safely: keep the previous firewall rule set and a contractor on call during each change window; any loss of alarm or recall function means immediate reversion and a retest.
6. Govern identities: move integration and API secrets to a vault, create per-engineer remote accounts, and schedule quarterly access reviews.
7. Write it into contracts and procurement: for new lifts require ISO 8102-20 conformity and, where A17.1-2022 applies, Section 8.14 evidence; for existing lifts, add security clauses at renewal.

Small and large estates: a single-building owner may only need to find the modem, verify the alarm path and add contract clauses. A portfolio owner should standardise one remote access pattern, one SIM contract and one integration model across sites, because each contractor otherwise brings its own.

Common failure patterns

• The invisible modem: a cellular gateway installed by the contractor years ago, with a default password and a public address, that the security team never knew about.
• Shared engineer logins: one remote account per contractor, used by every engineer, never disabled when staff leave or the contract changes hands.
• Alarm migrated, never tested: an auto-dialler moved to an IP adapter or GSM module without end-to-end test calls, or a prepaid SIM that expired unnoticed.
• Over-privileged integration: the access control integration or a mobile app client able to call to any floor, with a static key in a configuration file.
• Lift network flat with the BMS: a compromise of a BMS workstation reaches the group controller because both sit on the same VLAN.
• No off switch knowledge: during an incident nobody on site knows how to disable remote interaction and internet connectivity without stopping the lifts.

Framework mapping

Practitioner checklist

• Obtain and physically verify a connection diagram for every lift bank, including modems, SIMs and cloud links.
• Separate one-way telemetry from interactive remote access, and route interactive sessions through a brokered, recorded path with named accounts and MFA.
• Document and train staff on the means to disable remote interaction and internet connectivity.
• Test every emergency alarm end to end after any line, router, SIM or contract change, and alert on failed periodic test calls.
• Move alarm and gateway SIMs to monitored contracts with an owner and renewal date.
• Give every access control, app and robot integration its own scoped credential with an owner, vault storage and a rotation date.
• Place lift controllers and dispatch servers in their own network zone, separate from the BMS and corporate networks.
• Require ISO 8102-20 conformity and, where adopted, ASME A17.1 Section 8.14 evidence for new installations.
• Add vulnerability notification, credential handover and access removal clauses to maintenance contracts.

Standards and references

• ISO (via Standards Council of Canada): ISO 8102-20:2022 Electrical requirements for lifts, escalators and moving walks, Part 20: Cybersecurity
• StandICT.eu: ISO/DIS 8102-20 revision record
• ISA: ISA/IEC 62443 Series of Standards
• NIST: SP 800-82 Rev. 3 Guide to Operational Technology (OT) Security
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK for ICS: External Remote Services
• Elevator World: Remote Interaction Operation and Cybersecurity Is Codified (ASME A17.1-2022)
• Designing Buildings Wiki: How the PSTN switch over will affect your lift

Related NHI Mgmt Group resources: Building Management System Security Guide · OT Remote Access Guide · Physical Access Control Systems Security Guide · OT and ICS Identity and Access Guide