On-Premises vs Cloud Access Control: Comparing Solutions

Access control is one of the few systems in a building that everyone touches every day, and one of the few whose architecture is genuinely hard to reverse. The choice between an on-premises deployment and a cloud-managed one determines who holds the data, who carries the maintenance burden, and what happens on the day the internet connection drops. It deserves more analysis than it usually gets.

Both models are mature and both are defensible. The question is not which is better in the abstract, but which matches the organisation's risk profile, IT capacity, site count and budget structure.

What on-premises actually buys you

An on-premises system keeps controllers, server and credential database inside the building. The defining advantage is independence: when the internet fails, the system keeps making access decisions, because nothing it needs sits outside the building. For sites where a door that will not open is a safety or continuity problem, that alone can settle the argument.

It also keeps the data where the organisation's own policies apply, which matters in regulated sectors and in any environment where cardholder data cannot leave the premises.

Higher upfront capital cost for servers, controllers and licences
Requires in-house IT capacity for backups, patching and hardware replacement
Operates independently of internet connectivity
Data and credentials remain under direct organisational control
Software updates are a planned project rather than an automatic event

What cloud management changes

A cloud-managed system moves the management plane off-site. Well-designed platforms keep the door controllers making decisions locally against a cached credential set, so a connectivity loss degrades management rather than access. This is a question to ask a vendor explicitly rather than assume, because the failure behaviour varies significantly between products.

The economics are different in kind, not just in amount. Capital expenditure becomes operating expenditure, and the maintenance burden shifts to the provider. For an organisation running many small sites, the ability to manage them all from one console without a server at each location is often the deciding factor.

Lower entry cost, ongoing subscription instead of capital outlay
Updates and security patches handled by the provider
Scales across sites without additional server infrastructure
Introduces dependence on connectivity and on the provider's continuity
Data residency and privacy require contractual scrutiny, not just technical review

The questions that actually decide it

In practice the decision usually turns on a small number of concrete points rather than a general preference.

How many sites, and does each need independent local operation?
What happens to access decisions during an internet outage? Verify this behaviour, do not assume it
Is there in-house IT capacity to own patching and backup, honestly assessed?
Do regulatory or contractual obligations constrain where credential data may reside?
Is the budget structured for capital expenditure or operating expenditure?
What is the exit path if the vendor is acquired, raises prices, or discontinues the platform?

That last point is the one most often skipped. Credential data and door hardware are not trivially portable between platforms, and the migration cost is a real part of the total cost of ownership in either model.

What actually moves when you change platforms

Migration is not one problem, it is four, and they have very different costs. The physical door hardware (locks, strikes, magnets, request-to-exit devices, position switches) is almost always reusable. It is dumb hardware on dry contacts, and any controller can drive it. That is the cheap part, and it is the part vendors point at when they say migration is straightforward.

The reader-to-controller link is the first real constraint. Wiegand is a one-way protocol with no encryption and no supervision, and readers wired for Wiegand often need replacing to move to a platform that requires OSDP. OSDP over RS-485 supports encrypted, bidirectional communication and multi-drop wiring, but the cable topology is different: a daisy chain rather than a home run per reader. An OSDP migration in an existing building can therefore mean pulling new cable, not just swapping heads. Establish which protocol the current readers actually run, and whether the installed cable supports the alternative, before anyone quotes a migration.

Credentials are the second constraint, and the expensive one. A 125 kHz proximity card, a MIFARE Classic card and a DESFire EV3 card are not interchangeable, and the card number stored in one system is not necessarily readable in the format another expects. Where a site uses a proprietary or custom-keyed credential, the encryption keys may belong to the incumbent integrator rather than to the building owner. Ask who holds the keys, in writing, and get that answered before the first card is ordered.

Door hardware and wiring to the lock: usually reusable across platforms
Readers: reusable only if the new controller speaks the same protocol at the same voltage
Credentials: reusable only if card technology, format and keys are all available to you
Cardholder database: exportable in most systems, but photos, access levels and schedules often are not
Audit history: frequently the hardest item to move, and sometimes a retention obligation

Mobile credentials change this calculation rather than removing it. BLE and NFC credentials are issued by the platform, so they are inherently tied to it. A mobile-first deployment has no physical card stock to salvage, but reissuing to every user is a licensing and administrative exercise rather than a procurement one. Neither is free. Both should be costed before the platform is chosen, not after.

What to test in a proof of concept

Before committing to either model, run a small deployment on real doors with real users. Two or three doors will do, and one of them should be on the worst network segment in the building. A demonstration in a vendor's showroom proves nothing about how the system behaves on your infrastructure.

Pull the network cable at the controller and confirm which credentials still open the door, and for how long
Reconnect and measure how long offline events take to reappear in the audit log, and whether any are lost
Revoke a credential and time how long until the door actually refuses it, testing at the door rather than in the console
Test fire alarm interface and free-egress behaviour under a real panel signal
Export the cardholder database and the audit log yourself, and inspect the file format you get back
Confirm reader read range and read time with the exact credential you intend to deploy, not a demo card

The revocation test deserves emphasis. In a cached-credential architecture there is a window between revoking access in the console and the controller acting on it, and that window is a security property of the system. It ranges from seconds to hours depending on the platform and the connectivity, and the datasheet rarely states it.

To size the controller, reader and credential count for either architecture before you compare quotes, use our free Access Control Calculator

The hybrid middle ground

Many organisations end up somewhere between the two: local controllers that hold their own decision logic and credential cache, managed through a cloud console. This preserves offline operation at the door while removing the per-site server. It is often the right answer for multi-site deployments, and it is worth specifying deliberately rather than arriving at it by accident.

The key to choosing well is assessing the specific needs of the organisation while striking a balance between security and convenience. Weigh operational requirements, budget structure, IT resource availability and security policy. Then verify the failure behaviour of whatever you select before you commit to it.