Private keys available without workstation copies
SecureVault keeps private material in the cryptographic backend selected by the organisation and exposes authorised operations only: signing, decryption, certificate issuance, rotation and public-part export. Existing tools continue to use stable identities and aliases.
- Encrypted vault, PKCS#11 modules and TPMs
- Separate authorisation for each operation
- Append-only records and SIEM integration
Centralised inventory of keys, versions and identities
SecureVault distinguishes the logical key from private material, its versions and protocol identities. Owner, purpose, algorithm, provenance, backend, status and expiry are available in one searchable inventory.
Stable aliases
Applications use a stable name that points to the current version. Rotation activates a new version without requiring reconfiguration of the systems that use the key.
Provenance and recoverability
Origin, export capability, replication and backup verification are recorded for every version. Dependencies on a single device are therefore visible before a failure.
Lifecycle states
Activation, deactivation, revocation, rotation and scheduled destruction are distinct states. Irreversible operations require confirmation, recent verification and, where configured, a second approval.
Private material remains in the cryptographic backend
Workstations, pipelines and services submit an operation request. SecureVault verifies identity, permissions and policies, then instructs the backend to perform it without copying the private key into the database, records or endpoint.
Backend capabilities verified in advance
The internal encrypted vault, PKCS#11 tokens, hardware modules and TPMs expose supported operations and algorithms through a common interface. Incompatible choices are excluded before key creation.
OpenSSH agent
The local agent exposes the socket expected by OpenSSH, retains public material only and forwards signing requests over an authenticated channel. SSH, Git and scripts continue to use their established interfaces.
Self-hosted deployment
The service is deployed on the organisation’s servers or cloud, with PostgreSQL for metadata, a versioned API, web interface, command-line tools, metrics and structured logs.
One model for SSH, X.509, OpenPGP and code signing
Keys, identities, certificates and policies remain distinct objects while sharing the same inventory and operation records.
SSH
User and host identities, short-lived certificates, principals, source restrictions, serial numbers and revocation are managed by the same certificate authority.
X.509 e TLS
Requests, certificates, chains, issuance profiles, key matching and expiry alerts are inventoried; ACME renewal can take place without exporting the private key.
Code signing
Commits, containers, packages and other artefacts can be signed with non-exportable keys and policies bound to a project, service account and signing scheme.
OpenPGP
Primary keys and subkeys for signing, encryption and authentication keep identities, certifications, expiry, revocation and revocation certificates separate from private material.
Separation between key viewing and use
Authorisation is defined for each operation and organisational scope. Policies can require recent verification, restrict destinations and frequency, or make use subject to one or more approvals.
Environment separation
Organisations, projects and folders have their own permissions. Without metadata access, keys belonging to another scope cannot be viewed or inferred.
Recorded approvals
Requests can require multiple approvers, a reason, an expiry and quorum rules. The decision and context remain associated with the authorised operation.
Cryptographic profiles
Algorithms, curves and minimum lengths are classified as allowed, discouraged or prohibited. Before a new rule is applied, the dashboard identifies affected keys.
Traceability and integration with security processes
Every request associates the actor, session, origin, key, version, operation, outcome, policy decision and approvals. Records can be exported as JSON and forwarded through syslog or signed webhooks.
Backup procedures for each backend
Metadata, encrypted objects and the primary key follow separate protection procedures. Replication status and backup verification are exposed for each key.
Recovery verification
Integrity and write blocking are verified before recovery. Correspondence between metadata and backends is checked through cryptographic proofs, and the event is recorded.
Monitoring without sensitive data
Probes and metrics describe availability, signatures, errors, backend latency, policy denials, expiry and pending approvals without placing key names or fingerprints in labels.
Scope of application
SecureVault governs cryptographic material used by people, pipelines and services, while keeping password management and the general infrastructure inventory separate.
Technical workstations
SSH access and commit signing through short-lived sessions, verification at the time of use and central revocation, without storing private-key files on the workstation.
Pipelines and service accounts
Code and artefact signing with authorisations restricted to the project, signing scheme and identity of the automated process.
Infrastructure and PKI
Certificate issuance and renewal, SSH and X.509 authorities, TLS keys and generic cryptographic operations with a shared inventory and policies.
Key-management scope assessment
DEC can review the existing inventory, protocols, cryptographic backends, identities, authorisation policies, rotation, recoverability and integrations to define a verifiable SecureVault scope.