How MintEncoder Works
What it does, how your data is handled, and why we designed it the way we did.
CONTENTS
What MintEncoder Does
The Features page introduces MintEncoder at a high level. Here, we take a closer look at each capability, how it works in practice, and the real-world problems it was designed to solve.
Unlimited Products, No Code Changes
Many licensing systems are designed around a single product. As soon as a second product, edition, or service is introduced, code changes become necessary and the licensing system begins to dictate how the business operates.
MintEncoder was designed differently.
New products can be added directly from the application without modifying code, recompiling software, or redeploying the licensing system. Once a product has been created, licences can be minted immediately using the same signing infrastructure, audit trail, backup strategy, and recovery processes already in place.
This allows software publishers to launch new products, introduce additional editions, or expand their portfolio without requiring changes to the licensing platform itself.
The signing engine is deliberately product-agnostic. Rather than maintaining a hard-coded list of supported products, MintEncoder uses the product information supplied at the point a licence is minted. This removes a common growth limitation found in many licensing systems and allows the licensing platform to scale alongside the business.
Seat-Based or Domain-Based Licensing
Different software products often require different licensing models.
Some products are licensed by the number of users, devices, or seats permitted under the licence. Others are licensed against a specific customer domain, website, or environment. Forcing every product into a single licensing model often leads to unnecessary complexity for both the software publisher and the customer.
MintEncoder supports both seat-based and domain-based licensing on a per-product basis.
When creating a product, you can choose the licensing model that best fits your commercial requirements. Each licence minted for that product is then validated according to the licensing rules you have defined.
This flexibility allows organisations to use a single licensing platform across multiple products, even when those products have very different licensing requirements.
Whether you are licensing desktop software to a fixed number of users, web applications tied to a customer domain, or a mixture of both, MintEncoder allows each product to be licensed in the most appropriate way without requiring changes to the licensing system itself.
Minting and the Licence Log
Every licence minted by MintEncoder is permanently recorded in the Licence Log.
Each entry contains the information used when the licence was created, including the customer details, licence type, product, restrictions, expiry date, and the licence key itself.
The Licence Log serves as the authoritative record of what was issued, when it was issued, and to whom it was issued. This makes it possible to review historical licences, regenerate licence certificates, retrieve licence keys, and investigate queries long after a licence was first created.
Immediately after minting a licence, its details can be viewed directly from the Licence Minted confirmation screen. Existing licences can be accessed at any time through the Licence Log.
We deliberately designed the Licence Log as a permanent ledger rather than a temporary activity list. If a customer disputes the terms of a licence, loses their licence certificate, or requests historical information, the Licence Log provides a reliable record of exactly what was issued.
This approach helps software publishers maintain consistent records while reducing the operational overhead associated with managing licensing information across multiple documents, spreadsheets, or external systems.
Key Management and Rotation
Signing keys can be generated, activated, and archived without invalidating licences that have already been issued.
Keys age, people leave, systems change, and security requirements evolve.
MintEncoder was designed so that rotating a signing key is a routine maintenance task, not a high-risk migration project that could affect every licence you have already sold.
Per-Product Release History
Every product keeps its own version and changelog history, separate from your MintEncoder installation’s own version. Register a new version whenever you ship an update, and Mint Licence automatically offers that product’s current version rather than leaving you to remember and retype it every time.
We built this because the alternative — a plain text box with no memory behind it — meant version numbers were only ever as reliable as whoever happened to be typing them that day.
Trial and Subscription Licensing
Trial licences behave exactly like Subscription licences. They use the same signing process, the same verification process, and the same security model.
The only practical difference is the duration of the licence and the usage rights you choose to grant.
We deliberately avoided creating a separate or simplified licensing path for trial licences. By treating Trial and Subscription licences consistently, customers experience the same activation and validation process regardless of which licence type they receive.
This approach ensures that a licence which works correctly during a trial period will continue to work in exactly the same way when a customer upgrades to a subscription licence.
How Your Data Is Handled
Everything Stays Local
MintEncoder was designed to operate entirely under your control.
Your products, licences, signing keys, audit history, and application data remain on your own infrastructure. There is no cloud service, external processing platform, or third-party dependency involved in day-to-day operation. Nothing is transmitted anywhere unless you deliberately choose to create a backup, export a Recovery Key, or distribute a licence to one of your customers.
This approach provides complete ownership of your licensing environment while reducing reliance on external services, internet connectivity, or third-party providers.
For organisations with security, privacy, compliance, or data sovereignty requirements, keeping licensing operations entirely local can also simplify governance and reduce unnecessary risk.
PDF Certificates Are Never Stored Permanently
PDF licence certificates are generated on demand whenever you choose to view, print, or distribute one.
Rather than maintaining a permanent archive of customer documents, MintEncoder treats the Licence Log as the authoritative source of licence information. Each PDF is generated using the latest information available at the time it is requested.
Generated PDFs are written to a temporary working folder and are automatically removed when MintEncoder closes.
This approach reduces the risk of customer information being left behind in forgotten files, duplicate document stores, or temporary working locations. It also ensures that licence certificates can always be regenerated from the authoritative data held within MintEncoder, rather than relying on previously saved PDF copies.
In short, MintEncoder stores the licence information, not a permanent collection of customer documents.
Backups Are Scoped to What Matters
MintEncoder distinguishes between application files and customer-specific assets.
Application files such as executables, libraries, images, and other bundled resources are identical for every customer running the same version of MintEncoder and can be restored by reinstalling the software if required.
Automatic backups focus on the assets that are unique to your MintEncoder environment and cannot simply be recreated by performing a new installation.
This includes the MintEncoder database, signing keystore, application configuration, and installed licence.
By concentrating on the information that is unique to your organisation, automatic backups remain small, fast, and efficient while still providing everything required to recover a working MintEncoder environment.
As your licensing environment grows, backup size remains proportional to your actual data rather than the size of the application installation.
Backup Resilience
MintEncoder’s automatic backup system is designed around resilience rather than simple duplication.
Automatic backups can be scheduled to run at a defined time and written directly to one or two independent backup locations.
Each backup is created separately in its destination location rather than being generated once and copied elsewhere. This allows each backup destination to be validated independently.
Because each backup is created independently, MintEncoder compares the resulting backup files to identify unexpected differences between them.
A configurable tolerance buffer allows for normal variations caused by timestamps, storage performance, network latency, and other environmental factors.
This approach helps identify situations where a backup destination may be incomplete, unavailable, corrupted, or otherwise diverging from the expected result, even though backup operations appear to be succeeding.
Put simply, MintEncoder treats a successful write as a claim to be checked, not a fact to be assumed.
The objective is not simply to maintain multiple copies of the same backup, but to provide confidence that independent backup destinations are each receiving a valid representation of the MintEncoder environment.
Security, By Design
Cryptographic Signing, Not a Password Check
Many licensing systems rely on hidden serial number formats, password checks, or validation rules embedded within the application itself. Once those rules are discovered, licences can often be copied, altered, or generated without authorisation.
MintEncoder takes a different approach.
Every licence is digitally signed using a private signing key that only you control. When your application validates a licence, it is not checking whether a password matches an expected value. Instead, it is verifying a cryptographic signature that proves the licence was issued by an authorised source and has not been altered.
To the end user, a licence key may look like nothing more than a random string of characters:
wefioregnerkngmkl54-0igg234t,’grtkc9j]3gj31fjgjpjh45piut-0gtklmfvekqrjgqg
- Customer: John Smith
- Email: john.smith@example.com
- Licence Type: Subscription
- Expires: 31/12/2027
Because licences can contain customer-specific information, they can also help discourage licence sharing by clearly identifying the intended licence holder.
Attempting to modify a licence, extend its validity period, change customer details, or generate a licence outside of MintEncoder will cause the signature verification process to fail.
The result is a licensing system that does not rely on secrecy, hidden algorithms, or obscured validation logic. The licence either carries a valid signature or it does not.
For software publishers, this provides a clear and reliable way to distinguish genuine licences from licences that have been copied, modified, or created without authorisation.
Signing Is Kept Deliberately Separate
Many licensing systems tightly couple licence generation, key management, and application logic into a single codebase. While this may seem convenient initially, it often makes future maintenance, upgrades, and integration significantly more difficult.
MintEncoder was designed with a clear separation between licence management and licence signing.
The signing engine is responsible for generating and validating cryptographic signatures. MintEncoder is responsible for managing products, customers, licences, auditing, backups, and recovery operations.
By keeping these responsibilities separate, the signing process remains focused, predictable, and reusable, while the surrounding application can continue to evolve without affecting the integrity of previously issued licences.
This separation also simplifies integration into customer applications. Your software only needs to validate the signed licence presented to it and does not need access to MintEncoder itself, the signing keys, or the internal licensing database.
The result is a cleaner architecture, reduced operational risk, and a licensing platform that can grow independently from the software products it protects.
Keys Are Bound to the Machine That Created Them
Signing keys are among the most important assets in any licensing system. If they are copied to another machine, an attacker could potentially generate licences that appear genuine.
For this reason, MintEncoder protects signing keys using Windows Data Protection API (DPAPI) technology and binds them to the machine on which they were created.
This means that copying the signing keystore to another workstation, virtual machine, or server does not provide access to the underlying signing keys. The protected keystore remains tied to the Windows environment that created it.
In practical terms, the keystore becomes associated with the host machine that created it. Possessing a copy of the file on another system does not provide access to the signing keys it contains.
This approach provides an additional layer of defence beyond ordinary file permissions. Possession of the keystore file alone is not sufficient to use the signing keys it contains.
Where multiple authorised users share a dedicated MintEncoder workstation or virtual machine, each user can continue to authenticate using their own Windows credentials while the signing keys remain bound to the host machine.
The result is a licensing environment that supports operational flexibility without sacrificing control of the cryptographic material used to issue licences.
The Recovery Key: Deliberately Separate From Routine Backups
Normal backups protect the environment.
Recovery Keys protect the ability to sign.
Failure was one of the primary design considerations behind MintEncoder.
Hardware fails. Disks fail. Virtual machines fail. Files are deleted. Backups are misplaced. Disaster recovery was treated as a non-negotiable core requirement from the very beginning, not a feature added later.
Recovery Keys are designed to contain every signing key pair known to MintEncoder at the time they are exported. This is why MintEncoder requires a new Recovery Key to be exported whenever a new signing key pair is generated. Without exporting an updated Recovery Key, the newest signing keys would not be available during a future recovery operation.
Routine backups are designed to protect the MintEncoder environment, including the database, configuration, and day-to-day operational data.
This separation is deliberate. Possessing a routine backup alone is not sufficient to recreate signing capability on another machine. To restore or transfer signing capability, a Recovery Key must first be exported and then unlocked using the password chosen when it was created.
By separating environment recovery from signing-key recovery, MintEncoder helps ensure that disaster recovery remains possible without making signing capability unnecessarily portable.
Deploying MintEncoder Across a Team
If more than one person needs to mint licences, we recommend hosting a single MintEncoder installation on a dedicated workstation or virtual machine, with each user signing in using their own Windows credentials.
This approach provides a single, controlled signing environment while maintaining individual accountability.
Every licence minted, key pair generated, and product created is recorded against the Windows account that performed the action, creating a clear audit trail of administrative activity.
MintEncoder’s signing keystore is protected at the machine level.
In practical terms, the keystore becomes associated with the host machine that created it. Possessing a copy of the keystore file on another system does not provide access to the signing keys it contains.
This allows multiple authorised users to access the same MintEncoder environment without duplicating signing keys across multiple workstations, servers, or user profiles.
For organisations with governance, security, or compliance requirements, this model provides a practical balance between operational flexibility and cryptographic control: multiple authorised users, a single controlled signing environment, and a complete audit trail of who performed each action.
Administrator Lock: Protecting the Settings That Matter
Individual Windows accounts give you accountability — you always know who did what. They don’t, by themselves, stop a well-meaning but inexperienced team member from changing a backup location, generating a new signing key, or altering system settings they didn’t fully understand the consequences of.
The settings that determine whether your business can keep issuing licences — backup locations, the auto-backup schedule, Recovery Key management, system configuration, and signing key generation itself — can be locked behind a single administrator password, shared only among the people you’ve decided should be able to change them.
Setting the password up asks for a Recovery Email address, then emails a confirmation link to it before the lock ever activates. That’s deliberate: a lock with no verified way back in is worse than no lock at all. A mistyped address, or one that quietly can’t receive mail from mintencoder.com, would otherwise only surface the day someone actually needed to recover it — by which point it’s too late to fix. Confirming it up front turns that into a setup-time problem instead of a locked-out-forever one.
Everyone can still see these settings; the lock only disables the controls that would change something. Minting licences, viewing products, and reading the Audit Log are never affected — the lock is scoped specifically to the “engine room” settings, not day-to-day licensing work.
If the person who set the administrator password leaves the business, a new administrator isn’t locked out permanently. A signed, time-limited recovery code can be requested and emailed to the installation’s own Recovery Email address — itself protected the same way, so it can’t simply be redirected by whoever is currently logged in. If email recovery isn’t available, MintEncoder support can clear the lock so a new password can be set.
Data Protection & Compliance
MintEncoder was designed to keep licensing operations under your control.
Customer information, product data, licence records, signing keys, audit history, and backups remain within your own environment. There is no cloud service, third-party processor, or external dependency involved in the day-to-day operation of the platform.
To support accountability and governance requirements, MintEncoder maintains a comprehensive Audit Log recording key administrative actions, including licence minting, key generation, backup activity, and configuration changes.
Where multiple authorised users share a MintEncoder environment, actions are recorded against the Windows account that performed them.
PDF licence certificates are generated on demand and are not retained permanently. Generated PDFs are stored only temporarily and are automatically removed when MintEncoder closes, helping reduce the risk of customer information being left behind in forgotten files.
Features such as local-only data storage, machine-protected signing keys, Recovery Keys, audit logging, controlled backup processes, and individual user accountability may assist organisations in meeting their own compliance, governance, and audit objectives.
However, MintEncoder is not itself a compliance certification, standard, or regulatory framework. Compliance requirements vary between organisations, industries, and jurisdictions. MintEncoder should therefore be considered one component within a wider compliance, governance, and security programme.