So, you need to connect something unusual to Milestone XProtect.
It might be a camera XProtect has never met, a drone sending video and GPS, an alarm panel that needs to speak to an ARC, or an access-control event that should put the right cameras in front of an operator without them clicking through six different screens.
The temptation is to call it “custom middleware” and start designing something clever. I understand the attraction—we build this sort of software every day—but most XProtect projects should not begin there.
The safest starting point is usually much simpler: a supported XProtect driver, a native manufacturer integration, XProtect Access, the Universal Driver, Video Push, Open Network Bridge, a direct API integration or an existing specialist connector.
Custom development becomes the right answer only when the requirement genuinely exceeds those options. Or, put another way: use the boring answer if the boring answer works. Production systems tend to appreciate boring.
That is when a custom driver, MIP plug-in, API application or middleware service begins to make sense—and when the occasional bit of “magic glue” becomes proper engineering rather than a workaround.
First, a small terminology problem: the word “middleware” is used quite loosely in physical security. Depending on who is speaking, it can mean anything from a tiny service moving an event from A to B to an entire platform quietly keeping five other platforms from arguing with each other.
In practical terms, middleware is the software layer that sits between Milestone XProtect and another device, platform or operational system. It can translate protocols, normalise data, enrich events, handle retries and coordinate actions across products that were not originally designed to work as one application.
Middleware is therefore an architectural role rather than one specific type of Milestone integration.
There are four common approaches that are often grouped under the term.
A device driver sits at the XProtect Recording Server layer and connects the VMS to hardware or a device-like source.
This is the correct route when the source must behave like a proper XProtect device. That might include video channels, metadata, PTZ controls, discovery, input and output control, device health or telemetry.
A driver is generally concerned with how XProtect communicates with and manages a device.
A MIP plug-in extends applications such as XProtect Smart Client, Management Client or Event Server.
Plug-ins can provide:
A plug-in is therefore normally concerned with how operators or administrators interact with XProtect.
An API integration is an external application or service that communicates with XProtect through its documented interfaces.
An external system may use an API integration to create events, add bookmarks, retrieve configuration, subscribe to alarms or query system status.
Where the requirement is limited to exchanging data through documented interfaces, a direct API integration may be far more appropriate than building a driver or Smart Client plug-in.
A middleware service is a stand-alone service that connects several systems or performs more substantial translation and orchestration.
It might:
This is the point where middleware becomes less like a simple connector and more like the nervous system of the integration. Useful, important and absolutely not something you want held together by a scheduled task somebody created three years ago and forgot to document.
My general rule is that the best integration is normally the least complex option that can still be trusted in production.
Before commissioning custom development, work through the available options in order.
The first step is to confirm whether the camera, encoder or device is already supported by XProtect.
Where a tested native driver already exists, replacing it with custom development is rarely the correct starting point. Native support will usually provide the clearest upgrade path, the most familiar configuration process and the simplest support model. Reinventing the wheel does not become more sensible because the new wheel has an installer and a nice logo.
First check: always confirm native XProtect device support before commissioning a custom integration.
A number of common requirements can already be handled through existing XProtect components.
For example:
A project may sound custom during the initial conversation but turn out to be achievable through configuration and a relatively light integration.
The Universal Driver can be a practical option where the requirement is simply to bring video or audio into XProtect.
It is particularly useful for straightforward streams where the source can provide a compatible transport and codec.
However, the Universal Driver has an important boundary: it is designed primarily for video and audio streaming. It does not turn every source into a fully featured XProtect device.
Where the project also needs PTZ, input and output control, discovery, GPS, telemetry, device health or rich metadata, the requirement has moved beyond basic stream ingestion.
There is a valuable middle ground between native support and custom development.
A configurable specialist product may already solve most or all of the requirement without the cost and lifecycle burden of bespoke software.
Examples within the ORBNET product range include:
These products occupy the useful space between “XProtect already supports it” and “we need to build everything from scratch”.
The Universal Driver is genuinely useful. It is not, however, magic—and I have seen “it works in VLC” become the opening line of more technical investigations than I care to count.
It is normally sufficient when the problem is fundamentally about stream ingestion.
A standard RTSP camera or encoder that only needs to provide video and audio is a good example. A temporary or mobile source may also be suitable where device control and metadata are not required.
The Universal Driver is likely to be appropriate when:
It should not be treated as a shortcut for every unusual video source.
For example, sources using protocols such as RTMP, SRT, HLS or WebRTC may require a protocol-conversion layer before they can be presented to XProtect in a suitable format.
That does not automatically justify custom development.
A product with in our ORBNET Streamforce Eco System may provide the necessary conversion and stream management without introducing a new bespoke software project.
This is where things get more interesting. A custom driver is appropriate when an unsupported source must behave like a first-class XProtect device, rather than merely being a video URL that happens to record.
This usually means the integration needs more than a video URL.
The device may need to provide:
A drone integration provides a useful example.
If a drone only sends a live video stream, a gateway or configurable stream integration may be sufficient.
If the drone must appear as a managed XProtect device with colour and thermal channels, GPS position, telemetry, metadata and consistent recording behaviour, the requirement is much closer to a custom driver.
The same principle applies to specialist encoders, body-worn cameras, vehicles, sensors and proprietary hardware.
A driver should be treated as a proper product development effort rather than a quick project script. It needs structured testing, logging, version management and a defined support lifecycle. Version one is the exciting part; version four, after three firmware changes and two XProtect upgrades, is where the quality of the original decision becomes very obvious.
Choose an MIP plug-in when the most difficult part of the requirement is the operator or administrator workflow inside XProtect. In plain English: the hard bit is not getting the data in; it is deciding what the person in front of Smart Client should see and be able to do with it.
A plug-in may be appropriate where operators need:
For example, an access-control event might need to display nearby cameras, show cardholder details and give the operator a set of approved actions.
Some of that may already be achievable through XProtect Access and standard camera association. Where the workflow needs to go further, a custom Smart Client plug-in may be justified.
Plug-ins also introduce operational considerations. They must be packaged, installed and tested with the XProtect applications that load them. Client restarts, configuration compatibility, logging and upgrade testing all need to be considered.
Sometimes you do not need a driver or a plug-in. You need an API, sensible authentication and a clear agreement about who owns what when one of the systems is unavailable.
An API integration is often the best option when an external application simply needs to exchange information with XProtect.
Typical requirements include:
These requirements do not automatically need a custom driver or Smart Client plug-in.
A small external application or service may be able to perform the required task cleanly through the documented XProtect APIs while remaining independent of the XProtect client interface.
This can reduce deployment complexity and make the integration easier to update or replace later.
This is the “magic glue” category—although, sadly, the magic still needs logs, retries, monitoring and somebody responsible for supporting it.
A stand-alone middleware service becomes appropriate when the integration logic must live outside XProtect and coordinate several systems.
Common examples include:
Consider an alarm workflow involving an intrusion panel, XProtect, an alarm receiving centre and an access-control platform.
A simple connector may be able to raise an event in XProtect.
A middleware service becomes more appropriate when the workflow must also verify delivery, wait for operator acknowledgement, trigger an external response, update the access-control state and record each stage for later audit.
That is no longer just a notification. It is a coordinated process.
The greatest cost of a custom integration is rarely writing the first version.
The real cost is owning the second, third and fourth versions.
Custom integrations must continue to operate as XProtect, Windows, device firmware, authentication methods and third-party APIs change.
The ongoing responsibilities may include:
None of this means “never build custom”. We make a living doing exactly that, so it would be a slightly odd conclusion for me to reach. It means those responsibilities should be visible before development begins.
A prebuilt or configurable product spreads much of this lifecycle work across multiple deployments and customers. That can make it substantially more economical and supportable than writing a unique integration for a single project.
Use the guide below to identify the simplest sensible starting point for your integration, and the point at which custom development may become justified.
Best starting point
Use the native XProtect driver or manufacturer-supported integration.
Consider custom development when
The project requires unsupported metadata, controls or specialist workflow behaviour.
Best starting point
Use the Milestone Universal Driver for straightforward video or audio ingestion.
Consider custom development when
You also require PTZ, metadata, discovery, device health or input and output control.
Best starting point
Use a specialist video gateway or protocol-conversion product such as ORBNET Streamforce.
Consider custom development when
The conversion, stream selection, metadata handling or operational workflow is unique.
Best starting point
Use a metadata-capable driver, integration proxy or configurable mapping product.
Consider custom development when
Accurate timing, mapping, telemetry processing or mission-specific logic is required.
Best starting point
Use an existing alarm connector or event-routing product such as ORBNET Event Gateway.
Consider custom development when
The protocol is unsupported or the workflow needs state management, retries and auditing across several systems.
Best starting point
Use XProtect Access with an existing manufacturer or specialist connector.
Consider custom development when
The platform is unsupported or operators need a genuinely bespoke access and video workflow.
Best starting point
Use a direct XProtect API integration to exchange events, bookmarks, configuration or status information.
Consider custom development when
Data transformation, buffering, retries or coordination with multiple systems is required.
Best starting point
Start with standard Smart Client features, configurable views and existing integrations.
Consider custom development when
Operators need a dedicated workspace, side panel, view item, map, search category or guided workflow.
General rule: choose the least complex integration that can meet the operational, reliability and support requirements of the project.
The best XProtect integration is normally the simplest option that can be trusted in production.
Start with supported native integrations. Then consider built-in and generic options such as the Universal Driver, XProtect Access, APIs, Video Push and Open Network Bridge.
Where those are not enough, look for a configurable specialist product or existing connector.
Only move into custom drivers, MIP plug-ins or middleware services when the requirement genuinely demands unique device behaviour, operator workflow, protocol handling, metadata processing or cross-system orchestration.
Custom development is absolutely justified in the right project. It is not a failure of XProtect or of the products around it; it is simply the point where your requirement has become genuinely unique.
It just should not be the opening assumption every time somebody says, “Could we make XProtect do this?”
If you have a device, protocol or workflow that needs to connect with Milestone XProtect, send us the systems, data and operator outcome you are trying to achieve. We will help work out whether the sensible answer is configuration, an existing ORBNET product, or something genuinely custom.
Security middleware is the software layer between systems that translates protocols, normalises data or events and coordinates workflows between platforms such as XProtect, access control, alarms, maps and business applications.
When is the Milestone Universal Driver sufficient?It is normally sufficient when you need straightforward video or audio ingestion from a compatible source and do not require metadata, PTZ, input and output control, discovery or other advanced device behaviour.
When do you need a custom XProtect device driver?A custom driver is appropriate when an unsupported source must behave like proper XProtect hardware and requires capabilities such as metadata, PTZ, structured channels, telemetry, discovery or device-specific logic.
Should you build a custom integration or buy an existing connector?Check native support, built-in XProtect features, the Universal Driver and existing specialist connectors first. Custom development becomes sensible when those options cannot meet the requirement reliably, securely or supportably.
Can an external system create events or bookmarks in XProtect without a custom plug-in?Yes. In many cases an external application can create events, add bookmarks or subscribe to changes through XProtect APIs without requiring a Smart Client plug-in.