PSG Joins Mercury Security Technology Partner Program for Far-Edge Zero Trust

Partnership targets trust at the point of capture

Prometheus Security Group Global (PSG) has joined Mercury Security as a technology partner in a collaboration focused on applying Zero Trust principles closer to the devices that originate physical-security events. The companies announced the relationship on August 27, 2026. That date differs from the September 1 date in the initial report.

The stated objective is to combine Mercury’s open-architecture access-control platform with PSG’s Digital Encrypted Security Interface, or DESI, technology. Rather than treating a field input as trustworthy merely because it is wired to a panel or sits on an approved network, the approach is intended to establish device identity and authenticate communications at the far edge of the system.

Why field-device verification is a distinct issue

Access-control and intrusion systems commonly collect events from contacts, request-to-exit devices, locks, readers and other connected equipment before transmitting those events to controllers and management software. Network protections, controller hardening and encrypted upstream communications remain important, but they do not by themselves establish whether a signal originated with the expected field device.

PSG’s description of the partnership centers on cryptographically authenticated and verified signals at their source. The company has also identified readers, sensors and cameras among the types of field equipment its far-edge Zero Trust approach can address. Mercury’s public announcement specifically identifies request-to-exit devices, contacts and door hardware. Neither company has published a complete compatibility matrix or technical architecture for the partnership.

Mercury’s controller app environment provides the integration route

The partnership fits Mercury’s Embedded Application Environment, which enables approved technology partners and OEMs to develop and deploy applications on Mercury MP Intelligent Controllers. Mercury commercially launched that environment in March 2026 and describes a review process covering proposal evaluation, technical feasibility, development and security qualification.

For integrators, this matters because an application running at the controller can add specialized capabilities without necessarily changing the upstream access-control software architecture. Mercury says its app program is designed for controlled deployment through its OEM ecosystem, with application validation before distribution. That governance model does not eliminate the need for site-specific validation, particularly where life-safety interfaces, door hardware behavior or regulated environments are involved.

Modernization claim requires design-level qualification

Both companies position the arrangement as a way to improve assurance without wholesale replacement of installed access-control infrastructure. This is potentially relevant to high-security, government and critical-infrastructure sites where a complete rip-and-replace project can be costly and operationally disruptive.

However, “without replacement” should not be read as universal retrofit compatibility. Procurement teams should ask which Mercury controller families and firmware releases support the application, whether the access-control OEM supports the intended configuration, how DESI interfaces with existing supervised circuits or connected devices, and whether changes are required to power, enclosures, wiring, licensing, cybersecurity operations or acceptance testing.

Questions to include in a project review

A useful evaluation should begin with the threat model. Teams should identify which field signals create material risk if spoofed, substituted, bypassed or altered, then decide whether device-level identity and signal verification materially reduce that risk. Door position, request-to-exit and intrusion inputs may have different operational and safety implications, so each use case needs its own test criteria.

Installers and consultants should also define failure behavior before deployment. Key questions include how the system handles an unverified device or signal, how alarm and access decisions behave during communications loss, how certificates or cryptographic identities are provisioned and rotated, and who owns ongoing support across the end user, integrator, OEM, Mercury and PSG. The announced partnership establishes a technology relationship, but detailed implementation requirements remain a project-level matter.