In Mercury's survey of 561 security professionals, 32 percent said their current access-control systems lacked cybersecurity features, compared with 21 percent in its previous survey. This is a report of respondents' perceptions of their systems, not a technical audit finding that one-third of all controllers are vulnerable. Even with that limitation, it exposes a tension in the industry's push toward more autonomous access. Mercury's 2026 survey findings
Buyers are being offered increasingly capable software while the hardware responsible for enforcing physical permissions may be difficult to update, integrate or even inventory. Our finding is that the modernization opportunity sits in that mismatch. The controller in the cabinet can determine how much intelligence the rest of the system can safely use.
The controller has a long memory
A controller links the event at a reader to the physical decision at an opening. It sits within an installation whose readers, cabling, permissions and management software may have changed at different times. Replacing the visible user interface does not necessarily change what happens at this less visible layer.
Mercury's current findings describe rising complexity in AI features, cybersecurity coordination and integration. Because Mercury sells controllers, it has a commercial interest in modernization. Its survey is useful evidence of reported buyer concerns; it should not be treated as a neutral census or proof that buying its products is the answer. Sample composition and respondents' knowledge of their systems can affect year-to-year comparisons. Mercury's 2026 survey findings
Software is moving closer to the door
There is a concrete product development behind the discussion. In March, Mercury announced the commercial launch of an embedded application environment for its MP intelligent controllers. The company said approved applications could run on supported controllers with the required firmware. That moves some integration and processing work toward the edge rather than assuming a separate server must perform it all. Mercury's March 2026 embedded application announcement
The potential benefit is a shorter route from a local event to a local response. An application might use controller data without depending on a distant system for every step. But the placement of software also changes responsibility. Someone must know which applications are installed, which firmware supports them and what happens when an update fails. Local intelligence reduces some dependencies while creating a lifecycle to manage on the device.
Mercury's MP1502 documentation is a reminder that the hardware itself has a defined set of interfaces and capabilities. It is not an unlimited computer hidden inside a cabinet. Buyers need to connect a proposed application to the exact supported model and operating conditions. A platform-level promise is not evidence that every controller already installed in an estate can deliver it. MP1502 controller documentation
The hidden investment is the migration path
The strongest opportunity may be neither a new reader nor another analytics dashboard. It may be the ability to modernize an occupied building without losing control of its entrances. That requires inventory, dependency mapping, staged replacement and evidence that permissions still behave correctly after the change. These are commercially valuable tasks even when they produce no dramatic product demonstration.
Consider an illustrative campus with several generations of controllers. A central analytics service can flag an unusual access pattern, but the response must still be translated into an action each affected site can perform. If one building cannot receive or acknowledge the change reliably, the campus has uneven autonomy. Describing the whole estate as intelligent conceals that variation.
This suggests a different way to judge an integrator. Count neither the number of dashboards connected nor the number of devices sold in isolation. Examine how much of the estate has a known configuration, a supported update path and tested behavior during a communication failure. The useful output is dependable coverage of a process, not just deployment of a feature.
Do not confuse survey movement with deterioration
Mercury's 2025 report recorded many of the same tensions, including cybersecurity and interoperability gaps. Comparing the two reports can help identify questions, but it cannot establish that particular installations became less secure. Respondents might have become more demanding or more aware of missing features. A different sample could also explain part of the change. Mercury's 2025 survey report
That is the strongest limit on the headline finding. Some existing systems may already provide the protections their operators need, and an upgrade can introduce disruption or new software dependencies. The right response is a site-specific assessment. It is not an automatic replacement program triggered by an industry percentage.
What would show that the gap is closing?
The next persuasive evidence would pair modernization projects with operational results: fewer unknown devices, faster supported updates, successful recovery tests and fewer access exceptions after migration. It would also disclose the labor and interruption required to get there. Those measures connect infrastructure spending to an actual improvement in control.
If edge applications make that work easier, the controller becomes a foundation for practical autonomy. If they simply add another unmanaged software layer, they increase the burden on the people already struggling with integration. The most consequential autonomous-access company may be the one that can explain and maintain the cabinet, not the one with the most impressive screen above it.
References
Questions, news tips or corrections? Contact [email protected].
