René Schimmer, Senior Product Manager, Mercury Security

Traditional integrations generally communicate with controllers through APIs or external middleware. Embedded applications execute directly on the controller itself.

That gives developers access to events and processing closer to where access decisions occur while reducing dependence on external servers for certain workflows.

It also allows functionality to be packaged as an application rather than becoming part of the controller firmware itself.

Bobbie Ferraro, VP of Marketing and Critical Infrastructure Partners, Prometheus Security Group:

The industry has reached a point where the controller is no longer just making simple access decisions. Customers want it to do much more. We looked at Mercury's Embedded App Environment and saw an opportunity to extend trusted access control into areas that historically haven't been protected.

Our focus at PSG is zero trust at the physical edge. We've developed DESI, our Digital Encrypted Security Interface, which continuously authenticates edge devices and cryptographically secures communications from sensors back to the controller. Running alongside the Mercury platform allows us to bring those capabilities into existing deployments without forcing customers to replace their controllers, wiring or field devices. That's a huge advantage for critical infrastructure operators that want stronger cybersecurity while protecting previous investments.

Guy Arazi, Director of Technology Partnerships, SecuriThings:

For us, it was about solving a different problem.

Large organizations have thousands of connected devices. Controllers, cameras, intercoms, UPS systems, building automation equipment. Every manufacturer provides its own management tools, but customers are left trying to monitor everything from separate dashboards.

We built our platform to manage all those devices regardless of who made them. The Embedded App Environment gives us a much cleaner way to integrate directly with Mercury controllers so we can automate firmware updates, password management, certificate rotation and health monitoring without waiting for every feature to become part of the controller firmware itself. It puts us in the driver’s seat and lets us prioritize what our customers require.

Paul: What exactly is an embedded application environment?

René:
Historically, access controllers have executed a fixed set of functions defined by their firmware. If new capabilities were required, they generally had to be incorporated into a future firmware release.

An embedded application environment changes that model. It provides a secure environment on the controller where approved third-party applications can execute alongside the core access control functions without modifying the controller's underlying firmware.

This keeps the controller's core access control software separate from partner applications, allowing new capabilities to be added without changing the underlying controller firmware.

Paul: Why build an application instead of requesting a new controller feature?

Guy Arazi:
That's exactly the challenge. Every partner has their own requirements. Mercury also has its own roadmap, customer requests and engineering priorities. Even if something is important to us, it may not be the next item on Mercury's development schedule.

The Embedded App Environment changes that relationship. Instead of asking Mercury to build every feature, we can build capabilities ourselves while Mercury focuses on maintaining the platform. That allows innovation to happen much faster.

It changes how new functionality reaches customers. Instead of waiting for controller firmware updates, developers can build and deploy capabilities independently while still relying on the same underlying controller platform.

Bobbie Ferraro:
Mercury doesn't need to become the expert in zero trust for every edge sensor. That's our specialty.

An app platform like this lets us contribute our expertise while Mercury continues doing what Mercury has always done exceptionally well, which is providing an open, trusted access control platform.

Paul: Why move application logic onto the controller instead of running everything in the cloud or on a server?

René: Cloud services are excellent for centralized management, reporting and orchestration. The controller, however, remains the point where physical decisions are ultimately made.

Executing application logic at the edge can reduce latency, eliminate unnecessary network dependencies and allow certain functions to continue operating even if connectivity to upstream systems is interrupted.

Rather than replacing cloud architectures, embedded applications at the edge complement them by allowing appropriate workloads to execute where they make the most sense.

Paul: Both SecuriThings and PSG seem to solve very different problems. Does that illustrate the value of an open application platform?

Bobbie Ferraro:
Absolutely. We're focused on protecting the physical edge by establishing trusted identities for devices instead of simply trusting analog signals that have existed for decades.

Other partners can bring their own specialized capabilities to the platform. That's the real value of an open ecosystem: customers can add the technologies that address their specific security and operational requirements while continuing to build on the Mercury platform they already know and trust.

Guy Arazi:
That's one of the biggest advantages. No manufacturer can realistically become the best at every application customers need. An open ecosystem allows specialists to innovate in their own domains while customers gain access to a much broader set of capabilities.

Ultimately, the customer benefits because they aren't limited by a single vendor's development priorities.

Paul: What practical advantages does this bring to end users?

Guy Arazi:
For our customers, it’s all about operational efficiency. Operators don't necessarily care whether firmware updates or password rotations happen through one application or another. They simply want their infrastructure to remain healthy, secure and compliant. This matters even more for global organizations running sites across multiple countries, where each region can carry its own data protection and security compliance requirements. Managing that consistently from a single platform, rather than reconciling different tools site by site, is a real operational advantage.

The app environment gives us direct access to capabilities that previously weren't available, allowing us to automate many maintenance tasks that previously required workarounds or manual effort.

Bobbie Ferraro:
For us, it's about trust. Organizations are making increasingly important operational and security decisions based on information coming from edge devices.

If those devices and their communications aren't trusted, then everything built on top of them becomes less trustworthy as well.

By establishing cryptographically authenticated communications at the edge, customers gain much greater confidence in the data they're using to make security decisions.

Paul: Mercury often talks about openness. From a partner perspective, what does openness actually mean?

Bobbie Ferraro:
It means we're able to bring our own innovation to a platform customers already trust.

Mercury has enormous market presence. We don't replace it, we extend it. The Embedded App Environment gives us that opportunity.

Rather than competing with Mercury, we're helping customers solve additional problems using infrastructure they already own.

Guy Arazi:
I think openness creates a healthier ecosystem for everyone.

In this case, Mercury provides the platform. Partners develop differentiated applications. Customers gain more choice and nobody has to wait for a single vendor to solve every problem.

That's the kind of environment that encourages innovation rather than limiting it.

Paul: René, does this change what an access controller can become?

René: 
The controller remains an access controller first. What changes is that it becomes a platform capable of supporting additional workloads.

Instead of treating every new requirement as a firmware feature request, developers can build specialized applications that execute locally while leveraging the controller's existing interfaces and security model.

That creates a more flexible architecture without requiring to replace deployed hardware every time new requirements emerge.

Paul: Looking ahead, what excites each of you most about what is possible?

Bobbie Ferraro:
The potential goes well beyond traditional access control.

Trusted communication at the physical edge has applications across critical infrastructure, industrial environments and building automation. Access control is just the beginning.

Guy Arazi:
I think we're still in the early stages. As more developers build applications, customers will begin viewing access controllers much more like intelligent computing platforms rather than fixed-function hardware.

That opens the door (see what I did there?) to much faster innovation across the entire physical security ecosystem.

René:
Physical security systems are becoming increasingly software-defined. Customers want to extend systems through software rather than replacing hardware every time requirements evolve.

Open application environments allow manufacturers, software developers and systems integrators to contribute specialized capabilities while preserving a stable controller platform underneath.

That combination of architectural stability and software extensibility will become increasingly important as access control continues to intersect with cybersecurity, building automation, identity management and emerging AI-driven applications.