Key-Warden runs on Microsoft Azure and is built so that vendor and customer data is encrypted in transit, encrypted at rest, and strictly segregated between vendors. Here is exactly how. For a plain-language explainer of the licensing model itself, see how licensing works.
Every connection is HTTPS. Everything stored is encrypted at rest on Microsoft Azure. Every vendor has their own signing key, sealed in Azure Key Vault and never handed out in plaintext. Every credential is scoped to a single vendor, so it can only ever reach that vendor's own data - and card details never touch our systems at all.
All traffic - the website, the portal, the licensing API at api.key-warden.com, and the SDK's validation calls - travels over HTTPS (TLS). On top of the transport layer, every licensing answer is an Ed25519-signed token, and denials are signed too: your product verifies the signature against an embedded public key, so a tampered, spoofed, or replayed response is rejected even if the network itself were compromised.
Licence, activation, customer, and vendor records are stored in the Key-Warden Back-End on Microsoft Azure, encrypted at rest by Microsoft-managed encryption. Cryptographic material - signing keys, API secrets, integration tokens - is held separately in Azure Key Vault. Private signing keys are not retrievable in plaintext by operators, by vendors, or by support: products embed only the public half, which cannot forge a signature.
Vendors run on shared, hardened Azure infrastructure; what keeps them apart is enforced at four layers. Cryptographically: every vendor has their own Ed25519 signing key, generated and sealed in Azure Key Vault - one vendor's key cannot sign licences for another's products, so even a mis-routed record could not produce a valid licence. At the gateway: API credentials are scoped to a single vendor, so a credential can only ever read or write its own licences, customers, and telemetry. In the registry: a lookup outside your own catalogue receives the same refusal whether or not the record exists - another vendor's records cannot be confirmed to exist, let alone read. In the payment vault: when you connect your own Stripe or PayPal account, those credentials are sealed with AES-256-GCM under a key derived for your vendor account alone, rooted in a vault separate from the platform's other secrets and reached only by managed identity. One vendor's derived key cannot open another's, and a sealed credential lifted out of your record and dropped into someone else's fails its authentication tag rather than decrypting.
Licence keys are never stored in plaintext: the registry holds only keyed one-way hashes, and the hashing secret lives in Azure Key Vault - a copy of the stored data alone cannot recover a single licence key. Vendor API client keys are stored the same way, one-way hashed. Device fingerprints are stored as one-way SHA-256 hashes of your machineId, so no raw machine identifier ever touches the registry.
Sign-in uses OpenID Connect through Microsoft Entra External ID - email, Google, or a passkey you add - and the website never exposes API keys to your browser: portal calls are proxied server-side and carry a signed identity assertion. Inside each account, access is role-based (vendor superadmin and developer roles; customer owner and viewer roles), invitations are claimed only by the invited email on first sign-in, and safety guards prevent an account from ever losing its last administrator. Administrative actions are audit-logged.
Card and payment details are processed by Stripe and PayPal under their own PCI-DSS compliance. Key-Warden never stores card numbers - our records hold the payment reference needed to reconcile an invoice, nothing more. Vendors may connect their own Stripe or PayPal account, in which case checkout for their products settles directly into that account. For Stripe we accept restricted keys only: a full secret key is refused server-side, not merely discouraged, so the credential you give us can take a payment and nothing else - it cannot read your customers, issue refunds, or reach your payouts. Stored credentials are never returned to anyone, including you: there is no reveal and no recovery, only replacement.
Validation calls carry only what licensing needs: a licence reference, product code, hashed device fingerprint, client version, and timestamp. No usernames, hostnames, file paths, or document contents. Source-code hardening (the obfuscation preview) runs entirely in your browser - your source is never uploaded to us or to any third party, and this site loads no third-party scripts or trackers.
To run the service we process the licence and activation records needed to enforce seats, expiry, and revocation, plus the contact details you give us for delivery and notices. See our Privacy notice for details, including erasure.
Key-Warden handles personal information in line with the Australian Privacy Principles and the principles of the GDPR: collect the minimum, use it only for licensing, keep it only as long as needed.
Key-Warden serves every asset from its own domain - nothing is loaded from public CDNs. The open-source components below are redistributed with their licence texts, which are included alongside the files.
Found something? Email welcometo@key-warden.com and we will respond promptly. Please give us a reasonable chance to fix an issue before disclosing it publicly.