Seenaptec 1.6.1: Wiegand system migration, secure card issuance, and standalone access without a server

Today marks the release of Seenaptec 1.6.1. The new version is available in the Seenaptec distributions section.

The main changes in this release focus on three areas: simplifying migration from existing access control systems without mass replacement of cards and readers, creating a single protected perimeter for MIFARE Plus and DESFire issuance and management, and expanding the autonomous capabilities of AGRG hardware in case of a lost connection to the server.

Migrating from existing Wiegand systems without replacing cards

Seenaptec 1.6.1 significantly expands support for existing Wiegand infrastructure.

For fully integrated AGRG hardware, it is now possible to configure the Wiegand frame length and define which transport bits must be excluded when forming the card code.

For AGRG ACM2 — an access point gateway designed to replace a traditional controller while retaining existing Wiegand readers and other peripherals — a separate format override mechanism is provided.

In Seenaptec, you can define the Wiegand frame structure, select the exact bit range that forms the card identifier, and immediately verify the result on an actually scanned card.

The practical purpose of this feature is not simply to expand Wiegand support, but to enable migration from a legacy access control system to Seenaptec without rebuilding the existing infrastructure.

Seenaptec can preserve the identifier interpretation already in use at the site. Therefore, migrating to the new platform does not require mass card re-issuance or replacement of the installed reader fleet just because of format differences.

For example, when migrating from Lenel-class systems that use HID iCLASS readers, the existing card code can be obtained in Seenaptec in the same form in which it is used in the live system. This allows modernization to begin with the server architecture and access points, without turning the project into a full replacement of identifiers and peripherals.

In the case of AGRG ACM2, Wiegand processing is performed by the device itself. Therefore, after installing Seenaptec 1.6.1, the ACM2 firmware must be updated. The required version is already included in the distribution.

MIFARE Plus and DESFire issuance directly from Seenaptec

Seenaptec 1.6.1 introduces a full-featured reader workstation with support for desktop USB readers, including PROX KC-MF-USB.

A local agent is installed at the operator's workstation, while all primary operations are performed directly through the Seenaptec web interface.

The workstation supports reading and writing protected cards, as well as their issuance, re-issuance, and initialization.

Seenaptec allows you to create profiles for protected MIFARE Plus and MIFARE DESFire cards, manage read and write parameters, and perform card issuance directly from the system interface.

For MIFARE Plus, personalization of cards from the factory state SL0 to SL1 or SL3 is supported, as well as a subsequent SL1 → SL3 transition.

But the fundamental change is not only that Seenaptec has gained its own card issuance capability.

Seenaptec combines card issuance and the configuration of the entire card-reading infrastructure within a single protected perimeter.

In a traditional Wiegand architecture with protected MIFARE cards, changing keys means physically reconfiguring readers. An initialization card or a card carrying the new key is produced, after which personnel must sequentially visit every access point and present it to each reader.

At a site with hundreds or thousands of readers, such an operation turns into a separate operational project.

This is especially critical when roles are split between the integrator and the customer. If installation and initial configuration are performed by a third-party organization and the customer then takes the system into operation, a separate question of ownership and trust in the security keys stored in readers arises.

When keys need to be changed or fully replaced, the classic architecture once again requires physically reconfiguring the entire reader fleet.

In Seenaptec, this model changes fundamentally.

Card profiles and keys are stored centrally in the platform's protected vault. The same profile is used both for card issuance and for configuring fully integrated AGRG devices.

The required parameters are delivered to devices centrally over a secure OSDP channel. Updating the configuration or rotating keys no longer requires physically visiting the site and programming each reader with an initialization card.

For large sites, the difference becomes especially noticeable: a new profile or configuration is distributed to the infrastructure from the system, rather than manually floor by floor, building by building, and site by site.

An additional layer is provided by Seenaptec Password Store (the secrets vault). Key material is stored centrally and does not need to be handed to installation personnel in plaintext.

This makes it possible to separate operational authority from key ownership: the integrator can install, connect, and configure the system without receiving the customer's protected card keys.

For a large enterprise customer, this means not only shorter commissioning times but also a fundamentally different security model. After installation is complete, there is no need to consider the key perimeter compromised merely because the equipment was configured by a third-party integrator.

Card issuance, key management, and reader configuration become a single centralized operational model.

Autonomous access without returning to distributed controllers

Seenaptec 1.6.1 continues the development of Seenaptec SecureBus — SSB and the autonomous capabilities of AGRG hardware.

For AGRG ACM2, cabinet handles AGRG SH-O, and other devices, an autonomous emergency-opening scenario using authorized emergency cards has been implemented.

The key feature is that this scenario is executed directly by the end device and does not require contacting the central server at the moment of opening.

In other words, even in the event of a complete loss of connectivity with the server perimeter, a pre-planned and controlled method of emergency access remains available.

At the same time, Seenaptec does not return to the classic controller-based architecture.

In normal operation, business logic, access policies, users, and system management remain centralized on the server. Only the autonomous scenario that is genuinely needed during an emergency or a connectivity outage is offloaded to the end device.

This makes it possible to combine a centralized server architecture with local fault tolerance directly at the critical access point.

For data centers, telecommunications cabinets, distributed sites, and other critical infrastructure, this approach is especially valuable: there is no need to place a full-fledged traditional controller at every access point solely to keep it working in case the server connection is lost.

Additional changes

Seenaptec 1.6.1 also includes fixes for identified bugs and a number of minor user interface improvements.

The technical documentation has been substantially updated: sections covering hardware operation, Wiegand, protected cards, profiles, the reader workstation, and autonomous scenarios have been expanded.

The demo version of Seenaptec on the website has been updated as well.

The economic benefit of this architecture is becoming one of Seenaptec's key advantages when modernizing existing access control systems. Preserving existing readers, cards, and a significant portion of installed peripherals, together with abandoning traditional controllers at every access point, allows equipment costs in some projects to be reduced by up to 60% compared to a full system replacement.

Additional savings arise in installation and commissioning. There is no need to dismantle and re-lay the entire infrastructure, replace readers en masse, re-issue cards, or manually visit hundreds of access points to program new keys. The larger the site, the more noticeable the difference — not only in equipment costs but also in labor, deployment timelines, and subsequent operation.

As a result, Seenaptec 1.6.1 turns access control modernization from a complete equipment-replacement project into a managed transition to a new architecture: existing infrastructure is preserved wherever it is still fit for purpose, the controller layer is reduced, keys and readers are managed centrally, and critical access scenarios remain autonomous even without the server.