Two constraints shape licensing for medical software: networks you do not control, and a quality system that documents everything you ship. Both point the same way — toward licensing that works offline and can be pinned down on paper.
Clinical networks are locked down
Hospital IT segments clinical systems away from the internet as deliberately as factories isolate their production networks, and a workstation in a clinic cannot fail because an activation server was unreachable at seven in the morning. A KeyNub verifies locally — challenge–response against keys in a secure element on the dongle — so there is no phone-home, no grace period to explain to a clinician, and no firewall exception to negotiate with the hospital.
What your quality system will ask for
If your product is developed under IEC 62304 or heading into a regulatory submission, every third-party component becomes an entry in your SOUP documentation, and vague vendors make that chapter painful. KeyNub keeps it short: the SDK’s bindings, samples and C ABI header are published under Apache-2.0, releases are versioned and carry SHA-256 checksums, and a security policy with a disclosure channel is part of the repository. You can state exactly what you shipped, where it came from and how you verified it. To be equally clear about the boundary: KeyNub is not itself a certified medical component — it is a licensing library you document like any other SOUP item. We just make sure everything that chapter needs is already written.
No patient data on the key
The dongle stores license records, counters and cryptographic keys — nothing else, by construction. It has no reason to ever see patient data, so the answer to “what personal data does this component process?” is none, and your privacy analysis stays a paragraph instead of a section.
Configurations, options and long lifetimes
Medical platforms ship as one product in many configurations — modalities, analysis modules, station counts — and those configurations are records on the key: field service enables an option with your vendor authorisation instead of reinstalling software in a clinical environment. Support horizons of ten years and more are normal here, and because nothing about verification depends on a server — ours or yours — year twelve works exactly like day one.
Delphi and .NET country
Medical desktop software runs disproportionately on Delphi and .NET, with C++ where devices are involved and Python in the research tooling around them. Each binding is documented with a runnable sample, so the integration your auditors will read is short and boring — which is the highest compliment that code can earn.
All industries · All supported languages · Buy a KeyNub · Ask us something
