Skip to content

Dashboard

What this screen is for

The Dashboard is where your tenant opens: a read-only summary of its key estate, its cryptographic posture and its recent activity, assembled from the same reports the Analytics screen and the Audit Log show in full. Nothing on it changes your tenant. What you do here is read, follow a link to the screen that holds the detail, and, while your tenant is being set up, work through the Get started card.

Every figure is your own tenant's. A platform administrator working inside your tenant sees the same page over your data.

What must exist first

The Dashboard is offered to SIMPLE and STANDARD tenants alike. It is in the navigation of a tenant administrator, auditor or viewer; a key manager's navigation has no Dashboard entry. Each part of the page then needs its own permission:

  • The permission to read tenant analytics, for the four figures at the top, Needs attention, Get started, the posture band, Keys by Algorithm, PQC Migration Progress and Key Health Summary. Every built-in tenant role holds it.
  • The permission to read at least one audit trail, for Recent Activity, which is not shown without it. Key Operations (Last 30 Days) and Admin Activity read the audit trail too, but they are shown regardless: without the permission the chart stays empty and the card shows a loading spinner that never resolves. The built-in viewer role is in this position.

Decisions you make here

Working through Get started

The card appears above everything else while your tenant is not yet set up, and only to a viewer who can measure every step: the permission to read analytics and to list users, plus the permission to read exchanges on a STANDARD tenant or to read internal use cases on a SIMPLE one. Each step completes itself from what the server counts, and the card says which count:

  • Activate your first cryptographic exchange (STANDARD): an exchange whose status is ACTIVE. A draft or ready exchange does not complete it.
  • Create your first key and Create your first internal use case (SIMPLE): a key in the inventory, whatever its status, and a use case of any status.
  • Connect your application: the first recorded use of any key material your tenant has ever owned. It is a durable fact that never returns to false, and it is not the operations counter shown lower on this page.
  • Invite your team: two or more people whose membership is ACTIVE or PENDING: an invitation not yet accepted counts, a suspended membership does not.

A step's action is withheld until the step before it is done, but a step that is already done is never locked, whatever the state of its predecessor. The card's actions open the New Exchange wizard, the key wizard, the use-case dialog, a See how guide for the first operation, and the Team Members screen; an action you lack the permission for says so.

When every step is done, a viewer holding the permission to complete the first run writes a latch on the server, and from then on the card is not shown to anyone, including an administrator who joins later. Hide is yours alone, kept in this browser; Help › Get started reopens it while a step is still open. A viewer who saw the card incomplete is shown a one-time You're set up bar when it completes. The card is never offered on a RAPIDAPI tenant.

Reading Needs attention

Once the card is gone, or was never offered, the slot shows Needs attention: up to four rows, each naming exactly the population the server counted, from two reports that fail independently.

  • Active keys that have passed their soft expiration and have not expired yet.
  • Keys of any status that have reached the soft threshold of their usage limit, including keys at the hard limit and keys whose limit was lowered below the uses they had already recorded.
  • Keys whose status is EXPIRED. Its Expired keys link is the one row whose destination is a real filter over the same population; the other rows link to the Key Inventory or to Analytics unfiltered.
  • Active keys using an algorithm that carries quantum debt.

Nothing needs your attention right now is printed only when both reports answered, all four figures were measured at zero and no key custody row is shown. A report that failed shows its own error in place, and the other report's rows still render.

With the permission to read your tenant's key custody, one more row appears while a custody move concerns your tenant: on an ANKA-hosted deployment a destination to choose after a plan change, your consent to move your keys off your own KMS or a window waiting to be scheduled; on any deployment a scheduled maintenance window with its start, or a move in progress. Open key protection takes you to the Integrations tab of Settings, where the move is handled.

Reading the posture band

Cryptographic Posture is computed by the server for your tenant alone: the verdict is the worst of four pillars, plus your tenant's own key-custody sovereignty when it has declared a backend of its own. It is — rather than Healthy or At Risk while your tenant has no keys; when Governance & Compliance drives it, it names which of that pillar's two readings did. The four cards are the CAPA v0.11 pillars measured over keys:

  • Crypto-Agility: the share of your keys, in every lifecycle state, that have at least one admissible rotation target under your rotation policy.
  • Sovereignty: always — on this screen, because the tenant plane has no measurement for it. The verdict above it can still name Sovereignty as the reason your tenant is at risk, with no card explaining why.
  • Modernization: the number is 100 minus the share of active keys that carry quantum debt, so a tenant whose active keys are all symmetric reads 100% modernized. Its status comes from whether those classical keys have a post-quantum rotation target, not from the number.
  • Governance & Compliance: one pillar read two ways. The headline is conformance: of your keys, how many use an algorithm your own algorithm template still permits, measured only while your tenant has an explicit algorithm template. The second line is declaration: 1 of 1 when your tenant has an explicit template for its algorithm, rotation or lifecycle policy, otherwise 0 of 1. The status is the worse of the two readings.

Enterprise Readiness, the fifth pillar, is measured on the deployment plane and has no card here. Selecting a pillar card opens its breakdown; the Governance & Compliance breakdown shows both readings and offers View N non-conforming keys, which opens the Key Inventory filtered to them. Posture Trend plots Crypto-Agility, Modernization and the conformance reading of Governance & Compliance over the last 90 days of daily snapshots, taken at 02:00 UTC, and shows Collecting baseline until two exist.

Reading the figures

The four cards at the top count the keys of your tenant that have current material and were not deleted. Total Keys covers every status; Active Keys those whose status is ACTIVE; PQC Readiness is the post-quantum and hybrid share of the active keys, where a symmetric key counts in the total but in neither share, so a tenant holding only AES keys reads 0%; Alerts adds the soft-expiration and usage-threshold rows of Needs attention, and does not count expired keys.

Key Operations (Last 30 Days) counts the cryptographic events your audit trail recorded per day over the last 30 days, successful and failed alike. An event is post-quantum when its algorithm name begins with ML-KEM, ML-DSA, SLH-DSA or FALCON, and classical otherwise, so a composite whose name begins differently is charted as classical. Days with no events are left out rather than drawn at zero.

Keys by Algorithm is the share of active keys per algorithm, with symmetric algorithms coloured as classical.

Admin Activity has no window: it counts every administrative event your tenant ever recorded, minus those a platform operator performed on the platform side. Success Rate is the share whose outcome was not a failure, Active Admins the distinct actors over that whole history, and Recent Changes by Type the first five entity types the database returns, with their all-time counts: neither recent nor the five largest.

PQC Migration Progress shows the same adoption figure as PQC Readiness, and Legacy keys remaining the active keys with a quantum-debt algorithm. Key Health Summary repeats the attention rows, then Total ops, which is the sum of each key's current material counter: a rotation starts the key's counter again at zero, so the figure falls when a key is rotated. Rotated counts active keys rotated at least once and Revoked keys whose status is REVOKED.

Opening recent activity

Recent Activity shows the newest eight administrative and the newest eight cryptographic events of your tenant, in two tabs, from the same feed the Audit Log lists. Selecting a row opens the same event details the Audit Log opens, and View full audit log takes you there.

How it relates to other screens

Each report summarised at the top of this page is shown in full, with its export where one exists, on the Analytics screen:

The activity panel, the operations chart and the administrative figures come from the audit trail:

The Conformance breakdown's View N non-conforming keys and the Expired keys row of Needs attention open the Key Inventory already filtered:

Whether the governance and conformance pillars measure anything is decided by the template your tenant applies on the Policies screen, and the Get started steps are completed on their own screens:

Where to read more