Avigilon Alta (Openpath) & 56-bit Cards Explained

Avigilon, Motorola Solutions and the Alta / Openpath Platform

Avigilon was founded in Vancouver in 2004 as a video-surveillance specialist and entered the access-control market with a hardware ecosystem built around its own proprietary card format. Motorola Solutions acquired Avigilon in 2018, folding its physical access hardware, analytics cameras and management software into Motorola's broader public-safety and enterprise-security portfolio. The Avigilon brand now covers door controllers, readers, management software (Avigilon Unity) and the credential formats those readers accept.

In 2021 Motorola acquired Openpath, a California-based startup that had built a reputation for cloud-managed, mobile-first access control aimed at modern commercial offices. Motorola rebranded the Openpath platform as Avigilon Alta, positioning it as the cloud-native complement to the legacy on-premises Avigilon Unity line. Both platforms share a reader estate and both accept physical credentials — but Alta's architecture is designed around smartphone-based unlock as the primary method, with physical cards and fobs as a supported secondary option. That distinction matters when you need to order replacement physical credentials for an Alta installation, because the procurement path differs from a traditional on-premises Avigilon deployment. The Managed and Cloud Access category covers additional cloud-platform brands that follow similar mixed physical-mobile credential models.

Understanding which generation of Avigilon infrastructure a site runs — legacy Unity hardware, Alta cloud-managed, or a hybrid of both — determines which credential type you need to source. A facility running decade-old Avigilon RP40 readers requires a different credential than one running Alta's Wave2 readers, even if both are nominally "Avigilon" sites.

The 56-Bit Avigilon Wiegand Format Decoded

The most common physical credential in legacy Avigilon installations uses a proprietary 56-bit Wiegand data structure. Wiegand, as a protocol, transmits a fixed-width binary payload from card to reader over two signal lines; the bit-width and internal field layout are vendor-defined, which is exactly where Avigilon diverges from the standard 26-bit H10301 format used by most generic proximity cards. The Avigilon 56-bit frame carries a multi-digit facility code, a card number, and leading and trailing parity bits arranged in a pattern that Avigilon readers are programmed to decode. For a thorough explanation of how proprietary bit widths differ from the industry standard, see The Complete Wiegand Format Guide.

The 56-bit format operates at 125 kHz on a standard low-frequency proximity carrier — the same frequency as HID 26-bit, Indala, and most other first-generation prox credentials. What makes it a narrowly available format is the specific bit arrangement: Avigilon never published the frame structure publicly, and relatively few third-party encoder profiles include it. That scarcity creates problems for facilities managers who need to provision additional cards or replace lost credentials without going back through the Avigilon or Motorola channel. Compatible 56-bit credentials are reproduced on T5577 or EM4305 LF chips, which are configurable writable substrates widely used in the compatible-credential industry for exactly this kind of proprietary-format reproduction.

When sourcing compatible credentials for a legacy Avigilon site, the facility code and starting card number must be provided accurately — or a sample card must be submitted — so the format can be matched precisely. Wiegand readers perform a parity check on the incoming data; a credential with incorrect parity or an incorrect bit-count will produce a read error rather than an access denial, which is a useful diagnostic signal when verifying compatibility on a test reader. Other cloud-era platforms with similarly narrow Wiegand variants include Kastle Systems 32-bit and Lenel 42-bit compatible proximity cards — each requiring format-specific encoding rather than a generic 26-bit substitute.

Physical Credentials vs Mobile Credentials in Avigilon Alta

Avigilon Alta was designed to make the smartphone the primary access credential. When a user is enrolled in the Alta cloud platform, they receive a mobile credential delivered via the Openpath (Alta) app, which communicates with Alta readers using Bluetooth Low Energy and, on supported hardware, ultra-wideband. The reader grants access after verifying the mobile credential against the cloud-managed access policy. For this class of credential there is nothing to produce physically — the credential lives in the user's phone and is provisioned entirely through the Alta management portal.

Physical cards and fobs remain a first-class option in Alta deployments for users who prefer not to use a phone, for visitor credentials, and for facilities where smartphone use is restricted. Alta-issued physical cards at the HF layer use NXP DESFire technology — genuine NXP DESFire silicon with AES encryption — enrolled directly by the Alta system using its own key set. Because the DESFire credential is issued and enrolled by the Alta platform itself, a compatible supplier provides a compatible blank DESFire credential that the customer's Alta system then enrols with its own cryptographic keys. This is the correct procurement model for Alta HF cards: the supplier delivers the blank substrate; the platform provisions the credential. For context on how this compares to the genuine-vs-compatible question more broadly, Compatible vs Genuine Access Cards: An Honest Buyer's Guide covers the distinction in detail.

Some Alta installations also support legacy LF Wiegand credentials at the reader level, particularly on sites that have retained older door hardware or where Alta has been layered onto an existing Avigilon Unity infrastructure. In those environments a 56-bit LF credential will continue to work at readers configured to accept it, giving facilities a practical mixed-format estate where both LF and HF physical credentials coexist alongside mobile access. Comparable mixed-credential deployments appear in platforms like Verkada and Brivo, both of which issue physical credentials alongside app-based access.

Encoding a Compatible Avigilon Card

Producing a compatible Avigilon 56-bit credential requires three inputs: the correct bit-frame template, the facility code in use at the site, and the card number range to be issued. The bit-frame template defines how the binary payload is laid out — field widths, field order, and parity algorithm. Because the Avigilon 56-bit template is not a publicly standardised format, encoding is performed using proprietary profiles developed from analysis of genuine credentials. The encoded data is written to a T5577 or EM4305 chip at 125 kHz, after which the card presents identically to an original Avigilon credential at the reader antenna.

For Alta DESFire credentials, the process is different. A compatible Avigilon Alta compatible card is supplied as a compatible blank carrying genuine NXP DESFire EV2 or EV3 silicon in the correct memory configuration. The blank is not pre-personalised — it arrives without Avigilon-specific application data or keys. The customer's Alta administrator imports the blank card's UID into the Alta management console and enrols it as a new credential, at which point the platform writes its own application structure and keys to the card over the air or via the Alta encoder. This keeps the cryptographic key material entirely within the customer's system and under their control.

Identification of the format in use on an existing site is a prerequisite before ordering. If you have an existing credential, How to Identify Your Access Card or Key Fob Format provides a step-by-step method using a smartphone NFC reader or a handheld analyser. For 125 kHz cards, the chip type and modulation are readable without any destructive process. If no existing credential is available, the reader model and the installed software version together confirm which credential type the site accepts.

Ordering Compatible Avigilon Credentials

Compatible Avigilon credentials are available in both the 56-bit LF proximity format and as compatible DESFire blanks for Alta HF deployments. For the LF format, minimum order quantities are modest — small top-ups for a few lost cards are as practical as a full batch replacement — and lead times reflect the fact that each order is encoded to the specific facility code and card number sequence you provide. The Wiegand Bit-Format Cards range covers the full spectrum of proprietary Wiegand variants supplied by Security ID Systems, including formats from comparable cloud-managed and enterprise platforms.

Alta DESFire blank credentials are supplied in standard ISO CR80 card form factor and as 30 mm key fobs, matching the form factors Avigilon uses for its own issued credentials. Order quantities start at single units for testing through to bulk batches for large tenant fit-outs. Facilities that run multiple access platforms across a campus — for instance, Avigilon alongside DMP proximity cards or ATS Aritech 32-bit credentials — can consolidate credential sourcing through a single supplier rather than managing separate OEM channels for each format.

To place an order or confirm compatibility for your specific Avigilon installation, contact the Security ID Systems team with your reader model, the credential type (LF 56-bit or HF DESFire), and, for LF orders, the facility code and card number range. For Alta DESFire orders, the reader generation (Wave1 or Wave2) helps confirm the correct DESFire EV version and memory layout. The Office Building and Commercial Tenant Access Cards solution page covers the broader commercial tenant credential supply context for multi-floor and multi-tenancy sites where Avigilon and Alta installations are common. Security ID Systems is an independent manufacturer and supplier of compatible access-control credentials and is not affiliated with, authorized by, or endorsed by Avigilon, Motorola Solutions, or Openpath.