Sikkerkey vs STACKIT Secrets Manager
Summary
STACKIT Secrets Manager covers the core managed secrets workflow: applications can store and retrieve secrets, keep version history, restrict vault access by IP range, and use SAML SSO and platform IAM for administration. Vault KV v2 compatibility also gives teams access to existing client libraries and the Vault CLI.
SikkerKey goes significantly further around workload identity, secret lifecycle, and automated response. Machines authenticate without reusable passwords or bearer credentials. Ephemeral infrastructure can receive short-lived identities that expire automatically. AI agents get a separate, structurally read-blind identity class. Enrollment, temporary machines, managed rotation, leased database credentials, canary secrets, one-shot secret sharing, trash and restore, read-time access policies, and native alerts are built directly into the product.
The table below compares the two feature by feature, giving STACKIT full support where the capability exists, partial support where only part of the workflow is covered, and no support where the feature is not natively available.
STACKIT Secrets Manager is a capable managed KV secrets store with versioning, IP restrictions, SAML SSO, and Vault-compatible tooling. SikkerKey goes further with cryptographic machine identities, ephemeral infrastructure, read-blind AI agents, managed and leased credentials, canary secrets, recovery workflows, and native read-time controls.
| Feature | SikkerKey | STACKIT | 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. | Retrieve secrets through STACKIT Secrets Manager using Vault-compatible authentication and API access.Secret requests use bearer tokens obtained with a username and password. | 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. | Not natively supported. | 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. | Not natively supported. | 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. | Not natively supported. | 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. | Not natively supported. | 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. | 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. | STACKIT Secrets Manager is compatible with the HashiCorp Vault KV v2 API, so applications can use compatible Vault client libraries to read secrets.STACKIT does not provide first-party Secrets Manager runtime SDKs or native secret-watch callbacks. | 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. | STACKIT Secrets Manager supports the HashiCorp Vault CLI for reading, listing, creating, updating, and deleting secrets.STACKIT does not provide a dedicated Secrets Manager runtime CLI with process injection, multi-vault identity management, or managed-secret agent installation. | 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. | Store multiple named key-value pairs in a single secret and retrieve individual fields through the Vault KV v2 interface.Rotation applies to the secret as a whole; individual fields cannot be rotated or scheduled independently. | 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. | not natively supported. | 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. | Not natively supported. | 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. | Not natively supported. | 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. | Every change creates a new secret version, with prior versions retained in history. Previous versions can be restored, and version-retention limits can be configured globally or per secret | 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. | Not natively supported. | 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. |
| 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. | Restrict access to a Secrets Manager instance to trusted IP address ranges with an instance-wide access control list. ACL entries can be added, updated, listed, and removed through the API.ACL entries are IP ranges only; STACKIT does not document labels for identifying entries by office, VPC, runner, or region. | 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. |
| 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. | Not natively supported. | If a compromised machine touches the decoy, the project locks itself before anything real is read. |
| 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. | STACKIT records Secrets Manager lifecycle events in its platform audit log, including secret creation, deletion, and version-state changes. Audit entries include the action, initiator, timestamp, source IP, and related resource, and can be routed to external observability or SIEM systems.Secret reads are not included in the documented audit events. | 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. | Not natively supported. | 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. | STACKIT IAM provides built-in and custom roles for controlling management access to cloud resources, including Secrets Manager. Roles can be assigned to users, groups, and service accounts at the organization, folder, or project scope.STACKIT roles govern cloud-resource permissions, but they do not provide a Secrets Manager-specific vault role model spanning product capabilities such as alerts, integrations, enrollment, or billing. | 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. | STACKIT IAM roles can control who may manage Secrets Manager resources, with permissions assigned at organization, folder, or project scope. Custom roles can bundle specific permissions and be reused across users, groups, and service accounts.Access scope stops at STACKIT resource boundaries; roles cannot be scoped to selected secrets or define secret-level management capabilities. | 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. | Connect an external identity provider through SAML 2.0 for organization-wide SSO. STACKIT routes users from configured email domains to the federated provider and can automatically create user accounts on first sign-in. | 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 STACKIT 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 STACKIT's official documentation.