Cloud vs. Edge: Why Your Unified Physical Security Platform Needs Local Decision Making

Failure Scenario — 3:14 p.m.

The fire alarm goes off in a office tower in central London. Emergency exits need to release. Staff need to evacuate. The building's cloud-managed access control system dials the AWS data centre in Northern Virginia — which, as of 3:02 p.m., has been down due to a cascading DNS failure.

The doors don't open.

This isn't a hypothetical designed to scare you. It's the logical conclusion of an architectural decision made in too many boardrooms: "We'll just put it all in the cloud."

Modern security platforms promise centralised visibility, scalable management, and seamless updates. The cloud delivers all of that. But when the connection drops — and it will — your security system needs to keep making smart decisions without it. That's not a cloud problem. That's an architecture problem.

If you're evaluating unified security systems for a mid-to-large estate, this article breaks down exactly what's at stake, why cloud-only architectures carry hidden risks, and why the answer isn't less cloud — it's smarter edge.

Section 1: Cloud Architecture Simplified

What AWS Multi-AZ Actually Means

When vendors tell you their platform is "built on AWS with Multi-AZ redundancy," they're describing something genuinely impressive — and genuinely misunderstood.

AWS (Amazon Web Services) divides its infrastructure into Regions (like EU-West in Ireland) and within each Region, multiple Availability Zones (AZs) — essentially separate physical data centres a few miles apart, each with independent power, cooling, and networking.

Analogy

Think of an AWS Region as a city, and Availability Zones as different office buildings within that city. If one building loses power, your work automatically shifts to another. Multi-AZ protects you from a single building catching fire. But if the entire city floods — a region-wide outage — every building goes dark.

That is precisely what happened in October 2025, when a DNS misconfiguration inside AWS's US-East-1 region caused a cascading failure that took down Snapchat, Roblox, major banks, and healthcare providers globally. Organisations with Multi-AZ setups inside that region were no better off than those running single data centres. The whole city had flooded.

Multi-AZ is excellent engineering. It's just not the whole answer — especially for physical security systems where the stakes are a locked door, not a slow-loading webpage.

Section 2: Where Cloud-Only Falls Short

The risks your vendor may not be telling you about

• ‍80+: Major internet outages in the first half of the 2020s — up from a handful in prior decades
• ‍52%: Of organisations now use cloud-connected access controllers — but complete cloud reliance remains dangerous
• ‍44%: Of security professionals are actively adopting edge computing in their access control strategy

Cloud outages are not rare edge cases. They're operational realities. And for physical security systems, the consequences are categorically different from a website going offline.

Horror Story #1 — The Locked-Out Hospital

A regional hospital running a pure cloud-managed access system experiences an ISP fibre cut at 6 a.m. — shift change. With the cloud unreachable, every badge reader on secure wards defaults to its manufacturer-programmed fallback: fail-secure mode. Doors lock. Nurses can't reach medication storage. Consultants can't enter theatres. The IT team scrambles for a workaround that doesn't exist. The manual override is a printed code in a folder no one can locate.

Horror Story #2 — The Latency Incident

An investment bank's trading floor operates under tight compliance: every door entry must be logged and authorised within 800 milliseconds. During a routine cloud maintenance window, API response times spike to four seconds. Access events are dropped. The audit log has gaps. Six months later, those gaps become a regulatory headache worth more than the annual cost of the entire security system.

The underlying issue in both scenarios is the same: the intelligence lives too far away from the door. Every access decision — "Does this credential open this door right now?" — is a round trip to a server potentially thousands of miles away. When that round trip fails or slows, your physical security stops working.

Section 3: The Role of Edge Computing in Security

Bringing the brain closer to the building

Edge computing isn't a new concept — it just means processing data near where it's generated rather than shipping it off to a distant data centre. Your smartphone does this when it recognises your face without contacting Apple's servers. Your smart thermostat does it when it adjusts temperature based on local sensors.

In physical security, edge computing means your access controllers carry enough intelligence to make decisions independently — even when the cloud is unreachable. Credential validation, door-state logic, alarm responses, and audit logging all happen on-site, in real time.

Analogy

A cloud-only access system is like a security guard who can only let you in after phoning head office for approval every single time. An edge-capable system is a guard who already has the approved list, knows the rules, and can act independently — but still syncs updates with head office whenever they're in touch.

The business case is straightforward. Resilience: If an edge node loses connectivity, it operates independently without affecting other sites. Speed: Local authentication happens in milliseconds, not seconds. Compliance: Audit logs are created and preserved on-device, with no gaps during outages.

Section 4: How Edge Controllers Work in Practice

The Mercury example — intelligence at the door

Mercury MP Intelligent Controllers represent the direction the industry is heading: devices that aren't merely relay points for a distant server, but genuine decision engines embedded in your building's fabric.

Legacy access control architectures processed all logic centrally — the controller was essentially a dumb relay that asked the server whether to open a door. That design created latency, single points of failure, and limited adaptability. Mercury's approach inverts this model. The controller itself runs an embedded application environment, supporting custom and certified third-party software directly on the device, close to the point of access, where real-time performance and fault tolerance matter most.

In practical terms, this means:

Local enforcement. Controllers that support encrypted, supervised communication can make access decisions locally, allowing doors to function securely during network or host outages. Your building keeps working when the WAN link drops.

Trusted inputs. Supervised readers provide verified device status and credential data, giving controllers reliable information on which to base access decisions — without requiring a cloud confirmation on every swipe.

Resilient architecture. Distributed enforcement at the edge means no single centralised control point can take down your entire estate. One site going offline doesn't cascade to the rest.

According to Mercury's own 2025 Trends in Access Controllers Report, 72% of security professionals now consider controllers a critical part of their system design — not a commodity component. The controller is where your security policy lives.

Fail-Safe vs. Fail-Secure: The Choice That Matters Most

Any honest conversation about edge controllers has to address the two modes that govern what happens when systems lose power or connectivity:

• ‍Fail-Safe: Doors unlock on power loss or system failure. People can always exit. Essential for emergency egress routes, fire escape paths, and any door where trapping people is the greater risk.
• Fail-Secure: Doors lock on power loss or system failure. Nobody enters without authorisation. Required for server rooms, pharmaceutical storage, data vaults — where an unlocked door is the greater risk.

The critical point: an edge controller lets you choose and enforce this behaviour locally, based on each door's specific risk profile, without depending on a cloud server to make the call. In a pure cloud model, if the connection drops and the fallback isn't explicitly configured, the door defaults to whatever the hardware manufacturer hardwired — which may not match your security policy at all.‍

Conclusion: The Only Resilient Architecture Is Hybrid

Cloud and edge are not competing philosophies. They're complementary layers of the same stack. The cloud gives you centralised management, real-time dashboards, scalable audit trails, remote firmware updates, and enterprise-wide visibility. Edge gives you continuity, speed, and the assurance that a fibre cut in the North Sea doesn't unlock your server room.

The question to ask every access control vendor isn't "Is it cloud-managed?" It's: "What happens when the cloud is unreachable?" If the answer is vague, or involves phrases like "it's very rare" or "our uptime is 99.9%," keep asking. That 0.1% is a fire alarm at 3 a.m.

The most robust unified security platforms of 2026 are built on a clear principle: cloud for intelligence and management, edge for decisions and continuity. Any architecture that bets your physical security entirely on an unbroken internet connection has, in effect, handed a veto over your building's safety to an AWS engineer in Virginia you've never met.

Don't hand over that veto. Keep the intelligence local.

Ready to build a resilient, hybrid security architecture?

Request a WaveFusion Demo to discover how Wavestore's unified platform leverages intelligent edge processing to keep your building secure — even when the cloud isn't.