I need to access a WibuKey USB dongle from another computer on my local network, but the licensed software only detects it on the host PC. What is the safest way to share the dongle while maintaining stable license access?
Don’t try to clone the dongle, pass it through Remote Desktop, or expose the USB-sharing port outside your LAN. Those approaches are either unreliable, insecure, or likely to violate the license terms.
The safest route is the official WibuKey network-server mode, if the software vendor enabled network licensing for that license. Install the matching WibuKey runtime/server components on the dongle host, allow the required service through the local firewall, then configure the client to search that server. If the license is locked to local USB access, the software vendor may need to issue a network-capable license.
When native sharing is unavailable, USB Network Gate can redirect the physical dongle to one client over the LAN. Use a dedicated wired host with a static IP, disable sleep and USB power saving, restrict access to the client machine, and avoid switching the dongle between clients while the application is running. Keep in mind that USB redirection cannot turn a single-seat license into a concurrent license, and confirm that this setup is allowed by the vendor before relying on it.
Don’t assume USB redirection will survive a network drop cleanly. If you use USB Network Gate, test how the licensed application handles disconnects before putting it into production, since some software needs a full restart before it sees the dongle again.
A WibuKey network license and a USB dongle forwarded over Ethernet sounded like the same setup to me, but they behave very differently. The first lets the client request a license from the host service. The second makes one remote computer act as if the dongle were plugged directly into it.
I would ask the software vendor which type your dongle actually supports before installing anything. If network licensing is enabled, use the official WibuKey server/runtime, confirm the client can find the host, and check how many seats the license allows. Test it after rebooting the host with nobody logged in, since that catches service-startup problems that a quick test can miss.
If the vendor says it is local-only, USB Network Gate may work, but only one client should claim the dongle at a time. @hyp3r_falcon’s warning matters here because a brief LAN interruption can look like someone physically pulled the key out. I would keep the host wired, prevent sleep, and avoid mixing official network-server mode with USB redirection drivers unless the vendor specifically approves that setup.
The network layout matters more than it sounds. License-server discovery may work on the same subnet and then fail when the client sits on another VLAN, VPN, or guest Wi-Fi. A firewall exception on the host does not automatically make discovery traffic cross those boundaries.
For official WibuKey network mode, I would give the host a DHCP reservation, configure the client with the server’s address or hostname instead of relying only on automatic discovery, and limit the firewall rule to the client subnet. A manually specified server is usually less mysterious than waiting for broadcast discovery to find it. Make sure the WibuKey service runs before anyone signs in, and test the application from a cold boot rather than only after opening the WibuKey control panel on the host.
Be careful about updating the runtime just because a newer installer exists. Older licensed applications are sometimes certified against a particular WibuKey runtime, and replacing it can create a new problem while fixing the network issue. Get the supported version from the software vendor, save the existing configuration, and keep the old installer available before changing drivers.
I agree with @datanode7665 that the license type needs to be confirmed first. The useful question for the vendor is not merely “Can this dongle be shared?” Ask whether that specific license supports WibuKey network-server operation, how many simultaneous users it permits, and whether the client needs a manually configured server address. That wording tends to avoid the unhelpful answer that the dongle “works over a network” without explaining how.
If it is strictly a local USB license, USB Network Gate is a fallback rather than a license server. In that case, treat the connection like a long virtual USB cable: assign it to a single client, block other machines from attaching, and expect the application to react badly if Wi-Fi drops or the host reboots. I would avoid using that setup for a machine controlling production equipment unless the software vendor explicitly supports reconnection.
For day-to-day stability, the boring details matter: wired Ethernet, no sleep or USB selective suspend, automatic service startup, a small UPS if outages are common, and a documented way to reconnect after maintenance. Do not leave the dongle-sharing interface reachable from the internet, even behind a password. If remote access is needed, connect through a VPN first and keep the actual sharing service restricted to the LAN.
Picture two setups. In one, someone shares a dongle to a workstation that runs the licensed app for an hour a day, occasional CAD or reporting, nobody cares if it hiccups. In the other, the same dongle feeds a machine that’s cutting metal or running a test bench. Same USB key, same software, completely different tolerance for a dropped connection. Which case you’re in decides almost everything, and I don’t think the thread has said that plainly enough.
The license-type question from @datanode7665 is the right first step, no argument there. But I’d add a second question that gets skipped: what does the vendor say when the dongle goes missing mid-session? Some licensed apps re-check the key every few minutes, some grab it once at launch and never look again. That behavior matters more than whether you used network mode or a redirection tool, because it tells you how badly a LAN blip will actually hurt you. Cheapest way to find out is to just yank the USB key while the app is running on the host and watch what happens. If it screams, redirection over a network will scream the same way.
USB Network Gate is fine as the fallback everyone’s describing, and @0xowl3’s ‘long virtual USB cable’ framing is honest. I’d only push back slightly on treating it as a last resort for every case. If your vendor confirms one seat and you genuinely only ever need one client at a time, redirection is often less fuss to set up than getting a vendor to reissue a network license, which can take days and sometimes a support fee. So for a single low-stakes user it can be the practical choice, not just the desperate one.
The thing nobody’s mentioned: keep a written note of what license you actually paid for. If a vendor ever audits and sees a single-seat dongle being reached from a second machine, ‘we were only ever using one at a time’ is a much easier conversation when you can show it in writing that you asked them first. Get the yes in an email, not just a phone call.
And I’ll second the wired-plus-no-sleep advice without repeating it. That’s the boring part that quietly saves you, especially the USB selective suspend setting, which loves to switch itself back on after a Windows update.
A crashed client can leave the license looking occupied even after the application window is gone. Before deployment, test how the WibuKey server releases a seat after an app crash, client reboot, and cable pull, then document whether recovery needs a timeout or service restart.
I’d still choose official network-server mode when the vendor supports it, but make sure someone can view active license allocations on the host. With USB Network Gate, there is no seat management, so disconnect the device cleanly before another client claims it or you may end up rebooting both machines.
The dongle itself tells you whether network mode is even on the table, so you don’t have to sit blind waiting for the vendor to answer. Open the WibuKey control panel on the host, look at the entries programmed into the key, and check the network settings there. WibuKey stores a network access count in the dongle memory. If that number is zero, no amount of server configuration will hand out a seat across the LAN, and that’s your answer before you install anything. If it’s one or more, the network server path is real for you. This isn’t a substitute for confirming license terms in writing, but it stops the guessing.
On @datanode7665’s point about the two setups behaving differently, that’s the correct framing and it’s the thing most people trip over. The WibuKey server is not a separate product you go buy. It’s a mode. The same runtime can run as a server on the host and the client just points its subsystem at that machine. So when someone says ‘the vendor needs to reissue a network license,’ that’s sometimes true and sometimes not. It depends on what’s already burned into the dongle. Ask the vendor the count, not just whether it ‘works over a network.’
Where I’d push back a little is the tone around USB Network Gate being either a last resort or a quiet convenience. Both camps in this thread are right for different keys. If your dongle has network entries, redirection is the worse choice, full stop, because you’re taking something that already shares cleanly and forcing it through a virtual USB layer that breaks on every hiccup. If your dongle has zero network entries and the vendor won’t reprogram it, then redirection is your only option and the arguments about stability from @hyp3r_falcon and @stacklynx8203 all apply. So the tool mentioned above earns its place only after you’ve read the entry count. Check first, then decide.
Two smaller things nobody flagged:
-
WibuKey and CodeMeter are different Wibu systems. If your software is newer it might actually be CodeMeter with a CmDongle, and the whole network story there is handled differently through the CodeMeter WebAdmin interface. Make sure you’re troubleshooting the right one before you install a WibuKey server on a machine that never needed it.
-
The WibuKey network subsystem uses a specific UDP port for server discovery and TCP for the actual license traffic. If you lock the firewall to just the client subnet like @0xowl3 suggested, good, but make sure you allow both directions of that traffic and not only the inbound TCP. A half-open rule looks fine until the client can’t find the server and you burn an afternoon on it.
For the practical order of operations I’d run it like this: read the dongle entries, confirm the count and terms with the vendor in email, and only if the count is zero and they won’t budge do you reach for redirection. That keeps you out of the fragile setup unless you genuinely have no other door.