Machines that prove who they are.
Every machine generates its own cryptographic identity. Every request is signed. Every access is logged. You approve machines, assign them to projects, and grant access to individual secrets. Nothing implicit, nothing inherited.
One command to register
Generate a one-time bootstrap token from the dashboard. Run a single curl command on the target machine. It generates an Ed25519 keypair, registers with SikkerKey, and stores credentials locally. The token expires in 10 minutes and can only be used once.
curl -sSL https://api.sikkerkey.com/v1/bootstrap/<token> | shCredentials are stored at ~/.sikkerkey/vaults/{vaultId}/. Supports Linux, macOS, and Windows (PowerShell). No external dependencies.
Every request is cryptographically signed
Machines sign every request with their Ed25519 private key. The signed payload includes the HTTP method, path, timestamp, a unique nonce, and a SHA-256 hash of the request body. The server verifies the signature against the machine's registered public key.
signed = {method}:{path}:{timestamp}:{nonce}:{bodyHash}Machines need nothing beyond their Ed25519 keypair. Decryption happens server-side. If the signature doesn't verify, the request is rejected and logged as an auth failure.
Docs →Per-secret access grants
Machines don't get access to entire projects. You grant access to individual secrets. A machine can only read a secret it has been explicitly granted access to. Revoke access instantly from the dashboard, and the machine loses access on its next request.
Docs →
Automated provisioning for CI/CD
Connect GitHub Actions, GitLab CI, or Bitbucket Pipelines from the dashboard. SikkerKey generates a machine identity, pushes credentials to your repository, and optionally commits the pipeline file. Your CI fetches secrets on every run - no manual credential copying.
Each CI machine follows the same Ed25519 authentication model. Every secret read from a pipeline is signed, verified, and audit logged with the machine ID and source IP.
View all integrations →
Five checks on every secret read
A machine must pass all five checks on every request. Failing any one results in immediate rejection and an audit log entry.
Valid Ed25519 signature
The request signature must verify against the machine’s registered public key with a valid timestamp and unique nonce.
Machine approved and enabled
The machine must have been approved by a vault administrator and not disabled.
Account active
The vault owner’s account must be in good standing. Suspended accounts block all machine access immediately.
Machine added to project
The machine must be explicitly added to the project that contains the secret.
Explicit grant to specific secret
The machine must have been granted access to this specific secret, not just the project.
Built-in protection at every layer
Defense in depth, not security theater.
Replay protection
Every nonce is tracked in the database. A replayed request is rejected even if the signature is valid. Nonces are scoped per machine.
Timestamp window
Requests must be signed within a 5-minute window. Clock skew of up to 1 minute is tolerated. Anything outside is rejected.
Rate limiting and lockout
3 failed auth attempts in 5 minutes triggers a 30-minute lockout per IP and per machine. Brute-force is not viable.
Full audit trail
Every auth attempt, successful or not, is logged with the machine ID, IP address, timestamp, and failure reason.
Account status checks
Even with a valid signature, requests are rejected if the vault owner account is suspended, banned, or pending verification.
Zero stored secrets
The server stores only the public key. The private key exists only on the machine. There is nothing to steal from the server.
Stop using bearer tokens for machine access.
Register your first machine in under a minute. No credit card required.
Get Started Free