Alocity Announces Support for Mercury Security Access-Control Infrastructure

Alocity reports Mercury platform support

Alocity announced on September 8, 2026, that its physical-security platform supports Mercury Security’s open access-control platform. The company says the arrangement brings Mercury controller infrastructure into an environment that also includes its cloud access control, AI video, intercom, visitor-management and workflow tools. ([prnewswire.com](https://www.prnewswire.com/news-releases/alocity-expands-its-ai-operating-system-with-mercurys-open-access-control-infrastructure-302870742.html))

paragraphs_placeholder

A potential modernization path for Mercury-based sites

For end users with a Mercury-based access-control estate, the significance is primarily architectural. Controllers, field panels, readers, locks, wiring and power arrangements generally have longer replacement cycles than software. Alocity is positioning its support as a way to add centralized cloud operations and connected workflows while retaining an open controller foundation rather than moving immediately to a new proprietary hardware stack. ([prnewswire.com](https://www.prnewswire.com/news-releases/alocity-expands-its-ai-operating-system-with-mercurys-open-access-control-infrastructure-302870742.html))

That does not mean every installed Mercury environment is automatically ready for migration. Alocity’s announcement says supported Mercury hardware configurations and product availability are subject to Alocity and Mercury certification requirements. Installers and consultants should treat support as a compatibility program to be confirmed, not as a blanket assurance covering every controller generation, firmware level or legacy deployment. ([prnewswire.com](https://www.prnewswire.com/news-releases/alocity-expands-its-ai-operating-system-with-mercurys-open-access-control-infrastructure-302870742.html))

What the combined software layer is intended to cover

Alocity describes its Control Center as a cloud platform for unified management across access control, video, intercom and visitor operations. Its September announcement says Mercury-connected access events can be used alongside those functions and with workflow automation. ([prnewswire.com](https://www.prnewswire.com/news-releases/alocity-expands-its-ai-operating-system-with-mercurys-open-access-control-infrastructure-302870742.html))

The company also points to Aimee, its AI operator, as the conversational layer for authorized users. Alocity previously described Aimee as correlating connected door, camera and sensor events and producing natural-language incident summaries, with configurable escalation rules. Those capabilities could be relevant where security operations teams want a single event-review process spanning credential activity and video evidence. ([alocity.com](https://www.alocity.com/newsroom/alocity-launches-aimee-ai-operator))

Why Mercury compatibility matters to integrators

Mercury Security is an HID brand whose controller platform is designed around open architecture and interoperability with partner software and technical solutions. Mercury’s recent S4 I/O module announcement also emphasized modular expansion, forward and backward compatibility, and minimizing disruptive replacements as access systems evolve. ([mercury-security.com](https://www.mercury-security.com/mercury-strengthens-and-streamlines-access-control-expansion-with-new-s4-i-o-modules/))

In practical terms, an additional software option on a familiar controller ecosystem can expand the alternatives available to an integrator. It may be relevant for a phased project in which a customer wants to standardize operational software across sites while retaining selected access-control field infrastructure. It does not remove the normal engineering work around controller capacity, panel topology, reader communications, credential technologies, network segmentation, door hardware interfaces and fail-safe or fail-secure behavior.

Questions to resolve before specifying the integration

Procurement and engineering teams should obtain written confirmation of the supported Mercury controller and interface-module models, firmware versions, required gateways or appliances, licensing model, and cloud connectivity requirements. They should also establish which party supports commissioning, troubleshooting, software updates and incident escalation.

Because the proposed value depends on joining access events with video, intercom and visitor data, teams should review permissions, audit logging, retention, privacy controls and network design. Acceptance testing should cover normal access transactions as well as offline behavior, alarm handling, forced-door and door-held conditions, event latency, video association and recovery after communications loss.

The announcement establishes that Alocity is pursuing Mercury support, but it does not publish a universal bill of materials or a full compatibility matrix. A pilot at representative doors or sites is a prudent step before a broad migration, particularly where existing panels serve critical openings or operate under regulated facility requirements.

What to watch next

The next useful indicators will be published certification details, named controller configurations, implementation guidance and reference deployments. For customers invested in Mercury infrastructure, those details will determine whether the announcement translates into a straightforward software-led upgrade path or a more tailored integration project.

Mercury continues to develop its open controller ecosystem, including the S4 I/O Module family announced September 2, 2026. Alocity’s new support announcement arrives in that context, as organizations weigh cloud management and cross-system workflows against the operational cost and risk of replacing established field hardware. ([mercury-security.com](https://www.mercury-security.com/mercury-strengthens-and-streamlines-access-control-expansion-with-new-s4-i-o-modules/))