SikkerKey vs OVHcloud Secret Manager
Summary
SikkerKey and OVHcloud Secret Manager are both EU-hosted secrets managers that keep your secrets under EU jurisdiction. OVHcloud Secret Manager is a managed key-value store: a HashiCorp Vault KV2-compatible service with access through OVHcloud IAM, keys in OVHcloud KMS, and audit in OVHcloud Logs Data Platform. This comparison looks at where the two overlap, where they differ, and which capabilities are native to each.
The full feature rundown covers machine authentication, the secret model, access controls, audit, and team management. Two differences run through it. OVHcloud proves a workload's identity with an IAM token it carries, while SikkerKey signs every request with a key that stays on the machine; and OVHcloud Secret Manager lives inside an OVHcloud account, while SikkerKey is a standalone EU secrets layer whose one machine identity works the same across OVHcloud, AWS, Hetzner, on-prem, and a laptop.
Looking for an OVHcloud Secret Manager alternative? The table below compares them area by area, including the primitives a key-value store leaves out: structured secrets with per-field rotation, canary secrets, leased database credentials, a read-blind AI identity, and rotation verified against the live system.
SikkerKey and OVHcloud Secret Manager are both EU-sovereign secrets managers, but OVHcloud is a managed key-value store tied to an OVHcloud account, while SikkerKey is a standalone EU secrets layer with signed-request machine identity, structured secrets with per-field rotation, leased database credentials, canary secrets, and a read-blind AI identity.
| Feature | SikkerKey | OVHcloud Secret Manager | Why it matters |
|---|---|---|---|
| 01Secret Retrieval Authentication | |||
| Secret Retrieval | Asymmetric signing. Your machine signs a request with its private key, and SikkerKey verifies it with the public key. The keys are generated with Ed25519, and SikkerKey never sees your private key. | OVHcloud Secret Manager retrieves secrets over a REST API and a HashiCorp Vault KV2-compatible API. A client authenticates as an OVHcloud IAM identity, presenting an IAM token on each request.The token is a bearer credential the client carries, and access runs through an OVHcloud account and its IAM. A leaked token keeps reading the vault until it is revoked. | As a baseline, access to your secrets is gated by your cryptographic identity. |
| Machines | A machine is any device or environment you want to be able to access secrets. Generate a bootstrap command from the dashboard and run it on your machine. It generates a keypair locally and registers the public key with SikkerKey. The machine appears as pending-approval. | A workload authenticates as an OVHcloud IAM identity using a Personal Access Token placed on the host. IAM roles and policies decide what it can reach.The token is a bearer credential, not a per-machine identity. There is no locally generated keypair and no approval step, and the same token works from anywhere it is copied. | Bootstrap a machine in seconds, and it reaches your secrets only after you approve it. |
| Enrollment Tokens | An identity token with its own lifecycle you set, letting you mint up to 10,000 ephemeral machines and scope how long each machine's identity stays valid. Optionally harden the minting requirements with hostname regex matching and/or IP or CIDR allowlists. | No enrollment-token primitive. CI runners authenticate with OVHcloud IAM credentials provisioned through the account's IAM model.Nothing mints many bounded machine identities from one token with hostname and CIDR matching and an automatic expiry. | Short-lived machines get short-lived identities that expire with them. This prevents identity sprawl and stops forgotten privileged identities from lingering indefinitely. |
| Temporary Machines | A machine you provision for a fixed lifetime, from 1 hour up to 12 months, that expires on its own at the deadline. Attach optional guardrails enforced at every read: a time-of-day window, an IP/CIDR allowlist, and a country allowlist. Extend it later within a rolling 12-month cap. | No time-bounded machine identity. IAM policy conditions can express some access limits, but a self-expiring identity with country and time-of-day guardrails is not part of the model. | Give a contractor or a short-lived environment access that expires on its own when the work is done. The guardrails narrow it to the hours, networks, and countries you allow. |
| 02Agentic Secret Ops | |||
| AI Identity | A separate identity class for AI agents that can manage your vault but is structurally read-blind. It can create and rotate secrets and manage machines, projects, policies, and canaries, but it can never read a secret's plaintext, because the read path only authenticates machines. Capabilities are scoped and granted from the dashboard, and each agent is capped at its creator's current privileges. | No separate identity class for agents. An application or AI service authenticates as an OVHcloud IAM identity, and if that identity can read a secret, it reads the plaintext.There is no identity that can manage secrets while being structurally unable to read their values. | Hand an AI agent real management power over your vault, automating secret ops, provisioning, and policy, without ever giving it the ability to read a secret. The read-blind boundary is structural, so no scope or misconfiguration opens a path to your plaintext. |
| MCP Server | A local MCP server for Claude Code, Codex, Cursor, Continue, and other MCP-compatible clients. It runs next to the AI client over stdio and signs every request with an Ed25519 AI-agent identity. It exposes management tools across projects, secrets, rotation, policies, machines, and audit, with permissions assigned from the dashboard and bounded by the creator's access. Stored secret values stay on the application read path, so the client manages the vault without reading secrets. | Not natively supported.OVHcloud provides an MCP server for managing supported OVHcloud services, but Secret Manager is not currently exposed through it. | Teams can let AI clients perform real secret-ops work with signed requests, clear permissions, and audit attribution. The local binary fits existing MCP workflows while SikkerKey keeps management automation separate from application secret reads. |
| 03Developer Tooling | |||
| SDKs | Read-only runtime SDKs for Python, Node.js, Go, .NET, Kotlin, and PHP. Each uses the machine's Ed25519 identity and can read single values, structured fields, list, and export. SDKs can bootstrap memory-only identities from enrollment tokens for serverless and ephemeral hosts, and every SDK except PHP can watch a secret and fire a callback when its value changes, access is revoked, or it is deleted. | The Vault KV2-compatible API lets you read secrets with existing HashiCorp Vault client libraries in most languages.There is no dedicated Secret Manager SDK. You wire up a Vault client against the KV2 endpoint, with no machine-identity signing, change-watch, or memory-only bootstrap. | Applications can fetch secrets with the same security model in every runtime, without API keys or long-lived bearer tokens. Watch support lets services react to rotation and revocation quickly, while memory-only bootstrap covers platforms where writing an identity file is impractical. |
| CLI | A single-binary CLI for Linux, macOS, and Windows. It uses the same Ed25519 machine identity as the SDKs to read, list, and export secrets, and can run a child process with secrets injected into its environment. It also manages multiple vaults and installs managed-secret agents. | Because the API is Vault KV2-compatible, the HashiCorp Vault CLI can read secrets from the endpoint.OVHcloud's own CLI does not read secrets. There is no dedicated CLI that injects a secret into a process environment or restarts it on rotation. | Developers and operators can use SikkerKey in terminals, scripts, deploy jobs, and local tooling with the same grants applications use in production. Environment injection makes legacy applications work without code changes, while multi-vault support keeps production, staging, and personal workflows separate. |
| 04Secret Model | |||
| Structured Secrets | A secret that holds multiple named values. The SDK and CLI fetches any value by its field name. You can rotate any value manually on its own, or schedule specific values to rotate while the rest stay static. | A KV2 secret is a versioned map of key-value pairs, so it natively holds multiple named fields and returns them on read.The whole secret versions as one unit, so there is no per-field rotation or scheduling. The service has no rotation at all. | A real credential often has several parts that change at different times, so you rotate the volatile ones on their own schedule. |
| Managed Secret | A Sync Agent you run applies rotations to the external system that holds the secret. SikkerKey stages the new value, the agent writes it and verifies a live connection, and SikkerKey promotes it only after the agent confirms. A failed apply rolls back and logs the error. | No rotation engine. Changing a secret writes a new version by hand; there is no agent that applies a rotation and verifies it against the live system before it goes live. | Rotation runs on your own infrastructure and is verified against the live system before SikkerKey makes it the current value. |
| Leased Credentials | SikkerKey mints a short-lived database login on demand, one per machine, creating it directly in your database and dropping it when the lease ends. You set the provider, the credential shape, and the lease policy: lifetime, renewal, a hard cap, re-mint behavior, and revoke-on-machine-disable. | No dynamic secrets. The service stores and versions the values you put in it; it does not mint short-lived database logins on demand. | Each machine gets its own database login, so your database logs attribute every query to a machine, and the login expires when the lease ends. |
| Temporary Secrets | A one-shot, self-destructing secret you hand to a person. Creating one returns a link and a passphrase; the value is destroyed the moment it's viewed, on a wrong passphrase, or at expiry, which you set between 1 minute and 24 hours. The passphrase is stored only as an Argon2id hash. | No one-time share link. Handing a secret to a person is left to you and whatever channel you use. | A safe way to hand a secret to a person: it opens once and then expires on its own. |
| Secret Versioning | Every secret has a current version and an encrypted version history. Any change bumps the version and stores the new encrypted payload, whether a manual replace, a manual rotation, or a promoted managed rotation. Rollback restores any prior version as a new version. | The KV2 engine versions every secret. Each change creates a new version, and you can review or revert to a previous value. | A bad rotation or accidental replacement is reversible without breaking the audit chain. Operators restore a known-good value in seconds, machines receive it on their next read, and the rollback itself remains visible as the newest version. |
| Trash & Restore | SikkerKey gives deleted secrets a 30-day recovery window. Deleting a secret moves it to Trash, records when it was deleted and who deleted it, removes live machine access grants, and cancels rotation schedules. The Trash page lists deleted secrets with project, deletion time, who deleted them, days remaining, search, pagination, restore, permanent delete, and bulk permanent delete. Expired trash is permanently deleted automatically after 30 days. | Not natively supported. | Accidental deletes are recoverable without turning cleanup into support work. Teams can restore the secret during the recovery window, permanently purge sensitive leftovers when required, and let expired trash clear automatically after 30 days. |
| 05Access Controls | |||
| Access Policies | A named, reusable bundle of read-time constraints you bind to any secret, evaluated on every fetch. The axes are a time-of-day window, an IP/CIDR allowlist, read-rate caps, a co-signing machine that must approve, a TTL that destroys the secret after a deadline or a number of reads, and rotate-after-N-reads. One policy can govern many secrets. | OVHcloud has no reusable per-secret access policy. An individual secret cannot carry a time-of-day window, read-rate caps, a co-signing machine, TTL destruction, or rotate-after-N-reads. | Define the constraints a sensitive secret needs once and reuse the policy across every secret that shares them. Tighten it in one place and every bound secret tightens with it. |
| Canary Secrets | A decoy secret. When a machine reads it, the machine gets the decoy value and the project locks in the same transaction: every further request against the project returns 423 Locked. You can extend the freeze to other projects the machine is attached to. | No decoy-secret or read-triggered lockdown primitive. | If a compromised machine touches the decoy, the project locks itself before anything real is read. |
| Vault IP Allowlist | Restrict machine access to the vault by source IP or CIDR range. Add IPv4 or IPv6 addresses, label them by office, VPC, CI runner, or region, and enable enforcement across the vault. Changes apply immediately, and disabling the allowlist can require a fresh passkey check. | Not natively supported. | A machine key is only useful from an approved network. That narrows the blast radius of a leaked machine credential to the egress locations your team controls, while keeping the control simple enough to manage for office networks, cloud VPCs, and CI/CD runners. |
| 06Audit & Alerts | |||
| Audit Logs | SikkerKey records vault activity across people, machines, AI agents, and background jobs. Each entry captures what happened, when, where the request came from, the related secret or machine, and a severity level for triage. The dashboard filters by action, severity, source IP, and time range, with CSV export and live updates. | Secret activity streams to OVHcloud Logs Data Platform, where it can be searched and retained.Audit lives in a separate logs product you query, rather than a built-in log across every identity with severity triage and live updates in the vault. | During incident response or compliance review, teams can reconstruct a timeline across every identity that touched the vault. Severity classification helps separate routine activity from events that need review, and retention keeps high-severity events longer than routine activity while critical events stay available across the normal pruning window. |
| Email Alerts & Webhooks | Subscribe to vault events by action, category, and severity. Email alerts send selected events to the account email with the action, detail, related secret or machine, and source IP. Webhooks deliver them to HTTPS endpoints as signed JSON with delivery IDs for deduplication, with test delivery and health tracking in the dashboard. | No per-event alerts or webhooks. Audit events go to Logs Data Platform, and turning them into notifications is a separate build on that platform. | Teams can send urgent vault activity to people and systems at the same time: inboxes for human review, webhooks for SIEM, ticketing, incident response, or automation. Signed payloads, retries, health tracking, and visible delivery limits make the integration operationally predictable. |
| 07Team Management | |||
| Vault Roles | Vault roles control management rights across the organization vault, covering machines, AI agents, enrollment, audit, alerts, IP allowlist, integrations, members, billing, and more. Built-in Owner, Admin, Developer, and Collaborator tiers cover common shapes, and Enterprise teams can build custom vault roles from the same capability list. Role changes take effect on the member's next request. | OVHcloud IAM roles and permissions govern who can manage the service, per user or user group.It is the OVHcloud account's IAM, shared across every OVHcloud service, rather than a role model scoped to the secrets vault. | Teams can delegate operational ownership at the right level. Built-in tiers cover common organization shapes, while custom roles let teams separate billing, member management, audit visibility, machine operations, alert configuration, and support work. |
| Access Roles | Access roles define which applications and projects a member can open and what management actions are available inside each. Scope can be everything, all application or standalone projects, selected applications, or individual projects. Action toggles cover secret types, project machine attachment and grants, and access-policy controls like time windows, IP allowlists, rate caps, co-sign, and TTL. | IAM policies scope which secrets an identity or group can read, down to individual secrets.Scoping is IAM resource policy on the OVHcloud account, without an application-and-project structure or per-project access-policy controls. | Teams can reuse one project scope across many members and tune action rights per environment. A production app can be visible to an auditor, editable by its service owner, and restricted for contractors, with the same access model covering current and future projects. |
| SAML SSO | Connect a SAML 2.0 identity provider such as Okta, Microsoft Entra ID, or Google Workspace. Each sign-in domain is verified with a DNS TXT record before it can provision members, and SSO can run alongside existing sign-in methods or be enforced for verified domains. New SSO users join on the minimal Collaborator role with no project access until roles are assigned. | OVHcloud IAM supports SAML 2.0 federation, so members sign in through Okta, Microsoft Entra ID, Google Workspace, or ADFS. | Teams can bring SikkerKey into their existing identity provider, control who can sign in by verified domain, and roll new members into the vault with a minimal starting posture. Enforcement gives teams a clean path to require company sign-in without risking an owner lockout during provider changes. |
The OVHcloud Secret Manager details in this comparison are our interpretation of publicly available information as of 9 July 2026, and are subject to change. Do your own due diligence and consult OVHcloud Secret Manager's official documentation.