Deployment
A small app goes onto each laptop and a setting goes to the browser. Everything after that is a dial you turn when you are ready.
Who sets it up
What goes onto the laptop is the same in all three. The only difference is who sends it out.
If you already push software to laptops, this goes out the same way as everything else you send.
Takes about an afternoon.
No IT team and no fleet tools? Staff install it themselves and sign in, and it knows who they are from your existing accounts.
Takes an afternoon, spread over a week.
In parts of Europe, staff representatives have to agree before anything is installed. That conversation sets the date, not the install.
Takes as long as they need. Start it early.
Prerequisites
Four things from you, and the first one is the only one that can hold up a date. Tell your staff before anything is installed, in writing.
From you
From us
Installing it
Four steps, in this order. Nobody has to touch the laptop in person and nobody has to restart anything.
Policies configured for your industry and connected to the accounts your staff already sign in with. Nothing has touched a laptop yet.
One download per platform, through whatever you already use to send software. It works straight away, with nothing else to install.
Mac Windows Linux
A small file that turns on the browser part. Each browser your staff use needs its own, which is the step most often missed.
Chrome Edge Firefox Safari
Laptops start appearing in your console within the day, and it tells you which ones are properly covered rather than just installed.
Itzal asks for no access to files, screens or anything else on the laptop. The browser part needs no special permission at all, which is the main reason a rollout goes through without a security review stopping it.
Methods
There is no hardware, no network change and nothing to put in front of your traffic. If you can send an app to a laptop today, you can send this one.
| If you use | How it goes out | Good for |
|---|---|---|
| Jamf, Kandji or Intune | As a managed app, with the browser setting attached | Mac laptops |
| Intune, SCCM or Group Policy | As a managed app, the usual way | Windows laptops |
| Ansible, Puppet or Chef | As a package in your existing playbook | Linux machines |
| None of the above | A download link; staff install it and sign in | Teams without IT tooling |
Rollout
Itzal only watches for the first couple of months, so you can see what your staff are actually sending before you decide to stop any of it.
In writing, before anything is installed.
Before you start
Around a hundred people from different teams.
Weeks 0–3
The whole company, with nothing blocked yet.
Weeks 3–9
A quiet note before something sensitive goes out.
Weeks 9–13
Only the places you have decided against.
From week 13
Watching Warning Blocking Typical timings; you decide when each stage starts.
If a lot of people click past the warnings, the warnings are firing when they should not. Fix the detection, not the message.
Telling people
This lands much better coming from you than from us. Staff who hear about it from their own employer first take it as a policy; staff who meet it as a surprise banner take it as surveillance.
What is being added and why. What it looks at, and what it does not: no browsing history, no recording what people type, nothing from personal devices, and none of the actual text leaving the laptop. Say who can see the results and how long they are kept.
Whether they can see what their own team is doing. By default they cannot, and saying so out loud matters, because the assumption when nobody mentions it is that they can see everything.
The one thing that predicts a rollout going well is whether staff heard about it from their employer before they saw it on their screen.
Checking it works
Your console answers all four of these. Only the last one tells you the thing you actually want to know, which is why it is the number we report against.
Tells you a little
The app arrived and the browser setting is in place.
Tells you a bit more
It is switched on and talking to your console.
Tells you most of it
Staff can see for themselves, from the icon in their browser.
Tells you the whole thing
The console confirms it is reading the actual tools your staff open, not just sitting there. A site can redesign itself and quietly break this, and this is the only check that notices.
Worth agreeing before the pilot
| What to watch | Aim for | What it tells you |
|---|---|---|
| Laptops properly covered | 98% or better | Whether it is actually deployed |
| Warnings that were wrong | Under 1 in 10 | Whether your team will trust it |
| People clicking past warnings | Under 1 in 3 | Whether your staff will |
| Time to look at a finding | Within a day | Whether anyone can keep up with it |
The number of alerts is not on that list on purpose. A big number might mean a leaky company or a noisy tool, and the number on its own cannot tell you which.
If something is wrong
All four look fine from the laptop, which is why they are worth knowing about. A support engineer answers within a business day on every plan, and the console flags the first three for you.
What it runs on
The last two rows are the ones most products leave off a page like this. They are here because you will find them in a pilot anyway.
| Where | Status |
|---|---|
| Laptops | |
| Mac | Works |
| Windows | Works |
| Linux | Works |
| Browsers | |
| Chrome and Edge | Works |
| Firefox | Works |
| Safari | Partly |
| Not covered | |
| Phones and tablets | Not covered |
| Personal devicesDeliberately, not yet | Not covered |
Start a pilot
Fifty laptops, two weeks, nothing blocked
One of our engineers sets it up with you and stays while you tune it. Pick the team that uses AI tools the most, and you will know inside a fortnight whether this is worth doing.
Book a technical demo