Controller Derivation: Why the Panel Is the Right Place for Identity Intelligence
Most mobile credential architectures put intelligence in the cloud. The reader scans a credential, sends it to the cloud for validation, and waits for the response before the door opens. This works — until the cloud is slow, or unavailable, or compromised.
Controller Derivation is a different architectural pattern. It puts the access decision on the access control panel — the Mercury controller that’s already sitting in the IDF closet, already connected to readers, already making access decisions for badge-based credentials. The cloud handles enrollment and manifest distribution. It is never in the critical path for any door opening.
The architecture in four layers
Layer 1: Reader (edge). The NFC reader at the door runs the Reader Library firmware. When an employee taps their phone, the reader establishes an NFC session, reads the digital ID (ISO 18013-5), and verifies the cryptographic signature against the issuing authority. The verified identity attributes are transmitted to the panel via OSDP v2.2 (AES-128 encrypted). The reader processes identity data in transient memory only — nothing is stored at the reader edge. After the transaction, the reader holds zero PII. Communication between reader and panel uses OSDP v2.2 with AES-128 encryption.
Layer 2: Panel (controller). The Mercury controller runs the Panel Application — software deployed as a containerized application. The Panel Application receives the verified identity attributes from the reader, derives a site-specific UUID from those attributes, and validates the UUID against a locally cached credential manifest. If the UUID is valid, the Panel Application passes a standard credential number to the PACS through the panel’s native interface. The PACS doesn’t know or care that the credential originated from a digital ID — it sees a standard credential number, indistinguishable from a badge.
Layer 3: PACS (existing). The PACS — LenelS2, Genetec, Acre, RS2, Access It — applies its existing access levels, schedules, anti-passback rules, and area restrictions. Nothing changes in the PACS. No new APIs. No middleware. No proprietary protocol. The PACS makes the access decision using the same rules it applies to every other credential in the system.
Layer 4: Cloud (Connect). The cloud platform handles enrollment orchestration: when a PACS administrator enrolls a new employee, Connect generates the UUID, creates the credential in the PACS (via the Add-On), and distributes the updated manifest to the panel. The manifest is cryptographically signed — tampered manifests are rejected by the Panel Application. Manifests sync on a configurable interval (default: 60 minutes), with forced sync available for time-sensitive changes. The cloud is never involved in any door opening.
Why this matters: three architectural properties
On-premise access decisions. Every access decision is made locally on the Mercury controller. The designed latency budget: under 500ms for NFC session + identity verification, under 100ms for the reader edge response, under 50ms for panel derivation and manifest lookup, under 150ms for the panel-to-PACS authorization. Total tap-to-door: under one second. No cloud round-trip. No cloud dependency. Doors open during any cloud outage.
Zero PII at the edge. The reader processes identity data in transient memory and discards it after each transaction. The panel stores the credential manifest — which contains site-specific UUIDs, not personal data. If a reader or a panel is physically compromised, there is no PII to extract. This is a fundamentally different security posture from systems that cache personal data at the edge.
Site-specific UUIDs. The UUID derived from a verified identity is specific to the site. The same person at two different buildings gets two different UUIDs. Cross-site tracking is architecturally impossible — not just policy-prohibited, but mathematically impossible. A UUID from Building A cannot be correlated with a UUID from Building B, even by the system administrator.
The manifest model
The credential manifest is the core data structure. It’s a cryptographically signed list of valid UUIDs for a site, distributed from Connect to the panel. The panel caches the manifest locally with a 72-hour TTL.
When an employee is enrolled, their UUID is added to the manifest. When an employee is revoked, their UUID is removed and the manifest is re-signed. The panel receives the updated manifest on the next sync cycle — or immediately via forced sync for time-sensitive revocations.
The manifest model means the panel doesn’t need to query anything during a door opening. The data is already local. The access decision is a lookup against a signed list — computationally trivial and network-independent.
The PACS integration model
The Panel Application outputs a standard credential number through the panel’s native interface. This is the critical integration property: the PACS is unchanged. The PACS sees credentials. It doesn’t see UUIDs, identity attributes, or digital IDs. It sees the same kind of credential number it has always processed.
This means existing access levels, schedules, anti-passback, area restrictions, mustering, and audit logging all work exactly as they do today. The PACS administrator manages KeyShare-enrolled credentials using the same tools they use for badge-enrolled credentials — with the addition of the KeyShare Add-On tab for enrollment and revocation.
For the system integrator, the deployment is software-only on the panel side. No PACS migration. No new panel hardware. No rewiring. The SI loads the Panel Application onto the Mercury controller, configures the Add-On in the PACS console, and the system is operational.
