Licensing Software for Dark Sites and Restricted Networks: What Vendors Need to Get Right

A dark site is a customer network with no outbound internet access at all - common in defense, government, and industrial environments where the network is deliberately isolated for security reasons. A restricted network allows some connectivity, but only through tightly controlled, audited channels, which for practical purposes means a vendor's software still can't assume it can reach the cloud whenever it wants to.

These aren't edge cases. Automotive engineering, electronic design automation, industrial and manufacturing software, defense and aerospace, critical infrastructure, and healthcare all routinely run environments like this - and the customers running them tend to be large, well-funded, and looking for a long-term vendor relationship, not a quick trial.

For decades, the answer to "the customer's network is locked down" has been a static license file or a hardware dongle. Both solve the narrow problem of granting access. Neither solves the actual problem a vendor has today.

A static license file is issued once and never checked again. It can be copied, shared, or extracted from a decommissioned machine with no way for the vendor to know. It's also locked into whatever license model existed the day it was generated - if a customer wants to move from a flat perpetual license to usage-based or consumption pricing, the vendor has to hand-roll a new file and hope the customer applies it correctly.

A hardware dongle solves the copying problem but replaces it with a logistics one: dongles have to be manufactured, shipped, tracked, and replaced when lost or damaged - and customers still have to physically manage a USB key as part of running their software. It's not just a vendor cost. It's friction for the customer too, which is exactly what a security-conscious buyer doesn't want to add to their environment.

A licensing architecture built for dark sites and restricted networks has to satisfy three different people at once: the vendor's finance team, the vendor's engineers, and the customer's own IT and security staff. That means it needs to do more than just "work offline."

• •

  Run entirely inside the customer's own network, with zero outbound dependency once deployed - the only way to pass a security review that disqualifies anything requiring a live connection to a third party.

• •

  Enforce licenses live and in real time, not through a one-time static grant - so revenue protection and audit trails work the same way they do for a connected customer.

• •

  Support the same range of models the vendor already sells elsewhere - named user, floating or concurrent, consumption-based, high and low water marks, overdraft - instead of forcing the vendor's best accounts into a stripped-down, perpetual-only fallback.

• •

  Deploy simply enough that the customer's own IT team can stand it up without a special exception process - fitting into infrastructure they already run and trust, rather than requiring a bespoke install.

• •

  Reconcile usage and billing data back to the vendor automatically whenever connectivity does become available, without requiring the site to stay connected in the meantime.

• •

  Avoid forcing the vendor to build and maintain a second, parallel licensing architecture just for this segment of customers - the same models, the same APIs, the same reporting, whether a customer is in the cloud or fully air-gapped.

Defense, government, financial services, and critical infrastructure customers are often some of the largest and stickiest accounts a vendor can land. They're also usually the first ones a licensing architecture quietly filters out - not because the product is wrong for them, but because a security review kills the deal before anyone gets to discuss price.

That's the part that's easy to miss: these losses rarely show up as a lost deal on a scorecard. They show up as accounts that never reach a demo, because procurement or security disqualified the vendor in the first round. Getting the licensing architecture right doesn't just make one difficult deployment easier - it's what makes an entire category of revenue reachable at all.

It's also, in practice, an engineering decision made under pressure rather than a deliberate one. Teams build a cloud-first licensing model, land a few customers who need something more restrictive, and patch together a workaround for each one - until they're maintaining several slightly different systems instead of one. That's a harder problem to unwind later than it is to plan for up front.

The most reliable path and solution is a licensing platform already built around this exact requirement set. Nalpeiron's Zentitle Local License Server runs inside a customer's own network as a Docker container, enforcing the same named-user, floating, and consumption-based models available in the cloud, with zero internet connection required.