Skip to content

Key Lifecycle

What this screen is for

The key lifecycle policy decides which operations a key may still perform in each state of its life. It is two grids of ALLOW and DENY cells, one row per operation and one column per status, and this screen is where you read and edit your tenant's policy.

The Key Inventory shows one status per key. The policy sees two: the key identifier, called the alias, with the statuses ACTIVE, SUSPENDED, RETIRED and DELETED_LOGICAL; and each material version under it, with PENDING_PRIMARY, PRIMARY, RETIRED, REVOKED, PENDING_DESTRUCTION and DESTROYED. An operation is permitted only when the alias cell and the material cell are both ALLOW; a missing cell counts as DENY.

The platform enforces the policy on every encrypt, decrypt, sign, verify, re-encrypt and re-sign request of the crypto API, after the capability grant has been checked; a re-encrypt or re-sign checks the source key on the DECRYPT or VERIFY row and the target key on the REENCRYPT or RESIGN row.

The streaming file operations do not consult the policy: a suspended key still serves them, and a key with no current material is refused as not found. A denied request is answered as forbidden, worded like a grant denial, without saying which cell denied it.

What must exist first

The screen is reached from the Key Lifecycle card on the Policies hub, and is offered to SIMPLE and STANDARD tenants alike.

  • The permission to read the lifecycle policy, which is what shows the grids. Without it the screen says you do not have permission to view the policy.
  • The permission to write the lifecycle policy, which enables the DEFAULT and STRICT buttons, the cells and Save policy. Without it the grids are read-only.
  • The permission to delete the lifecycle policy, which shows Reset to DEFAULT.
  • A stored deployment lifecycle policy. It is the ceiling every tenant policy is checked against, and the platform stores it for itself: a new installation comes up with the built-in DEFAULT template already in place, so there is nothing to do here before your first save. Deployment ceiling missing answers a deployment that has no stored policy at all, which is a fault to report rather than a state an installation passes through.

Decisions you make here

Reading the two grids against your keys

Each lifecycle decision on the Key Inventory sets the two statuses the policy reads:

  • An active key is ACTIVE with its current material PRIMARY.
  • Suspending a key makes the alias SUSPENDED; its material versions are not changed.
  • Revoking a key makes the alias RETIRED and every material version REVOKED.
  • Archiving a key makes the alias RETIRED and every material version RETIRED.
  • The approval of a key's destruction request makes every material version PENDING_DESTRUCTION; the alias stays RETIRED.
  • Destroying a key makes the alias DELETED_LOGICAL and every material version DESTROYED, and destroyed material is refused before the policy is consulted.
  • Rotating a key leaves the alias ACTIVE, makes the new version PRIMARY and the previous one RETIRED.

The alias grid also carries rows for ROTATE, SUSPEND, RETIRE and REVOKE, and the material grid for ROTATE and REVOKE. They are stored and checked against the ceiling like every other row, but no operation reads them today: rotation and the lifecycle actions follow a fixed rule of their own. The transition lists a policy also carries are not shown here and are not consulted.

Choosing DEFAULT or STRICT

DEFAULT and STRICT load the platform's two built-in templates into the grids; nothing is stored until you save.

Under DEFAULT, an active key may do everything. A suspended, revoked or archived key, a key marked for destruction, and the previous versions of a rotated key may still decrypt and verify, and nothing else, until their material is destroyed — with one platform rule the policy cannot relax: a key suspended or revoked for a security compromise is refused those reads too, whatever this grid says (see Key Inventory — Suspending and reactivating). Under DEFAULT, data already protected stays readable through every state but deletion, for every cause except a security compromise.

Under STRICT, only an active key's current material may do anything, decrypt and verify included. Suspending, revoking or archiving a key seals what it protected, and so does rotating it: what was encrypted under the previous version can no longer be decrypted unless it was re-encrypted first. Choose STRICT only when sealing on rotation is what you want.

Editing a cell

With the write permission, clicking a cell toggles it between ALLOW and DENY, and the template name becomes CUSTOM. Save policy is enabled once something has changed and sends the whole policy: both grids replace your tenant's stored policy, and your tenant then has a policy of its own even if you saved a template unchanged.

Staying within the deployment ceiling

Your tenant may set DENY anywhere, and ALLOW only where the deployment policy also allows. A save that exceeds the ceiling is refused, and the screen lists every offending cell, as alias · DECRYPT on RETIRED; set each back to DENY or pick a stricter template.

A row the deployment policy does not declare counts as DENY in every column, so applying a built-in template can be refused on a deployment whose stored policy carries fewer rows than the template. That is a ceiling your platform administrator chose to narrow, not something a new installation starts out with: the built-in templates fit under the ceiling a fresh deployment is given, and both DEFAULT and STRICT apply there without anyone preparing anything.

Resetting

With the delete permission, Reset to DEFAULT removes your tenant's own policy after you confirm. Your tenant then follows the deployment policy, whatever it is: the dialog and the confirmation message say DEFAULT, but if the platform administrator has stored STRICT or a custom ceiling, that is what applies. The screen does not say whether your tenant has a policy of its own or inherits; the template badge names whichever policy is in effect.

When a saved policy takes effect

Once a save or a reset is committed, the policy is written to the policy cache and an invalidation is published to the crypto service, which drops its copy and reads the new policy on the next operation.

There is no restart and no waiting period: an operation a stricter policy denies is refused on the next request. Should the invalidation not arrive, the crypto service keeps its copy for the policy cache lifetime, five minutes by default. The Key Lifecycle card on the hub can show the previous template name for up to a minute after you go back.

How it relates to other screens

The screen is opened from, and returns to, the Policies hub:

The statuses the grids are keyed on are set by the lifecycle actions on the Key Inventory. The suspend and archive dialogs there describe what stops; under DEFAULT, decrypt and verify are what survives:

On a STANDARD tenant an operation needs both a capability grant for the key and a lifecycle policy that allows it in the key's current state; either one alone refuses it:

Where to read more