Cloud-managed access control, explained for IT directors

Most of our access control projects in Orange County now involve someone from IT, and that is an improvement. The systems have moved onto the network, the credentials are tied to the directory, and the failure modes look more like IT failure modes than locksmith ones. But the sales material for these platforms is written for facilities buyers, so the questions IT actually asks, about architecture, segmentation, and offboarding, tend to go unanswered until the install is already scheduled.

This is the briefing we wish we could hand every IT director before the first meeting. We install PDK, Brivo, and Verkada, with PDK (ProdataKey) being our most common install, and the architecture described below applies to all three with minor differences we will flag as we go.

Architecture: what runs where

"Cloud access control" undersells how much of the system is not in the cloud. There are three layers:

• Readers and door hardware. The reader at the door, the electric strike or maglock, the request-to-exit sensor, the door position switch. Dumb by design, wired back to the controller.
• The edge controller. A panel in your IT closet that holds a local copy of the credential database and schedules, and makes every grant-or-deny decision on site. On PDK this is the Cloud Node; Brivo and Verkada have their own equivalents. This is the piece that actually runs your doors.
• The cloud management plane. Where admins live: user management, schedules, reports, alerts, the mobile apps, the API. It pushes configuration down to the controller and receives events back up.

The division of labor matters most when the WAN drops. Because the controller decides locally, an internet outage changes nothing at the door: badges still work, schedules still run, exit hardware still releases. The controller queues events and syncs the log when the connection returns. What you lose during the outage is management, meaning you cannot add a user, remotely unlock a door, or watch events live until the WAN is back. PDK documents this behavior explicitly, and Brivo and Verkada behave the same way. Any platform that cannot make offline decisions at the edge should come off your shortlist immediately, and yes, a few of those still exist at the cheap end of the market.

One consequence worth internalizing: a credential revoked while a site is offline is not actually revoked at that site until the controller reconnects. For most companies that window is minutes a year and irrelevant. If you are terminating someone hostile, check that the site is online first.

Network requirements

The network footprint is smaller than people expect. Here is what we ask of an IT team on a typical install:

• One or two switch ports per controller, not per door. Readers connect to the controller over dedicated low-voltage wiring, not Ethernet, so a 12-door building might touch your network in exactly one place.
• A dedicated VLAN. Put the controllers on their own segment with an egress rule allowing only the vendor's published domains and ports, plus DNS and NTP. No route to your server VLAN, no route from guest Wi-Fi. Every platform we install publishes its firewall whitelist; PDK's is on their support site, and we hand it to your network admin before install day.
• Outbound-only connectivity. The controller initiates a persistent outbound TLS connection to the cloud and all management traffic rides that tunnel. There is no inbound port forwarding, no DMZ host, no dynamic DNS. If a vendor asks for an inbound rule to reach the panel, that is a legacy on-prem product wearing a cloud costume, and it is our single fastest disqualifier.
• PoE budget, if applicable. Some controllers and most modern intercoms and wireless-lock gateways are PoE or PoE+ powered. Count the watts before install day: a switch that is already feeding cameras and APs at 80 percent of budget does not need three more class 4 devices surprise-added to it. Door lock power itself should come from dedicated battery-backed supplies, not PoE.
• Almost no bandwidth. Events and database syncs are tiny. Cellular failover carries an access system fine, which is a cheap way to keep management alive during a wired outage.

OSDP vs. Wiegand at the reader

The wire between the reader and the controller is the part of the system most buyers never ask about, and it is where a lot of older installs are quietly indefensible. The legacy standard is Wiegand, a one-way, unencrypted protocol from the 1980s. Card data crosses that wire in the clear, the controller cannot supervise the reader, and a device planted behind the reader plate can skim every credential presented. Distance tops out around 150 meters and there is no way to know a reader has been tampered with until someone notices physically.

The replacement is OSDP, an open standard maintained by the Security Industry Association. It is bidirectional, supervised, runs over RS-485 to about 1,200 meters, and in Secure Channel mode encrypts reader-to-controller traffic with AES-128. Supervision means the controller notices when a reader drops or is tampered with. That is the difference between finding out at 2 a.m. from an alert and finding out never.

What to actually specify: OSDP-capable readers on every new door, and Secure Channel turned on, not just supported. OSDP hardware frequently gets installed with Secure Channel disabled because it is faster to commission that way, which buys you the new acronym with the old security. Put "OSDP Secure Channel enabled and verified" in the scope of work and make the integrator show you. On retrofits, existing Wiegand wiring can often be reused for OSDP since it is just copper, which keeps the upgrade cost in readers and configuration rather than walls and conduit.

Credentials: what to issue in 2026

The reader protocol protects the wire. The credential protects everything before it, and this is where the largest gap between "what is common" and "what is defensible" lives.

125 kHz prox cards are still the most common credential we see in Orange County buildings, and they are trivially cloneable. The card broadcasts an unencrypted ID with no authentication of any kind, and handheld cloners that copy one in seconds cost less than a tank of gas. From an IT lens, a prox card is a password written on the outside of the badge. They persist because they are cheap and because replacing a few hundred of them is annoying, not because anyone defends them on merit.

13.56 MHz smartcards, specifically MIFARE DESFire EV2 or EV3, are the current standard worth specifying. They do AES-based mutual authentication between card and reader, with diversified keys, and there are no publicly known practical cloning attacks against a properly implemented DESFire deployment. If you issue plastic, issue this, and avoid anything a vendor cannot name a cipher for.

Mobile credentials over BLE or NFC are the other defensible option and the one our customers increasingly default to. The credential lives in a phone protected by a lock screen and, on the platform side, revocation is immediate and remote. Phones also get reported lost faster than badges do. The practical caveats: some staff will refuse a work app on a personal phone, visitors and contractors still need something physical, and BLE read range needs tuning at doors where cars or hallway traffic pass close by. Every platform we install reads mobile and smartcard on the same reader, so a mixed population is the normal case, not a compromise.

On retrofits we often run old prox and new credentials side by side during migration, since multi-technology readers handle both. That is a transition state with a scheduled end date, not a destination. Our legacy migration guide covers the sequencing.

Directory integration and offboarding

This is the feature that justifies cloud access control to an IT department all by itself. Every terminated-employee physical security incident we have been called about had the same root cause: badge access was managed in a silo, and nobody deactivated it.

The major platforms all sync with your identity provider now, with different plumbing. Verkada does SCIM provisioning from Entra ID and other IdPs into Command, with users and groups mapped to access groups. Brivo's Identity Connector runs as a SCIM app in Entra ID, Okta, or Google Workspace and pushes creations, updates, deactivations, and group memberships into Brivo Access. PDK has a native Entra ID integration that syncs users and maps Entra groups onto pdk.io access groups, and it is free to enable on our installs.

Configured properly, the flow you want falls out naturally: HR terminates, the IdP account is disabled, the sync deactivates the person in the access platform, and the cloud pushes the revocation to every controller. Badge access dies within the sync interval, no ticket, no human in the loop. Three things to verify rather than assume, because this is where deployments quietly fail:

• The deprovisioning path, specifically. Every vendor demos user creation. Ask what happens on disable, on delete, and on group removal, and test each one during the pilot with a real test account.
• The sync interval. Directory syncs run on schedules, not instantly. Know the worst-case lag and keep a documented manual-revoke procedure for urgent terminations.
• Group mapping discipline. Access groups should map to directory groups you already govern. If door permissions get hand-assigned per person inside the access platform, you have rebuilt the silo with a nicer UI.

APIs and webhooks

The platforms are REST-first underneath, and the APIs are usable rather than decorative. Common things our customers build: door events streamed into a SIEM or Slack, occupancy and first-in/last-out reporting, visitor management tied to calendar invites, and lightweight provisioning glue where the native directory sync does not quite fit. Webhooks or streaming event subscriptions beat polling for anything alert-shaped, so ask whether the platform pushes events or makes you fetch them. Also ask what API access costs, because on some platforms it is included and on others it lives in a higher tier, and that is better discovered before the contract than after.

Vendor due diligence: the questions to ask

You would run security review on any SaaS vendor touching your building's front door. Run the same one here. The questions we think earn their place:

A vendor that handles these five in one meeting without checking with the home office is telling you something. So is one that does not.

Rollout: how to actually cut over

The install itself is our job rather than yours, but rollout shape is a joint decision, and the buildings that go smoothly all follow roughly the same sequence.

• Pilot one real door. Not a conference room: a door with actual traffic, usually a staff entrance or the IT closet itself. Run it for two to four weeks. Test directory sync, offboarding, offline behavior (unplug the WAN and badge in), alerting, and the admin experience for whoever will live in the console.
• Phase by zone, not by floor plan aesthetics. Perimeter doors first, since they carry the most risk, then interior high-value rooms, then convenience doors. Each phase is a complete, working system.
• Plan for coexistence. Mid-migration you will have two systems running, and multi-technology readers that accept old and new credentials make that survivable. Keep the legacy system's admin access alive until its last door is gone, and give coexistence an end date with an owner, because "temporary" dual systems have a way of turning three months into three years.
• Re-badge deliberately. Issuing new credentials to everyone is the tedious part. Tie it to the phase schedule, use the overlap window, and let the platform report on who has not activated yet rather than chasing people by spreadsheet.

For budgeting, per-door installed pricing and what moves it up and down is covered in our Orange County cost guide. The short version is that hardware and labor dwarf software, and the electrified door hardware is usually the biggest line, which is also why an access control installer who is vague about per-door hardware should worry you more than any software line item.

Monitoring and alerting

Treat the access system like any other production system: it emits events, and some of them deserve a pager. The ones worth wiring into your existing stack on day one are controller offline (your doors are now running blind on the last synced database), door forced open, door held open past threshold, and repeated invalid credential attempts at one reader. All three platforms can push these natively to email or mobile, and the APIs and webhooks get them into Slack, Teams, or a SIEM if that is where your team actually looks. If you run cameras as well, pairing door events with video of the same door is the single integration that makes 2 a.m. alerts resolvable from a phone instead of a drive to the site.

The system also deserves a spot in your ordinary IT hygiene: controllers in the patch and firmware review cycle, the admin console behind SSO with MFA, admin accounts reviewed with the same quarterly access review you already run, and battery-backed power supplies actually tested once a year. None of this is exotic. It is just applying the operational discipline you already have to a system that historically escaped it.

Where an integrator fits

Everything above is the part you can evaluate from a desk. The part you cannot is the door itself: strike vs. maglock, fail-safe vs. fail-secure, fire code and egress requirements, permits, and the wiring standards that separate a clean install from a service-call generator. That is our side of the table. We have been doing commercial security in Orange County since 1984, we install PDK most often and Brivo and Verkada where they fit better, and we are comfortable in the meeting where your network admin asks about egress rules, because that meeting is where good installs start.