AZT Protect

Overview orients the operator within a single plant before any issue is opened. Plant operating areas sit with endpoint, protection, attention and offline summaries, the threat surface, an exposure ranking, recent activity and operations status, so location and security context are read together.

Status and severity carry separate meanings here. An offline endpoint is a reporting question, while a severity value describes how serious a finding is, and the layout keeps the two from collapsing into one number.

All Sites lets an operator compare the organisation's plants and choose where to investigate. A world map is paired with an equivalent plant table listing reported protection, endpoint totals, alerts and last-seen time, with a focused panel for the site needing attention.

Last-reported data that has gone stale is presented as unknown current status, not as proof that protection has been lost. The locations and figures in this view are fictional illustrative content, not a Pfizer engagement or deployment.

Endpoints is the fleet overview. Protection, attention and offline summaries sit above a grouped endpoint map, with an attention panel naming the priority device, why it needs review and its latest event, and a ranked list of the endpoints most at risk below.

The screen is built for triage: it prioritises which device to look at next and routes into device inspection. The ranking uses illustrative weights rather than a validated security score.

Zones explains how the site's endpoint fleet is grouped. Six operating areas, Engineering, Production, Robotics, Paint Shop, Packaging and Utilities plus Control, are drawn as workcells connected to the Trust Center, with attention and offline counts on each group and a priority endpoint panel bringing the next investigation into focus.

Zones draws the plant's operating areas as workcells connected to the Trust Center, while Endpoints draws the same groups as their devices, so each view answers a different question. The accompanying risk ranking is prototype prioritisation for the design, not a validated security score. The view describes grouped endpoint coverage and does not offer network segmentation or rule editing.

Network traces relationships between site, Trust Center, operational group, endpoint, application and event. Plant topology is paired with the selected group's protection scope, inherited policy, signals and reporting status.

A relationship list gives the same content in words and routes toward endpoint, policy and investigation context, so nothing depends on reading the diagram. It shows reported relationships rather than live packet inspection.

Vulnerability Radar prioritises findings while keeping assessment coverage visible. The radar groups critical, high and medium findings alongside affected endpoints, checked versus pending endpoints and assessment freshness.

A priority review queue names the device and the finding, and a check-status panel makes incomplete coverage explicit. This is distinct from the dashboard threat surface, and it is a simulated prototype with no connected live vulnerability feed, no scan engine and no automatic remediation.

Inventory Summary answers what the estate is made of and whether that record is current. A device-class catalogue covers workstations, PLCs, servers and HMI panels, with application and endpoint totals, the operational-group footprint and last-seen freshness supporting device-context follow-up.

Utilities and Control are combined in this view and labelled as such. The figures describe composition and freshness, not a count of vulnerabilities.

The Trust Center is the management plane. Enforcement happens locally, at the Trust Agent on the endpoint. That separation shapes the whole journey: an operator can inspect an event and record a review without the interface suggesting that protection has been changed.

Policy coverage is shown as an assignment structure rather than a single toggle, so an exception can be read against the group it inherits from.

The investigation screen places the execution timeline beside application context and policy impact. Endpoint, application and policy links give routes to supporting detail without leaving the event.

TrustID detail compares the trusted baseline with the observed execution, so the reason for the block is legible before anyone decides what to do about it.

The confirmation states plainly that the executable remains blocked and that application trust and endpoint policy are unchanged. Cancel and confirm are explicit actions.

This is the key decision of the project. Recording a review documents that someone looked at the event. It never grants trust, unblocks an executable or changes protection on the endpoint.

The mobile view brings the timeline and the review action forward. Supporting information moves into a narrower sequence instead of shrinking the desktop dashboard, and status words accompany colour throughout.

The same consequence wording travels with the action, so the smaller screen never loses the distinction between reviewing and enforcing.

Beneath the site comparison, a regional view carries one plant's location context, last-reported protection and the next connectivity check, and a site risk page separates assessment coverage from findings.

Both keep the same rule as All Sites: stale reporting is unknown data, and coverage that is incomplete says so.

Reusable status and action families, policy-domain controls and connected review states, documented as one architecture across the console.

Desktop, tablet and mobile compositions covering monitoring, investigation, review and recovery, with an interactive prototype of the investigation and review sequence.