Elevator maintenance: what a vulnerable dependency means in the field

A vulnerable dependency in elevator equipment is a maintenance question before it is an attack story. The practical task is knowing which units run which software, who can change it, and how a fix reaches a machine that must keep carrying people. This post stays on that process and avoids invented incidents.

I did not find a public source for elevator specific cyber requirements while researching this, so I do not cite any elevator safety code. Check the codes that apply where you work with your safety engineers.

Where do elevators fit in the standards we can cite?

NIST SP 800-82 Rev. 3 covers operational technology, defined as programmable systems and devices that interact with the physical environment. Its listed examples include industrial control systems, building automation systems, transportation systems and physical access control systems. Elevators are not named in the abstract I read, but building automation and physical access are, and many elevator installations connect to both. Treat that as an inference and confirm for your site.

ISA/IEC 62443 says it applies to building automation among other sectors, and splits duties among asset owners, product suppliers, integrators and service suppliers. A maintenance contractor often sits in the last group, so the series is relevant to what you promise a building owner.

What does a "dependency" mean on a service call?

Modern controllers and remote monitoring gateways contain software the manufacturer did not write: an operating system, a network stack, a web interface, a library for parsing messages. A flaw in one of those is a vulnerable dependency. You will rarely see it. You will see it only if the manufacturer publishes a component list or an advisory.

So the day to day questions are:

• Which units have a network connection, and to what?
• Which firmware version is installed in each?
• Does the monitoring gateway accept connections from the internet or a vendor cloud?
• Who holds the service credentials, and are they shared across sites?

None of these need a scanner. They need a spreadsheet kept current.

Why is patching slow here?

Because the equipment is safety related and often certified in a specific configuration. Changing firmware may need the manufacturer, a technician on site, a maintenance window and sometimes an inspection afterward. NIST's guidance for OT says its countermeasures must account for performance, reliability and safety requirements, which is the same tension. You will often choose between patching, network isolation and monitoring, and the right answer depends on the unit.

What can a service firm ask its suppliers?

• A software component list per firmware release, in a machine readable format.
• A contact and process for vulnerability reports.
• How long the product receives security updates.
• Whether remote access is on by default and how to turn it off.
• Whether the supplier follows ISA/IEC 62443-4-1 for product development, which covers the secure development lifecycle for suppliers.

CISA has a general SBOM Sharing Primer describing how such lists move between parties. It is not elevator specific.

What to do

1. Build a fleet register: site, unit, controller model, firmware version, network connection.
2. Mark every unit with remote monitoring and record where it connects.
3. Replace shared or default service credentials, one site at a time, with a manufacturer approved process.
4. Subscribe to each manufacturer's security notices.
5. When an advisory arrives, match it against the register and classify each unit as affected, not affected or unknown.
6. Plan fixes with the safety engineer and manufacturer, not around them.
7. Add component list and update period questions to your next supplier review.

Quick check

Sources

• NIST SP 800-82 Rev. 3
• ISA/IEC 62443 series
• CISA: SBOM Sharing Primer

Last reviewed: 18 October 2026.