SikkerKey vs AWS Secrets Manager
Summary
AWS Secrets Manager covers the core secrets-management workflow well: applications can retrieve secrets, rotate them, keep version history, recover deleted values, and audit access.
SikkerKey goes significantly further around how secrets are accessed and how identities behave over time. Machines use per-request asymmetric signatures instead of reusable credentials. Ephemeral infrastructure can receive short-lived identities that expire automatically. AI agents get a separate, structurally read-blind identity class. Enrollment, temporary machines, leased database credentials, canary secrets, one-shot secret sharing, and stateful read-time access controls are built directly into the product rather than assembled from separate services and custom integration.
The table below compares the two feature by feature, giving AWS full support where the capability exists, partial support where only part of the workflow is covered, and no support where the equivalent must be built from separate AWS primitives.
AWS Secrets Manager is a strong conventional secrets store. SikkerKey goes further with cryptographic machine identities, ephemeral infrastructure, read-blind AI agents, leased credentials, canary secrets, and native read-time controls. For teams that want those workflows built in rather than assembled from AWS primitives, SikkerKey is the stronger fit.
| Feature | SikkerKey | AWS Secrets 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. | AWS Secrets Manager retrieves secrets through the GetSecretValue API. Requests are authenticated using AWS Signature Version 4.SigV4 uses symmetric credentials that AWS also holds, and the identity is an IAM principal tied to an AWS account. | 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. | IAM Roles Anywhere lets workloads outside AWS use an X.509 certificate to obtain temporary IAM credentials and access Secrets Manager.Onboarding requires certificate infrastructure and IAM configuration. AWS does not provide a built-in flow where a machine generates its identity locally, registers itself, and waits for explicit approval before gaining access. | 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.A similar workflow can be assembled from separate AWS identity, provisioning, and IAM primitives, but it requires custom integration and is not provided as a native Secrets Manager capability. | 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. | AWS can issue temporary IAM credentials that expire automatically and can be used to access Secrets Manager. IAM policies can also restrict secret access by source IP and request time.Temporary credentials are limited to hours rather than a machine lifecycle of up to 12 months. AWS does not provide a native temporary-machine object with an extendable lifetime or built-in country guardrails enforced on every secret read. | 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. | Amazon Bedrock AgentCore Identity provides purpose-built identity and credential access controls for AI agents. Agent capabilities are governed through IAM roles and policies.Agent access is permission-based rather than structurally read-blind. An agent can be denied secret retrieval through IAM, but AWS does not provide a separate Secrets Manager identity class whose authentication path makes plaintext retrieval impossible. | 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. | AWS MCP Server lets AI coding agents manage AWS services through MCP. It executes AWS API calls using the caller’s existing IAM credentials and permissions.The agent operates with ordinary IAM permissions, so secret retrieval is available whenever its identity is allowed to call it. AWS does not provide a Secrets Manager MCP identity that remains structurally unable to read secret values while retaining management access. | 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. | AWS SDKs let applications retrieve individual or multiple secrets from Secrets Manager across supported programming languages.AWS SDKs retrieve secrets through the standard Secrets Manager APIs. They do not provide a built-in secret watcher that fires application callbacks when a value changes, access is revoked, or a secret is deleted. | 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. | AWS CLI lets users retrieve, list, and batch-retrieve secrets from Secrets Manager, with named profiles for working across different AWS environments.AWS CLI does not provide a native command that retrieves secrets and launches an arbitrary child process with them injected into its environment. | 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. | AWS Secrets Manager can store multiple named values as JSON key/value pairs within a single secret.Fields are not independently managed or rotated. Rotating one value requires updating the secret as a whole, with per-field rotation schedules requiring custom rotation logic. | 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. | AWS Secrets Manager stages a new credential, applies it to the external system, tests that it works, and promotes it only after successful verification.Supported AWS services and integration partners can use managed rotation. Other external systems require a custom Lambda rotation function. | 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.AWS provides short-lived authentication tokens for existing database users through IAM database authentication, but it does not mint a unique database login per machine and manage that principal through a configurable lease lifecycle. | 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 similar one-time sharing workflow can be built from AWS storage, encryption, and application primitives, but AWS does not provide it as a native Secrets Manager capability. | 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. | AWS Secrets Manager creates a new version whenever a secret value changes and maintains version history using staging labels. Previous versions can be restored as the current version.AWS rolls back by moving the current-version label to the existing prior version, rather than restoring the old value as a newly created version. | 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. | AWS Secrets Manager makes deleted secrets immediately inaccessible and schedules them for permanent deletion after a configurable recovery window. Secrets can be restored before the deadline.AWS supports a 7-to-30-day recovery window rather than a dedicated fixed 30-day Trash workflow. Deletion attribution is available through CloudTrail rather than shown directly with each deleted secret. | 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.Similar restrictions can be implemented through a combination of IAM conditions, custom application logic, and external state, but AWS Secrets Manager does not provide a reusable per-secret policy object for these read-time lifecycle controls. | 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. | AWS can restrict Secrets Manager access by source IPv4 or IPv6 address and CIDR range using IAM policy conditions. Access can also be limited to specific VPCs or VPC endpoints.IP restrictions are configured through AWS policies rather than a dedicated Secrets Manager allowlist with labeled entries and a passkey-protected disable action. | 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.Decoy resources and automated responses can be assembled from AWS monitoring and security services, but Secrets Manager does not provide a decoy secret that atomically freezes further project access when read. | 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. | AWS records Secrets Manager activity in CloudTrail, including the action, identity, time, source IP, and related resources. Events can be searched, filtered, and exported.CloudTrail does not assign a SikkerKey-style severity level to each vault event, and live event handling is configured through EventBridge rather than built into the Secrets Manager audit view. | 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. | AWS can route Secrets Manager events through EventBridge to email and HTTPS endpoints. SNS webhook deliveries include unique message IDs, cryptographic signatures, retries, and delivery monitoring.Alert subscriptions are configured across EventBridge and SNS rather than through a dedicated Secrets Manager alerting interface. AWS events also do not carry a native SikkerKey-style severity level for filtering. | 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. | AWS IAM controls management rights through reusable policies attached to users, groups, and roles. AWS provides managed permission sets for common access levels, and customers can build custom roles from individual service actions.AWS management roles are configured through IAM rather than as a dedicated Secrets Manager role system with built-in vault-specific tiers. | 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. | AWS IAM can restrict which Secrets Manager resources a member can access and which management actions they can perform, using resource ARNs, tags, and reusable permission policies.AWS Secrets Manager does not provide a member access role scoped directly to application and project containers. Equivalent boundaries are assembled through IAM policies and resource tagging rather than selected from a native project-aware role model. | 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. | AWS IAM Identity Center connects external SAML 2.0 identity providers and centrally manages workforce access. Users and groups can be provisioned from the IdP and receive access through explicit assignments and permission sets.AWS uses an organization-wide identity source and explicit access assignments rather than verified-domain SSO. It does not provide SikkerKey’s DNS-verified domain model for allowing or enforcing SSO per sign-in domain. | 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 AWS Secrets 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 AWS Secrets Manager's official documentation.