Jailbreak Detection

Jailbreak Detection finds Android and iOS devices that have been rooted or jailbroken, and lets an admin act on them. A rooted or jailbroken device has had its built in security stripped away, so it is far easier for malware or unapproved apps to reach corporate data. The ask from the product team was direct: scan the managed devices, find the compromised ones, and take action against them, because a jailbroken device should not sit quietly inside the fleet.

The moment I started sketching, it was clear the feature was really two jobs stitched together. One is detection, working out which devices are compromised. The other is remediation, deciding what happens to a device once it is flagged. Almost every decision on this project came back to keeping those two jobs clear in the admin's head.

The requirement told me what actions to take on a jailbroken device, but it never said how a device would be found in the first place. Detection was assumed, not designed. So I had to work backwards from the actions and figure out the scanning side myself.

That gap is where most of the thinking went. The enforcement actions were known. The detection, the scheduling, and the language around it did not exist yet, and that was mine to define.

Talking through how an admin would actually use this, two journeys kept showing up. In the first, the admin already knows a device is compromised. Maybe a previous compliance scan flagged it and nobody acted, maybe someone reported it, maybe they checked the device in person. Here scanning is beside the point. They just want to select the device and apply an action.

In the second, the admin has no idea which devices are affected. The flow has to start with a scan, then let them review what came back and act on it. I designed the feature so both paths were first class, so an experienced admin was never forced to scan when they already knew the answer.

Before any screen, I had to decide where Jailbreak lived in the product. It is an administrative security capability with a fair amount inside it, so I placed it under Admin, in the miscellaneous area, right alongside Geofencing. Following the same placement and patterns we had just shipped for Geofencing meant admins did not have to learn a new mental model.

Inside, I split it the same way Geofencing was split: one section for detection and one for the actions taken afterward. Separating the two kept each screen focused and matched how admins already think, which devices are compromised versus what should happen to them.

I wireframed both journeys end to end before touching any visuals. The first board is the direct path, selecting a compromised device and choosing an action like quarantine. The other two are the scan first path, where I worked through scheduling a scan, reviewing the results, and applying actions to whatever came back non compliant.

Here is the twist. I had designed a whole scanning section, schedule a scan, set a frequency, pick recurrence, attach actions. Then I sat down with the engineering team and understood the backend properly. The scan was going to run on its own in the background. Admins were never going to schedule it.

So I removed the entire scanning interface. It looked like a feature, but it was configuration for something the system already handled invisibly, and every control on it was cognitive load with no payoff. The final design kept only what an admin genuinely needed to decide: what should happen when a device is found compromised. Cutting my own work here was the right call, and it made the whole feature simpler.

Because detection now happened in the background, there was no single Jailbreak page to send people to. Instead I surfaced the status where admins already spend their time. The Devices page got a Jailbreak Status column, and each flagged device opens a detail view of exactly which checks failed and which passed.

The part that stayed is compliance enforcement, where an admin decides what a jailbreak actually triggers. Everything lives in one list, and creating a setting walks through targeting device groups, choosing whether to act on compromised or potentially compromised devices, and picking the actions themselves.

The hardest and most interesting part of this project was that there was almost no UI to look at. Competitors like ManageEngine and VMware Workspace ONE talk about jailbreak and root detection, but there were very few real interfaces for configuring it. So the interaction model and the information architecture had to come from first principles, from the backend capabilities, and from the patterns already in our product.

What I keep from it is the value of cutting. I designed a full scanning experience and then removed it once I understood the system underneath, and the feature was better for it. Designing a backend capability is less about drawing screens and more about deciding where a mostly invisible process should surface, and trusting that a simpler surface is usually the right one.