.png){kind=small}
Cloud Access Control, NCSC Aligned and Installer Tested for Facilities
Cloud access control manages who can enter a building through software hosted off site, while the door hardware, readers, and controllers stay on your premises. For most multi-site or growing organizations, we recommend a cloud-managed system, moving to a hybrid model with strong local caching wherever constant connectivity cannot be guaranteed. Before signing with any vendor, demand their security documentation and proof of offline fail-safe behavior.
TL;DR:
Cloud access control systems require verified offline fail-safe behavior to ensure doors operate correctly during network outages.
Vendors should provide documented responses to security standards like the NCSC Cloud Security Principles and information on data residency, certification scope, and log management.
Offline functionality relies on local caching and must be tested regularly to prevent doors from failing open or trapping occupants during connectivity issues.
Integration points such as directory and HR syncing are common sources of operational failure, so regular testing of sync and access permissions is essential.
Cost factors include site size, required integrations, support tiers, and customization, with ROI driven by easier admin, faster provisioning, and centralized management.
Table of Contents
What cloud access control includes and how it works
A cloud access control system splits responsibilities between a remote management console and the physical hardware on your doors. The cloud layer handles administration, permissions, and reporting. The local layer, meaning controllers, readers, and the door hardware itself, still does the actual job of locking and unlocking.
Facility teams typically work with these components day to day:
Cloud console: the dashboard where you add users, assign credentials, and set schedules from any browser.
Controllers and readers: physical units mounted near doors that talk to the cloud and enforce decisions locally.
Credentials: mobile passes, key cards, or fobs assigned to staff and visitors.
Visitor management: temporary or scheduled access for guests, contractors, and deliveries.
Audit logs: a timestamped record of every entry attempt, granted or denied.
APIs: connections that let the access system talk to other software, such as HR platforms or building management tools.
What changes compared to a traditional setup is mostly what disappears: the on-site server and the need for someone to drive to a building to update a permission list. Remote provisioning, role-based access control, mobile unlock, and automated scheduling all become features you configure from a laptop rather than tasks that require a site visit.
Deployment models: cloud-native, hybrid and on-premises tradeoffs
Three deployment patterns dominate the market, and the right one depends on how much connectivity and local control your sites need.
Cloud-native (SaaS): the entire management layer lives in the vendor’s cloud, offering the fastest updates and easiest multi-site scaling, but requiring reliable internet at every location.
Hybrid: cloud-based administration paired with local controllers that retain enough logic and cached data to keep doors functioning during an outage, a common choice for facilities that cannot risk downtime.
On-premises: a traditional server-based system kept entirely in-house, offering maximum local control at the cost of manual updates and harder remote management.
Migration between models rarely happens overnight. Many organizations move in phases, replacing one building or one wing at a time, often through gateway devices that let older card readers or controllers keep working alongside new cloud-managed hardware. Checking hardware compatibility before committing to a platform avoids the common trap of ripping out usable readers simply because a new system does not support them. The tradeoff running through all three models is the same: more cloud control generally means more scalability and less manual admin, while more local control means better resilience when networks fail.
Security and compliance: what to demand from vendors
Security guidance for cloud-connected access control is specific, and facility managers who skip it tend to find out the hard way during an audit or after an incident.
SP 800-210 sets out access control guidance across IaaS, PaaS, and SaaS cloud models, noting that controls designed for lower-level service models generally apply to the higher-level models built on top of them. That matters for access control platforms because most are delivered as SaaS, built on infrastructure the vendor does not fully control end to end, which means security assurances need to cover every layer involved.
In the UK, NPSA guidance on network-connected security technologies is direct about what buyers should require: a site-specific risk assessment before deployment, and a published vendor response to the NCSC Cloud Security Principles. The same guidance stresses that even a fully cloud-managed system depends on local hardware and network resilience, so physical installation quality and offline behavior remain part of the security picture, not an afterthought.
A vendor’s published response to the NCSC Cloud Security Principles is one of the clearest trust signals available, according to NPSA guidance, and facility teams should treat its absence as a reason to ask harder questions.
Before shortlisting any vendor, request:
Their written statement addressing each NCSC Cloud Security Principle.
Data residency and processing location details, backed by contract terms rather than a sales claim.
Current ISO27001 or SOC2 certification scope, not just a logo on a website.
Multi-factor authentication enforced by default, with no shipped default credentials left active.
Documented logging retention periods and who can access those logs.
Integrations and keeping doors working when the network does not
Cloud access control rarely runs in isolation. Most deployments connect to an identity provider such as Active Directory or Entra ID, an HR platform for automated onboarding and offboarding, a visitor management tool, and sometimes a building management system.
Directory and HR syncing is the most common source of operational failure, since a failed or mismapped sync can leave an access profile active after someone leaves the organization, creating what integration teams call a ghost account.
Role mapping errors during initial setup often grant broader access than intended, so permissions should be reviewed against actual job function rather than copied from a template.
Offline operation at the controller level needs to be verified, not assumed: local caching should let doors keep functioning on their last known permission set during a WAN outage, without failing open or trapping people inside.
Pro Tip: Run a scheduled test that simulates a network outage at least twice a year to confirm doors behave correctly and that the sync queue catches up cleanly once connectivity returns.
How to evaluate a cloud access control vendor
A structured checklist keeps evaluation focused on evidence rather than sales pitches. Start with security assurances, since everything else depends on them:
Does the vendor publish a response to the NCSC Cloud Security Principles, as recommended in CAPSS guidance?
Where exactly is data processed and stored, and is that written into the contract?
What is the scope of their SOC2 or ISO27001 certification, and does it cover the product you are buying?
Can they share penetration test summaries or remediation timelines?
Move next to operational checks:
Confirm local caching and offline fail-safe behavior through a documented test, not a vendor claim.
Ask for sample directory sync logs and how failed syncs are flagged.
Request the escalation path and response times for support issues.
Clarify the update cadence for firmware and software, and who is responsible for applying it.
Commercial evaluation matters just as much. Ask whether pricing is per door, per user, or bundled as a managed service, and get a total cost of ownership figure that includes hardware, licensing, and support rather than a software-only quote. Watch for red flags: a vendor with no published security posture, hardware that only works with their proprietary ecosystem, or vague answers about where data lives. NSI ICP 30 also sets out planning and maintenance expectations worth checking against any proposed installation plan, including logging and maintenance record obligations.
Cost shapes and what drives return on investment
Cloud access control pricing generally falls into a few recognizable shapes: per-door licensing, per-user licensing, a blended hardware-plus-SaaS subscription, or a fully managed service fee that bundles support and maintenance.
What pushes the total cost up or down:
Number of doors and sites, since most licensing scales directly with footprint.
Integrations required, such as HR systems or building management platforms, which can carry setup or connector fees.
Service level and support tier, including whether you need guaranteed response times.
Customization, like bespoke reporting or non-standard hardware compatibility.
The return on investment case usually comes down to fewer on-site visits for admin changes, faster provisioning when staff join or leave, and centralized visibility across multiple buildings instead of separate local systems that nobody checks consistently.
How an IT and security integrator approaches these projects
When we take on a cloud access control project, the process starts with an audit of existing infrastructure and network readiness, not a hardware catalog. That groundwork shapes decisions on data residency, security posture, and whether a cloud-native or hybrid architecture suits the site better.
From there, the typical workflow moves through architecture planning, deployment with local caching built in from the start, and a testing phase that includes simulated outages before handover. Our cloud migration and IT audit work and Ajax-certified installation experience both feed into this, since access control sits at the intersection of networking and physical security rather than belonging cleanly to either.
Whichever provider you work with, ask for architecture diagrams, test reports, and references before signing anything.
— Andrii
Getting started with cloud access control support
We combine cloud migration and IT audit work with installation services, which means a single point of contact for both the network side and the physical security side of a cloud access control project.
If you are planning a new installation or weighing whether to migrate an existing system, our Access Control & Physical Security Systems page outlines what we install and support, and our Cloud Migration & IT Audit service is the right starting point if you need an infrastructure review first. Whoever you choose to work with, keep requesting vendor security documentation and offline fail-safe proof before you commit.
FAQ
What are cloud access controls?
Cloud access control systems manage door permissions, credentials, and schedules through a remote console, while readers and controllers remain installed on site. Administrators add or remove access from any browser instead of updating a local server.
What are the best cloud-based access control systems?
The best fit depends on your number of sites, connectivity reliability, and integration needs rather than a single universal answer. Look for a vendor with a published response to the NCSC Cloud Security Principles, confirmed offline fail-safe behavior, and licensing that matches your site count.
What are the four types of access control?
Common models include role-based access control, discretionary access control, mandatory access control, and attribute-based access control, each defining permissions differently. Role-based control, which assigns access by job function, is the model most cloud platforms use by default.
What are the four types of cloud security?
Cloud security generally covers identity and access management, data protection, network security, and governance or compliance controls. NIST SP 800-210 focuses specifically on the access control piece across IaaS, PaaS, and SaaS layers, noting that guidance for lower layers typically extends upward.
Sources
Recommended
Comments