Lifted Lines: Managing Elevators as Critical Tech Infrastructure

Elevators Are More Than Mechanical Assets

Elevators are easy to categorize as a facilities or mechanical concern—until an outage turns them into an operational, safety, security, and tenant-experience issue all at once. This episode examines why modern elevator systems should be managed as critical infrastructure nodes rather than isolated assets.

The discussion opens with a realistic high-rise failure scenario: a storm causes an elevator control cabinet to lose power, multiple cars go offline, tenants back up in the lobby, deliveries miss scheduled windows, security reroutes foot traffic, and an elderly tenant is stranded long enough to trigger an emergency call. The incident is not limited to a technical fault. It creates a ripple effect across building operations and the property’s reputation.

For property leaders, facilities teams, security personnel, and IT stakeholders, the key message is straightforward: elevators sit at the intersection of power, life safety, access control, networking, vendor operations, and tenant continuity. A weakness in any one of those areas can create a much larger problem.

What Makes an Elevator a Technology Infrastructure Node?

Traditional elevator components still matter: drive machinery, controllers, and safety gear. But many current elevator environments also include technology components that need coordinated operational ownership.

• Controller systems used for diagnostics and operation
• Remote service ports used by elevator vendors
• Building-management-system interfaces
• IP cameras in elevator cars or lobbies
• Card readers and other access-control integrations
• Network connections supporting diagnostics, monitoring, or vendor access
• Normal power, UPS equipment, breakers, and emergency power transfer systems

These dependencies mean an elevator outage can be caused by more than a mechanical malfunction. A single breaker, a shared UPS, a failed battery bank, or an improperly documented transfer switch can become a single point of failure. If the building does not have a clear picture of these dependencies, teams may not discover the weakness until cars are offline and occupants are affected.

Where Facilities, IT, and Vendors Commonly Misalign

Network connectivity can improve elevator operations by enabling remote diagnostics and faster maintenance response. It also introduces questions that cannot be left informal. An elevator vendor may view the controller as vendor-managed equipment that needs connectivity. Building IT sees another device on the network that must be inventoried, secured, and supported appropriately.

The resulting ownership questions are often unclear:

• Who maintains controller firmware?
• Who approves remote vendor access?
• Who documents network paths and failover procedures?
• Who owns the network port serving the controller?
• Who owns the UPS and emergency-power transfer equipment?
• Who retains diagnostic logs after an incident or test?

Without explicit answers, buildings can accumulate unmanaged endpoints, inconsistent maintenance windows, unclear escalation paths, and systems that are unreachable at the exact time the team needs visibility. The goal is not to prevent elevator vendors from supporting their equipment. The goal is to establish controlled, documented access and clear responsibilities that protect both uptime and the broader building network.

Balancing Security, Access, and Uptime

Elevator resilience involves real tradeoffs. Restricting remote vendor access can reduce network exposure, but it may also delay troubleshooting and extend an outage. Allowing overly broad vendor access can speed response, but it can widen the building’s attack surface. The right answer is not a blanket yes or no. It is a written operating model that defines who receives access, how access is granted, what segmentation is required, and how emergency approval works.

Firmware creates a similar decision point. Delaying updates may avoid short-term compatibility concerns, but it can leave systems unsupported or exposed over time. A disciplined maintenance approach weighs the risk of change against tenant safety, service continuity, security posture, and compliance requirements.

Manual operation and emergency lowering procedures are equally important. These are life-safety measures that must be preserved, but their execution needs to be practical. If only vendor personnel can use a manual procedure and they are not on site, occupants may face long waits. If broad building staff have override access without the right training, the building can introduce serious safety risks. The operational target is documented, practiced, auditable procedures with clearly assigned roles.

A Real-World Power Resilience Failure

The episode shares a multi-tenant office tower incident in which the main machine room lost power during a transfer test. The UPS serving several elevator controllers had a mis-rated battery bank and failed after approximately 10 minutes. Elevators went offline during peak egress, security consoles filled with tenant complaints, and deliveries accumulated on lower floors.

The investigation uncovered several operational gaps: UPS ownership was unclear, transfer scenarios had no defined testing schedule, and remote logging was limited. The corrective actions focused on governance as much as equipment:

• Contracts were updated to define UPS ownership and testing responsibilities.
• Vendor access was segmented on the network.
• Quarterly transfer tests were required with facilities and IT witnesses.
• Post-test logs were retained for accountability and future troubleshooting.

The later transfer tests produced significantly less downtime and clearer accountability. This is the value of treating an elevator environment as integrated infrastructure: a disruptive failure becomes an opportunity to build repeatable operational discipline.

Three Actions to Take This Week

1. Build and publish an asset and responsibility map. Include elevator controllers, network endpoints, UPS equipment, transfer switches, and the teams or vendors responsible for each component.
2. Schedule and witness transfer and load tests. Test during low-impact windows, simulate power transitions and high-traffic conditions, and retain the results.
3. Document remote-access rules and segmentation. Define who can access elevator-connected systems, how approval works, and what happens during an emergency.

Clear ownership, regular testing, and written access controls reduce ambiguity when a failure occurs. More importantly, they shorten downtime, support safer response, and protect the tenants who depend on vertical transportation every day.

Resources

Visit the GDS Technology site for episode resources, checklists, and a sample responsibility matrix to help align facilities, IT, security, and elevator vendors around resilient operations.

Elevators Need to Be Managed as Critical Building Infrastructure

When elevators work, they tend to disappear into the background. Tenants move between floors, deliveries stay on schedule, visitors reach meetings, and building staff focus on other priorities. When elevators fail, however, the consequences become immediate and highly visible.

Consider a multi-tenant high-rise on a Monday morning. A storm causes an elevator control cabinet to lose power. Several cars go offline. Tenants stack up in lobbies. Delivery windows are missed. Security staff have to reroute foot traffic. An elderly tenant is stranded long enough to trigger an emergency call. What began as a power issue quickly becomes a service-continuity, safety, security, and reputation issue.

That is why elevator systems should not be treated as isolated mechanical assets. In modern buildings, elevators are connected to power systems, fire and life-safety processes, access control, networking, remote vendor support, and tenant operations. Property leaders need an operating model that recognizes those connections before an outage exposes them.

The Elevator Environment Has Expanded

The core physical components of an elevator remain essential: drive machinery, controllers, and safety gear. But the supporting environment has become more complex. Many systems now include remote service ports, diagnostic capabilities, building management interfaces, IP cameras, card readers, and network-connected components.

That broader footprint changes the risk profile. An elevator controller may rely on a network port. A vendor may need remote access for maintenance. A UPS may support multiple controllers. Emergency power transfer equipment may be involved during an outage. Any of those dependencies can become a single point of failure if it is not identified, assigned, and tested.

A single breaker can take down a controller. A shared UPS can fail. A battery bank can be mis-rated. A transfer switch can be documented incorrectly or not tested often enough. These are not theoretical edge cases. They are the quiet dependencies that turn a local equipment fault into a building-wide operational event.

Ownership Boundaries Are an Operational Control

One of the most common sources of elevator-related risk is unclear ownership. Elevator vendors often own or maintain the controller and may request network access for diagnostics or support. IT teams are responsible for protecting the building network and managing connected endpoints. Facilities teams oversee physical systems and maintenance. Security teams may be affected when cars, lobbies, cameras, or access paths change during an outage.

If no one has documented the boundaries, every incident starts with avoidable questions. Who owns the controller? Who owns the network port? Who approves remote access? Who owns the UPS? Who validates emergency transfer behavior? Who retains diagnostic logs? Who coordinates the vendor, facilities, IT, and security response?

Those questions should be answered in an asset and responsibility map, not during a service disruption. The map should identify the equipment involved, its dependencies, its location, its support contacts, and the accountable party for each component. At a minimum, it should cover controllers, UPS equipment, transfer switches, network endpoints, remote access methods, and emergency-power dependencies.

This documentation does more than clarify administration. It speeds incident response. When a car goes offline, the team can quickly determine whether the issue points to power, connectivity, controller operation, vendor service, or another dependency. That reduces frantic handoffs and helps ensure the right people are engaged first.

Remote Access Must Support Both Security and Recovery

Remote vendor access is a practical example of a real operational tradeoff. Restrict it too tightly, and a vendor may be delayed when urgent diagnostics are needed. Allow broad, uncontrolled access, and the building may create unnecessary exposure on its network.

The answer is controlled remote access rather than unmanaged access. Building teams should define in writing who can connect, how access is granted, what approval process applies, and what network segmentation protects the rest of the environment. Emergency scenarios should have a defined path that supports fast response without abandoning accountability.

Network segmentation is especially important because elevator-connected devices should not simply be treated as ordinary endpoints. The elevator controller may need narrowly scoped connectivity to approved vendor services or management systems. It should not have broader access than the function requires. This approach helps the building preserve remote diagnostic benefits while reducing the chance that an unmanaged or poorly governed endpoint affects broader network health.

Maintenance Is Not Only Mechanical

Preventive maintenance must include more than mechanical checks. Mechanical condition matters, but so do firmware, security reviews, network health, backup power, and power-transition behavior. A building that maintains the elevator hardware but ignores supporting technology dependencies may still experience avoidable downtime.

A practical cadence should include scheduled mechanical checks, firmware and security reviews, network health checks, and verification of UPS and emergency-power components. The exact schedule may depend on the property and vendor requirements, but the principle is consistent: critical dependencies need planned attention rather than reactive attention.

Testing is where documentation becomes operationally meaningful. Transfer and load tests should be scheduled during lower-impact windows when possible. Teams should simulate power transitions and high-traffic conditions so they can observe how the environment behaves before a real emergency. Results should be documented and retained.

Witnessing matters as well. Facilities, IT, and appropriate vendor representatives should participate so that the technical result is understood across ownership boundaries. A passing test that only one party understands can still leave the building exposed when a real failure requires coordinated action.

The UPS Failure That Exposed the Gaps

One office tower experienced this firsthand during a transfer test. The main machine room lost power, and the UPS serving several elevator controllers failed after roughly 10 minutes because its battery bank was mis-rated. The result was elevator downtime during peak egress, a flood of tenant complaints to security consoles, and delivery congestion on lower floors.

The investigation did not identify just one failed component. It found an operating-model problem. Ownership of the UPS was unclear. There was no established transfer-test schedule. Remote logging was limited. The building lacked the visibility and accountability needed to diagnose and respond efficiently.

The corrective actions were direct. Contracts were updated to define UPS ownership and testing responsibilities. Vendor access was segmented. Quarterly transfer tests were required with facilities and IT witnesses. Post-test logs were retained.

The outcome was reduced downtime during later transfer tests and clearer accountability when issues occurred. The lesson is not that every building will experience the same battery failure. The lesson is that infrastructure resilience depends on ownership, testing, and documentation as much as it depends on equipment.

Manual Procedures Require Training and Practice

Manual operation and emergency lowering procedures are life-safety features, so they must remain available and reliable. However, availability alone is not enough. Teams need to know who can execute the procedure, when it should be used, what training is required, and how the action is documented.

If only vendor staff can perform a critical manual measure and no one is available on site, recovery may be delayed. On the other hand, giving broad building staff control access without sufficient training can introduce major safety concerns. The balanced approach is a documented procedure with defined roles, regular drills, and an auditable record of testing.

Tabletop exercises can help teams prepare without waiting for a live incident. Bring together IT, facilities, security, and vendor representatives. Walk through the sequence of an elevator outage. Identify how the incident is reported, who verifies power status, who contacts the vendor, how tenant impacts are handled, how remote access is approved, and how the event is documented. These exercises turn isolated expertise into coordinated response.

Three Practical Actions for Property Leaders

Property leaders and facilities teams can begin reducing elevator-related operational risk immediately.

1. Create an asset and responsibility map. Document controllers, UPS systems, transfer switches, network endpoints, vendor contacts, and accountable owners.
2. Test power transitions and load conditions regularly. Schedule and witness the tests, then retain the logs and findings.
3. Put remote-access governance in writing. Define access rights, network segmentation, approval workflows, and emergency procedures.

These actions create clarity before a failure forces decisions under pressure. They also help protect tenant uptime without compromising safety or network security.

Listen for the Full Discussion

In this episode of Built, Wired & Secured, the conversation translates elevator resilience into concrete operational choices for property leaders, facilities teams, IT, and security stakeholders. Listen for practical guidance on identifying single points of failure, defining ownership boundaries, testing backup power, and building a response model that keeps people and operations moving.