The cloud has been part of the conversation for decade – shared computing resources dates back to the 1950s. Yet after all this evolution, ‘cloud-based’ still means different things to different vendors.
In access control, it can refer to cloud management, cloud storage or cloud dependency. The distinction matters enormously – particularly at 3am when a network fails and doors need to keep working.
So, if cloud-based appears in your security specification, what are you actually specifying? As centralised management platforms become standard, security professionals face a critical question: where should intelligence reside? The answer reveals competing architectural philosophies, each with profound implications for reliability, security and operational resilience.
The Architecture Spectrum
Cloud deployment and cloud dependency are not the same thing. A system can be deployed on cloud infrastructure while maintaining operational independence. Or it can depend entirely on cloud connectivity for every function. Understanding this distinction is essential.
Fully cloud-dependent platforms treat door controllers as endpoints that rely on constant communication with cloud servers for access decisions. Every card read, every unlock command requires that connection. These systems offer deployment simplicity: minimal on-site infrastructure, automatic updates and browser-based management from anywhere.
And on the opposite end sits traditional on-premise systems where all intelligence, data and decision-making occur locally. Nothing depends on internet connectivity, but management requires direct site access or complex remote configurations. Multi-site organisations face the administrative responsibility of managing independent installations at each location.
Between these extremes lies distributed intelligence: systems that provide centralised management – whether on customer-controlled servers or cloud infrastructure – while maintaining autonomous decision-making at the edge. Controllers process access decisions independently. Centralised management provides efficiency, but operational functionality doesn’t depend on it.
Where the Trade-offs Lie
Cloud-dependent architectures excel at deployment speed and eliminate on-site server requirements. For small installations with reliable connectivity, this simplicity proves compelling. The vulnerability? When internet connectivity fails – and it does fail – the system loses functionality exactly when security teams need it most. Doors may default to fail-safe or fail-secure states, but the system cannot adapt to changing conditions, grant emergency access, or provide real-time visibility.
We’ve seen this across the industry: ransomware attacks taking down networks, broadband outages during critical operations, connectivity failures during security incidents. In these moments, architectural decisions transform from specification detail to operational crisis.
Distributed intelligence addresses this vulnerability directly. In JanusC4, door controllers operate as autonomous units. They store up to 500,000 credentials locally and make access decisions independently. Whether deployed on customer-managed cloud infrastructure or on-premise servers, the architecture remains the same: network connectivity enables management, synchronisation and monitoring, but controllers continue functioning when that connectivity disappears.
Doors still open for authorised users. Time schedules still apply. Local access control logic continues operating. The system degrades gracefully rather than failing completely. This isn’t just theoretical resilience – it’s how critical infrastructure maintains security during the network failures that inevitably occur.
But the trade-off is complexity. Distributed systems require more capable hardware at the edge and careful consideration of credential synchronisation across installations.
The Grosvenor Perspective
Our journey from Sateon to JanusC4 taught us that operational resilience outweighs deployment convenience. Sateon earned its reputation through blade-based, distributed architecture that functioned regardless of network conditions. When we evolved the platform into JanusC4, we preserved that architectural philosophy whilst adding improved connectivity and flexible deployment options.
This wasn’t inert design – it was pragmatism informed by decades of customer experience. Organisations managing critical infrastructure – healthcare centres, research facilities, manufacturing operations, secure government installations – can allow ‘the system went down because connectivity failed’ as an explanation. They need centralised management for operational efficiency, but they cannot accept centralised dependency as an architectural compromise.
JanusC4 can be deployed on customer-controlled cloud infrastructure, yet it maintains the distributed intelligence that enables continued operation during outages. Cloud deployment doesn’t require cloud dependency.
Questions Worth Asking
When evaluating access control systems, architectural questions deserve prominence: What happens to door operation during network outages? Where are credentials stored and processed? How much intelligence resides at the controller level? What’s the failover strategy? Can the system operate in a degraded state, or does connectivity loss mean complete failure?
These questions reveal whether you’re specifying centralised management, which every modern system should provide, or accepting centralised dependency, which transforms connectivity from operational tool into single point of failure.
The distinction matters. Professional security means protecting what matters most, even when – especially when – everything else stops working.
You can find out more about what JanusC4 can do on the product page.