Elevator systems: what should defenders inspect first?

Inspect five things in this order: how the controllers can be reached remotely, which controllers and firmware versions exist, who holds credentials, what else shares their network, and how patches are approved. Most risk sits in the first two, and both can be checked without touching a lift.

Why this order?

Reachability decides whether a flaw can be used at all. A weak component behind a closed path is a maintenance item. The same component on an open path is an incident waiting for a trigger. NIST's SP 800-82 Rev. 3 treats OT security as a balance between security and safety, performance and reliability, so every step below avoids operating the equipment.

1. Remote access

Find every route in: vendor monitoring modems, cellular gateways, VPN accounts for contractors, and any controller port exposed to a tenant or building network. Ask the maintenance provider to list them in writing, then confirm against what you see on the network. Remove routes nobody can justify.

2. The controller inventory

Record model, firmware version, install date and the contractor responsible. You cannot judge a vulnerability notice without it. If a manufacturer can supply a bill of materials for the firmware, request it.

3. Credentials

Check for shared maintenance logins, default passwords and accounts for people who left the contractor. Ask whether access uses multifactor authentication on the contractor side. Rotate anything shared.

4. Network neighbors

Is the controller on its own segment, or on the same flat network as tenant devices, cameras and office computers? ISA/IEC 62443 organizes systems into zones, and part 3-2 covers risk assessment for system design, which is where that thinking lives. You do not need the standard to ask the question: what could reach this device, and what could it reach?

5. The patch process

Ask how firmware updates are tested, who approves them and what happens if an update fails. ISA publishes a dedicated report on patch management in the IACS environment, ISA-TR62443-2-3. A written process matters more than a fast one.

What to do

1. Request the remote access list from the maintenance provider this week.
2. Build the controller register and mark every unknown firmware version.
3. Rotate shared credentials and remove departed accounts.
4. Draw the network around each controller on one page, and flag flat segments.
5. Agree a written patch approval process with named roles.
6. Revisit the list after any advisory that names a component in your register.

What not to do

Do not scan a live controller with an aggressive tool. Do not push firmware yourself. Both can interfere with equipment that carries people. Passive checks, documents and the contractor's records come first.

What does a finding look like?

Here is a hypothetical example, written as a template and not as a report of a real event. Finding: the maintenance modem for the controllers in building A accepts connections from any address and uses a password shared by the contractor's whole team. Risk: anyone who learns the password can reach the controller's management interface. Recommendation: restrict connections to the contractor's known addresses, require multifactor authentication on their side and issue a named account per technician. Owner: the property manager, with the contractor. Due date: thirty days.

Notice the shape. The finding names the asset, the exposure, the consequence and a fix that does not require touching the lift. It also names an owner and a date, which are what turn a finding into work. Use the same shape for each of the five areas.

Quick check

Sources

• NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• ISA/IEC 62443 series of standards

Last reviewed: 18 October 2026.