Show Notes
Security Controls Must Also Support Operations
Access control is designed to protect people, property, and sensitive areas. But when readers, locks, elevators, and lockdown procedures depend on power, networks, cloud platforms, and centralized commands, a failure can quickly become an operational outage.
This episode examines the tension between strict security and uptime in commercial buildings. The central question is simple: what breaks if the access system goes down? For property leaders, facilities teams, IT teams, and security teams, the answer can include locked-out tenants, inaccessible conference rooms, restricted elevators, delayed emergency response, and a rushed effort to coordinate manual overrides.
The discussion opens with a midsized office tower scenario: a software update affects a cloud access platform, readers stop accepting credentials, elevators enter restricted mode, and tenants cannot enter or receive guests through the lobby. At the same time, emergency responders arrive for another incident and find that doors will not unlatch locally. The result is two hours of disrupted operations, missed meetings, frustrated tenants, and serious reputational damage for the building operations team.
Why Access Systems Become Bottlenecks
Three recurring causes can turn a security platform into a building-wide interruption:
- Dependencies: Many access solutions assume continuous power, network connectivity, and cloud availability. If one of those dependencies fails, access may fail with it.
- Single points of control: Centralized controllers and cloud-only lockdown commands can create a critical failure point when there is no independent local fallback.
- Ownership gaps: Access control often touches security, IT, facilities, electrical systems, and tenant operations. If responsibilities are unclear, response and recovery slow down when an incident occurs.
One example involved card readers powered by a UPS that shared capacity with elevator controls. A generator failure and UPS misconfiguration caused the readers to drop while the elevators continued operating. The security team initiated a cloud-based lockdown, but offline readers prevented local door release. The incident combined power dependency, centralized command, missing local fallback, and an unowned test plan.
The Real Trade-Off: Risk, Impact, and Response
There is no universal answer for every building. Operators need to balance three factors: risk exposure, operational impact, and response capability.
- Manual mechanical overrides can improve availability, but they can weaken security if access to them is not tightly controlled.
- Redundancy can add cost and operational complexity, but dedicated power circuits, local controllers, and battery-backed readers can prevent a much larger disruption.
- More resilience procedures can create more opportunities for human error, so procedures must remain usable under pressure.
The practical goal is not to choose security over uptime, or uptime over security. It is to design layered controls that preserve safe, predictable building access when a primary system or dependency fails.
Design Choices That Support Resilience
For owners who need strong lockdown capability without unnecessarily interrupting tenant access, several choices matter most:
- Maintain a tested local fallback that can operate independently of the cloud.
- Use dedicated power paths for critical readers and controllers.
- Document manual release procedures, including who is authorized to use them.
- Train the people who will need to carry out those procedures during an outage.
- Treat local control panels and battery-backed edge devices as risk-mitigation investments rather than optional extras.
Tenant downtime is felt immediately. Insurance coverage or warranty arguments do not resolve missed meetings, inaccessible spaces, or the reputational cost of a building that cannot function during a failure.
Emergency Response, Capital Planning, and Coordination
Resilience affects more than convenience. Emergency responders need predictable local access during a crisis. A cloud-reliant access platform that cannot function during an outage can delay response or allow dangerous conditions to continue.
Resilience should also be addressed during capital planning. Owners can compare the operational losses associated with an outage against the incremental cost of redundancy, local fallback, and better commissioning. Access control crosses electrical, IT, and mechanical systems, so coordination among vendors and trades is essential. Without it, hidden single points of failure can survive into production.
A Four-Step Decision Framework
- Identify critical functions. List the doors, elevators, and related systems that would have a meaningful operational impact if unavailable.
- Map dependencies. Document power sources, network paths, cloud reliance, and control ownership for each critical function.
- Evaluate single points of failure. Ask what happens if each dependency goes down.
- Define mitigation and test it. Decide whether redundancy, local fallback, or procedural controls are appropriate. Test failover, train staff, and repeat after significant changes or at least annually.
Four Actions to Take This Week
- Run a tabletop exercise around the loss of a primary access-control dependency, such as power or network connectivity.
- Ask vendors exactly how devices behave offline and require documented fallback behavior in proposals.
- Document ownership and escalation responsibilities across operations, IT, and security.
- Include resilience measures in capital and operations-and-maintenance planning.
Download the one-page checklist and explore related resources, tabletop scenarios, and vendor questions at gds-technology.com/builtwiredsecured.
Security vs. Uptime: Why Building Access Systems Need a Failure Plan
Access control is often evaluated through a security lens: who can enter, which doors should lock, how quickly a building can go into lockdown, and how credentials are managed. Those are necessary questions. They are not the only questions.
For commercial buildings, an access-control system is also part of daily operations. It affects tenant arrival, guest access, conference-room use, elevator movement, secure-area entry, and emergency response. When the system relies on power, network connectivity, cloud services, centralized controllers, or a single operational team, a technical failure can become a tenant-facing outage in minutes.
The better design question is not simply, “How secure is this system?” It is, “What breaks if this goes down?”
How a Security System Can Interrupt a Building
Consider a Monday-morning failure in a midsized office tower. A software update affects the cloud access platform. Readers stop accepting credentials. Elevators enter a restricted mode. Tenants cannot badge into the building or allow guests through the lobby. Emergency responders arrive for a separate incident and find doors that do not unlatch locally.
The immediate operational impact is obvious: tenant operations stall, meetings are missed, conference rooms go unused, and building personnel begin coordinating manual overrides under pressure. The less visible impact is just as important. The operations team has lost credibility with tenants and ownership because systems intended to protect the property became an obstacle to keeping it running.
This is why access control should be treated as an operationally critical system. If it touches everyday building functions, it needs the redundancy, procedures, ownership, and testing expected of other essential systems.
The Three Failure Patterns to Watch
Security-linked outages often originate in one or more of three areas.
1. Dependencies on power, network, and cloud services
Many access platforms assume persistent power and connectivity. Readers, controllers, cloud consoles, network paths, and related systems can all become dependencies. When one fails, access may become unreliable or unavailable.
A practical example involved readers powered through a UPS that shared capacity with elevator controls. A generator failure combined with a UPS misconfiguration caused the readers to drop while elevators remained operational. Security personnel initiated a cloud lockdown, but because the readers were offline, doors could not be released locally. Tenants were left outside secure areas.
The problem was not one device. It was a chain of dependencies that had not been designed and tested as a complete operational scenario.
2. Centralized control without local fallback
Centralized management can simplify administration, but it can also create a single point of control. Cloud-only lockdown commands or centralized controllers are a risk when there is no tested local option for maintaining safe access or releasing doors during a disruption.
Local fallback does not mean eliminating centralized security. It means designing layered controls. A building can maintain centralized oversight while retaining a local, independent way to operate essential access functions when cloud connectivity or a centralized service is unavailable.
3. Unclear ownership across teams
Access control sits at the intersection of security, IT, facilities, electrical systems, mechanical systems, vendors, and tenant operations. If the organization has not decided who owns response decisions, technical troubleshooting, local release authority, and escalation, delays are almost guaranteed during an incident.
The fastest technical fix is not always enough. Teams must know who can authorize a manual release, who contacts the vendor, who validates network conditions, and who communicates with tenants. Those responsibilities should be documented before an outage, not negotiated during one.
Balance Security, Operational Impact, and Response Capability
Building operators often face a real trade-off. Manual mechanical overrides can improve availability, but they may weaken security if they are poorly controlled. Redundant power, local controllers, and battery-backed readers improve resilience, but they add cost and complexity. Additional procedures can make a system more resilient, but too many steps can introduce human error.
The answer is not a universal configuration. It is an informed decision based on three considerations:
- Risk exposure: What security risks are present if a fallback mechanism is used?
- Operational impact: What happens to tenants, visitors, emergency response, and business operations if access is unavailable?
- Response capability: Can the building team execute the fallback safely, quickly, and consistently?
For many properties, the appropriate answer includes dedicated power paths for critical readers and controllers, a local fallback independent of the cloud, clear manual-release authorization, and training for the people expected to act during a disruption.
Design for the Failure Moment
Resilience should not be treated as a feature added late in procurement. It should be incorporated into capital planning, design, commissioning, and operations-and-maintenance planning.
Owners can start by quantifying the potential operational loss of an outage. How much disruption would result if tenants could not enter for two hours? What would restricted elevators mean during a busy workday? What happens if responders cannot access a critical area locally? Comparing those consequences with the incremental cost of redundancy changes the conversation. Local control panels, separate power circuits, and battery-backed edge devices may cost more up front, but they can prevent much larger operational and reputational losses.
Vendor and trade coordination is equally important. Access control touches electrical, IT, and mechanical systems. A design may look resilient when each component is reviewed separately, while still containing a hidden single point of failure across systems.
One campus facility found this during testing. Its cloud-managed access system relied on network connectivity across several buildings, and a single VLAN misconfiguration could isolate access panels throughout the campus. Rather than replacing the entire platform, the team added local control relays, established a separate management VLAN for critical devices, and formalized an emergency local-release procedure. That limited scope change and tested process prevented widespread tenant disruption during a later network contractor error.
A Practical Four-Step Review
Operators can use a concise framework to evaluate security-linked single points of failure.
- Identify critical functions. List doors, elevators, and systems that would create meaningful operational impact if they became unavailable.
- Map dependencies. For each function, document power sources, network paths, control ownership, and cloud reliance.
- Evaluate single points of failure. Ask, “What breaks if this goes down?” for every dependency.
- Define mitigation and test. Select redundancy, local fallback, or procedural controls as appropriate. Test failover, train staff, and repeat after significant changes or annually.
This framework turns a broad resilience discussion into specific decisions that can be budgeted, assigned, tested, and defended.
Four Immediate Actions for Property Leaders
There are four practical actions that can begin this week:
- Run a tabletop exercise around a loss of power or network connectivity and validate local fallback procedures.
- Ask vendors how devices behave offline and require documented fallback behavior in proposals.
- Document ownership and escalation across operations, IT, and security teams.
- Include resilience measures in capital and operations-and-maintenance plans.
The objective is not to weaken building security. It is to ensure that security controls continue supporting safe, productive operations when a system fails. Listen to this episode of Built, Wired & Secured for the complete discussion and download the one-page checklist, sample tabletop scenarios, and vendor questions at gds-technology.com/builtwiredsecured.
Design for the moment when a system fails. If people can remain safe and productive during that moment, the building is better prepared for the real world.