Your Mercury Panels Can Do More Than You Think
If your building runs Mercury Security controllers — LP series, MP series — you already have the infrastructure for identity-based access control. The panels sitting in your IDF closets aren’t just relay drivers. They’re computing platforms that can run containerized applications.
Most security directors don’t know this. Most system integrators don’t either. Mercury’s MercOS platform supports on-panel applications — software that runs alongside the panel’s core access control logic, sharing the same hardware but operating independently.
This is the foundation of KeyShare’s physical access approach: deploy software on the panel you already own, rather than adding new hardware to the rack.
What Mercury panels already do
Mercury LP and MP controllers handle the standard access control workload: reader communication (OSDP or Wiegand), access decisions against credential databases, relay control for door hardware, event logging, and upstream communication with the PACS head-end (LenelS2, Genetec, Acre, RS2, Access It).
What’s less well-known is that these controllers also support containerized applications via MercOS. An application deployed on the panel can communicate with readers (via OSDP), access the panel’s credential database, and interact with the PACS — all without modifying the panel’s core firmware or disrupting existing operations.
What KeyShare adds
The KeyShare Panel Application is a containerized application that runs on Mercury LP and MP controllers. It adds one capability: identity-based access control.
When a reader with the KeyShare Reader Library firmware verifies a digital ID, the result is transmitted to the Panel Application via OSDP. The Panel Application derives a site-specific UUID from the verified identity, validates it against a cached credential manifest, and passes a standard credential number to the PACS through the panel’s native interface.
The PACS sees a standard credential. It applies existing access levels, schedules, and rules. Nothing changes in the PACS configuration. The panel continues to process badge-based credentials simultaneously — identity-based access and badge-based access coexist on the same panel, same readers (if OSDP + NFC capable), same PACS.
The deployment conversation with your SI
For system integrators, the deployment is software-only on the panel side:
- Deploy the Panel Application container onto the Mercury controller (LP or MP series).
- Install the KeyShare Add-On tab inside the customer’s existing PACS console.
- Configure Connect (cloud platform) for enrollment orchestration and manifest distribution.
- Enroll the first employees — right-click a cardholder in the PACS, select “Enroll with KeyShare.”
No new panels. No new wiring. No PACS migration. The SI’s Mercury expertise transfers directly — they already know the panels, the ports, the configuration tools. KeyShare runs on top of that expertise. For a deeper look at the architecture, see Controller Derivation: why the panel is the right place.
The only physical hardware consideration is the reader edge. If existing readers support OSDP v2.2 and NFC, the Reader Library firmware can be deployed via OTA update through the Panel Application. If readers don’t support NFC, reader upgrades are needed at the door — but the OSDP wiring stays. Wiegand readers require a full swap.
Capacity and performance
The Panel Application has a minimal footprint: 24 MB of memory, negligible CPU impact on panel operations. It supports up to 50,000 credentials per panel and up to 8 OSDP readers. Access decision latency — from OSDP result received to credential number passed to PACS — is under 100 milliseconds.
The credential manifest is cached locally on the panel with a 72-hour TTL. During a cloud outage, the panel continues making access decisions against the cached manifest. Doors open normally. When connectivity returns, the manifest syncs.
What this means for your security program
If you’re evaluating mobile credentials and running Mercury panels, you don’t need to budget for new controller hardware. The panels you have can run the software that eliminates per-user credential fees, removes the proprietary app requirement, and keeps access decisions on-premise.
The question for your SI: “Can you deploy the Panel Application on our existing Mercury controllers?” If you’re running LP or MP series on a current MercOS version, the answer is yes.
