OTORIO / OT Security Platform
Designing a remote upgrade flow and an audit log for air-gapped OT environments.
OTORIO is an OT security platform, later acquired by Armis in 2025.
Two kinds of users depend on the remote access product. The Operations person keeps assets connected and up to date, and software updates meant shutting down the system and involving OTORIO's dev team. The Site Manager oversees multiple sites, and with no audit log had no way to see who accessed what, when, or prove compliance to an auditor.
User flows
The path each user takes through the product.
Operations person
Site Manager
I interviewed CS, Dev, and DevOps to map what was technically possible, and defined error states throughout the flow so the user is never left guessing. I also interviewed customers who work with audit logs daily to understand which filters they actually need, and in what order they search.
No published flows exist for air-gapped OT upgrades.
DevOps and Dev each had a partial picture. I mapped the flow before designing anything.
Researched comparable systems to define what gets surfaced by default.
Real-time status per server, not a final summary. Filters follow the investigation order: user and time first, asset as a second layer. The user arrives knowing what they're looking for.
Two capabilities, one platform, each designed for a different trigger. The Site Manager arrives after an incident, looking for answers. The Operations person arrives after a notification, an update is ready and needs to run.
Responsible for keeping assets connected and up to date, hardware updates, connectivity checks, system upgrades.
"I need to know what needs updating, and be able to do it without calling anyone."
Oversees multiple sites and needs to verify everything is running correctly, no unusual connections, no anomalies.
"I need to know that nothing happened that shouldn't have."
An upgrade shuts the system down, one account at a time. So every step has to feel deliberate.
Two upgrade paths at equal weight: Azure Storage or manual file upload. In air-gapped environments, the file upload path isn't a fallback.
"Update required" vs "Up to date" is pre-calculated before the user arrives. The user sees a decision, not a diagnostic. Local Servers and Connectors listed separately, each with its own status.
The process runs in the background. The user doesn't wait: a minimized notification keeps them informed without locking the interface.
The Site Manager arrives after something happened. They need answers fast.
Everything that compliance documentation requires is logged: that's a lot of data. Defaulting to 7 days prevents the Site Manager from arriving to an overwhelming table.
Asset and connector as a second layer.
Primary filters
Easy by default, complete on demand.
One confirmation modal, no reconfiguration.
A software upgrade of the remote access product was cumbersome: it took several days and required development time. Mapping the flow with the developers and DevOps showed what was broken in it, which had not been clear until then.
The design lets the Operations person, who keeps each site's systems up to date, run an upgrade alone, remotely. Every step shows what is happening, so there is no need to call anyone.
Before, there was no way to see who accessed what, and when, or to prove it to an auditor. The design lets the Site Manager, who oversees several sites, find the event and export the record as proof from one screen.
The aim was that the user is never left uncertain: what is updated, what needs an update, and how long it will take. A time estimate was hard to give, and the design works within what the system can show.
A user running a remote upgrade on an air-gapped factory needs to know exactly what failed and why. That was one of the first things I designed, not the last.
