Verkada access control explained for multi-site building security

a[data-rs-seo-link]{text-decoration:underline!important;color:#1a56db!important;cursor:pointer!important;}a[data-rs-seo-link]{text-decoration:underline!important;color:#1a56db!important;cursor:pointer!important;}

What Verkada access control is

Verkada access control is a hybrid-cloud physical access control system for managing doors, users, credentials, schedules, events, and connected security workflows through Verkada Command. In practice, it is most relevant to organizations that want centralized administration across multiple facilities without maintaining traditional on-premises access control servers.

It should still be evaluated as a building security platform, not as software alone. A working deployment depends on door hardware, readers, locks, sensors, power, network design, emergency egress, and life-safety compliance. Those site conditions often determine whether a design can be installed, approved, and operated safely.

This guide explains how Verkada access control is structured, what changed in the product line during 2026, where the system may fit, and what buyers should verify before specification. For broader context on electronic door security and related technologies, see our Access Control coverage.

How the system is put together

Verkada describes its access control architecture as hybrid cloud. Verkada Command is the cloud management layer, where administrators manage users, doors, schedules, credentials, alerts, events, and permissions. The field layer includes access controllers, readers, locks, door position indicators, request-to-exit devices, and other inputs or outputs installed at the building.

Current Verkada controller materials list several models for different door counts and applications. The AC12 is positioned for one-door deployments, the AC43 for four-door deployments, the AC62 for larger sixteen-door deployments, and the AX11 for input-output and elevator-related applications. Some older product overviews refer to the AC42 in the four-door position, so project teams should confirm the current model, region, and part number before purchase or bid submission.

A typical electronic access-controlled door includes a credential reader, a locking device, a door position input, and a request-to-exit input. Verkada help materials describe a door as a configured set of components connected to a Verkada controller. That distinction matters because the access decision is only one part of a working opening. The electric strike, maglock, crash bar, power supply, fire alarm interface, egress hardware, and authority-having-jurisdiction requirements can all affect whether the installation is safe and code-compliant.

Readers and credentials are where Verkada has expanded most visibly. Public product materials describe support for physical cards and fobs, Verkada DESFire EV3 credentials, Apple Wallet, Android NFC, Bluetooth unlock through the Verkada Pass experience, PIN options on keypad readers, license plate recognition unlock in supported video workflows, and face unlock on the AF64 Access Station Pro where enabled. Compatibility can vary by reader generation, credential license, geography, and deployment policy, so credential planning should take place before readers are ordered.

What changed in 2026

Verkada’s 2026 access control updates point to a clear product direction: more mobile administration, more flexible credential migration, more resilient wireless locks, and more operational tools for emergency and temporary access workflows. The timeline below summarizes notable publicly listed updates and why they matter to security teams.

The practical takeaway is that Verkada is not treating access control as a static badge-and-door product. Recent updates focus on daily operations: who can make changes, when doors change state, how visitors receive temporary access, how wireless locks remain usable, and how door actions appear inside a broader command center view.

Strengths for security, IT, and facilities teams

The main appeal of Verkada access control is centralized administration. Multi-site organizations often struggle with local access databases, VPN-dependent management tools, inconsistent card policies, and slow user deprovisioning. A cloud-managed platform can reduce that friction by giving authorized administrators one interface for sites, doors, schedules, groups, credentials, and events.

Another strength is the native relationship between access control and other physical security functions. Verkada’s public access control materials emphasize links with video security, alarms, visitor management, intercoms, and license plate recognition. For an operator investigating a forced-door event or tailgating alert, the value is not simply that a door event exists. It is that the event can be reviewed with visual context and related activity from the same platform.

Credential choice is also important. Many buildings cannot replace every card, reader, tenant credential, and badge-printing process at once. The 2026 EV3 Multi-Technology Card update is notable because it addresses a common migration problem: organizations may need to support more secure credentials while still operating legacy proximity use cases during a transition. This does not remove the need for a credential audit, but it can make phased modernization more realistic.

Reliability features matter because doors must operate even when network conditions are imperfect. Verkada controller materials describe local processing and storage, peer-to-peer communication for certain cross-device operations, and backup power options. The 2026 static cache update for wireless locks extends that theme to battery-powered openings by allowing a local backup credential list when the lock is disconnected from its controller. Buyers should still test outage behavior against their own topology, because offline access decisions, remote administration, event syncing, alerts, and lockdown behavior are different requirements.

For cybersecurity and governance, Verkada’s public security materials describe audit logs, role-based access, support-access controls, penetration testing, a vulnerability disclosure program, and SOC 2 Type 2 reporting. Government-grade materials also discuss TAA and FY2019 NDAA compliance, FIPS 140-2 encryption on designated access controllers, PIV card authentication on designated readers, and AWS GovCloud options. Procurement teams should verify the current compliance status, hosting environment, and exact hardware suffix for any regulated deployment rather than assuming every Verkada access product carries the same designation. See also: Alarm and Detection.

Limitations and questions to verify before specification

Verkada access control is not automatically the right fit for every facility. Its main architectural tradeoff is ecosystem dependency. If an organization prefers open controller hardware, a Mercury-based architecture, a self-hosted access control server, or deep customization across many third-party systems, a cloud-managed unified platform may feel restrictive. Organizations that value centralized administration and reduced server maintenance may view that same ecosystem approach as an advantage.

Reader communication deserves specific attention. The Security Industry Association describes OSDP as a modern reader-to-controller standard intended to improve interoperability, cybersecurity, and device management compared with legacy Wiegand. SIA also notes OSDP Secure Channel encryption and the standard’s international publication as IEC 60839-11-5. In the field, however, secure communication depends on the devices selected and how they are configured. A project should verify whether each reader path uses Wiegand, OSDP, or OSDP Secure Channel, and whether the intended credentials are cryptographically stronger than legacy proximity numbers.

Door hardware is another frequent source of project risk. A controller specification does not confirm that a maglock, electric strike, electrified exit device, power supply, fire alarm relay, and egress arrangement are suitable for a specific opening. Access control work intersects with building code, fire code, disability access, tenant rules, and local inspection practice. Any deployment should include a qualified integrator and, where required, review by the authority having jurisdiction.

Biometric and video-related features should be evaluated with privacy in mind. Face unlock, video-linked access events, visitor records, mobile credentials, and audit logs can improve security operations, but they also create policy obligations. Organizations should define who can view events, how long records are retained, how consent is handled, how exceptions are approved, and how access is revoked when an employee, contractor, student, or tenant leaves.

Finally, verify licensing and lifecycle cost. Verkada Command access generally depends on active licensing for products, and advanced credential or platform features may require specific licenses. Hardware cost, software term, credential cost, installation labor, lock power upgrades, network changes, cellular backup, training, and future expansion should be compared as total system cost, not as controller price alone.

Evaluation checklist for a Verkada access control project

Frequently asked questions

Is Verkada access control cloud based?

Yes. Verkada access control is managed through Verkada Command, a cloud-based platform. Verkada describes the architecture as hybrid cloud because controllers and locks also perform local functions at the edge, including access decisions based on stored configuration in supported outage scenarios.

Can Verkada access control keep working during an internet outage?

Verkada materials describe local processing, local storage, and peer-to-peer communication for certain controller operations. Wireless lock updates in 2026 also added local backup credential caching for disconnected locks. However, each organization should test its own outage scenarios because local door operation, remote administration, alerts, and event synchronization are different capabilities.

What credentials does Verkada support?

Public Verkada materials describe support for physical cards and fobs, DESFire EV3 credentials, Bluetooth through Verkada Pass, Apple Wallet, Android NFC, PINs on keypad readers, license plate recognition unlock, and face unlock on supported devices. Compatibility depends on reader generation, licensing, device region, and deployment configuration.

Can Verkada use existing readers and cards?

In some cases, yes, but this needs verification. Verkada documentation discusses compatibility with Wiegand and OSDP-based readers and with a range of credential types. Existing low-frequency proximity cards may support continuity, but they may not meet modern security goals. A migration plan should separate short-term compatibility from long-term credential security.

Is Verkada access control suitable for regulated or government environments?

It may be suitable for some regulated deployments, particularly where designated government-grade hardware, AWS GovCloud options, PIV support, and documented security controls align with procurement requirements. Teams should verify current certifications, FedRAMP status, hardware suffixes, hosting region, data governance, and contractual terms before specifying the system.