SaaS or on-premises: choosing how to run DYCRYPT

The way your application verifies a DYCRYPT licence does not need to change with the deployment model. It still uses the product public key, expected product identifier, and the Java, Node.js, Python, or C++ SDK.

What changes is who operates the platform and where your signing keys live.

Choose SaaS for speed

DYCRYPT SaaS lets your team create an organisation, define products, issue licences, and integrate without operating a licensing deployment. It is the fastest way to evaluate the workflow and take a standard application into production.

Choose Sovereign for on-premises requirements

DYCRYPT Sovereign runs on-premises when policy, data residency, network isolation, or existing security controls require DYCRYPT to stay in your environment.

Sovereign can sign through an existing HSM or PKCS#11 token. The private key remains on the device while DYCRYPT requests the signature it needs. Enterprise remains the path for custom development, custom roles, and bespoke integrations.

Key protection in either model

Your application receives only the public key or certificate needed to verify. DYCRYPT keeps private signing operations inside a protected signing boundary, separate from everyday product and licence management.

Choose the model that fits your operational requirements, then keep the same application-side contract: verify the signature, enforce the product and machine binding, handle licence status explicitly, and never place a private signing key in the application.