Platform Overview
What this screen is for
The Platform Overview is where the platform context opens: a read-only summary of the whole installation, assembled from the same reports the Tenants, Analytics, System Health, Integration Topology and audit screens show in full. It has six bands, top to bottom: Posture, Platform at a glance, Activity, Tenants & alerts, PQC migration and Recent activity. Nothing on it changes the platform. What you do here is read, follow a link to the screen that holds the detail, and refresh.
Beside the title, two chips name the platform version and the deployment type your session reports. The ago figure at the right is the newest successful read on the page; every read is repeated when it is a minute old and the window regains focus, and the refresh control repeats them all at once. Every figure states its period: Current state for a count of what exists now, the instant of measurement for the services, and the window the server applied for anything counted over time.
What must exist first
This is a platform screen: opening it while you are working inside a tenant sends you to that tenant's Dashboard. Its sidebar entry is shown to every platform role, and each band then needs its own permission. A read you are not permitted, or that fails, degrades its own card and never blanks the page:
- The permission to read platform analytics, for the posture band, the Keys card, the key distribution, the migration card and the per-tenant columns of the matrix.
- The permission to read platform observability, for the Services card.
- The permissions to read the platform statistics and the platform crypto audit trail, for the Crypto operations card, the operations chart and Top tenants by operations; the admin trail permission for the Admin tab of recent activity. The built-in platform viewer role holds no audit permission; the administrator and auditor roles hold them all.
- The permission to read each integration family's platform configuration, for Enterprise Readiness. A family you may not read is left out of its count and named as not readable.
- The permission to list tenants, which fills the Tenants card, the matrix rows and the tenant names elsewhere on the page.
Every figure is computed over the tenants of your installation that have not been closed, whatever their status. The key figures include the platform tenant's own keys; the Tenants and Users cards and the posture pillars exclude it.
Decisions you make here
Reading the posture band
The hero states one verdict: Healthy, At Risk with the pillar reading that drives it and its priority action, or Posture unavailable when nothing could be measured. The server computes the verdict as the worst of its four measurements over your tenants, and it is — while no key has been evaluated; the console adds only Sovereignty, which the server does not fold in. When the verdict is driven by Governance & Compliance it names which of its two readings did, conformance or policy declaration. The third slot is the most severe of the alerts listed lower on the page.
The five cards below are the five pillars of CAPA v0.11, each with the threshold the server graded it against printed on the card where it has one:
- Crypto-Agility: the share of evaluated keys, in every lifecycle state, with at least one admissible rotation target under their tenant's rotation policy.
- Sovereignty: the state of the deployment's key-protection backend, from declared, bound, activating, bound but not corroborated, to configured. It is a configuration state, not a liveness check; a backend that is merely unreachable is still configured.
- Modernization: the number is 100 minus the share of active keys carrying quantum debt; the status is whether those classical keys have a post-quantum rotation target, so debt alone never fails the pillar. Its breakdown offers View PQC migration, which moves you to the PQC migration band.
- Governance & Compliance: one pillar read two ways. The headline is conformance: of the keys of tenants that declared an algorithm template, how many still use a permitted algorithm. The second line is declaration: how many tenants have at least one explicit policy template, and how many are unmeasured because they declared none. The status is the worse of the two readings, each graded against its own served threshold. Its breakdown shows both.
- Enterprise Readiness: how many integration families this deployment is connected to, out of the families whose state the server reports. It is not a ratio and has no threshold. A family is connected when the server reports it active; one that is not applicable to this deployment type, or that you may not read, is outside the count and named as such. Geolocation and licensing report no status and are not measured. The card turns amber only when a configured family is not operating. Selecting it opens the integration topology.
Tenants with no algorithm template cap a green conformance at amber, and a key whose algorithm cannot be classified counts against conformance. The families Enterprise Readiness counts are key protection, timestamping, identity federation, workload identity federation, email and notifications, SIEM/XDR forwarding and observability export.
Posture Trend plots Crypto-Agility, Modernization and Governance & Compliance, the last drawn from its conformance reading, over the last 90 days of daily snapshots taken at 02:00 UTC; Sovereignty and Enterprise Readiness are not ratios and have no line. It shows Collecting baseline until two snapshots exist. The projection to 100% and its confidence are rendered only as the server states them, one per reading, so the declaration projection and the conformance projection of Governance & Compliance are named apart.
Reading the platform at a glance
- Services: services available of services probed, as the System Health screen counts them, with host memory and disk use; unavailable, degraded and unmeasured services are named when there are any, and the card says when the evaluation was taken and whether the server considers it stale. View System Health opens the detail.
- Tenants: the tenants listed on the Tenants screen, with how many are active and how many suspended, and provisioning or closed ones when there are any.
- Users: the non-deleted users of those tenants, including invitations pending activation, and how many are pending.
- Keys: the keys that have current material and were not deleted, in every status, with how many are active, rotated and revoked, and expired ones when there are any. Rotated keys are a subset of active keys.
- Crypto operations: the cryptographic events of the last 30 days, with the share that succeeded and how many failed. The days are UTC days ending today; the card prints the window the server applied.
Reading the activity band
Cryptographic operations per day is drawn from the daily audit totals over the same window as the Crypto operations card, every day of it, with a day that recorded nothing drawn at zero. Encrypt/Decrypt counts ENCRYPT and DECRYPT events and Sign/Verify counts SIGN and VERIFY; every other operation is counted in the card's total and drawn in neither line. The daily series does not separate successes from failures.
Top tenants by operations lists up to eight tenants with the most cryptographic events in that same window, busiest first. Its window is printed above the list.
Reading the tenant matrix and alerts
Tenant Organization lists your tenants with their type, applications, keys, active keys, PQC % of active keys, Ops (total), their posture verdict and their conformance. Ops (total) is read from the ten tenants with the most cryptographic events over the whole history, from the statistics snapshot whose age the card header shows: a tenant outside that ten reads —. It is not the window of the Activity band.
The caption counts tenants whose verdict is At Risk; a tenant with no verdict is neither. Expanding a row shows its algorithm, rotation and lifecycle templates and whether each is tenant-assigned, deployment-locked or inherited.
Platform Alerts is composed on this page from the reports above: expired keys, keys past their soft expiration, keys at their usage threshold, revoked keys, classical keys whose migration priority is CRITICAL, and keys expiring within seven days. All keys are healthy! means all six counts were zero.
Reading the PQC migration band
Key Distribution by Algorithm Family splits the active keys into Classical, PQC and HYBRID. A symmetric key is in Total but in no slice, so a platform holding only AES keys shows an empty ring over a non-zero total.
PQC Migration Readiness rings the post-quantum and hybrid share of active keys and lists the active classical keys by migration priority; Legacy Keys Remaining is their count. PQC adoption per tenant orders tenants ascending, laggards first, with display bands at 40% and 70% that are not posture verdicts. Strategic Recommendations restate the same counts as actions, and each opens the Analytics screen.
Opening recent activity
Recent activity shows the newest ten administrative and the newest ten cryptographic events of the platform stream, in two tabs. Selecting a row opens the event's details.
How it relates to other screens
The matrix rows, the tenant counts and the names on this page are the tenants of the Tenants screen, where they are created and moved through their lifecycle:
The Sovereignty pillar and the setup banner above the posture band read the key-protection backend's state; the Services card reads the System Health document:
Enterprise Readiness counts the deployment planes the integration topology draws, one per family:
A tenant administrator sees the same posture model over one tenant, on the Dashboard, without Enterprise Readiness: