For years, cyber-physical systems security was shaped by one dominant word: visibility. The promise was straightforward. If we could see more assets, map more devices, identify more protocols, and extend coverage deeper into operational environments, we would naturally become safer. In its first phase, that model was not only useful but essential, especially in healthcare, where connected medical devices, OT systems, gateways, ward workstations, and hybrid biomedical-ICT components created a complex and uneven attack surface.
Today, however, the visibility paradigm is reaching its limit. Visibility remains necessary, but it is no longer the destination. Mature organizations already operate multiple tools that observe the same environment from different perspectives. They have telemetry, inventories, passive discovery, security consoles, vulnerability feeds, and local operational records. Yet even with all that observation, the feeling of control does not rise proportionally. In many cases it declines. The reason is simple: seeing more does not mean understanding better, and understanding better still does not guarantee better decisions.
Inside a hospital, the same asset can be described differently by different systems. An IoMT platform may identify it as a medical device and understand its clinical role. A passive sensor may capture its flows and protocols. A CMDB may preserve only an administrative or historical name. A vulnerability feed may attach CVEs, known exploited vulnerabilities (KEVs), or exposure indicators to it. A security operations center (SOC) may treat it as a lateral-risk node, while clinical staff experience it as a crucial component in patient care.
None of those representations is false. The problem is that none of them is sufficient on its own. When dashboards disagree on the number of assets, when one console reports a severe issue and another downplays it, when technical severity does not match operational severity, the CISO does not have a discovery problem. The CISO has a governed-truth problem. And if truth is not governed, risk cannot be prioritized in a credible way.
The canonical asset—a singular digital representation of an asset—is a critical maturity step. It means we stop treating every discovery record as an isolated object and begin reconciling identity: one physical device, many sources, one governed representation. This layer introduces provenance, confidence, precedence rules, and conflict traceability. But once the organization knows what the asset is, the decisive question remains unresolved: how risky is this asset, here and now, for this organization?
That answer cannot be derived automatically from a CVSS score or from a single technical indicator. In healthcare CPS, risk is never just the arithmetic of vulnerabilities. It is the relationship between real exposure, clinical criticality, care-path relevance, service disruption potential, existing compensations, network segmentation, vendor supportability, and the maintenance reality of medical operations. Two devices with the same vulnerability can mean very different things if one sits in a critical intensive-care workflow and the other in a marginal administrative corner.
This is where the concept of canonical risk becomes necessary. If the canonical asset tells us what the object is, canonical risk tells us what that object means in terms of action. It is not a cosmetic score and not a simple average of pre-existing values. It is a governed, explainable, and auditable synthesis of technical signals, operational context, and explicit priority logic.
In practice, canonical risk should compose at least four families of inputs.
The first is technical exposure: known vulnerabilities, KEVs, reachability, insecure connectivity, weak configurations, and lateral movement potential
The second is clinical and operational context: patient impact, service continuity, departmental dependency, maintenance windows, and replaceability
The third is control context: segmentation, monitoring, compensating controls, manual fallback procedures, and containment capability
The fourth is the decision layer itself: the rules by which the organization determines what to remediate first, what to accept temporarily, what to escalate, and what to watch more closely
This is precisely where ASL Roma 1’s Healthcare Operational Protection & Excellence (HOPE) can express its most original value. Not as a platform that replaces security tools, the CMDB, the SOC, or asset-discovery tools, but as a higher-order layer that composes meaning. HOPE can absorb partial truths from source systems, build the canonical asset, apply contextual weighting rules, and generate a motivated canonical risk.
That changes the conversation. A traditional dashboard tells you that you have 100 vulnerable assets. A mature decision layer tells you which 10 truly deserve priority, why they deserve it, what evidence supports that conclusion, how quickly action is needed, and what type of action makes sense. More importantly, it allows the organization to explain that decision to executives, engineers, clinicians, and auditors. Governance begins the moment priority is no longer an impression created by a console, but the traceable result of explicit rules.
In many healthcare environments, the volume of alerts, reports, dashboards, and vulnerability lists produces a paradox of hyper-visibility: everything appears important, and therefore nothing becomes truly actionable. Action fragments, teams compete over urgency, leadership receives inconsistent messages, and remediation drifts away from actual risk. Canonical risk is meant to break that paradox.
Its purpose is not to eliminate complexity but to make complexity governable. A good canonical-risk model does not hide disagreement between sources. It absorbs it, weighs it, contextualizes it, and turns it into operational priority. Once that happens, the organization can stop arguing over which tool is right and start asking which action is most sensible, sustainable, and protective for care delivery.
The most important leap is cultural as much as technical. In healthcare, cyber teams and clinical teams often speak different languages. The vocabulary of vulnerabilities, exploits, telemetry, and threat feeds does not naturally align with the vocabulary of care pathways, service criticality, and patient safety. If HOPE is designed as a decision layer, it can become a shared grammar.
It does more than translate technical risk into a color-coded status. It creates an explicit relationship between exposure, impact, and responsibility. In that sense, canonical risk is not only an operational mechanism; it is a governance object. It formalizes the logic of decision-making, preserves exceptions over time, supports guided risk acceptance, and holds together security, compliance, and clinical sustainability.
The next maturity level for CPS security will not be defined by who can see more devices. It will be defined by who can make better decisions about the assets already in view. After visibility and after the canonical asset, the real threshold of maturity is canonical risk. That is the point at which cybersecurity stops being only an observational discipline and becomes a discipline of governed priority. That is also where HOPE can truly differentiate itself: not as another screen, but as the engine that turns plural signals into one coherent, explainable, and defensible decision.
In a healthcare ecosystem where every device matters, every maintenance window is delicate, and every choice can affect continuity of care, the real advantage will not come from possessing more data. It will come from composing the right truth at the right time and turning it into an action that can be defended, audited, and executed.
Stefano Scaramuzzino is the cybersecurity team leader and network and information systems manager, for ASL Roma 1, Italy's largest local health authority.
A partner at Deloitte Italy Cyber Risk Services, Battelli has 25 years consulting experience with a specific focus on ICT/Cybersecurity where he is well-recognized trusted advisor and subject matter expert in critical infrastructure protection (CIP).