Key Inventory
What this screen is for
The Key Inventory lists your tenant's cryptographic keys and is where you create them and take every lifecycle decision about them: editing their limits, rotating, suspending, revoking, archiving and destroying. Each row shows a key's identifier, type, algorithm, status, conformance to your algorithm policy, usage against its limit, how many internal use cases reference it, and its expiry.
A key keeps one identifier for its whole life. Rotating it adds a new material version under the same identifier, so applications keep using the same name while the key underneath it changes.
What must exist first
Key managers open this screen as their home in the console, and tenant administrators open it from their tenant's navigation. It is the same screen for both: what you can do on it follows the permissions you hold, and a control you are not permitted to use is not offered.
- The permission to read keys, which is what shows this screen. Creating keys, editing their metadata, rotating, suspending, reactivating, revoking, archiving, marking for destruction, cancelling a destruction and deleting are each a further permission.
- A key protection backend. Until one is configured, creating a key is refused and the console says so.
The screen is offered to SIMPLE and STANDARD tenants alike, and creating and managing keys works the same for both. What differs is how a key is authorized for use, described under Who can use a key below.
The built-in key manager role carries the key permissions but not the permissions to read capability grants, material versions or the audit trail, so the parts of a key's detail that show them stay unavailable to it. The tenant administrator role holds them.
Decisions you make here
Creating a key
With the permission to create keys, Generate Key creates a key. These decisions are made when the key is created:
- Key identifier: the name applications use. The console accepts lowercase letters, digits, hyphens and underscores, and generates one when you leave it blank. It cannot be the identifier of another live key in your tenant.
- Structure: a simple key uses one algorithm; a composite key combines a classical and a post-quantum component in one key. A composite key can never be rotated to a simple one.
- Algorithm: only the algorithms your tenant's algorithm policy admits are offered. A later rotation can move the key to another algorithm within its purpose.
- Purpose: encryption and key wrapping, or signing and verification. It is fixed for the life of the key. It follows from the algorithm, and you choose it only for an algorithm that can serve both.
- Lifecycle limits: an expiry date, an optional earlier soft expiry that only warns, a maximum number of uses, and a soft usage limit that warns before the maximum. A maximum of 0 means unlimited. A key past its expiry or at its maximum no longer encrypts or signs, but still decrypts and verifies.
- Export: whether the key may be exported, public key included. The recommended production preset leaves export off.
Editing limits
With the permission to edit key metadata, Edit Metadata on an active key changes its maximum usage limit, its soft usage limit and its expiry date. The identifier, algorithm and type cannot be changed after creation.
Rotating a key
With the permission to rotate keys, Rotate on an active key creates a new material version under the same identifier, and new encryption and signing use it from then on. The previous version is retired; under the default lifecycle policy it still decrypts and verifies what it protected, so existing data stays readable.
The new version can use a different algorithm, always within the key's purpose, and your tenant's rotation policy can refuse a target. When the policy permits a target weaker than the current key, the console asks you to confirm that downgrade explicitly. The Conformance column marks keys whose algorithm does not meet your tenant's algorithm policy, and says when no compliant algorithm is available to rotate to.
Suspending and reactivating
With the permission to suspend keys, Suspend in an active key's detail puts it on hold, for example while a suspected compromise is investigated. A suspended key no longer encrypts or signs and cannot be rotated; under the default lifecycle policy it still decrypts and verifies. Its material versions and the grants that name it are untouched. You must give a reason, which is recorded in the audit trail against your account.
With the permission to reactivate keys, Reactivate lifts the hold and returns the key to the status it had before. Reactivate when the investigation clears the key; if a compromise is confirmed, revoke it instead.
Revoking
With the permission to revoke keys, Revoke withdraws a key for good: it no longer encrypts or signs, and it can never become active again. Under the default lifecycle policy it still decrypts and verifies existing data. You must give a reason, which is recorded in the audit trail against your account.
Archiving and destroying
Destroying a key is a chain of deliberate steps, and nothing else on the platform starts it:
- Archive a revoked key, with the permission to archive keys. Its metadata is kept for compliance, and under the default lifecycle policy it still decrypts and verifies.
- Mark for destruction an archived key, with the permission to mark keys for destruction; the console also requires the permission to delete keys. You set a cooling-off period of 1 to 365 days, 30 by default, during which the key cannot be deleted. If internal use cases still reference the key, the dialog says how many, and does not stop you.
- Cancel destruction during the cooling-off period returns the key to archived. It needs the permission to cancel destructions, and the console also requires the permission to delete keys.
- Delete Permanently once the cooling-off period has passed, with the permission to delete keys, after typing
DELETE. Every material version is destroyed, so data protected only by this key can no longer be decrypted. Capability grants that name the key are revoked, and its identifier becomes free for a new key.
Material versions
With the permission to read material versions, the Lineage tab of a key's detail lists every version with its status and algorithm. Further permissions let you revoke a retired version, mark a retired or revoked version for destruction, cancel that destruction, and destroy the version once its cooling-off period has passed, without touching the version in current use.
Who can use a key
On a STANDARD tenant, the Access tab of a key's detail lists the capability grants that name the key, with the permission to list capability grants. With the permission to create capability grants, Grant access starts a new grant with this key already chosen.
On a SIMPLE tenant, key use is authorized through internal use cases instead. The Use cases column shows how many reference each key, and Unreferenced only narrows the keys on the current page to those no use case references.
How it relates to other screens
A STANDARD tenant authorizes an actor to use a key through capability grants, which name keys from this inventory:
An internal use case references a key without owning it. The key outlives every use case that references it, and revoking a use case leaves its key here:
Deleting an application can archive keys that were used only through its actors; the applications screen says which:
Key lifecycle decisions and the operations performed with a key are recorded in the audit trail. A key's own history is on the Audit History tab of its detail, which needs the permission to read the audit trail: