Licensing and Distributing a Commercial VMS Plugin

Almost every plugin project we're asked to rescue is technically fine. What went wrong was commercial: the plugin needs a licence change nobody told the customer about, or entitlement was designed assuming internet access on a network that has none, or the installer works on the developer's machine and nowhere else, or there's no answer to "which XProtect versions does this support" three years in.

This article is about that half. It applies whether you're a product company selling into the Milestone and Genetec ecosystems, or an integrator productising something you built once for a single customer.

"Licensing" means three different things

Most confusion here comes from one word covering three separate mechanisms with different owners, different failure modes and different timelines. Separate them before you design anything:

They interact, but they fail independently. A plugin can be fully certified by the vendor and still refuse to load because the customer's licence lacks the right entry. It can load fine and still not run because your own licence server was unreachable. Design each layer deliberately.

Layer 1 — the vendor's permission

Neither platform lets you distribute a commercial plugin without a relationship.

Milestone. The Technology Partner Program is free to join and the MIP SDK is openly available, but admission is gated on passing certification for at least one integration — certification is the entry ticket, not a later formality. Milestone tests functionality, usability and performance against a real XProtect environment, and targets roughly 60 calendar days to a decision once a project starts. Passing yields the partner badge and the right to describe the product as a certified solution. We covered that pipeline in detail in how Milestone Technology Partners get certified and published.

Genetec. Entry runs through the Development Acceleration Program (DAP), which is open to technology partners, integrators and end users and is an application rather than a paywall — joining gives you the SDK documentation, the installer and a Security Center development licence. Above that sits a paid SDK assistance plan, which buys access to Genetec's SDK technical team, and integration certification is included in some of those plans rather than all of them. So the sequence is: join DAP and build; decide separately whether you are buying vendor engineering support and certification. Tiers, inclusions and process change — confirm the current terms with Genetec directly rather than with any third-party summary, this one included.

The scheduling consequence matters more than the paperwork: certification is a dependency with a lead time, not a release step. If a customer expects delivery in Q1 and you begin certification in Q1, you will miss. Start the vendor conversation while the product is still being designed — partly for the calendar, partly because vendor review comments are much cheaper to act on before the architecture has set.

Layer 2 — what changes on the customer's licence

This is the one that damages deals, because it surfaces during procurement, in front of the customer, usually as a surprise.

On Genetec, plan for a licence change. Before your plugin can be installed, the end user's Security Center licence has to include a certificate for that plugin. The sequence is: finish development, contact Genetec for the plugin's part number and production certificate, then the customer updates their licence to carry it — which means a procurement step on their side, involving their Genetec channel, before your software runs at all. Whether that part number carries a cost to the customer is a question to settle with Genetec for your specific product, and to settle before a salesperson tells a prospect the plugin just installs.

On Milestone, you have a choice. A plugin can use the MIP plug-in licensing framework: the plug-in licence is added to the customer's Software Licence Code (SLC) as a sub-product, identified by your company name plus a plug-in ID and a licence ID, and it cannot be used on any other system. Your plugin's licence request is embedded in the normal XProtect licence request, which the Milestone licence server validates against what is registered on that SLC before returning a signed base licence carrying your sub-product — and administrators activate it online or offline from the Management Client exactly as they do the rest of their licensing. Or the plugin can stay outside that framework and carry its own entitlement. Both are legitimate; they suit different businesses.

Use the vendor's framework when your product is priced per system, sold through the vendor's channel, and your customers are already comfortable with that activation workflow — there's nothing new for an integrator to learn, which is worth real money in reduced support load. Run your own entitlement when you need a model the framework doesn't express, when you sell the same product on several VMS platforms and want a single licensing story across them, or when you need feature-level or usage-level control the framework can't give you.

What you must not do is leave this undecided until a customer asks. "Does this change our licence?" has exactly one acceptable answer, and it's a specific one.

Layer 3 — your own entitlement, on networks with no internet

Here is the constraint that invalidates most licensing designs imported from ordinary software: a large share of security networks have no outbound internet access, by policy and by design. A licensing scheme that assumes it will fail at exactly the sites you most want as references.

This is also a place where the vendor frameworks help more than people expect: Milestone's plug-in licensing supports offline activation from the Management Client, so a plugin inside that framework inherits a workflow already designed for disconnected sites. If you are running your own entitlement instead, you are rebuilding that yourself. Two patterns work. Pick deliberately:

• Signed offline licence files. The customer receives a cryptographically signed entitlement bound to a machine or system identifier — the VMS's own licence code is a convenient anchor — and the plugin verifies the signature locally. No network call ever. Simplest to reason about, works on any network, and the right default for genuinely air-gapped deployments. The cost is operational: reissuing on hardware changes becomes a support process you have to staff.
• Cached online validation with a long grace period. The plugin validates against your licence server when it can, caches the result, and keeps operating on the cached entitlement for a defined window — long enough to cover a real outage or a maintenance weekend, not so long that the check is meaningless. Enables usage-based models and remote entitlement changes. The cache must survive a service restart, or the first reboot during an outage takes the site down.

Whichever you pick, one rule is absolute: a licensing failure must never stop the plugin doing safety-relevant work. If your plugin routes alarms, an expired or unreachable licence should degrade loudly — log, alert, warn in the UI, refuse new configuration — and keep delivering alarms. A perimeter breach that went unnotified because a licence check timed out is an incident with your name on it, and it is the fastest way to be removed from an approved-vendor list permanently.

Packaging: the installer is part of the product

Your plugin will be installed by an integrator's engineer, on a customer's server, possibly at 2 a.m. during a maintenance window, with your documentation open in one hand. What that person experiences is your product quality as far as they'll report it.

Both platforms split across machines, so one artefact is rarely enough:

• Milestone. Client-side plugins are deployed by placing assemblies into the MIPPlugins folder on each machine; Event Server plugins go on the Event Server, which loads them on service restart; device drivers ship inside Milestone device packs and aren't yours to distribute at all. A site with fifty Smart Clients is a software distribution problem — ship an installer with a silent/unattended mode so it can go out through the customer's existing tooling, and never document a manual file copy as the supported path.
• Genetec. The server component installs on the Genetec Server and is then added as a Role in Config Tool and pointed at a database; client extensions still have to reach every Security Desk and Config Tool workstation. Include the Config Tool steps in your documentation with screenshots — that's where installs stall.

What separates a professional package from a zip file:

1. Silent install and upgrade. Unattended switches, and an upgrade path that preserves configuration. Ask what happens to a customer's settings when they install v2 over v1 — if the answer is "they re-enter them", that's a defect.
2. A published compatibility matrix. Which XProtect or Security Center versions you have actually tested, and which device pack versions where relevant. Publish what you tested, not what you assume works.
3. A prerequisite check that fails early and clearly. Wrong .NET runtime, missing VMS component, insufficient privileges, unreachable database — each with its own message. "Installation failed" costs you a support call every time.
4. Diagnostics an integrator can send you. A log location documented on page one, and ideally a single command that collects versions, configuration and recent logs into one file. This alone can halve support round-trips.
5. A clean uninstall. Including what happens to the customer's data — and say which is removed and which is kept.
6. Signed binaries. Code-signed assemblies and installer. Unsigned software on a hardened security server is an argument you don't want to have during a maintenance window.

OEM and white-label distribution

A common and profitable path is not selling the plugin yourself: a VMS vendor, a hardware manufacturer or a large integrator ships it under their own name. The engineering implications are worth designing for up front rather than retrofitting.

• Branding has to be data, not code. Names, logos, colours and support contacts belong in configuration and resources, so a new OEM is a build configuration rather than a fork. Forked-per-customer plugins are where maintenance costs go to die.
• Plugin identity is not brandable. Both platforms identify plugins by GUID. Decide deliberately whether each OEM build gets its own identity — needed if two OEM builds must coexist on one system — because changing that decision later means a migration for every existing install.
• Support flows through the OEM. Your diagnostics have to be usable by their first-line support, not only by you. Budget for a tier-2 escalation path and the documentation it needs.
• Certification may be per-brand. If each OEM ships under their own partner identity, confirm early whether certification transfers or has to be repeated. The answer changes the launch calendar for every OEM deal.
• IP terms in writing, before the first build. Who owns the core, what the OEM licenses, what happens at termination. On our own engagements the default is that the customer gets the source and the IP is transferred at delivery — whatever your model, make it explicit rather than implied.

The commercial model, briefly

Licensing mechanics should follow the pricing model, not the reverse, so decide the model first. VMS add-ons are usually metered on one of a handful of axes: per system or site, per camera or door, per server, per concurrent operator, or per feature tier — sometimes perpetual with a maintenance component, sometimes subscription.

Two engineering notes, independent of which you pick. First, your meter must be countable by the plugin, reliably and cheaply. Per-camera pricing means counting cameras correctly as they're added, removed and disabled, and deciding what happens at the limit — refuse, warn, or keep working and report. Second, whatever you meter becomes a support conversation. Per-camera licensing generates disputes about what counts as a camera; per-site licensing generates disputes about what counts as a site. The simplest meter your business can tolerate is usually the right one.

Where projects usually need a specialist

The pattern in this article's failures is that all of them are cheap to design for at the start and expensive to retrofit. Entitlement assuming internet access, discovered at an air-gapped site. A certification lead time discovered after a delivery date was promised. A licence part number discovered during the customer's procurement. An installer that works on one machine, discovered by an integrator at 2 a.m. A per-customer fork, discovered when the third OEM asks for a change.

None of that is difficult work. It's work that has to happen before the code sets, which is why it tends to be done by people who have shipped into these ecosystems before — the same reason we do it as part of plugin engineering rather than as an afterthought: architecture and certification first, then the long-term version tracking that keeps a plugin loading through years of platform releases.

Working with Xplug.in

Send us the product, and we'll tell you what the commercial layer needs

• A licensing and distribution review before you commit. Send what the plugin does, who sells it and where it gets deployed. You get back which layer applies at each step, what your customers will see on their VMS licence, and which decisions are still cheap to change.
• An entitlement design that holds on an air-gapped site — signed offline licences or cached validation with a grace window, and an explicit answer to what the plugin does when a licence check fails while an alarm is in flight.
• A package an integrator can actually deploy — silent install and upgrade, prerequisite checks that fail clearly, signed binaries, collectable diagnostics, and a published version matrix instead of an implied one.
• Certification taken to a decision, on Milestone, Genetec or both, with the architecture reviewed against the vendor's criteria before submission rather than after the first round of comments.

Get a licensing review Schedule a technical demo

Xplug.in is a Milestone Technology Partner and Genetec Technology Partner, working within the Development Acceleration Program, with 140+ plugins shipped since 2014 — including OEM and white-label builds shipped under other companies' names. Write to contact@xplug.in or use the form; one email gets you a straight answer.

Questions we get asked

Does a customer need a new VMS licence to run my plugin?

On Genetec, plan for yes. The customer's Security Center licence has to include a certificate for your plugin before the plugin can be installed: once the integration is ready for production you obtain a part number and production certificate from Genetec, and the customer updates their licence to carry it. That is a procurement step for the customer rather than a silent install. On Milestone, a plugin can use the MIP plug-in licensing framework, where the plug-in licence is added to the customer's Software Licence Code as a sub-product and cannot be used on any other system, or it can stay outside that framework entirely.

Both mechanics are vendor-specific and change over time, so confirm the current position with the vendor before telling a customer nothing on their licence changes.

Should I use the VMS vendor's licensing framework or my own licence server?

Use the vendor's framework when your plugin is sold through the vendor's channel and priced per system, because the customer's existing activation workflow then covers your product too and integrators have nothing new to learn. Run your own entitlement when you need a model the vendor's framework does not express, when you sell the same product across several VMS platforms and want one licensing story, or when you need usage or feature-level control the framework cannot give you.

How should plugin licensing work on an air-gapped or offline site?

Assume no outbound internet, because on many security networks there genuinely is none. Two patterns work: signed offline licence files, where the customer receives a cryptographically signed entitlement bound to a machine or system identifier and no network call is ever needed; or a cached online check with a long grace period, where the plugin validates when it can and keeps operating on the cached entitlement for a defined window.

What must never happen is a plugin that stops handling alarms because a licence server was unreachable.

What is the difference between being certified and being listed on Milestone Marketplace?

They are separate steps. Certification is Milestone testing the integration against functionality, usability and performance criteria, and it gates formal admission to the Technology Partner Program. Marketplace listing follows a verification review, and Milestone is explicit that verification means it reviewed the partner's documentation and found the solution compatible with the specific XProtect version used in testing — it does not guarantee functionality or compatibility with untested environments. A Solution Finder listing is a third step with its own requirements.