It looks elegant. It is fast. It even compiles. And it is, almost without exception, the wrong choice. This article explains exactly why, and what to use instead.

The naïve approach

The textbook version of "encrypt my license key" usually looks like this:

KEY        = KEY_DATA | ENCRYPTED(HASH(KEY_DATA))
ENCRYPTED  = AES-128 / Blowfish / 3DES / "rolled my own"
SECRET KEY = a constant compiled into the product binary

To validate a key at runtime, the product:

1. Splits the key into the data portion and the encrypted-hash portion.
2. Hashes the data portion locally.
3. Decrypts the encrypted-hash portion with the secret embedded in the binary.
4. Compares. If they match, the key is "authentic".

This is, structurally, a poor man's digital signature — except that the "signing key" and the "verification key" are the same secret, and that one secret has to live inside every copy of your product you have ever shipped.

The "secret in the binary" fiction

If you have spent any time around reverse engineering, you already know where this is going. A symmetric key sitting inside a shipped executable is not secret. It is, at most, lightly obscured.

A determined attacker with Ghidra, IDA, or dnSpy needs hours, not weeks, to:

• Identify the validation routine (it has a recognisable shape: hash, decrypt, compare).
• Set a breakpoint on the decryption function call.
• Read the key out of memory or out of the static-data segment.

Obfuscation, code packing, anti-debug tricks, white-box cryptography — none of them change the fundamental problem. They raise the cost from a single afternoon to a few afternoons. For a product worth pirating, that is not nearly enough.

The blast radius is your entire customer base

The really bad part is what happens after the secret leaks. With a symmetric scheme:

• The leaked key is the same key every customer's installation uses to validate. There is no per-customer rotation possible after the fact.
• Anyone who downloads the leaked secret can mint unlimited working license keys instantly. Keygens appear on warez sites within days.
• Your only remediation is to change the secret and ship a new build, and hope every paying customer upgrades quickly. In the meantime, support is flooded with calls from legitimate buyers whose newly-purchased keys do not work in their old installation.

The economics are brutal. One reverse-engineering session, one keygen post, and your licensing system is permanently compromised for every version of the product currently in the wild. A new release does not undo the damage to the old one.

And then there is the key length problem

Even setting aside the security disaster, the most common symmetric algorithm of the modern era — AES — is structurally unsuitable for short license keys. AES has a 128-bit block size. The smallest possible AES ciphertext is 16 bytes. Add a hash payload to it and you are already at 32 bytes of binary data, which becomes 52 characters in Base32 — and that is before you add any product-side payload like edition, expiry, or seat count.

No customer wants to type a 52-character key from a printed invoice. No support agent wants to read one over the phone. The block-size mismatch alone is a usability killer.

Older 64-bit-block ciphers like Blowfish at least produce short enough output to be typeable, which is why you still occasionally see them in legacy licensing libraries. The reverse-engineering problem, of course, is identical.

What you actually want

The thing developers reach for symmetric encryption to do — produce a small payload that the product can confirm was issued by you — is a textbook description of a digital signature. The key insight is that signing and verification can use different keys:

• The private key stays on your build server. It never ships. It generates new license keys.
• The public key ships inside every copy of your product. It can verify signatures, but it cannot create new ones.

A leaked public key is worthless to a pirate. They can use it to verify keys to their heart's content, but they cannot mint new ones. The catastrophic "single secret protects every install" failure mode of symmetric schemes disappears completely.

The standard objection is signature size — a 2048-bit RSA signature is 256 bytes, which is far too large to be a typeable license key. That is true, and it is the reason naïve developers go back to symmetric encryption in the first place. The actual answer — short signatures with strong security — is elliptic-curve cryptography, and we cover it in detail in the follow-up article: ECC vs RSA for License Keys.

Bottom line

If your license-key system uses the same secret to issue keys and to validate them, you are one reverse-engineering session away from shipping a free keygen with your product.

Use digital signatures. Keep the private key off the customer's machine. The moment you internalise this, every other licensing decision gets easier.

For a deeper walkthrough of the full design space — including hardware fingerprinting, online activation, and how to keep the resulting keys short enough to type — see our pillar guide: How To Generate License Keys Securely.

If you would rather skip the cryptography homework and ship something that already gets this right, the SoftActivate Licensing SDK includes the full ECC-based key generation pipeline (with C++ and C#/.NET source code) and an interactive license designer you can experiment with in your browser.

Those features matter, but the deployment model of the licensing server matters just as much. Specifically: should your licensing server run on your own infrastructure, or should it be delivered as a SaaS service?

There is no universal winner. The right answer depends on your compliance requirements, your operational maturity, the type of customers you sell to, and how much control you want over upgrades and data residency.

This post lays out the trade-off clearly so you can choose a model that fits your business rather than copying whatever is fashionable.

Start with the real question: who should operate the licensing infrastructure?

At a high level, both models can deliver the same licensing outcomes:

• issue and validate license keys
• activate machines online
• enforce seat or device limits
• manage subscriptions and renewals
• expose admin tools for support and sales teams

The real difference is who operates the service boundary.

With an on-premises licensing server, you run the server stack yourself. Your team owns deployment, patching, backups, uptime, database maintenance, monitoring, and access control.

With a SaaS licensing server, the vendor runs that infrastructure for you. Your team consumes the service through a browser UI and APIs, while the vendor handles hosting, upgrades, scaling, and most operational maintenance. That is the core distinction reflected in general SaaS vs on-prem guidance from AWS and others: SaaS removes most infrastructure management from the customer, while on-prem keeps that responsibility in-house.AWS

If your team frames the decision that way, the trade-offs become much easier to reason about.

When on-premises is the better choice

On-premises licensing infrastructure is usually the right fit when control is not a preference but a requirement.

1. You have strict compliance or data-residency constraints

Some vendors serve customers in defense, government, industrial control, healthcare, or other regulated environments where data location and network boundaries are heavily controlled. In those settings, even a well-run SaaS may be difficult to approve.

If activation logs, customer records, device fingerprints, or audit trails must stay inside a defined environment, an on-prem deployment is often the simplest path through procurement and security review.

2. Your customers expect private deployment options

Enterprise buyers do not all want to depend on a third-party cloud service for license enforcement. Some insist that critical operational dependencies remain within infrastructure they control, especially when software must function inside isolated or low-connectivity networks.

For vendors selling into those accounts, on-prem is less a technical decision than a sales-enablement decision.

3. You want full control over upgrades and change windows

A SaaS model usually means the platform evolves on the vendor's timetable. Even if changes are well-managed, you are still downstream of someone else's release calendar.

On-prem gives you tighter control over:

• when to roll out updates
• when to rotate credentials or certificates
• how to integrate with internal identity systems
• how long to keep compatibility with legacy application versions

That can matter if licensing is embedded into long-lived desktop or industrial software with conservative release cycles.

4. You already have strong internal ops capability

If you already operate customer-facing infrastructure reliably, adding a licensing server may not be a major burden. Teams with established DevOps, security, database, and monitoring practices can often absorb an on-prem deployment more comfortably than smaller vendors expect.

In that situation, the extra control may outweigh the operational cost.

When SaaS is the better choice

SaaS is usually the better option when speed, elasticity, and reduced operational burden matter more than absolute infrastructure control.

1. You want to launch quickly

A SaaS licensing server removes a long list of tasks from the critical path:

• provisioning servers
• configuring backups
• setting up monitoring
• hardening the public surface
• planning database maintenance
• staffing for uptime and patch response

That can cut weeks or months from an initial rollout. Broad industry guidance consistently highlights lower setup overhead and easier scaling as core SaaS advantages.AWS LeanIX

2. Your team is small

Many software companies do not want to become infrastructure operators just to issue license keys and handle activations. If your engineering team is focused on the product itself, SaaS lets you keep that focus.

That is especially attractive for startups and mid-sized ISVs where one senior developer often ends up owning every "temporary" internal service forever.

3. Your demand is uneven or growing fast

Activation traffic is not always steady. A new release, a large reseller deal, or a migration campaign can create bursts of load. SaaS platforms are generally easier to scale because the underlying capacity is managed by the provider rather than procured and installed by your team.AWS

If you expect growth, seasonality, or unpredictable spikes, that elasticity has real value.

4. You want the vendor to own routine maintenance

A well-run SaaS licensing platform should absorb much of the repetitive operational work:

• applying security patches
• managing availability and failover
• upgrading the admin console
• tuning performance
• handling backups and recovery procedures

That does not remove the need for vendor due diligence, but it does move a significant amount of work off your plate.

The practical trade-offs, side by side

Here is the simplest way to think about the decision:

That table is intentionally boring, because boring is useful here. Most bad decisions happen when teams over-romanticize one model instead of evaluating who will carry the cost.

A licensing-specific lens: what matters beyond generic SaaS vs on-prem debates

The licensing-server decision has a few wrinkles that do not always show up in generic software deployment comparisons.

Activation reliability matters at the worst possible moment

When a licensing server fails, the failure is customer-visible immediately: new activations break, seats cannot be reassigned, trials may not convert cleanly, and support starts taking calls.

That means your choice is not just about cost. It is about who you trust to meet the operational bar for a service tied directly to revenue recognition and customer onboarding.

Offline fallback changes the equation

If your product supports offline activation or over-the-phone activation, the pressure on always-on connectivity is lower. In the SoftActivate Licensing SDK, the platform supports both online activation and offline scenarios, which can reduce dependence on a constantly reachable public endpoint for some use cases.README

That does not eliminate the need for a server, but it can make the deployment choice less binary. Some vendors keep the main licensing workflow online while preserving offline fallback for high-friction environments.

Multi-tenant and reseller models push many vendors toward SaaS

If you operate across multiple brands, resellers, or customer partitions, centralized administration becomes more valuable. The current SDK notes optional multi-tenant support for SaaS providers and resellers in its server architecture, which is a strong hint about where hosted models gain leverage operationally.README

If your business model depends on central visibility across many tenants, SaaS often becomes more attractive.

Choose on-premises if these statements sound like you

On-prem is usually the better fit if most of the following are true:

• you sell into tightly regulated or air-gapped environments
• you need strong control over where licensing data lives
• your customers expect self-hosted or private deployment options
• you already have capable internal ops and security teams
• you need custom integration with internal identity, network, or audit systems
• your release cadence is conservative and you want explicit change control

In short: choose on-prem when control, compliance, or deployment sovereignty outweigh convenience.

Choose SaaS if these statements sound like you

SaaS is usually the better fit if most of the following are true:

• you want to launch without building operational plumbing first
• your team is small and product-focused
• you want the vendor to handle scaling, patching, and uptime
• your customers are comfortable with cloud-delivered back-office services
• you expect growth, bursty activation traffic, or multi-tenant operations
• you value faster iteration over strict control of every infrastructure layer

In short: choose SaaS when speed, leverage, and lower ops overhead outweigh the need for full infrastructure ownership.

The answer for many vendors is not ideological but hybrid

A lot of software vendors end up needing both.

They use a hosted licensing environment for most customers because it is faster to operate and easier to scale, while preserving an on-premises option for enterprise accounts with strict procurement or security constraints.

That hybrid path is often the most commercially realistic one:

• SaaS for default deployments
• on-prem for regulated or high-control customers
• offline activation support for edge cases and disconnected environments

If you can support that without fragmenting the product, you get the sales flexibility of on-prem and the operational efficiency of SaaS.

Bottom line

The best choice is not "modern" versus "traditional." It is who should own the operational risk of your licensing infrastructure.

Choose on-premises if your business needs maximum control, private deployment, strict data handling, or enterprise-specific integration.

Choose SaaS if your priority is faster rollout, easier scaling, and avoiding the long-tail cost of running infrastructure yourself.

And if your market spans both startups and regulated enterprises, plan for a model that can serve both.

For the bigger licensing design picture — including secure license-key generation, activation flows, and how client-side verification fits into the stack — start with How To Generate License Keys Securely. For a closer look at the cryptographic side of compact, verifiable license keys, see ECC vs RSA for License Keys.

That settles the security question. It immediately raises a usability one: which signature algorithm fits inside a license key short enough to type from a printed invoice?

This post walks through that decision in detail, contrasting RSA and elliptic- curve cryptography (ECC), and explains why every modern licensing SDK that takes both security and UX seriously ends up on ECC.

Recap: what we are signing, and what we are sending

A license key, broken down to its essentials, is a tuple:

KEY = KEY_DATA | SIGNATURE(KEY_DATA)

Where KEY_DATA carries the bits the product needs to know — edition, seat count, expiry, customer id — and SIGNATURE(KEY_DATA) is what proves the publisher generated it.

Both pieces have to be encoded into a typeable string, almost always Base32 (5 bits per character, with confusing characters like O, 0, I, 1 removed). Total key length in characters is therefore ceil((data_bits + signature_bits) / 5).

The signature is the dominant term by far.

Trying RSA first

RSA is the digital-signature algorithm most developers learned in school. It is well-understood, has excellent library support, and the security analysis is mature. So let's see what an RSA-signed license key would actually look like.

The current public recommendation for new RSA deployments is a 2048-bit modulus (1024-bit is considered broken; 3072-bit is recommended for long-lived data). A 2048-bit RSA signature is exactly 256 bytes — that is the modulus size, by definition.

Encoded in Base32, 256 bytes becomes:

ceil(256 * 8 / 5) = 410 characters

For just the signature. Add even a tiny 8-byte payload and you are at 422 characters, formatted into 84 groups of 5. No human will type that. No support agent will read it over the phone. No reseller will fit it on a postcard.

You can shave a little off with truncated hashes (which weaken the scheme) or deterministic ECDSA-on-RSA hybrids (which do not exist). The fundamental issue is the modulus size, and it is not negotiable for security reasons.

This is why the few products that try to use RSA for licensing fall back to license files instead of license keys — a binary blob you double-click, or a multi-line Base64 dump you paste into a textbox. License files solve the size problem, but they introduce their own usability disasters: you cannot read them over the phone for activation; resellers cannot include them on a sticker or printed certificate; "I lost my license file" becomes a daily support ticket; and refunds spike.

ECC: equivalent strength, a fraction of the bytes

Elliptic-curve cryptography produces digital signatures that are cryptographically equivalent to much larger RSA signatures. The widely-cited NIST equivalence table:

Read the third row carefully: a 256-bit ECC key gives the same security as a 3072-bit RSA key — 12× smaller, with the security level current guidance recommends for newly-deployed cryptography.

For signature size, the typical Schnorr-family ECC signature is roughly 2 × field_size bits. A 160-bit curve produces a ~40-byte signature. That is 64 Base32 characters. Drop in a small payload, format into groups of 5, and you are looking at a 25-30 character key — exactly what users expect.

The Schnorr twist that keeps keys distinct

There is a subtler reason ECC (specifically Schnorr-style signatures over ECC) wins for licensing — one that is rarely discussed but matters a lot in practice.

Most signature schemes are deterministic: same input, same key, same signature. That is a problem for license keys, because two customers who happen to buy the same product edition on the same day would receive identical keys. To avoid this, deterministic schemes have to either:

• Add a random salt to the payload (which inflates the data portion), or
• Add a customer-specific field like email or order id (which ties the key to per-customer data and complicates reseller workflows).

Schnorr signatures, by contrast, are non-deterministic by design: the signing process picks a random nonce, and there are exponentially many valid signatures for the same payload under the same private key. Two customers buying identical SKUs get different keys, and the data portion stays minimal.

This single property is the reason a SoftActivate-style key can carry only a few bytes of payload (edition + flags) and still be unique per customer.

The patent landscape (briefly)

ECC has a famously thorny patent history. Most of it is now expired or never applied to the variants used in licensing. The combination this SDK uses — ECC over GF(2^n) with a polynomial basis representation, signed with Schnorr (whose key patent expired in 2008) — is unencumbered by Certicom's historical claims.

Curves over prime fields (the kind used by ECDSA, EdDSA, secp256k1) are similarly free of active patents at this point. If you are evaluating licensing libraries, "uses ECC" is no longer a red flag the way it was in the early 2000s.

A worked example

Here is what a real ECC-signed license key looks like, broken down:

KEY:  M9Y2P-K3HFQ-X7TBR-NCAS4-VGW8E-J5DUZ
            └─ 30 chars × 5 bits = 150 bits total
            ├─ 10 bits payload (edition, flags)
            └─ 140 bits Schnorr signature over GF(2^160)

The customer types 30 characters. The product runs ~5 ms of ECC verification on first launch, caches the result, and never bothers them again. Cryptographically, an attacker would need to forge a Schnorr signature over GF(2^160) without the private key — currently estimated at ~2^80 operations, which is computationally infeasible. The product binary contains only the public verification key. Even a perfect reverse-engineering of the binary yields no ability to mint new keys.

That is the entire point of using public-key cryptography for licensing.

Bottom line

If you want typeable, secure, per-customer-distinct license keys, ECC with a Schnorr-family signature scheme is not just a good choice — it is effectively the only viable choice. RSA is fine if you are willing to live with license files; for everyone else, ECC wins on every axis that matters.

For the full design context — hardware fingerprinting, activation servers, expiring licenses — see the pillar guide: How To Generate License Keys Securely.

The SoftActivate Licensing SDK ships an ECC-over-GF(2^n) + Schnorr implementation with full C++ and C#/.NET source code, so you can read every line of the verification routine that ends up inside your shipped binary — which is, incidentally, exactly the level of transparency you want from anything guarding your revenue.