Key Inventory

What this screen is for

The Key Inventory lists every key your tenant still holds, whatever its state — active, expired, suspended, revoked, archived or pending destruction — and is where you create keys and take every lifecycle decision about them. Each row shows a key's identifier, type, algorithm, status, conformance to your algorithm policy, usage against its limit, how many references point at it and its expiry; a revoked or archived key also shows its cause and when, and a key pending destruction how long remains. Total Keys counts every key the current filter selects, across all pages.

Select a row to open that key's details; the controls inside a row keep their own job. 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. A key's detail also shows its Key identity, which names that one key. An identifier is never reused in your tenant, not even after its key is destroyed.

What must exist first

Key managers and tenant administrators open this screen from their tenant's navigation; what you can do on it follows the permissions you hold, and a control you may not use is not offered. The permission to read keys shows the screen; creating keys, editing their metadata, rotating, suspending, reactivating, revoking, archiving, requesting a destruction and cancelling one are each a further permission. A key protection backend must also be configured: until one is, 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 How it relates to other screens below. The built-in key manager role carries the key, material version and capability grant permissions but not the permission to read the audit trail, so a key's Audit History tab stays unavailable to it. The tenant administrator role holds them all.

Decisions you make here

Besides your permissions, the actions a key offers follow its state: active offers Rotate, Suspend and Revoke; expired, Rotate and Revoke; suspended, Reactivate and Revoke; revoked, Archive; archived, Mark for destruction; pending destruction, Cancel destruction.

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 any key your tenant has ever held, destroyed keys included: an identifier is never reused.
Structure, Algorithm, Purpose and Export: a simple key uses one algorithm; a composite key combines a classical and a post-quantum component and never rotates to a simple one. Only algorithms your tenant's algorithm policy admits are offered; a later rotation can move the key to another within its purpose. The purpose, encryption and key wrapping or signing and verification, is fixed for the key's life; it follows from the algorithm, and you choose it only when one serves both. Export says whether the key, public key included, may be exported; the recommended production preset leaves it off.
Lifecycle limits: an expiry date, an optional earlier soft expiry that only warns, a maximum number of uses (0 means unlimited) and a soft usage limit that warns before it. The maximum is a protection budget: each signature and each encryption (one per key the result is encrypted to) counts one use, for simple and composite keys alike; decrypting and verifying never count.

A key past its expiry or at its maximum shows as expired, with the limit it reached, and no longer encrypts or signs, but nothing else changes: its current version is not retired, the key is not suspended or revoked and no cause is recorded, so it keeps decrypting and verifying what it protected, and rotating it gives it a new version that protects again.

Editing a key's metadata

With the permission to edit key metadata, Edit Metadata in a key's details panel, not on its row, changes the key's name and description in every state except deleted. An active, expired or suspended key, which still has current key material, also takes changes to export, the usage limits and the expiry settings; a revoked, archived or pending-destruction key has no current material, so only its name and description change. The identifier, algorithm and type never change after creation.

A limit the key has already reached is final: once its expiry has passed the expiry date can no longer be changed or cleared, and once its maximum number of uses is used up neither can the maximum. The dialog shows such a field read-only and points you to rotating the key, the way forward. A new maximum must also be above the uses the key has already recorded.

Rotating a key, by hand or on a schedule

With the permission to rotate keys, Rotate on an active or expired key creates a new material version under the same identifier, which new encryption and signing use from then on; the previous version is retired. Rotation is how an expired key protects again: the new version starts with no uses counted and its own expiry, which must lie in the future. Your tenant's lifecycle policy decides which key states can be rotated, and Rotate is offered only where it allows it.

A rotation carries no suspension or revocation cause, because nothing went wrong, so the cause rule under Suspending, reactivating and revoking never applies to a rotated-out version: under the default lifecycle policy it keeps decrypting and verifying what it protected, and re-encryption off it keeps working, so existing data stays readable.

If the answer to a rotation is lost, for example the connection drops or the request times out, confirming the same rotation again in the same window never rotates the key twice: the console sends both attempts as one rotation, so the key advances at most once. Closing the window, or changing the target, starts a new rotation. If another rotation of the key landed first, the rotation is refused with nothing changed: reopen the key to see its current version.

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.

With the permission to read rotation schedules, the Next rotation column, and the same row after a key's expiry in its details, show when the key next rotates automatically, in your display time zone. A past date is marked Overdue; "—" means the key is not scheduled.

You enable automatic rotation key by key with Rotate this key automatically, at the top of a key's Automatic rotation section; the sentence under it says what will rotate the key. The switch governs the triggers under it: while it is off nothing rotates the key, and the triggers keep their settings, shown paused and not editable, until you turn it on again. You can always turn it on: with an interval or a usage option already in place it takes effect at once; with none, it opens the triggers and asks you to choose one, and nothing is saved until you do.

Under When to rotate, the interval row shows the interval, its source and Edit. Hours are offered only when the deployment's minimum interval is under a day, minutes only when it is under an hour; an interval below that minimum is refused before sending, and a stored hour or minute interval the deployment no longer allows must become days, months or years before saving. The Tolerance is the window after the due instant in which the scheduler starts the rotation, spread so that keys due together do not rotate at once: 1% of the effective interval, at most 6 hours, never before the due instant.

A key with a maximum number of uses can also rotate on its usage. Under When to rotate, At the soft usage limit and When the usage limit is exhausted, each followed by the key's limit, rotate the key when its uses reach that limit, while automatic rotation is enabled; either one is enough without an interval. An option is offered only when the key has that limit; the section says when it is missing. With both on, the soft limit normally rotates the key first and exhaustion acts as a safeguard.

While automatic rotation is on you can turn any trigger off; turning off the last one also turns automatic rotation off, as the confirmation says. A key returned to its inherited interval keeps rotating when the tenant or the deployment sets one, and the editor names the interval it would follow, or none. A refused change is explained next to its control. Reaching either limit is recorded in the audit trail and e-mailed, in English, to everyone in your tenant who may change rotation schedules.

The first rotation wins, whether time, usage or a person asked for it, and every rotation starts the count and the interval again from the new version. The Rotation cause column of the Lineage tab says why each version exists: Manual when someone rotated the key, Scheduled when automatic rotation did on its interval, Usage threshold or Usage limit reached when the previous version reached its soft limit or its maximum, and "—" for the first version or one created before the cause was recorded.

With the permission to read schedules, the Rotation schedule tab shows the key's schedule and its runs, 20 per page (with more than one schedule, Show executions chooses whose runs are shown), with their state, planned time, attempts, result and completion. A run replaced by a newer one says so. Without a schedule the tab says automatic rotation is not enabled; when scheduling is unavailable it offers Retry. Rotate now there is the same rotation as Rotate, offered exactly when Rotate is. Any rotation restarts the interval from the new version.

Suspending, reactivating and revoking

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 under either shipped lifecycle policy, cannot be rotated, and — when the cause is a security compromise — the platform refuses every operation on it, whatever your tenant's lifecycle policy says. Its material versions and the grants that name it are untouched. The dialog asks for two required inputs:

Cause: one of the causes the platform publishes — security compromise, algorithm deprecated, administrative, policy violation or regulatory requirement. It is not a label: it decides what survives the hold, as set out below. There is no default; a suspension with none is refused. Reason: free text, recorded in the audit trail against your account and read by whoever decides later whether the hold can be lifted.

A security compromise stops decrypting data already encrypted with the key, verifying signatures already made with it, and re-encrypting or re-signing off it onto another key — and it alone also stops every write, whatever your tenant's lifecycle policy allows on a suspended key. None of the other four causes stops those reads: while the key is on hold, what stays readable is decided by that policy, exactly as before the hold. The cause can only narrow the policy further, never relax it.

Before you confirm, the dialog shows what the selected cause does to this key — which reads stop and which continue, version by version. That statement is computed by the server for the key you are looking at, under your tenant's lifecycle policy; the console renders it and decides none of it. Each act also carries whether it can be taken from the key's current state at all: an act the server marks as not applicable shows no live outcome, because its verdicts describe a state the key cannot reach from here.

The rule follows NIST SP 800-57 Part 1 (§7.3–§7.4): a key withdrawn for a reason other than a compromise may keep processing data it already protected. One limitation is declared: the platform cannot tell when data was protected, so data protected during a suspension reads like data protected before it. A key revoked or suspended for SECURITY_COMPROMISE is refused every cryptographic operation, DECRYPT and VERIFY included: §7.5 permits such processing only under highly controlled conditions, which the platform cannot attest to, so it is stricter than NIST there.

With the permission to reactivate keys, Reactivate lifts the hold, whatever its cause — a security compromise included, when the investigation clears the key — returns the key to its prior status and clears the cause, with the history kept in the audit trail. Encryption and signing come back with that status; the read path follows the server's verdict, shown operation by operation, which can read stops on some versions when a version was revoked for a compromise. If a compromise is confirmed, revoke the key for a security compromise instead.

With the permission to revoke keys, Revoke withdraws a key for good: it no longer encrypts or signs, whatever the cause, and it can never become active again. A suspended key can be revoked directly, and after a revoke its detail stays open so you can archive it. A key is revoked once: an already revoked, archived or pending-destruction key cannot be revoked again, because that would replace the cause it was revoked for. A key suspended for a security compromise can be revoked only for a security compromise, and the dialog says so if you choose another cause.

Revoke asks for the same two required inputs as Suspend — a cause and a reason — and shows the same server-computed statement of what the chosen cause does to reads on this key. The rule is the same: revoking for a security compromise stops decrypt, verify and re-encryption or re-signing off the key on every material version; revoking for any of the other four causes does not stop historical decrypt, verify or migration off the key — your tenant's lifecycle policy still applies to them and may deny them on its own. There is no default cause.

Archiving, destroying and material versions

Destroying a key is a chain of deliberate steps, and no single person completes it:

Archive a revoked key, with the permission to archive keys. Its metadata is kept for compliance. Archiving records no cause of its own and asks for none, but it asks you to type the key's identifier and to give a reason, which is required and recorded in the audit trail: the key keeps the cause it was revoked for, and the dialog shows it together with its outcome. So a key revoked for a security compromise stays unreadable after it is archived, and a key revoked for any other cause is judged by your tenant's lifecycle policy, as before.
Mark for destruction an archived key, with the permission to request destructions. You set a cooling-off period of 7 to 365 days, prefilled with your tenant's default, and give a reason, which is required and recorded in the audit trail. The request waits for the approval of another person, on the approvals screen; nothing about the key changes until then. If anything still references the key, the dialog says so, as described after this list, and does not stop you.
The approval starts the cooling-off period: the key reads pending destruction, and its detail shows when the destruction runs. When the period ends, the platform destroys the key on its own. Every material version is destroyed, so data protected only by this key can no longer be decrypted. The key then leaves the list; the Deleted view shows it read-only, with its cause and dates, and its identifier is never used again.
Cancel destruction before the platform runs it returns the key to archived, and each version to the status it had before, so a version revoked for a security compromise on the Lineage tab is revoked for it again, even when the key was revoked for another cause. It needs the permission to cancel destructions. A request still waiting for approval is withdrawn from the approvals screen instead.

Destroying a key ends, in the same step, every authorization that names it: cryptographic exchanges not yet ended and internal use cases that use the key are revoked, each recording that the key's destruction ended it and which key it was, and capability grants that name the key are retired. This holds whether the key or its last material version is destroyed. A use case is revoked whole even when it also names another key; that other key is not destroyed and nothing about it changes.

Every dialog that requests a destruction says so before you confirm: Mark for destruction, and the request that destroys the key's last material version on the Lineage tab. It states how many internal use cases and cryptographic exchanges that reference the key now will be revoked, leaving out a kind with none, and that the capability grants naming it are retired. The counts are a reading, never a restriction.

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 or PENDING_PRIMARY version, giving a required cause and a reason; the server decides from that cause and your lifecycle policy what the version may still do. They also let you request the destruction of a RETIRED, REVOKED or PENDING_PRIMARY version and cancel it: once another person approves, the platform destroys the version when its cooling-off period ends.

How it relates to other screens

On a STANDARD tenant, a key's Access tab lists the grants naming it, with the permission to list capability grants, and Grant access starts one with this key chosen, with the permission to create them. A SIMPLE tenant authorizes key use through internal use cases. On every tenant type the References column counts the internal use cases, the exchanges not yet revoked or expired and the standalone grants that reference each key, each once; select it for the breakdown. A wildcard grant names no key and is not counted. Unreferenced only shows keys with none. The count never blocks an action.

A STANDARD tenant authorizes an actor to use a key through capability grants, standalone or owned by a cryptographic exchange, which name keys from this inventory; in the References column a standalone grant counts as a grant, and a grant an exchange owns counts as that exchange, never twice. An internal use case references a key without owning it: revoking a use case leaves its key here, and destroying a key revokes the use cases that use it.

Deleting an application can archive keys used only through its actors; the applications screen says which. Key lifecycle decisions and key operations are recorded in the audit trail; a key's own history is on its Audit History tab, which needs the permission to read the audit trail. The tab groups operations by key, because one identifier may have been held by several: one section per key, with its lifespan and operation count, a banner when more than one key performed operations, and Identity not recorded for operations that name no key. You can narrow it to one key.

On the Audit History tab rows read newest first. An administrative row says what changed: a rotation reads Rotation v1 → v2 with its cause (Manual, Scheduled, Usage threshold or Usage limit reached) and who started it, a failed rotation gives its reason, and other changes list each field before → after. Performed by names the scheduler, the system or a user, and keeps the identifier, which you can copy. A change you make in the key's detail can take a few seconds to appear; the tab reads again by itself, and Refresh reads it on demand.