Verkada Access Cards: Reader Compatibility and Enrollment
A third-party card can be suitable for a Verkada installation only when its technology and format are supported by the installed reader and approved for enrollment by the administrator. The software platform name alone is not a compatibility guarantee. Check the complete path from card to reader to controller before ordering.
American Key Cards is independent and is not affiliated with or endorsed by Verkada. This guide is informational; it does not offer Verkada-issued encrypted credentials or promise compatibility with an unverified installation.
Check the reader and controller separately
Verkada’s supported card formats sheet distinguishes controller support from reader support. It lists standard 26-bit Wiegand among the supported formats, but explicitly excludes HID® iCLASS®, Indala® and Kantech XSF cards from Verkada readers. Those technologies require an appropriate third-party reader, with an underlying format supported by the controller.
That distinction prevents a common ordering mistake: seeing a format in a platform’s compatibility list and assuming every reader connected to that platform can read it. A controller can process data that its branded door reader cannot obtain from a particular card.
Verkada’s AD33 data sheet is one example of a model-specific source. It describes low- and high-frequency credential support and an OSDP-based connection to the access-control unit. That controller connection is separate from the card’s radio technology. Neither a Wiegand bit count nor the word OSDP describes the complete card-to-reader security arrangement.
Three situations to distinguish
| Existing installation | What to verify before ordering |
|---|---|
| Legacy proximity credentials | The actual radio technology, supported format and authorized number allocation. |
| Verkada encrypted credentials | The required credential product and the approved Verkada provisioning path. A generic smart-card blank is not equivalent. |
| Third-party readers or integrated locks | The specific reader or lock model, its enabled technologies and the controller’s supported format. |
If the system is already configured for encrypted credentials, do not enable legacy proximity as a workaround for an incorrect purchase. Ask the administrator or integrator to preserve the intended security configuration and obtain the right credential instead.
An order checklist for the administrator
- Record the reader model at each relevant door, not just the access-controller model.
- Identify one working credential through its approved order record and configured credential type.
- Confirm the full encoding format, including facility code where that format uses one.
- Reserve unused identifiers and decide who will enroll the new users.
- Obtain a small sample and check the identity shown in access events, as well as permitted and denied doors.
For replacement of a lost card, disable the old credential through the site’s normal process. A newly purchased card has no authority to enter a building until its administrator assigns the appropriate access.
Keep the result with the next purchase order
Record the tested reader models, credential specification and approved supplier reference. This gives a future administrator something stronger than “these look like our old cards.” If a reader or lock is later changed, repeat the compatibility check for that location.
If you are evaluating legacy HID proximity credentials, the HID Prox security guide explains the replacement and migration questions to ask.