Show Notes
Why Elevators Need to Be Managed Like Technology Infrastructure
In this episode of Built, Wired & Secured, Alex Morgan and Michael Harrington examine a building system that is often underestimated until it fails: the elevator environment. The discussion starts with a familiar but high-impact scenario. A storm interrupts power to an elevator control cabinet in a multi-tenant high-rise, several cars go offline, tenants back up in the lobby, deliveries miss service windows, security has to redirect traffic, and an elderly tenant is stranded long enough to trigger an emergency call. The point is clear: when elevators are treated as isolated mechanical assets, operational risk stays hidden until it shows up all at once.
The episode explains why elevators now sit at the intersection of multiple building systems. They are tied to power, fire and life safety, access control, and in many cases the building network itself. When one dependency breaks, the impact extends far beyond inconvenience. Tenant experience, safety, building operations, and reputation can all be affected within minutes.
What Makes a Modern Elevator System More Than Motors and Pulleys
Michael walks through the components building teams should be thinking about beyond the obvious machinery and safety gear. Modern elevator environments often include:
- Controllers used for diagnostics and operations
- Remote service ports for vendor maintenance access
- Building management interfaces
- IP cameras at cars or lobbies
- Integrated card readers tied to access control
- Normal and backup power dependencies
One of the strongest operational warnings in the episode is that seemingly minor infrastructure details can become major single points of failure. A single breaker, a shared UPS, or an improperly documented transfer switch can quietly become the weak link that takes multiple cars offline. That is why elevator systems should be treated as infrastructure nodes with documented dependencies, not standalone devices left to one vendor silo.
Where Facilities and IT Commonly Misalign
The conversation then moves to a common friction point: network connectivity. Remote diagnostics can improve troubleshooting speed, but adding elevator-related devices to the network introduces risk and ownership confusion. Michael highlights the questions that often go unanswered:
- Who maintains firmware?
- Who approves remote vendor access?
- Who documents failover procedures?
- Who owns the network segment supporting elevator-connected devices?
When those answers are unclear, building teams end up with unmanaged endpoints, vague maintenance boundaries, and inconsistent incident response. In the best case, that creates delays. In the worst case, it creates exposure on the network and leaves critical systems unreachable during an outage.
The Real Tradeoffs Between Security and Uptime
A key theme in the episode is that operational decisions are rarely simple. Restricting remote vendor access can improve security posture, but it may also slow down troubleshooting and extend downtime. Allowing broad access may speed support, but it can also widen the attack surface. The same is true with firmware. Delaying updates can avoid immediate compatibility problems, yet it can also leave systems unsupported or exposed over time.
The takeaway is not that one side always wins. The right answer depends on balancing tenant safety, service continuity, compliance obligations, and cybersecurity risk. The discussion makes a practical case for governance rather than improvisation.
Why Manual Procedures Still Matter
Alex asks about lockout procedures and manual operation, and the answer reinforces that resilience is not only about connected systems. Manual or emergency lowering procedures remain life safety functions, but they can create problems if access is poorly structured. If only vendor staff can execute them and they are not on site, downtime stretches. If too many building staff can override controls without training, safety risk increases.
Michael describes the operational sweet spot as documented, practiced procedures with clear roles and regular drills. That approach supports fast action without sacrificing safety or auditability.
A Real-World Failure That Changed the Process
One of the most useful parts of the episode is the office tower example shared by Michael. In a multi-tenant building, the main machine room lost power during a transfer test. The UPS feeding several elevator controllers had a mis-rated battery bank and failed after 10 minutes. The result was predictable but costly: elevators went offline during peak egress, security consoles flooded with complaints, and deliveries stacked up on lower floors.
The post-incident review found three core issues:
- Unclear ownership of the UPS
- No transfer-scenario test schedule
- Limited remote logging
The response was disciplined rather than reactive. Contracts were updated to define UPS ownership and testing responsibilities. Network segmentation was enforced for vendor access. Quarterly transfer tests were required with facilities and IT witnesses present. Post-test log retention was also added. According to the episode, those changes reduced downtime in later tests and created clear accountability when issues surfaced.
Three Practical Actions to Take This Week
The episode closes with three direct actions property leaders, facilities teams, and IT teams can adopt immediately:
- Build and publish an asset and responsibility map covering controllers, UPS systems, transfer switches, and network endpoints
- Schedule and witness regular transfer and load tests, then retain the logs
- Define remote access rules and segmentation in writing, including who gets access, how it is granted, and how emergency approvals work
These are not complex changes, but they reduce ambiguity, improve incident response, and make elevator-related downtime easier to contain. More importantly, they help building teams manage elevators as integrated infrastructure that affects people, operations, and business continuity.
Why This Conversation Matters
This episode is a concise reminder that modern building performance depends on more than visible tenant amenities. Elevators affect mobility, safety, service delivery, and reputation. Treating them as part of the wider technology and operations environment helps reduce hidden risk before it becomes a Monday morning crisis.
Elevators Are Not Just Mechanical Systems Anymore
When people think about critical building infrastructure, they often focus on network rooms, power distribution, access control, or fire and life safety. Elevators are usually placed in a different category: essential, yes, but mechanical. In this episode of Built, Wired & Secured, Alex Morgan and Michael Harrington make the case that this view is outdated. In modern buildings, elevators sit at the intersection of physical systems, power resilience, security, and network-connected operations. Treating them like isolated assets creates avoidable risk.
The discussion opens with a scenario many operators can imagine immediately. A storm causes an elevator control cabinet to lose power in a multi-tenant high-rise. Several cars go offline. Tenants build up in the lobby. Deliveries miss time-sensitive windows. Security staff start rerouting foot traffic. An elderly tenant is stranded long enough to trigger an emergency call. The outage affects more than mobility. It creates operational disruption, tenant frustration, and reputational damage in a matter of minutes.
That scenario is the central point of the episode: elevator failures do not stay contained. They ripple across the building.
Why Elevator Infrastructure Has Become More Complex
Michael breaks down what sits behind the visible elevator experience. Yes, there are the expected components: drive machinery, controllers, and safety systems. But modern elevator environments also include diagnostic controllers, remote service ports, interfaces into building management systems, and in some cases integrated IP cameras or access control readers in lobbies or cars.
That matters because each added point of integration creates dependency. An elevator system can now rely on:
- Normal power
- Backup power
- Transfer switching
- Vendor remote access pathways
- Building network connectivity
- Security and access-control integrations
Once those elements are present, the elevator environment stops being a standalone mechanical system. It becomes part of the broader operational technology fabric of the building.
The episode emphasizes how small undocumented decisions can create major failure points. A single breaker. A shared UPS. A transfer switch no one has fully mapped. These are the details that do not get much attention during normal operations, but they can take down service at exactly the wrong time.
The Ownership Problem That Causes Preventable Failures
One of the most practical lessons in the episode is that many elevator incidents are not caused only by hardware. They are caused by unclear ownership.
When an elevator vendor needs remote access for diagnostics, where does that access live? Who approves it? Who is responsible for maintaining firmware? If the device is on the building network, does facilities own it, or does IT? If power resilience depends on a UPS, who is responsible for testing that UPS under transfer conditions?
These questions sound administrative, but they directly shape response speed and accountability during an outage. Without clear answers, teams end up in a familiar pattern:
- Facilities assumes IT has visibility into connected devices
- IT assumes the vendor owns the controller and related maintenance
- Security only gets involved once tenant traffic becomes a problem
- No one has a documented failover path or test history ready when service drops
The result is confusion during the exact moment when clarity matters most.
Security and Uptime Are Both Real Requirements
A strong part of the conversation focuses on tradeoffs rather than absolutes. Building teams often face a real tension between reducing risk and preserving uptime.
For example, remote vendor access can speed troubleshooting and shorten outages. But if it is too broad or poorly segmented, it also expands the attack surface. Tight restrictions can help from a security perspective, but they may delay vendor response when a critical event occurs. Neither extreme is ideal.
The same logic applies to firmware updates. Some operators postpone updates to avoid compatibility surprises. That may seem prudent in the short term. Over time, though, delayed updates can leave systems unsupported or exposed, especially when the connected components are part of a larger networked environment.
The episode does not argue for convenience over security or vice versa. Instead, it argues for structured decision-making. Teams need documented rules that reflect tenant safety, business continuity, compliance obligations, and cybersecurity realities all at once.
Manual Procedures Are Still Part of Resilience
Another important point is that resilience is not only about automation, diagnostics, or remote access. Manual and emergency procedures still matter.
Lockout procedures and emergency lowering functions are life safety features. But they can become operational bottlenecks if the building has not planned for them properly. If only vendor staff can execute those procedures and they are off site, a building can end up waiting too long during a critical event. On the other hand, if too many untrained staff members can override systems, the building introduces safety and liability risks.
Michael describes the answer as a documented and practiced operational model. That means clearly assigned roles, procedures that are drilled regularly, and controls that preserve both safety and accountability. The goal is not unrestricted access. The goal is fast, safe, auditable action when elevators are unavailable.
What Resilience Looks Like in Practice
The episode offers a useful checklist for moving from reactive response to operational discipline.
It starts with an asset map and a responsibility matrix. Building teams should know who owns and supports each of the following:
- Elevator controllers
- Remote service ports
- Network endpoints
- UPS units
- Transfer switches
- Emergency power dependencies
That map should not stay informal. It needs to be published, accessible, and connected to maintenance and incident workflows.
From there, maintenance needs to be broader than routine mechanical checks. The episode recommends scheduling firmware and security reviews, confirming network health, and testing under load during low-impact windows. Those exercises should include high-traffic simulation and power-transition scenarios, with results documented and stored.
Contracts also matter more than many building teams expect. Michael calls out the importance of requiring access to diagnostic logs and setting a defined service level agreement for critical failures. Those details reduce finger-pointing after handover and improve response when a vendor relationship becomes time-sensitive.
Just as important, the teams involved should run tabletop exercises together. IT, facilities, vendor representatives, and security all need to know what the first steps look like when an elevator goes down. A documented process is useful. A practiced one is far better.
The Office Tower Example That Ties It Together
The most concrete example in the episode comes from a multi-tenant office tower where the main machine room lost power during a transfer test. A UPS supporting several elevator controllers had a mis-rated battery bank and failed after ten minutes. That single weakness triggered broad disruption. Elevators went offline during peak egress. Complaints flooded security consoles. Deliveries stalled on lower floors. Operations were affected immediately.
The investigation identified three specific weaknesses: unclear UPS ownership, no schedule for transfer-scenario testing, and limited remote logging. None of those gaps were dramatic on their own. Together, they created a predictable failure.
The post-incident changes are worth noting because they are practical and repeatable. 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 present as witnesses. Logs were retained after tests. According to the episode, later transfer events produced significantly less downtime, and accountability was much clearer when problems appeared.
That is the operational model this conversation advocates: not perfect prevention, but measurable reduction in confusion, downtime, and blame.
Three Actions Property and Operations Teams Can Take Now
The episode ends with three immediate steps that can be implemented without waiting for a major capital project.
- Build and publish an asset and responsibility map that includes controllers, UPS systems, transfer switches, and network endpoints
- Schedule and witness regular transfer and load tests, then retain those logs
- Define remote access rules and network segmentation in writing, including access approval workflows for emergency scenarios
These are simple actions, but they address the root issue repeated throughout the episode: ambiguity. When ownership, access, and test practices are unclear, outages last longer and confidence drops faster. When those items are documented and rehearsed, buildings respond with discipline instead of chaos.
The Bigger Business Lesson
The larger takeaway is that tenant experience depends on infrastructure choices that are often invisible until something breaks. Elevators are part of that equation. They influence mobility, accessibility, delivery operations, security response, and perception of the property itself.
For property leaders, facilities teams, and IT stakeholders, this episode is a reminder that resilient buildings are not built through isolated systems. They are built through coordinated ownership, documented dependencies, and tested operational processes.
If you want a clearer framework for where building technology, risk management, and tenant operations intersect, this episode is worth a listen. It turns elevator management from a narrow maintenance topic into a practical conversation about resilience, accountability, and uptime. Listen to the full episode for the complete discussion and the supporting operational guidance referenced throughout.