The same platform, seven different sets of constraints

Attackers do not maintain a separate playbook per industry. Ransomware, credential theft, lateral movement and insider misuse arrive in a hospital much as they arrive in a bank. What differs is everything around the attack: what is worth taking, what breaks when it is disrupted, who audits the response, and what the organisation is permitted to do about it automatically.

Four variables account for most of it. The first is the asset class. A bank's crown jewels are payment rails, settlement systems and customer identities. A hospital's are electronic medical records and clinical devices that cannot be patched or taken offline. A utility's are substations and control systems where the consequence of disruption is physical rather than financial.

The second is the regulator, and specifically what it wants evidenced. RBI, PCI-DSS, SEBI and IRDAI shape a banking deployment. NERC CIP and IEC 62443 shape an energy one. Data protection law shapes healthcare and government. These are not badges to display; they determine which evidence has to be collected continuously rather than assembled before an audit.

The third is tolerance for autonomous action, and it varies more than anything else. Isolating a compromised laptop in a bank's back office is straightforward. Isolating a clinical workstation mid-procedure, or issuing any command that touches a safety-instrumented system in a plant, is not. This is why the governance envelope is configured per environment rather than shipped as a default.

The fourth is the IT and OT mix. An organisation whose estate is entirely IT has one collection problem. One with a plant floor, a substation or a fleet of medical devices has two, and needs them on a single investigation rather than in two consoles.

Underneath those four variables the platform does not change. The same SAGE™ model reasons about the telemetry, the same AuraXP™ agents run the investigation, the same AirWatch™ policy bounds what may happen without a human, and the same case carries the evidence. Sector specialisation here means configuration, baselines and evidence mapping, not a different product with a sector name on it.

That matters commercially as well as technically. A platform that ships genuinely different code per vertical accumulates versions that diverge, and the sector with fewest customers gets the least attention. One platform configured per sector does not have that failure mode.

Three of the seven, manufacturing, energy and utilities, and defence and aerospace, carry an operational technology estate, and that changes the mechanics of collection rather than just the emphasis.

In an industrial network, availability outranks confidentiality, most protocols were designed before authentication was a consideration, and equipment commissioned fifteen years ago may be supported for another decade without ever being patchable. Active scanning has caused outages on production control systems, so Spharaka Signal™ collects passively from a SPAN port or network tap by default and reads industrial protocols at register level. The OT cybersecurity section covers that subject properly, including the Purdue model, the protocol families and the standards.

Defence and aerospace goes further still: classified and disconnected networks mean the reasoning model has to run locally or the platform is useless. That is a deployment constraint, and it is the reason SAGE™ is small enough to run in your own data centre.