CyGard
®
The HSM stores the key. CyGard governs its use.
.png)
Bank-grade cryptography, operated with office-suite procedures
CyGard® is the governance layer that the HSM is missing. A single artifact deployed on the client's Tomcat, the existing corporate database, and the already installed HSM: no per-key licensing, no additional hardware, and no integration projects measured in months.
Each key has a NIST standard status, an automatically enforced cryptoperiod, and a privilege matrix per application, key, and operation that is enforced in the API itself—not in a procedure someone must remember.
How it works
Demonstrable control, simple integration
CyGard decides if an operation is allowed: privilege matrix, NIST status, requester role, audit trail. The custodian executes the how: the HSM generates the key and operates with it inside the token. Changing custodian requires three configuration variables, not a single line of code.
Signature Journey
Barrier 1 - Identity
Understand the risk
The application key is compared against its hash. It is revealed in plaintext only once, when the application is created, and is never exposed again.
Barrier 2 - Quota
He knows what he has
Rate limiting per application key: requests per minute on the data plane, per IP during login.
Barrier 3 - Status
Carry out the plan
An active key allows the operation; a deactivated one does not allow signing; a suspended one allows nothing.
Barrier 4 - Grant
Installed capacity
An explicit grant for that application, on that key, for that operation must exist. Without it, there is no signature.
Control Planes & Key Residency
Management Plane
Username and password. Keys are created, privileges are granted, states are transitioned, and certificates are issued. Authorization is role-based.
Administrator
Operator
Auditor
Data Plane (Machines · App Key
Consumer microservices can only invoke cryptographic operations, authorized by the privilege matrix and key status.
Recommended Mode
The private key resides and operates inside the HSM
The key is generated in the token, and all six operations (sign, verify, encrypt, decrypt, wrap, and unwrap) are executed inside it, without ever leaving.
It is the mode that satisfies strict cryptographic boundary requirements and is designated for CA-grade keys. The CA is created inside the token the first time it is used, persists across restarts, and signs certificates and CRLs within the hardware.
Key material is never "loaded" into CyGard: it is provisioned in the custodian either generated on-site or importing existing keys via wrapping so the private portion never travels in plaintext over the network.
Version 1 Scope
What remains out, by product decision
Version 1 is complete and operable without these. Two additional known limits, consistent with the single-node topology: rate limiting is applied per node, and the hardware-custodied CRL is persisted to a file, also per node.
Second factor in management plane
v1.1
Today: username and password over JWT, with account lockout and rate limiting.
Dual control with N-of-M quorum
v1.2
Today: all administrative actions are recorded in the sealed log, with actor identification and integrity verification.
Active-active high availability
v2
Today: single node; active-passive is viable with an external database and shared HSM partition.
ML-DSA as a governable key type
minor
Subject to client HSM firmware; the foundation is already prepared.
An excellent safe, without internal access control
Excessive privilege by design
A microservice that should only verify signatures receives, in practice, the ability to sign. Compromising it is equivalent to compromising the CA: there is no technical boundary between them.
Lifecycle without effective control
NIST SP 800-57 accurately defines states and cryptoperiods, but without a tool to enforce them, they remain written recommendations. Since key rotation forces every consumer to reconfigure, rotation is kept to a minimum.
Indefensible traceability
A log in a flat table can be modified by anyone with write access, including an attacker already inside. It serves daily operations, but proves nothing to an auditor.
The HSM protects the material, but does not govern its use
Anyone with the partition PIN can sign, verify, encrypt, and decrypt with any key residing inside it. Three concrete consequences stem from this asymmetry.
Deployment and operation
A single WAR file
Backend and console in a single artifact on the client's Tomcat. Updating means replacing and restarting, without touching configuration, database, or HSM.
Existing database
PostgreSQL, MySQL or MariaDB, SQL Server, SQLite, and H2. The engine is detected via URL, and migrations build the schema upon startup.
Any PKCS#11 HSM
SoftHSM in development, Thales Luna in production, CloudHSM, nShield, or Utimaco. Just three configuration variables.
Bootstrap wizard
Tests the connection, encrypts the password, applies migrations, and creates the first administrator, protected by a token known only to the server operator.
Self-hosted console
TLS terminated at Tomcat with corporate certificate, strict headers, and zero external resource dependencies.
JDK 25 LTS
Integrates ML-KEM and ML-DSA, NIST-standardized post-quantum algorithms, verified by the project's test suite.
Operational Transformation