Because an elevator controller is software that moves people. It is built from third-party components like any other firmware, and a flaw in one of them is a safety and availability issue, not only a data issue. Owners and maintenance contractors should know what is inside and who patches it.
What makes an elevator a software supply chain problem?
A modern controller combines a vendor's logic, an operating system or real time kernel, communication libraries and often a remote monitoring module. NIST's OT guide, SP 800-82 Rev. 3, lists building automation systems and transportation systems among the kinds of operational technology it covers, and defines OT as programmable systems that interact with the physical environment.
That puts a lift in the same category as a factory controller for planning purposes. The difference is who is responsible. The building owner holds the contract, the maintenance company holds the keys, and the manufacturer holds the source. A vulnerable library falls between all three.
We do not cite any specific elevator incident here, because we have not confirmed one worth citing. The argument does not need one.
Which standard describes the roles?
ISA/IEC 62443 separates asset owners, service providers and product suppliers, with a part for each. Part 2-1 covers the owner's security program, part 2-4 covers service providers, and part 4-1 covers a secure product development lifecycle for suppliers. A separate report, ISA-TR62443-2-3, covers patch management. Using these as vocabulary in a maintenance contract makes responsibilities explicit.
What should an owner ask the maintenance provider?
- Which controller models and firmware versions are in our buildings?
- Do the controllers have remote access, and who can use it?
- Is there a bill of materials for the controller firmware, and will you share it?
- How do you learn about vulnerabilities in the components, and how fast do you tell us?
- How is a patch tested before it reaches a car carrying passengers?
What to do
- Build a register of every lift and escalator controller: building, model, firmware, remote access path.
- Ask the maintenance provider for firmware bills of materials in SPDX or CycloneDX.
- Find out whether any controller is reachable from the internet or from the tenant network, and close that path if it is.
- Put the answers to the five questions above into the maintenance contract schedule.
- Agree who may approve a firmware change and what manual checks follow it.
- Check the register against vulnerability data once a quarter and after any public advisory about a listed component.
Where does Safeguard help?
If a supplier gives you an SBOM, you can scan it with the Safeguard CLI, which accepts SPDX and CycloneDX files, and see known vulnerabilities by component. Safety acceptance testing remains with qualified elevator professionals and the manufacturer.
What if the maintenance company is small?
A small contractor may not have a security team, and may not receive component bills of materials from the manufacturer. That does not remove your need to ask. It changes the request.
Ask for what they do have: the controller models, the firmware versions, the remote access method and the manufacturer's support contact. Then ask the manufacturer directly for the firmware bill of materials and a vulnerability notification process, and copy the contractor.
If neither can supply a list, record that as a risk in your register with an owner and a review date. For new installations, make the bill of materials and a patch commitment conditions of purchase. Over a few contract cycles, those conditions move the market more than any single audit.
Do not pressure anyone to do an untested patch to close a finding. A safe delay with a clear plan is better than a rushed change to a machine that carries people.
Quick check
Is an elevator controller really an IT asset?
It is operational technology. It needs software hygiene like IT, plus safety review that IT does not have.
Who is responsible for patching it?
It depends on your contract, which is why the contract should name a role for each party.
Sources
- NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
- ISA/IEC 62443 series of standards
- Safeguard CLI documentation
Last reviewed: 18 October 2026.
