Open architecture is not just an API logo. It means having the freedom to choose, combine and change different technology layers in the future without having to rebuild the entire system from scratch.
In the security technology market, “open architecture” has become one of the most commonly used terms. It can be found in descriptions of VMS, access control and video analytics solutions alike. However, for an integrator, the phrase “open platform” is not enough.
The more important question is: what exactly can I integrate, how deeply does the integration work, and what happens if, five years from now, the customer needs a different camera, analytics solution, access control system or cloud service?
Open architecture is not a single technology layer
In simple terms, a security system can be divided into several layers:
devices → communications/protocols → VMS or another platform → integrations/API → applications and business systems.
An open architecture should provide freedom of choice across more than one of these layers.
For example, in a video surveillance project, it may mean being able to use cameras from different manufacturers rather than being limited to a single manufacturer's ecosystem. But simply connecting a camera is not enough. What also matters is which functions remain available after integration.
ONVIF is a good example. It provides standardised communication between devices, but the fact that “a camera is ONVIF” does not automatically mean that the VMS will use all of the camera's capabilities. Both Genetec and Digifort documentation clearly show that the range of supported functions depends on the specific driver, profile, device and implementation.
Therefore, open architecture ≠ ONVIF. ONVIF is one of the tools that can help achieve openness.
Next question - how deep is the integration?
For an integrator, there is an important difference between:
“the system receives a signal”
and
“the systems actually work together”.
Let's assume that an access control system and video surveillance system are operating at the same site.
With a basic integration, the VMS may receive an event: Door forced open.
With a deeper integration, this event could automatically:
- call up a specific camera;
- display live video to the operator;
- create a bookmark;
- trigger an alarm;
- initiate a predefined procedure;
- send the event to another system;
- include the event in a report.
This is where APIs, SDKs, plug-ins and event-to-action mechanisms become important.
For example, the Genetec Security Center SDK provides access to platform functions such as video, access control, intrusion and ALPR, while the Web SDK allows events, alarms, door control, cardholder data and system status to be integrated into other applications.
Digifort, in turn, provides an SDK that can be used to access live and recorded video from the server, as well as integration mechanisms for third-party systems. Its documentation also demonstrates a middleware approach for integrations such as access control, perimeter intrusion and video walls.
So, in both cases, the question is not simply “can it be integrated?”, but rather “what can we actually do after the integration?”
What does this mean at the design stage?
Open architecture also changes the integrator's work before installation even begins.
A traditional approach might look like this:
Select a VMS → find compatible cameras → choose the remaining hardware.
A more open approach allows the process to start differently:
What are the project requirements? What are the best solutions for each layer? And how can we connect them into one functioning system?
This is particularly important in projects involving specialised technologies.
For example, a transport facility may require video cameras, ALPR, access control, intercom, perimeter detection and a transport management system. In a manufacturing facility, the priorities may instead be video, access control, industrial sensors and automation.
Open architecture allows the platform to be used as an integration layer, rather than necessarily as the only technology supplier.
Genetec un Digifort: two different approaches to openness
It is important to remain neutral here: open architecture does not mean that all platforms have to be built in the same way.
Genetec Security Center positions itself as a unified security platform with a broad technology partner ecosystem. Genetec highlights SDK integrations, third-party access control hardware, SIP/VoIP devices, storage and other partner integrations. The platform also supports third-party devices, including ONVIF cameras, and Genetec maintains a Supported Device List and certification programmes.
Digifort, meanwhile, makes extensive use of openness at the video infrastructure and integration level. Its documentation lists compatibility with ONVIF devices, integrations with more than 400 partner brands, and dedicated middleware solutions for access control, perimeter intrusion, video walls and other systems.
Therefore, when evaluating two “open” platforms, simply counting integration logos is not particularly useful.
It is more important to look at the type and depth of integration, certification, supported functions and the actual project requirements.
Why is this becoming even more important in 2026?
The lifecycle of security systems is often much longer than that of a single generation of technology.
A camera may be replaced after a few years. An analytics solution may change even sooner. Meanwhile, the VMS infrastructure, access control and integrations may remain in place for ten years or more.
Therefore, in 2026, the question is no longer simply:
“Does this solution work today?”
It is:
“How much choice will we have tomorrow?”
This is further reinforced by the development of cloud technologies, hybrid infrastructure, AI analytics and increasing cybersecurity requirements. The European Union's 2026 ICT Supply Chain Security Toolbox specifically highlights multi-vendor strategies and reducing dependencies on high-risk suppliers as one of the approaches to mitigating risk.
At the same time, interoperability (the ability of different systems, devices, software or organisations to interact with one another, exchange data and utilise that data without requiring any additional effort on the part of the user) in the public sector is increasingly being considered through the lens of vendor lock-in - not only as a matter of technical compatibility, but also as the ability to change suppliers in the future, retain data and avoid disproportionate migration costs.
This is already a practical issue in the Nordic market
Sweden provides a good example. In 2026, Genetec Security Center is used at the World of Volvo experience centre in Gothenburg together with more than 100 i-PRO cameras, while at another Volvo site, Federation enables centralised management of security functions. The project was implemented by Swedish systems integrator Granitor.
This illustrates an important principle: open architecture is not an objective in itself. Its value becomes apparent when an integrator needs to combine technologies that are best suited to a particular project.
The same logic is relevant in the Baltics. Municipalities, transport infrastructure, manufacturing facilities and logistics centres rarely start a project with a completely “blank sheet of paper”. There are usually already cameras, access control, intercoms, sensors, servers or other systems in place.
Therefore, the practical question is not “will we replace everything?”, but rather “what can we retain, what is worth replacing, and how can we connect everything into a single architecture?”
And what does it mean for the integrator?
This is where open architecture becomes a business issue, not just a technical one.
1. More choice in system design.
The integrator does not have to look for a single manufacturer's solution for every function. Technology can be selected according to the project's requirements.
2. Easier use of existing infrastructure.
If the customer already has functioning cameras, controllers or other systems, they do not necessarily have to be discarded simply because a new platform is being introduced.
3. Lower vendor lock-in risk.
The more a system relies on documented standards, APIs and integration capabilities, the more options remain available throughout the next stage of the system's lifecycle.
4. More opportunities to differentiate a project.
The integrator's value is no longer limited to installing hardware. It lies in the ability to create an architecture in which technologies from different manufacturers actually work together.
5. But also greater responsibility.
Open architecture does not mean “connect everything”. The more systems are integrated, the more important it becomes to verify version compatibility, licensing, API limitations, cybersecurity, performance and who will provide support if something goes wrong.
This is exactly where an integrator needs to look beyond the manufacturer's presentation slide filled with dozens of partner logos.
A good question to ask before starting a project
Not:
“Is this platform open architecture?”
But:
“What choices will this architecture actually leave me with five years from now?”
What cameras will I be able to use?
What systems will I be able to integrate?
How deeply will they be integrated?
What can I retain from the existing infrastructure?
How will I be able to add new technologies?
And, most importantly - will the system be able to evolve without having to start from scratch every time?
This is the level at which open architecture becomes a real advantage for the integrator - not as a logo in a specification, but as the freedom to design, integrate and change the system in the future according to the customer's needs.