Access control architectures split cleanly along where the software and credential database live: on a local server inside the building, or on remote infrastructure managed by a third-party provider. On-premise systems keep hardware, software, and access event data inside the facility, with the owner's IT team responsible for patching, backups, and uptime [S6]. Cloud-based access control (often called access control as a service, or ACaaS) hosts the management software and event database on remote servers reached over the internet, and exposes administration through a browser or mobile app [S1][S2].
The cost gap between the two is large enough to be the first spec number a procurement team should pin down. Cloud deployments typically run $5 to $50 per user per month depending on feature tier, while on-premise systems for mid-sized companies start at roughly $500,000 in initial setup before adding ongoing maintenance and licensing [S8]. For a 200-employee site, that translates to a five-figure first-year cloud bill against a six-figure capital purchase for the equivalent on-premise stack, before IT labor is counted.
Where Each Architecture Fits the Compliance Brief
On-premise access control keeps authorization data, event logs, and the system of record physically inside the organization's network perimeter, which is the only architecture that satisfies environments where data cannot leave the building [S2][S9]. Government facilities, defense-adjacent operations, public safety sites, critical infrastructure, and energy and utilities are the recurring examples cited for this requirement [S1][S2]. In these cases, the decision is effectively pre-made by regulation, and the engineering question becomes one of server sizing, redundancy, and lifecycle cost rather than architecture choice.
Cloud-based access control is the right architecture for multi-site operators, fast-growing tenants, and any facility that cannot justify a dedicated security IT headcount. Administrators can add or revoke credentials, change schedules, and pull event logs from any internet-connected device, and the provider carries the patching, backup, and disaster-recovery burden [S1][S5]. The single hard dependency is the WAN link: if internet access drops, the local readers and electronic locks still release on cached credentials, but remote administration and real-time event reporting pause until connectivity returns [S4][S5].
Decision Matrix: Five Criteria Side by Side
The two architectures trade off against five criteria that map directly to an engineering spec sheet, and the answer changes by site type: [S3]
1. Upfront cost. On-premise requires capital for servers, software licensing, and a control cabinet, typically $500,000 or more for a mid-sized company before installation labor [S8]. Cloud replaces that with a monthly or annual subscription, lower at entry, but compounding over a typical 7 to 10 year refresh cycle [S4][S5].
2. Data sovereignty. On-premise stores every credential, badge event, and alarm on local hardware under the owner's direct control [S1][S2]. Cloud stores the same data on the provider's servers, with the regulatory acceptability of that arrangement dependent on the certifications the provider holds, for example ISO 27001 for information security management [S2].
3. Scalability. Cloud platforms add new doors, users, or sites through software configuration, with no new hardware required at the building [S1][S5]. On-premise scaling requires purchasing and racking additional server capacity, then bringing it under the same management software [S3][S4].
4. Maintenance and patching. On-premise updates are scheduled and executed by internal IT staff, with downtime risk falling on the owner [S3][S4]. Cloud updates are pushed by the provider on a regular cadence, with no customer downtime window, but the customer loses the ability to delay or skip a release [S1][S4].
5. Resilience. On-premise uptime is bounded by the local server stack, UPS, and HVAC; a single failure can take the system down until hardware is replaced [S3]. Cloud uptime rides on the provider's data center redundancy, typically expressed as a published SLA, with the local side protected by cached credentials on the door controllers [S2][S4].
For a regulated single-site critical-infrastructure operator, the matrix points to on-premise. For a retail or property-management group with 20 to 200 sites and a thin IT bench, the matrix points to cloud. The interesting engineering cases sit between those poles.
Hybrid Deployments: When One Door Cannot Be Cloud and the Next Must Be On-Premise
Hybrid-cloud access control centralizes multi-site management on a cloud platform while keeping specific doors, panels, or data sets on a local server, and this is now the most common architecture in organizations that span both regulated and commercial real estate [S1][S9]. The implementation pattern is to let the cloud platform federate across both cloud-managed and on-premise-managed doors from a single administrative interface, so the operator gets unified reporting without forcing a uniform data-residency posture on every site [S1].
This is also where the audit trail retention question becomes load-bearing. The detailed comparison in access control audit trail retention shows that retention floors vary by jurisdiction and by the data classification of the controlled area, which is why some badge events can live in the cloud and others must stay on a local archive. Engineering teams specifying a hybrid stack should resolve the per-door data-classification map before they commit to a single vendor's cloud-only or on-premise-only product line.
Infrastructure Footprint: What Disappears From the Building When You Go Cloud
Moving from on-premise to cloud removes the dedicated access control server, the rack space it occupies, the UPS feeding it, the cooling load on the room, and the dedicated network segment that isolated it from corporate IT, with only the door controllers, readers, and electronic locks remaining at the building [S3][S6]. That is a meaningful reduction in the control cabinet footprint for smaller sites, and it is one of the cleaner engineering cases for cloud: a 200 m² tenant space that previously needed a half-rack of security hardware can be served by a single PoE-powered door controller and a cloud tenant license.
The trade-off is that the control cable between the reader, the door controller, and the lock stays exactly the same in either architecture, so the bulk of the field installation cost is identical. The savings show up in the head-end, the server room, the IT staffing, and the software update path, not in the cabling or the hardware mounted on the door.
Identity Stack and Adjacent Systems
Both architectures still depend on the same identity and access management primitives: a unique credential per user, a policy that defines which doors that credential opens, a schedule, and an audit log of every access decision [S4]. The National Institute of Standards and Technology frames identity and access management as ensuring that the right individuals reach the right resources at the right times and for the right reasons, and that definition does not change with deployment model [S4].
Where they diverge is in how the management plane integrates with adjacent systems. A cloud-based access control platform typically exposes REST APIs and supports federation with cloud identity providers, which is the cleaner integration path for SaaS-heavy tenants. An on-premise platform is usually the better fit when the serial server connecting to legacy intrusion panels, elevator controllers, or PSIM consoles must stay inside the facility for latency or security reasons. The decision is rarely about access control alone; it tracks the broader IT modernization plan.
What to Specify in the Procurement Document
Engineers writing a spec for a new access control build should pin down five numbers before vendor selection: the number of doors and readers, the peak concurrent credential count, the retention period for badge events, the maximum tolerable administrator-action latency, and the recovery time objective for the management plane. Cloud platforms typically meet sub-second administrator latency and offer retention configurable from 90 days to multi-year tiers; on-premise platforms meet the same latency target but require the customer to size storage and backup windows against the same retention number [S1][S3][S4].
The verification step after deployment is identical in both architectures: pull a randomized sample of access events, confirm the audit log shows the credential, the door, the timestamp, and the decision, and confirm the retention policy is enforced on the storage layer. That test passes or fails on the storage implementation, not on whether the management plane is in the building or in someone else's data center.
The architecture decision for the next 12 to 24 months will track three signals: how aggressively the customer's IT organization is moving off local server hardware, whether new regulations expand or narrow the list of sites that must keep access data on premise, and whether the customer is standardizing on a single multi-site management console or allowing per-region autonomy. Sites whose regulatory posture is already firm on data sovereignty should keep on-premise; sites whose posture is still evolving should plan a hybrid deployment from day one rather than redesign it after a first cloud-only pilot.