Choosing secure storage for passwordless credentials, verifiable credentials, and signing keys is not a matter of selecting the most powerful product. It depends on what must be protected, which operations the application needs to perform, how much control the security team requires, and how the system will behave across regions and failure scenarios. This guide compares hardware security modules (HSMs), cloud key management services (KMS), and purpose-built credential vaults, then provides a review cadence, migration checklist, and rotation template for keeping the decision current.
Overview
HSMs, cloud KMS products, and credential vaults solve related but different storage problems. An HSM is designed to generate, protect, and use cryptographic keys within a controlled hardware boundary. A cloud KMS provides managed key lifecycle operations through a provider-hosted service and API. A credential vault is generally designed around application secrets, identity records, tokens, passwordless credentials, or verifiable credentials, often with access policies and workflow features above the raw key-management layer.
The right architecture may use more than one option. For example, an application could use a KMS or HSM-backed key to encrypt data, while a credential vault manages application access, metadata, versioning, and retrieval workflows. Treating these products as interchangeable can create gaps: a key-management service may not provide the data model or presentation controls needed for an identity wallet, while a general-purpose vault may not provide the hardware-backed guarantees required for a particular signing operation.
Start by separating three assets:
- Root and signing keys: keys used to sign tokens, credentials, certificates, or system messages. These usually need strict usage controls, non-exportability where supported, and a carefully governed rotation process.
- Application secrets: database credentials, API tokens, OAuth client secrets, and integration keys. These need controlled retrieval, short-lived access where possible, and detailed audit trails.
- Identity credentials: passkeys, recovery material, verifiable credentials, subject identifiers, and related metadata. These need a storage model that supports the user journey, privacy requirements, revocation or status checks, and selective access.
Make the threat model explicit before comparing vendors. Consider administrator misuse, compromised application credentials, cloud account takeover, insider access, data exfiltration, regional outage, accidental deletion, and recovery-key loss. A secure credential vault is useful only when its policies, application integration, and operational controls match those threats.
What to track
Use the following comparison points when evaluating HSMs, cloud KMS products, or a purpose-built vault. Record the provider, service tier, region, contract assumptions, supported standards, and the date each item was verified.
| Area | HSM | Cloud KMS | Credential vault |
|---|---|---|---|
| Primary purpose | Hardware-protected cryptographic key operations | Managed key creation, protection, and use through cloud APIs | Controlled storage and retrieval of application or identity credentials |
| Security boundary | Dedicated or shared hardware boundary, depending on deployment | Provider-managed service boundary with documented controls to verify | Application, tenant, policy, and encryption boundaries to validate |
| Threat model | Strong fit when key extraction resistance and restricted signing are central concerns | Strong fit for managed key operations where cloud dependency is acceptable | Strong fit when access workflows, secret isolation, and credential lifecycle are central concerns |
| Latency and availability | Measure network path, partitioning, capacity, and failover behavior | Measure API latency, quotas, regional coverage, and dependency on the cloud control plane | Measure read and write latency, caching behavior, replication, and recovery objectives |
| WebAuthn and verifiable credentials | Often requires an application layer around cryptographic operations | Often requires an application or wallet layer for credential data and user workflows | May provide a more direct model, but confirm WebAuthn, W3C Verifiable Credentials, and DID support rather than assuming it |
| Audit logs | Check operation-level records, administrator actions, export options, and retention | Check API events, key-use logs, identity integration, retention, and alerting | Check per-record access logs, policy decisions, version history, and export formats |
| SDKs and APIs | Review supported languages, signing interfaces, and operational tooling | Review native SDKs, authorization integration, rate limits, and error behavior | Review secret and credential APIs, policy configuration, webhooks, and migration tooling |
| Compliance evidence | Request current certifications, attestations, and applicable hardware claims | Review the provider's current scope, service boundaries, and regional statements | Confirm the product's scope, data-processing terms, audit evidence, and privacy controls |
| Cost model | Track appliance or service fees, capacity, support, and redundancy requirements | Track key, request, storage, network, and multi-region charges where applicable | Track seats, records, requests, storage, environments, support, and recovery features |
Do not evaluate only the storage layer. Test the complete path from the identity application to authorization, retrieval, cryptographic use, logging, incident response, backup, and deletion. For OAuth or OIDC integrations, document which component validates tokens and which component is permitted to access signing keys. A practical secure credential vault architecture should make those boundaries visible.
Cadence and checkpoints
A recurring review prevents a storage decision from becoming outdated as products, standards, and compliance requirements change. Use this operating cadence as a starting point:
- Monthly: review failed access attempts, unusual retrieval volume, disabled or unused credentials, backup status, quota pressure, and unresolved alerts. Confirm that emergency access remains controlled and tested.
- Quarterly: review key and credential ownership, access policies, privileged users, service accounts, recovery procedures, rotation completion, and audit-log retention. Test a representative restore or failover procedure without exposing production credentials.
- Every six months: re-evaluate provider feature rows, service regions, SDK and API changes, supported WebAuthn and verifiable-credential standards, pricing tiers, and current compliance evidence. Re-run latency and availability tests for critical paths.
- After a major event: review immediately after a vendor announcement, security incident, material contract change, standards update, cloud-region change, new regulatory interpretation, or migration to a new authentication flow.
Use a rotation schedule that distinguishes routine replacement from emergency replacement. A simple template is:
- Asset: key, passkey-related secret, signing credential, API token, or recovery credential.
- Owner: accountable team and technical contact.
- Purpose and scope: the exact service, tenant, region, and operation permitted.
- Last rotated: date and change record.
- Next review: quarterly checkpoint or earlier expiry.
- Rotation method: overlapping versions, staged cutover, or controlled replacement.
- Revocation and rollback: steps, approvals, monitoring, and recovery path.
How to interpret changes
Not every product change requires migration. Classify changes by their effect on confidentiality, integrity, availability, privacy, and operational effort.
A new SDK version may be a maintenance task if API behavior and security controls are unchanged. A change to signing algorithms, key export rules, regional replication, token format, or audit-log availability deserves architectural review. Similarly, a new verifiable-credential feature is valuable only if it fits the application's issuer, holder, verifier, status, and privacy model.
Use a decision record for each material change. Capture the old and new behavior, affected assets, threat-model impact, migration steps, testing evidence, rollback plan, and approval owner. If a provider cannot clearly explain a service boundary or certification scope, record that uncertainty rather than treating a broad compliance label as proof that the entire workflow is covered.
Performance changes should be interpreted alongside failure behavior. Lower average latency is not enough if rate limits, cold starts, regional failover, or retry behavior can cause authentication failures. For passwordless systems, test enrollment, sign-in, recovery, device replacement, and account closure. For verifiable credentials, test issuance, storage, presentation, status checking, selective disclosure where supported, and deletion or wallet recovery.
If the current design stores identity data and keys together, consider whether separation would reduce blast radius. A credential vault may hold encrypted records and policy metadata while a KMS or HSM controls the encryption or signing key. This layered design can improve separation of duties, but it also introduces dependencies that must be monitored and recovered together.
When to revisit
Revisit the HSM-versus-KMS-versus-vault decision at least every six months and during quarterly access and rotation reviews. Reopen it sooner when the identity product adds passwordless authentication, begins issuing or accepting verifiable credentials, expands into a new region, changes its recovery model, or introduces stricter latency or audit requirements.
Use this practical checklist:
- Inventory every key, secret, credential, and recovery artifact, including its owner and data classification.
- Map each asset to its required operation: storage, retrieval, signing, encryption, verification, presentation, or recovery.
- Update the comparison table with current service boundaries, certifications, supported standards, APIs, regions, pricing assumptions, and audit capabilities.
- Run threat-model, latency, failover, rotation, and restore tests against the highest-risk workflows.
- Choose a layered design when one product cannot meet both cryptographic and credential-lifecycle requirements.
- Record the decision, assign an owner, schedule the next review, and link evidence to the change record.
Teams building customer onboarding or identity verification workflows should also review how storage choices affect privacy, retention, and recovery. The digital identity verification compliance checklist can help connect the storage review to broader identity-workflow controls. For migration planning, document cutover and rollback before moving live credentials; the KYC platform migration runbook offers a useful model for staged change management.
