Policies
What this screen is for
The Policies hub shows the cryptographic policies that govern your tenant, one card each: Algorithm Availability, Algorithm Rotation, Key Lifecycle and, when the deployment delegates the decision to tenants, TSA Usage. Each card names the template in effect. Algorithm availability and rotation are chosen from a catalog of predefined templates; the key lifecycle policy is edited on its own screen; TSA usage is a three-way switch.
Every policy has two levels. The platform administrator sets a deployment-wide policy on the Platform Policies screen, and your tenant either inherits it or carries a policy of its own. This screen is where your tenant's own policy is set, changed or given up.
What must exist first
The hub is offered to SIMPLE and STANDARD tenants alike. It appears in the navigation for anyone holding a permission to read the tenant's policies, or to read or write its lifecycle policy. The built-in key manager role holds none of these; the tenant administrator role holds them all.
- The permission to read effective policies loads the algorithm, rotation and TSA cards. Without it the algorithm and rotation cards show no template name, and the TSA card is not shown at all.
- Changing the algorithm or rotation template needs the write permission for that policy; Follow deployment policy on either card is offered with the same permission, while the server requires the delete permission to carry it out.
- Browsing the template catalog needs the permission to read policy templates; without it the dialog reports that templates could not be loaded.
- The Key Lifecycle card appears only with the permission to read the lifecycle policy.
- The TSA Usage card appears only with the permission to read TSA usage and only while the deployment's TSA mode is OPTIONAL.
Decisions you make here
Choosing an algorithm availability template
The algorithm availability policy decides which algorithms your tenant may create keys with, import, and rotate to. With the write permission, Change template opens the catalog: one card per template with its description, a Currently applied mark on the one in effect, and Preview details to inspect its full content. Apply is enabled only once you select a template other than the current one.
Applying a template makes its content your tenant's policy. It replaces the deployment policy for your tenant; it is not combined with it. The catalog offers every template the platform ships and does not hide the ones the deployment policy would refuse: the server compares the policy the template would give your tenant with the deployment's effective policy, dimension by dimension, and refuses a template that admits anything the deployment does not. A deployment dimension that is left empty restricts nothing. You cannot write a policy of your own here: a tenant may only pick a template.
Choosing an algorithm rotation template
The rotation policy sets the rules a rotation target must satisfy: whether the new algorithm must serve the same operations, whether a weaker algorithm is refused, whether a classical key may move to a post-quantum algorithm and the reverse, whether the algorithm family may change, and which standards the target must meet. It is applied when a key is rotated on the Key Inventory. The catalog dialog works exactly as for the algorithm policy, and the template you apply replaces the deployment's for your tenant.
When a change is refused
When the platform administrator has not allowed your tenant to choose its own policies, the cards still offer Change template. Applying is then refused by the server, and the dialog shows You don't have permission to perform this action. The same sentence is shown for a missing permission, so it does not tell you which of the two is the cause; the platform administrator can. Follow deployment policy is not offered in that case.
A deployment whose policies the platform administrator has locked does not by itself stop you. The lock fixes the deployment's own policy; whether your tenant may carry a policy of its own is the separate permission above. With it, you may apply a template that is narrower than the deployment's on a locked deployment exactly as on an unlocked one.
A template that is wider than the deployment policy is refused differently: the refusal names each dimension the template exceeds and the values the deployment does not admit. Choose a narrower template, or ask the platform administrator to widen the deployment policy.
Resetting to the deployment policy
Follow deployment policy is offered on a card whose policy is your tenant's own, and only while the platform administrator lets your tenant choose its own policies: without that permission a reset would undo a policy chosen for your tenant, so the server refuses it.
It does not remove your tenant's policy: it binds it to the deployment policy, so that your tenant's effective policy is the deployment's from the next operation on. What the card shows afterwards depends on how the deployment policy is set:
- When the deployment policy is a template, your tenant's policy is bound to that template, and the card names it. A later change to the template's content reaches your tenant without another reset. If the platform administrator later moves the deployment to a different template, your tenant stays on the one it was bound to; if the new one is narrower, the platform administrator is shown your tenant as a conflict and decides.
- When the deployment policy was written by hand rather than picked from a template, your tenant receives a snapshot of the deployment's effective policy as its own custom policy, and the card says it follows the deployment's custom policy rather than naming a template. A later change to the deployment policy does not reach it; reset again to take it.
The card keeps offering Follow deployment policy in both cases, and pressing it on a policy that already follows the deployment changes nothing. It is refused when the installation has no deployment policy for that card, because there is nothing to follow.
A tenant created without a template of its own starts out following the deployment policy in the same way, in whichever of the two states the deployment policy dictates.
Opening the key lifecycle editor
The Key Lifecycle card shows the name of the lifecycle policy in effect and Open editor takes you to its own screen. It has no inline change or reset; everything about the lifecycle policy is decided there.
Choosing TSA usage
The card appears only while the deployment's TSA mode is OPTIONAL, which is the one mode in which each tenant decides whether its signatures are time-stamped. It shows ON, OFF and inherit, and it can be changed only when your tenant already has a selection of its own: while your tenant inherits, the switch is disabled and the card says so. The platform administrator makes the first selection for a tenant from the Platform Policies screen; from then on you can move it between ON and OFF, or choose inherit to give it up.
Selecting ON is refused when no time-stamping connection is configured to stamp for your tenant; the refusal is shown below the cards.
When a saved policy takes effect
A template you apply, or a reset, is written to the policy cache and an invalidation is published to the crypto service at once, so the next key creation, import or rotation is evaluated under the new policy. The console also refreshes the Key Inventory's algorithm lists and rotation previews. Data already encrypted or signed is not affected by any policy on this screen.
How it relates to other screens
The policies here are applied when keys are created, imported and rotated on the Key Inventory. The Conformance column there marks keys whose algorithm no longer meets your algorithm policy:
The key lifecycle policy, which decides what a suspended, revoked or archived key may still do, has its own screen:
Constraint policies are a different thing: they limit how a capability grant may be used, and they are managed on their own screen on STANDARD tenants: