Onsite hardware keeps the physical enforcement layer at the facility, while cloud service delivery moves administration, updates, and server functions into a managed environment. In practice, that means doors and devices still operate locally, but policy changes, monitoring, and maintenance are handled through the cloud. The distinction is mainly about where control and operational burden sit.
How onsite hardware and cloud software split the control plane
Access control hardware that stays onsite keeps the decision point close to the door, panel, or reader. Cloud-delivered access control shifts the administrative plane into a managed service, so updates, schedules, user changes, and reporting are handled remotely. The practical difference is not whether the door unlocks locally, but where policy is authored, stored, and maintained.
Onsite systems usually preserve more local autonomy if the internet link fails, because the facility can keep enforcing cached rules and device logic. Cloud systems trade some of that local independence for easier central management, faster policy rollout across sites, and less server maintenance at the edge.
What changes operationally when access control moves to the cloud?
The biggest operational change is who carries the burden of maintenance. With onsite hardware, the owner typically manages firmware, controllers, backups, and patching. With a cloud service, the vendor or provider manages more of the software stack, while the customer focuses on configuration, users, and governance of access policy.
This also changes how change control feels in day-to-day use. In a cloud model, policy updates and event visibility can be faster to distribute across multiple locations, and administrators can often manage the system from anywhere. That convenience matters most when an organisation needs centralized oversight across many doors, buildings, or distributed teams.
The trade-off is dependency. A cloud model introduces reliance on the provider platform, the network path, and the account used to administer it. Onsite hardware reduces some of that dependence, but it also tends to make remote management, scaling, and cross-site standardisation more manual.
Why the distinction matters for resilience, governance, and security
The answer is partly architectural and partly risk-based. Onsite hardware can reduce exposure to service outages outside the facility, but it can increase the burden of local maintenance and patch discipline. Cloud access control can simplify administration, but it concentrates trust in the provider, the administrator account, and the internet-connected management plane.
That is why identity and authorization become more important in cloud-managed systems: whoever can log into the service can often change policy across many devices at once. In onsite deployments, compromise may be more physically or locally bounded; in cloud deployments, a single account or token issue can have broader operational reach. For general guidance on access decisions and least privilege, see the Authorisation Models Guide and the Privileged Access Management Guide.
Security teams should also distinguish availability from control. Local hardware may keep doors functioning during a cloud outage if rules are cached, but that does not remove the need to secure administrative access, firmware updates, and audit logs. Cloud service delivery can improve observability and central control, but it raises the consequence of misconfiguration or account compromise because policy changes can propagate quickly.
How to choose between onsite and cloud-managed access control
The right choice usually comes down to governance, scale, and tolerance for external dependency. A single site with strict local continuity requirements may prefer onsite control. A multi-site organisation that values centralized policy, easier updates, and unified reporting may prefer cloud service delivery.
What to verify: check whether the system can keep enforcing critical door rules during a network or provider outage, how configuration changes are authenticated, and whether logs are retained in a way your security team can actually review. If the cloud platform is used, make sure administrative access is separated from everyday user access and that emergency procedures still work if the service is unavailable.
What good looks like: the facility keeps local enforcement where it matters, while the management layer is simple enough to govern, audit, and recover. The most common mistake is treating cloud-managed convenience as if it were a full replacement for local resilience, or treating onsite hardware as if it eliminates the need for software lifecycle management.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Cloud and onsite access control both depend on who can administer users and permissions. |
| IA-5 — Authenticator Management | The choice changes how credentials and admin access are issued, rotated, and protected. | |
| CP-2 — Contingency Plan | Onsite versus cloud changes outage handling and offline enforcement expectations. | |
| Recommendation — Define and review administrative accounts and permissions for access-control systems. Protect and rotate credentials used to manage the access-control platform. Document offline operation and recovery steps for access-control outages. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The subject is fundamentally about where access control policy is managed and enforced. |
| A.8.2 — Privileged access rights | Administrative access to cloud-managed access control must be tightly limited and governed. | |
| Recommendation — Set and enforce access-control rules for the chosen deployment model. Restrict privileged administrative access to the access-control platform. | ||
Practitioner Guidance
What to prioritise: decide first whether your dominant requirement is local continuity or centralized administration. If door operation must survive WAN or provider disruption, insist on a design that preserves local enforcement logic and clearly defines offline behaviour.
Decision rule: if the system will be managed by multiple sites or a small central team, cloud administration usually improves consistency; if the facility has constrained connectivity, strict availability needs, or a low tolerance for third-party dependency, onsite control is easier to contain operationally.
What to verify: confirm who owns firmware updates, credential administration, audit retention, and emergency access procedures. In cloud-managed deployments, the security of the admin path matters as much as the door hardware itself.
Practitioner takeaway: the control plane is the real boundary, not the reader on the wall; choose the model that best matches your resilience needs, then prove you can still govern access when the network, provider, or admin account is unavailable.
Related resources from NHI Mgmt Group
- What is the difference between JIT access and Zero Trust for NHIs?
- What is the difference between service metrics and control metrics in ticketing software?
- What is the difference between a managed AI service and a control plane over your own cloud?
- What is the difference between temporary credentials and standing credentials in cloud access control?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
