Key Management Analyzer Beta

Scans live, credentialed key and certificate infrastructure for quantum-vulnerable algorithms: HashiCorp Vault, AWS KMS, AWS Certificate Manager, Azure Key Vault, Azure Managed HSM, GCP Cloud KMS, Kubernetes Certificate Manager, and Microsoft AD CS.

A different trust model than the other analyzers: Certificate, Network, Binary, and Code Analysis all work from a file or a passive network probe. The Key Management Analyzer requires you to issue it real, scoped credentials into your own infrastructure, since there is no file to read or network port to probe for a key that only exists inside a vault or HSM. See Metadata-Only, By Design below for the constraints this analyzer operates under in exchange for that access.

Supported Backends

Each backend field set, plus an optional custom endpoint/authority/CA-cert path/naming-context override for a local test environment or non-default forest, is configured under Key Management Analyzer → Connections.

Credential Model

Every backend uses a credential you issue yourself, scoped read-only via an attached policy, role, or RBAC ClusterRole, rather than a static long-lived token where the backend supports something better:

• Vault — AppRole exchanges a Role ID and Secret ID for a short-lived token, rather than using a root or long-lived token directly.
• AWS — an IAM Access Key attached to a read-only policy scoped to KMS and Certificate Manager describe/list actions.
• Azure — a Service Principal with a read-only role assignment on the Key Vault or Managed HSM.
• GCP — a Service Account JSON key with a read-only IAM role on the target key rings.
• Kubernetes — a ServiceAccount bound to a ClusterRole permitting only get/list on cert-manager's Certificate custom resources.
• AD CS — an ordinary domain account bind. AD CS has no REST or gRPC API; the connector authenticates via an LDAP simple bind against a domain controller. The default "Authenticated Users" read access to CN=Public Key Services is typically sufficient, since any domain member already needs it to discover CAs and templates.

On-premise only. There is no hosted or cloud-relay path for this analyzer, given the elevated trust level of the credentials involved.

Metadata-Only, By Design

The connector interface has exactly three methods: authenticate(), list_keys(), and list_pki_issuers(). There is no decrypt(), sign(), or export() method anywhere in the interface, on any of the eight backend implementations. This is enforced by an automated test that asserts those methods do not exist on the interface or any connector, not merely that the application chooses not to call them.

In practice this means the Key Management Analyzer can tell you that a Vault Transit key uses RSA-2048, or that a cert-manager Certificate has no spec.privateKey block and therefore defaults to RSA-2048, but it can never read the key material itself, use a key to sign or decrypt anything, or export a private key or certificate from the backend.

How Analysis Works

1. Authenticate — exchanges the stored credential for a live session against the target backend (a Vault token, an AWS/Azure/GCP SDK session, a Kubernetes API session, or an LDAP bind).
2. Enumerate — calls list_keys() and, where the backend has a PKI/certificate concept, list_pki_issuers(), to retrieve key and certificate metadata: algorithm, key size or curve, and identifying name.
3. Classify — determines whether each object's algorithm is quantum-vulnerable. For cert-manager specifically, the absence of a field is itself meaningful: a Certificate with no spec.privateKey block is RSA-2048 by cert-manager's own default, not unknown.
4. Risk scoring — findings feed into the unified 4-component Quantum Risk Score (0–100), the same engine used by every other analyzer.

Result Fields Explained

Connection Summary

Per-Object Fields

Algorithm Risk Reference

Credential Storage

How a saved connection's credential is stored depends on which path you're using:

• CLI (rivet scan-vault, scan-kms, scan-acm, scan-azure-kv, scan-azure-hsm, scan-gcp-kms, scan-certmanager, scan-adcs) — credentials are supplied inline at scan time and never persisted anywhere, matching scan-cert, scan-network, and scan-binary.
• Saved connections (Electron app or API) — non-secret configuration (backend type, address, custom overrides) is stored in Rivet's database. The credential itself is stored only in your machine's own OS-native credential manager (Windows Credential Manager, macOS Keychain, or Linux Secret Service), never as a database column and never in plaintext.

On headless Linux (a server or container with no desktop session), the Secret Service backend that saved connections rely on requires a running keyring daemon, which may not be present by default. This affects only the saved-connection path; the CLI never touches the credential store and is unaffected.

Limitations

• Azure Managed HSM is not yet live-verified. No emulator exists for Managed HSM, and a real instance carries an hourly cost plus a one-time security-domain activation ceremony. The connector is built and wired the same as the other seven, but has not been run against a live instance.
• Beta status reflects the analyzer as a whole, not a specific backend. All eight connectors share the same metadata-only interface and the same credential-scoping model; Beta will lift once packaged-build verification and real-cloud-account testing are complete across all eight.
• A clean scan result means no known quantum-vulnerable algorithms were detected among the objects the credential can see. It reflects the scope your credential's read permissions grant, not a guarantee that no other keys or certificates exist in the backend.

Relationship to Other Analyzers

The Key Management Analyzer uses the same 4-component unified risk engine as Certificate, Network, Binary, and Code Analysis. The difference is the detection method and the trust model: instead of reading a file or probing a network port, it authenticates directly to your key and certificate infrastructure with a credential you provide. The risk score scale (0–100) and component weights are identical across all analyzers.

For full documentation of the risk scoring methodology and quantum computing threat timeline, see the Risk Scoring documentation.