Cryptography

The Cryptography module governs your organization’s cryptographic posture: which cryptographic policies are in force, which cryptographic assets exist (keys, certificates, secrets), what reviews have been performed, what exceptions are in place. It is the governance layer above key-management systems, HSMs, certificate authorities, and secret stores.

This module does not perform cryptography. It does not hold key material, does not issue certificates, does not run signing operations. It governs the posture of cryptography across the organization so an auditor or customer can see the discipline.

When you would reach for this

You set up cryptography governance when:

• A regulator or framework requires a documented cryptography policy with reviewable posture.
• Cryptographic assets (keys, certificates, secrets) need inventoried governance records distinct from where they’re actually stored.
• Certificate expiry and rotation need governance visibility beyond the issuing CA’s own console.
• Periodic cryptographic reviews need an audit trail.
• Cryptographic exceptions (use of a weak algorithm under documented compensating controls, deferred algorithm migration) need formal records.

You don’t reach for this for the key material itself, the certificate issuance, or the actual signing or encryption operations. Those live in your KMS, HSM, CA, secret store. This module is the governed register around them.

What lives in the module

Six record types:

• Cryptographic policy captures one organizational cryptographic policy: algorithm choices, key length requirements, rotation cadence, deprecation timelines.
• Cryptographic asset captures one tracked cryptographic asset: a key, a key pair, a key bundle. It points at where the asset actually lives (KMS, HSM, secret store) without holding the asset itself.
• Certificate captures one tracked certificate with expiry, issuer, scope.
• Secret captures one tracked secret with rotation cadence and storage reference.
• Cryptographic review captures a periodic review of cryptographic posture.
• Cryptographic exception captures an approved deviation from policy (e.g., a vendor system that requires an older algorithm).

A worked example: a digital wallet operator governs its cryptography across customer accounts

A digital wallet operator handles customer funds, processes transactions, and signs records for regulatory reporting. Its cryptographic posture is core: customer balances, transaction integrity, regulatory submissions all depend on cryptography. The security architect, Beatriz, sets up Cryptography like this.

Step 1: define cryptographic policies. Beatriz creates policy records for the major areas:

• customer-account-encryption-at-rest — AES-256, key rotation annually, KMS-backed.
• transaction-signing — ECDSA P-256, signed at the application tier with a key held in HSM.
• regulatory-submission-signing — RSA-4096, signed by the compliance signing service.
• data-in-transit — TLS 1.3 only, no older versions, periodic cipher suite review.

Each policy captures the algorithm requirements, key length, rotation cadence, and migration timeline for any deprecated choice.

Step 2: inventory cryptographic assets. Each significant key or key bundle becomes a record: the customer account encryption key (in the KMS), the transaction signing key (in the HSM), the regulatory submission key (in the HSM), TLS server keys. Each record names where the asset actually lives, the owner, the rotation date.

Step 3: certificate register. Public-facing TLS certificates, code-signing certificates, mTLS certificates with counterparties: each is a record with issuer, expiry, scope, owner. The register surfaces approaching expiries.

Step 4: secret register. API keys, integration credentials, service-account secrets that aren’t keys but need rotation discipline: each is a record with rotation cadence and storage reference. The actual secret value is never in the record.

Step 5: periodic reviews. Annually, Beatriz conducts a cryptographic review per policy: are the policies still appropriate, are the deployed assets still aligned, are there algorithm migrations needed.

Step 6: exceptions. A legacy partner integration requires TLS 1.2 with a specific cipher suite for backwards compatibility. Beatriz creates a cryptographic exception: scope (the specific integration), reason (partner system limitation), compensating posture (network segmentation, additional monitoring), approver, expiry (when the partner agrees to migrate).

After a year:

• The cryptographic posture is inventoried in a governed register.
• Approaching certificate expiries are surfaced ahead of time.
• Exceptions are bounded and audited.
• An auditor reviewing the cryptographic posture has a single place to look.

What you’ll see in the product

Cryptography lives under Governance → Cryptography in the workspace.

Six top-level tabs: Policies, Cryptographic Assets, Certificates, Secrets, Cryptographic Reviews, Exceptions.

Every change is captured in the workspace Audit Log.

Common workflows

Defining a cryptographic policy

1. Policies → New. Capture algorithm, key length, rotation cadence, deprecation timeline.
2. Inventory existing cryptographic assets against the policy; raise findings for any misalignment.

Inventorying assets

1. Cryptographic Assets → New. Reference the asset’s actual storage location, capture owner, classification, rotation cadence.
2. The record is metadata; the asset itself lives where it lives.

Tracking certificate expiry

1. Certificates → New. Capture issuer, expiry, scope.
2. The register surfaces approaching expiries.
3. Renewal is handled in the CA and the asset record is updated.

Requesting an exception

1. Exceptions → New. Scope, reason, compensating posture, approver, expiry.
2. Approver decides.
3. The exception is visible alongside the affected policy and asset records.

Related

• Risks - cryptographic posture failures often become risks.
• Findings - posture misalignments are findings.
• Exceptions - cryptographic exceptions also surface in the central exceptions register.
• Vulnerability Management - algorithm vulnerabilities are also vulnerabilities.
• Change Management - algorithm migrations are governed changes.